Re: Properties question ( again? )

2004-01-19 Thread J.Pietschmann
Andreas L. Delmelle wrote:
fop.fo.flow.Table
line 157:CommonBackground bProps = propMgr.getBackgroundProps();
line 193:this.BackgroundColor =
this.propertyList.get(PR_BACKGROUND_COLOR).getColorType();
I thought porpertyList had been retired in HEAD?

How should I see this? Is one of the two superfluous? Do they complement
each other? Shouldn't the latter be rewritten as :
this.BackgroundColor = bProps.backColor
I'd think so.

J.Pietschmann


RE: Properties question ( again? )

2004-01-19 Thread Andreas L. Delmelle
 -Original Message-
 From: J.Pietschmann [mailto:[EMAIL PROTECTED]
 
  
 I thought porpertyList had been retired in HEAD?
 

That's what I initially thought, but got a bit confused...

  Shouldn't the latter be rewritten as :
  
  this.BackgroundColor = bProps.backColor
 
 I'd think so.
 

Ok. Probably means reviewing a few patches submitted recently.

Thanks for the quick response.


Cheers,

Andreas



Re: Properties question ( again? )

2004-01-19 Thread Finn Bock
[J.Pietschmann]

I thought porpertyList had been retired in HEAD?
PropertyListBuilder was recently removed from HEAD.

[Andreas L. Delmelle]

How should I see this? Is one of the two superfluous? Do they complement
each other? Shouldn't the latter be rewritten as :
this.BackgroundColor = bProps.backColor
That is also my feeling.

regards,
finn


RE: Properties question ( again? )

2004-01-19 Thread Glen Mazza
Please fix it whenever you get write access.

Glen

--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
   Shouldn't the latter be rewritten as :
   
   this.BackgroundColor = bProps.backColor
  
  I'd think so.
  
 


__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


Re: Properties Implementation and Canonical Mappings

2003-12-01 Thread John Austin
On Mon, 2003-12-01 at 02:45, Glen Mazza wrote:
 --- John Austin [EMAIL PROTECTED] wrote:
  
  The property strings are given to the Property
  object
  constructor by some path beginning with a SAX
  parser.
  It is reasonable to assume that the SAX parser loses
  refs to most of these strings and that the Property
  implementation retains the only references to these 
  String objects.
  
  How big are String Objects ? 
  At least 16 bytes plus storage for characters. 
  
  What does this save us ? 
  Probably only about 1,600,000 bytes for this file. 
  CPU cost of creating strings is probably similar to 
  cost of checking string table for a copy.
  
 
 Just to clarify, the (additional?) CPU cost you
 mentioning above is *not* occurring for the present
 process, correct?  I think you're referring to the
 cost that would be added as a result of the changes
 you're recommending (because there now will be a
 string table search to avoid duplication).

Going back to the beginning of my involvement, I found this
issue because Property searches are the high-runner for CPU
in FOP. I don't want to split hairs in isolation over which
search/constructor sequence is faster. I want to remove the
conditions that cause the current pathology.

Hash table lookups are FAST. When we invest in object creation
we recover many times over in the end. 

 Also, the string table you mention--I think you're
 speaking generically, but is there a specific, already
 available construct in Java that we can use for this
 purpose in FOP?  I'd like to find out what you have in
 mind for a specific implementation.

HashMap works fine the way Peter has it set up in alt-design.

I use the same construct in the Perl code I use to analyze the
large sample FO files.

-- 
John Austin [EMAIL PROTECTED]


Re: Properties Implementation and Canonical Mappings

2003-11-30 Thread John Austin
Input: The XSL-FO file produced from:
DocBook: The Definitive Guide 

Document size:   648 Pages  // for the O'Reilly edition
FO file size:   21,659,370 bytes
Properties: 526,648
Tags:   285,223
Height of tree: 17   // max height of the parse tree
Unique prop names:  117  // bounded by the spec
Unique prop values: 13,520   // bounded by the real world

Using these numbers, we can explore the sort of benefits to expect
from revised Property implementation. With over a million strings,
the FOTree for this document would use forty or fifty Mb in addition
to data structures. 

This document can be used as an example even though it probably
can't be formatted (yet) by FOP. It has a lot of tables. It could 
be a goal of the FOP project to generate this well-known document.

I was thinking of using the XSL-FO spec from the W3C web site but
couldn't find the stylesheet to make the FO file. If anyone knows
where to find them, please let me know.

Statistics from this file:

Number of Elements by tree level:
level=1 count=1
level=2 count=473
level=3 count=5242
level=4 count=5480
level=5 count=7129
level=6 count=26231
level=7 count=22475
level=8 count=36447
level=9 count=62288
level=10 count=38536
level=11 count=30486
level=12 count=23641
level=13 count=23190
level=14 count=2023
level=15 count=771
level=16 count=701
level=17 count=109

Element frequencies:
a 24 I wonder where this came from 
fo:basic-link 5225
fo:block 112142
fo:conditional-page-master-reference 48
fo:external-graphic 1097
fo:flow 472
fo:footnote 22
fo:footnote-body 22
fo:inline 62792
fo:layout-master-set 1
fo:leader 1764
fo:list-block 279
fo:list-item 1004
fo:list-item-body 1004
fo:list-item-label 1004
fo:marker 5335
fo:page-number 1872
fo:page-number-citation 3224
fo:page-sequence 472
fo:page-sequence-master 12
fo:region-after 38
fo:region-before 38
fo:region-body 38
fo:repeatable-page-master-alternatives 12
fo:root 1
fo:simple-page-master 38
fo:static-content 4720
fo:table 6497
fo:table-body 6497
fo:table-cell 33174
fo:table-column 19225
fo:table-footer 1
fo:table-header 29
fo:table-row 15301
fo:wrapper 1799

Properties: 526648
Tags: 285223
num_keys: 117
num_vals: 13520


-- 

John Austin [EMAIL PROTECTED]


Re: Properties Implementation and Canonical Mappings

2003-11-30 Thread Glen Mazza
--- John Austin [EMAIL PROTECTED] wrote:
 
 The property strings are given to the Property
 object
 constructor by some path beginning with a SAX
 parser.
 It is reasonable to assume that the SAX parser loses
 refs to most of these strings and that the Property
 implementation retains the only references to these 
 String objects.
 
 How big are String Objects ? 
 At least 16 bytes plus storage for characters. 
 
 What does this save us ? 
 Probably only about 1,600,000 bytes for this file. 
 CPU cost of creating strings is probably similar to 
 cost of checking string table for a copy.
 

Just to clarify, the (additional?) CPU cost you
mentioning above is *not* occurring for the present
process, correct?  I think you're referring to the
cost that would be added as a result of the changes
you're recommending (because there now will be a
string table search to avoid duplication).

Also, the string table you mention--I think you're
speaking generically, but is there a specific, already
available construct in Java that we can use for this
purpose in FOP?  I'd like to find out what you have in
mind for a specific implementation.

Thanks,
Glen

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


Re: Properties Implementation and Canonical Mappings

2003-11-29 Thread J.Pietschmann
John Austin wrote:
In the interest of contributing (instead of just
trashing) to the proposed implementation, I wrote 
a simple Perl script to get some counts out of a 
real-world XSL-FO file.

Input: The XSL-FO file produced from a DocBook file
I have left from a dormant project. The perl program 
counts the number of properties in the source file.

PDF size:   130 Pages  // some users have a lot more
FO file size:   1.2M bytes
Properties: 22,815
Unique prop names:  89  // bounded by the spec
Unique prop values: 2,227   // bounded by the real world
Note that storing the property name and value refs supplied
to the Property constructor will use 45,620 strings. If the
Property implementation employs canonical mapping to ensure
that only one copy of each unique string is stored, then just
over 2,300 strings are required. 

The property strings are given to the Property object
constructor by some path beginning with a SAX parser.
It is reasonable to assume that the SAX parser loses
refs to most of these strings and that the Property
implementation retains the only references to these 
String objects.

How big are String Objects ? 
At least 16 bytes plus storage for characters. 

What does this save us ? 
Probably only about 1,600,000 bytes for this file. 
CPU cost of creating strings is probably similar to 
cost of checking string table for a copy.

What does it buy for us ?
Bounds a source of current Order(n) memory growth. 
It gets us in the habit of using another good technique.

I am all ready thinking along the lines of:
The property lists for these FO's are usually generated by
programs and will be the repeated many times. Perhaps we
could use larger, faster working Property Lists consolidated with
Canonical Mappings to save both time and space.
I am thinking again along the lines of handling properties more
like C++ virtual function table (vTable). This object is larger
than Peter's ordered Property array, but would be faster. 
That's a reason C++ has fast virtual function dispatching.




Re: Properties Implementation and Canonical Mappings

2003-11-29 Thread J.Pietschmann
Darn, racall the last post.

John Austin wrote:
Note that storing the property name and value refs supplied
to the Property constructor will use 45,620 strings. If the
Property implementation employs canonical mapping to ensure
that only one copy of each unique string is stored, then just
over 2,300 strings are required. 
Have a look at String.intern()

J.Pietschmann




Re: Properties Implementation and Canonical Mappings

2003-11-29 Thread John Austin
On Sat, 2003-11-29 at 16:35, J.Pietschmann wrote:
 Darn, racall the last post.
 
 John Austin wrote:
  Note that storing the property name and value refs supplied
  to the Property constructor will use 45,620 strings. If the
  Property implementation employs canonical mapping to ensure
  that only one copy of each unique string is stored, then just
  over 2,300 strings are required. 
 
 Have a look at String.intern()

Bruce Eckel said not to trust it for some reason. I have 2nd Ed
of Thinking in Java and the online one is 3rd Ed so I haven't
found chapter and verse for this yet. 

The only 'bad thing' said about it that I could find quickly was:

http://mindprod.com/jgloss/gotchas.html

The other good thing we can do is  compare these string refs for
equality.


 J.Pietschmann
-- 
John Austin [EMAIL PROTECTED]


Re: Properties of PDF Documents

2002-10-02 Thread Oleg Tkachenko

Ing. Atilio Ranzuglia Buteler wrote:
 i'm looking for information about the following:
 
 - is the any way in securing a pdf document. to prohibit
 that a user selects and copies the text?
 
 - can the printer be selected from the pdf document?

I doubt this has something to do with fop, look for info about pdf format at 
planetpdf.com, for example.

-- 
Oleg Tkachenko
Multiconn International, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Properties of PDF Documents

2002-10-02 Thread Ing. Atilio Ranzuglia Buteler

the thing is that i'm producing the pdf document with fop,
otherwise i'll be looking for information about the pdf
specification


--- Oleg Tkachenko [EMAIL PROTECTED] wrote:
 Ing. Atilio Ranzuglia Buteler wrote:
  i'm looking for information about the following:
  
  - is the any way in securing a pdf document. to
 prohibit
  that a user selects and copies the text?
  
  - can the printer be selected from the pdf document?
 
 I doubt this has something to do with fop, look for info
 about pdf format at 
 planetpdf.com, for example.
 
 -- 
 Oleg Tkachenko
 Multiconn International, Israel
 
 

-
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, email:
 [EMAIL PROTECTED]
 


__
Do you Yahoo!?
New DSL Internet Access from SBC  Yahoo!
http://sbc.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Properties of PDF Documents

2002-10-02 Thread Oleg Tkachenko

Ing. Atilio Ranzuglia Buteler wrote:
 the thing is that i'm producing the pdf document with fop,
 otherwise i'll be looking for information about the pdf
 specification

fop cannot accomplish what you want, but you can postprocess generated pdf by 
some pdf-oriented library (iText is the most mentioned), see PDF encryption 
example by J.Pietschmann at 
http://marc.theaimsgroup.com/?l=fop-devm=102002975028427w=2.

-- 
Oleg Tkachenko
Multiconn International, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties

2002-05-03 Thread Karen Lease

Not really. As a fairly interested party, I must admit that mentions of
throwing it out and starting over don't leave me totally indifferent,
but I've got little enough time as it is for FOP these days, and I'm
trying not to let myself be distracted.
In any case, we all know that it's never right the first time around.

Regards,
Karen

Peter B. West wrote:
 
 Hello devs.
 
 Does the near-silence on this one signify consent?
 
 Peter
 
 Keiron Liddle wrote:
 
  Hi Peter and others,
 
  What is the status of property handling?
 
  Are we going to go with Peter's suggestion and commit the java source
  to cvs and work on handling properties fully from there?
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties

2002-05-03 Thread Peter B. West

Karen,

I was your opinion that I was most concerned about on this one. I, for 
one, am quite happy to hold off to give you more time to make an 
argument. Part of my point was that it *was* in pretty good shape the 
first time around.

Peter

Karen Lease wrote:

Not really. As a fairly interested party, I must admit that mentions of
throwing it out and starting over don't leave me totally indifferent,
but I've got little enough time as it is for FOP these days, and I'm
trying not to let myself be distracted.
In any case, we all know that it's never right the first time around.

  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties

2002-05-01 Thread Peter B. West

Hello devs.

Does the near-silence on this one signify consent?

Peter

Keiron Liddle wrote:

 Hi Peter and others,

 What is the status of property handling?

 Are we going to go with Peter's suggestion and commit the java source 
 to cvs and work on handling properties fully from there?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties

2002-05-01 Thread Bertrand Delacretaz

On Wednesday 01 May 2002 18:19, Peter B. West wrote:
 Does the near-silence on this one signify consent?

I don't know enough about this to give meaningful advice, so in my case yes, 
silence means consent.

- Bertrand

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties

2002-05-01 Thread J.Pietschmann

Bertrand Delacretaz wrote:
 On Wednesday 01 May 2002 18:19, Peter B. West wrote:
 
Does the near-silence on this one signify consent?
 
 
 I don't know enough about this to give meaningful advice, so in my case yes, 
 silence means consent.
 
Yes, it ought to be a reasonable idea.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties

2002-04-29 Thread Jeremias Maerki

 What is the status of property handling?
 
 Are we going to go with Peter's suggestion and commit the java source to 
 cvs and work on handling properties fully from there?

+1. 

 As this is a section largely separate from the layout then it is a good 
 area to work on independantly. After all, there are lots of properties 
 that need handling ranging from easy to very hard.

My hope is that this part will become more simple to understand
and to handle. Until recently, I've mostly been able to stick to the
rendering part of FOP. But I see myself going into the other parts more
and more (I'm still trying to understand overflow/clipping). You might
also remember the recent posts about padding and border. I went lost
trying to understand why this really happens (actually, I haven't
invested that much time in that).

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Properties documentation

2002-01-02 Thread Keiron Liddle

On 2002.01.02 15:10 Peter B. West wrote:
 Keiron,
 
 Thanks for clueing me up on the documentation.  I strongly accept you 
 recommendation, and I will gladly use it in future.  Btw, the heading 
 graphics from the the design documents seem to have been screwed up. 
 Have you noticed this?

Yes, I noticed. I figured that that it would be easier to way for the new 
website design than to delve into the outdated stylebook.
The new design will look quite different without all the images etc.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Properties documentation

2002-01-01 Thread Keiron Liddle

Hi Peter,

Thanks for the work. Maybe this can go with the rest of the design.

I would strongly suggest that you do not write the html.
The apache web site is done from xml and all the images, layout etc. is 
done from a stylesheet. These will also be updated by others.
If you look at docs/xml-docs/fop/*.xml this is the xml format. It is 
converted by stylebook (will become cocoon soon) into the html.

On 2001.12.29 02:57 Peter B. West wrote:
 Dear list,
 
 After sepnding some days wrestling with various graphics tools in linux 
 in an attempt to make html that looked like the standard apache 
 documentation, I finally surrendered and made do with CSS to create a 
 facsimile that should be sufficient for this list.  It works with a 
 recent Mozilla build, and should probably work with IE5.something.
 
 I have made some notes and some semi-UML diagrams to illustrate the 
 approach I have been taking to the implementation of properties.  These 
 can be found at 
 
http://home.iprimus.com.au/pbwest/xml-fop/docs/html-docs/design/properties-new.html.
 
 lease let me know if there is some easy way to get full conformance with 
 the Apache XML norm, or if there are severe problems viewing these pages 
 with modern browsers.
 
 Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Properties documentation

2001-12-30 Thread Peter B. West

Bernard,

Thanks for that.  I have just had a long day trying to make the html at 
least readable under Navigator 4.75.  Isn't html wonderful?

I have also tried the current Opera 5.0 release on linux, with 
reasonable results.  The problem with using CSS is that the actual font 
sizes on a particular browser are still unpredictable.

Peter

Bertrand Delacretaz wrote:

On Saturday 29 December 2001 02:57, Peter B. West wrote:

. . .let me know if there is some easy way to get full
conformance with the Apache XML norm, or if there are severe problems
viewing these pages with modern browsers.


Hi Peter,
FYI, with Konqueror (modern yes, 100% finished maybe not), the PNG images 
(like in PropertyConsts.html) aren't displayed, but right-clicking them allow 
them to be opened in the image viewer. Maybe a mime-type problem?

The pages look fine with IE5.

- Bertrand


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Properties documentation

2001-12-29 Thread Bertrand Delacretaz

On Saturday 29 December 2001 02:57, Peter B. West wrote:
. . .let me know if there is some easy way to get full
 conformance with the Apache XML norm, or if there are severe problems
 viewing these pages with modern browsers.

Hi Peter,
FYI, with Konqueror (modern yes, 100% finished maybe not), the PNG images 
(like in PropertyConsts.html) aren't displayed, but right-clicking them allow 
them to be opened in the image viewer. Maybe a mime-type problem?

The pages look fine with IE5.

- Bertrand


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties, elements

2001-07-13 Thread Keiron Liddle


On Thu, 12 Jul 2001 22:50:44 Karen Lease wrote:
 A few quick thoughts...
 
 That was probably just my XML super-ego thinking that case-by-case
 checks were a _bad_ thing... But on the other hand, as Arved points out,
 the complexity of the model would make it rather problematic. It's
 certainly more important to focus on detecting cases which FOP (or FO)
 can't or isn't supposed to handle and giving some kind of comprehensible
 message to the user, rather than getting hung up on formal correctness.

I was thinking along the lines of some simple hashmaps (tables) containing
which elements are allowed as a child for the current element and which are
not allowed as a descendant, which is passed down to the children. This
includes sets such as block and inline.

The attribute constraint example is more difficult and will we run into a
problem handling the situation anyway. So the error handling could be left
until the problem is encountered.


 We also need to think about what to do when we encounter this kind of
 case. Obviously we want to inform the user. We could either stop on an
 exception or just ignore the offending FO and keep going.

Usually a spec has a section on how the processor should handle errors but
I couldn't find it in the XSL spec.

Anyway, I think I will create a document with all the constraint info for
all the elements.

Keiron.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties, elements

2001-07-13 Thread Arved Sandstrom

At 11:21 AM 7/13/01 +0200, Keiron Liddle wrote:

On Thu, 12 Jul 2001 22:50:44 Karen Lease wrote:
 We also need to think about what to do when we encounter this kind of
 case. Obviously we want to inform the user. We could either stop on an
 exception or just ignore the offending FO and keep going.

Usually a spec has a section on how the processor should handle errors but
I couldn't find it in the XSL spec.

You're right, doesn't seem to be anything said about content-model errors. I 
like the idea of trying to help out the user; I would say that we ignore the 
offending FO (and all descendants), with a warning (line, column, name, and 
short explanation if possible), and continue if possible.

For example, let's say that someone's XSL has produced FO with a 
page-sequence containing not only an fo:flow and a couple of 
fo:static-contents, but a top-level fo:block by mistake. I can see errors 
happen fairly often as people work up stylesheets. The user-friendly thing 
to do would be to emit a warning about the fo:block, and continue checking 
the tree. Maybe we'd catch several independent errors that way, and help
the user speed up the debugging/correction process.

One thing to consider is stopping the process after refinement, but before 
layout, if there are any content-model errors. Or maybe all of this can be 
subject to user control?

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: properties, elements

2001-07-12 Thread Karen Lease

A few quick thoughts...

That was probably just my XML super-ego thinking that case-by-case
checks were a _bad_ thing... But on the other hand, as Arved points out,
the complexity of the model would make it rather problematic. It's
certainly more important to focus on detecting cases which FOP (or FO)
can't or isn't supposed to handle and giving some kind of comprehensible
message to the user, rather than getting hung up on formal correctness.

We can do some global checking in the end method if that's necessary.
That lets us look at all the descendants of an FO. The other way to look
at constraints like the footnote one (or more generally, no floats
beneath other floats - Dieu merci!) is from the ancestor point of view.
When an FO is created, it knows what its parent will be even though it
isn't yet on that parent's child list. So a footnote or float FO can
check to see if has a footnote or float ancestor.

We also need to think about what to do when we encounter this kind of
case. Obviously we want to inform the user. We could either stop on an
exception or just ignore the offending FO and keep going.

Considering the property validity checks, I haven't touched that stuff
in ages. In general there are warning messages for values that aren't
convertible into one of the expected types. Most properties are just
assumed to be valid for all elements unless they are explicitly
associated with a particular element or elements.
There are still lots of values which aren't handled, including the
famous inherit keyword for all properties. In short, there is still
plenty of work in there for some enterprising person(s).

Regards,
Karen

Arved Sandstrom wrote:
 
 At 10:25 PM 7/11/01 +0200, Karen Lease wrote:
 Keiron Liddle wrote:
 
  Then after that I will see about handling the element child constraints (I
  haven't worked out how this should be done yet, any ideas) and doing a
  similar thing (to be impl.) with the rest of the elements that we don't
  have yet.
 
 
 For things like tables, I had been thinking of handling child type
 checking in the addChild method. That way we can give messages early in
 the game and also do special things like handling different children in
 special ways. An example is when table-cell FO are directly under a
 table-body (or header or footer) rather than in a table-row. In that
 case, I think it would be better to create a fake row to hold them.
 That kind of work is logically done during FO tree building.
 
 However that's rather a piecemeal approach. Perhaps it would be good to
 describe (schema? DTD?) the possible child types and have the base class
 implementation do that kind of checking.
 
 Just my .02 euros!
 
 I wonder if we should bother with formal parse-time validation at all (i.e.
 the schema/DTD idea). We already know that inheritable properties complicate
 the attribute issue, and then we also know that there are enough formatting
 objects with special content constraints that why even bother?
 
 I suggest letting the existing (and improved as required) properties
 refinement mechanism worry about checking property validity (Karen, maybe
 you can give us a state of the union as to where we stand on this?), and as
 Karen also mentioned, let's build in our own checking mechanism. My
 contribution to Karen's comments is merely to argue for not even bothering
 with schemas or DTDs at all.
 
 Perhaps we should winnow out all the rules from the spec into one document,
 and that should give us a 10,000 ft view of what we are faced with. That
 might lead us to an efficient approach, or suggest certain base-class
 checking shortcuts rather than sub-class checking. For example, among the
 variety of things we have are:
 
 1) fo:wrapper -
 (#PCDATA|%inline;|%block;)*
 An fo:wrapper is only permitted to have children that would be permitted to
 be children of the parent of
 the fo:wrapper, with two exceptions:
 * An fo:wrapper may always have a sequence of zero or more fo:markers as its
 initial children.
 * An fo:wrapper that is a child of an fo:multi-properties is only permitted
 to have children that would
 be permitted in place of the fo:multi-properties.
 This restriction applies recursively.
 
 2) fo:footnote
 Contents:
 (inline,footnote-body)
 An fo:footnote is not permitted to have an fo:float, fo:footnote, or
 fo:marker as a descendant.
 Additionally, an fo:footnote is not permitted to have as a descendant an
 fo:block-container that
 generates an absolutely positioned area.
 
 3) fo:table-header
 Contents:
 (table-row+|table-cell+)
 The fo:table-header has fo:table-row (one or more) as its children, or
 alternatively fo:table-cell (one or
 more). In the latter case cells are grouped into rows using the starts-row
 and ends-row properties.
 In addition this formatting object may have a sequence of zero or more
 fo:markers as its initial children.
 
 I do not get the feeling that we have a comprehensive or consistent system
 for enforcing these content rules. Note 

Re: properties, elements

2001-07-11 Thread Karen Lease

Keiron Liddle wrote:
 

 
 Then after that I will see about handling the element child constraints (I
 haven't worked out how this should be done yet, any ideas) and doing a
 similar thing (to be impl.) with the rest of the elements that we don't
 have yet.


For things like tables, I had been thinking of handling child type
checking in the addChild method. That way we can give messages early in
the game and also do special things like handling different children in
special ways. An example is when table-cell FO are directly under a
table-body (or header or footer) rather than in a table-row. In that
case, I think it would be better to create a fake row to hold them.
That kind of work is logically done during FO tree building.
 
However that's rather a piecemeal approach. Perhaps it would be good to
describe (schema? DTD?) the possible child types and have the base class
implementation do that kind of checking.

Just my .02 euros!

Karen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]