Hi, Keiron

I think what I should do is establish a section on the website with all the
other design notes that is a central location for these kinds of studies.
This could be the first one. I can undertake to start churning these out on
a fairly regular basis - I think we need them.

Once they are in CVS then it would be easier for others to annotate them,
modify them, and what have you. We'll have to settle on a mutually agreeable
figure format so as not to unduly restrict access.

As far as the spec goes, absolutely, I agree. That's why I think that these
diagrams help so much - in order to draw them you must work your way through
the spec in detail. The process also exposes any gotchas before too much
code has been written based on different assumptions.

I'll proceed on the above basis and set up a place for these
diagrams/studies, and crank out some more. I am somewhat reluctant to do any
coding at the moment until such a time (hopefully not far away) where I am
satisfied that I understand the new design well.


> -----Original Message-----
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: May 2, 2002 6:18 AM
> Subject: Re: [REDESIGN] Line layout manager discussion
> I agree with you (except for the last statment about one line).
> I found this statement interesting:
> 6.6.7. fo:inline
> "An fo:inline that is a child of an fo:footnote may not have block-level
> children. An fo:inline that is a
> descendant of an fo:leader or of the fo:inline child of an
> fo:footnote may
> not have block-level children,
> unless it has a nearer ancestor that is an fo:inline-container."
> It suggests that what you are saying is correct and that block-level
> elements create a block area outside the immediate line area. So
> to have a
> block area inside a line area you must use the inline-container, a block
> is never automatically embedded.
> Also in this section, reading between the lines (it's amazing how they
> manage to contradict themselves in such a short section)
> 4.7.3. Inline-building
> An inline fo element with a block element as a child will create inline
> areas and return the block area.
> It will create a single inline area that can fit consecutive child inline
> areas on a single line. So the child inline areas are put into parent
> inline areas that are separated by line breaks and block areas.
> So Karen's approach is looking better.
> I really wish this spec would say relevant things in the right places and
> mention how everything is handled rather than being so vague.

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

Reply via email to