Arved Sandstrom wrote:
>
> At 12:22 AM 8/6/01 +0200, Karen Lease wrote:
> >So much for the explanations. Unfortunately, I'm not sure I'll try to
> >fix this right away, since I fear that it involves some rather major
> >changes. It really comes down to the fact that the fo:inline object
> >doesn't actually generate a nested inline area, but just adds characters
> >to the LineArea. So there's no place for it to actually store the
> >line-height information. Perhaps someone else will be be braver. In any
> >case, it's certainly on the list for the layout redesign...
>
> As soon as FOP 0.20.0 hits the streets, this is something that we may as
> well tackle and get over with. I ran into the same stumbling block a few
> weeks ago - I wanted to complete the set of FOs that can have markers, and
> fo:inline was one. Unfortunately, as you point out, fo:inline currently
> generates no area. If we are going to follow the conceptual model in the
> spec, which FOP currently does, then I figure we need to do so consistently,
> so fo:inline needs to create an area.
>
> I actually went down the initial design and coding road a bit. My conclusion
> was that if this is carefully done then it is not that bad. I also figured
> that for an initial cut it is better to duplicate and add classes to support
> this rather than to modify any existing classes, like FOText, because they
> are too central. But one could make the argument that FOText itself maybe
> needs work, so why _not_ modify it for the general case?
>
Yes, I pretty much agree. When I was doing the "redesign", I was working
on the concept of creating inline areas for all inline type objects
(except wrappers). I was going to just make one big "inline flow set"
with all the inline areas in a single sequence, and then do the breaking
from there. Once the line breaks were determined, then we can do the
line-height calculations according to the rules and the values of the
different properties. The biggest problem with having the actual text at
different levels in the tree is for doing things like white-space
handling, word-breaking hyphenation etc (assuming that at least some of
those should abstract from the actual inline tree).
Along those lines, and after trying to understand the white-space
handling in LineArea, I was wondering if it wouldn't be possible to do
that while building the FO tree. I was thinking of some kind of state
machine and using an iterator over the FO tree to abstract the level
problem. Sounds like I need to look into Peter's Tree work. (I'm sure
all that sounds quite obscure... oh well, just lettings people know
where I might be poking around.)
Regards,
Karen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
