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?

Arved Sandstrom

Fairly Senior Software Type
e-plicity (
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia

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

Reply via email to