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?
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]
