You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Simon Pepping <sp...@leverkruid.nl> on 2004/05/27 21:07:18 UTC
InlineLMs
Inline area generating LMs and Inline area containing LMs
and their corresponding FO nodes
=========================================================
In the listings below the LMs are followed by the FO nodes that
generate them.
The following LMs may occur in inline content
---------------------------------------------
BidiLayoutManager extends LeafNodeLayoutManager: BidiOverride
ContentLayoutManager: Leader with use-content property set
ICLayoutManager extends LeafNodeLayoutManager: InlineContainer
InlineStackingLayoutManager: FObjMixed, Inline, BasicLink (anonymous
subclass),
LeafNodeLayoutManager: Leader (anonymous subclass, may
insert other LMs), Character, ExternalGraphic,
InstreamForeignObject, PageNumber (anonymous subclass),
PageNumberCitation (anonymous subclass)
RetrieveMarkerLayoutManager (depending on the marker): RetrieveMarker
TextLayoutManager: FOText
ToBeImplementedElementLayoutManager: MultiSwitch, MultiPropertySet,
MultiToggle
The following LMs may contain #PCDATA or inline content
-------------------------------------------------------
InlineStackingLayoutManager: Title
LeafNodeLayoutManager: Leader (anonymous subclass, may insert other
LMs)
The following LMs may contain #PCDATA, inline or block content
--------------------------------------------------------------
InlineStackingLayoutManager: Inline, BasicLink (anonymous subclass),
Marker
LineLayoutManager: Block
ToBeImplementedElementLayoutManager: MultiCase, MultiToggle
For the FO nodes and their LMs, see AddLMVisitor.
For inline content, see the FO spec., sections 6.2 Formatting Object
Content, 6.6, Inline-level Formatting Objects, 6.9 Dynamic Effects:
Link and Multi Formatting Objects. For content models, see the FO
spec., section 6.
This is a block element that uses most of them (substitute some other
name for the graphic):
<fo:block language="en" country="US"
hyphenate="true" text-align="justify">
We start with some normal text.
A character FO: <fo:character character="A"/>
An external graphic: <fo:external-graphic src="Question.gif"/>
An SVG graphic:
<fo:instream-foreign-object id="svg">
<svg:svg width="20" height="20" xml:space="preserve">
<svg:g style="fill:red; stroke:#000000">
<svg:rect x="0" y="0" width="15" height="15"/>
<svg:rect x="5" y="5" width="15" height="15"/>
</svg:g>
</svg:svg>
</fo:instream-foreign-object>
<fo:inline background-color="blue">
A text with a blue background.
</fo:inline>
A ruled leader: <fo:leader leader-length="120pt"
leader-length.maximum="200pt" leader-pattern="rule"/>
<fo:inline background-color="blue">
A text with a blue background,
<fo:inline background-color="red">
and some text with a red background
(<fo:basic-link internal-destination="svg">SVG</fo:basic-link>)
</fo:inline>
inside it.
</fo:inline>
A leader using a content pattern:
<fo:leader leader-length="120pt" leader-length.maximum="200pt"
leader-pattern="use-content">X<fo:inline background-color="red">X</fo:inline></fo:leader>
This is page number <fo:page-number/>.
The SVG graphic is on page number
<fo:page-number-citation ref-id="svg"/>.
This is a link to the
<fo:basic-link internal-destination="svg"><fo:inline background-color="red">SVG</fo:inline>
graphic</fo:basic-link>.
We end with some normal text.
</fo:block>
Note that Luca's patch causes a loop on this block. The null
implementation of AbstractLayoutManager.getNextKnuthElement causes
this. It should be modified to finish the LM:
public KnuthElement getNextKnuthElement() {
setFinished(true);
return null;
}
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: InlineLMs
Posted by Chris Bowditch <bo...@hotmail.com>.
Simon Pepping wrote:
>>Great stuff. Do you think Luca's patch is ready to be committed with this
>>change? Or is more testing required?
>
>
> No. Without this change other childLMs than TextLM cause an infinite
> loop, because null is returned but the childLM never finishes. This is
> a special feature of getChildLM(): It is a sort of iterator over the
> childLMs but it does not advance to the next childLM except when the
> current childLM is finished. With this change the childLM declares
> itself finished immediately, without contributing any breakposs. A
> real null implementation. :-)
>
> A way must be found to let childLMs other than TextLM contribute to
> the Knuth algorithm. Some LMs simply contribute a box. Others,
> esp. InlineStackingLM, contribute text elements from their own TextLM
> childLMs. These must be forwarded to the LineLM, and the LineLM must
> be able to request hyphenation from those TextLMs. This is not
> trivial. I expect that Luca is working on it. If not, someone else
> must take it up.
Simon, thanks for the full explanation.
Chris
Re: InlineLMs
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Tue, Jun 01, 2004 at 12:16:24PM +0100, Chris Bowditch wrote:
> Simon Pepping wrote:
>
> >Note that Luca's patch causes a loop on this block. The null
> >implementation of AbstractLayoutManager.getNextKnuthElement causes
> >this. It should be modified to finish the LM:
>
> Great stuff. Do you think Luca's patch is ready to be committed with this
> change? Or is more testing required?
No. Without this change other childLMs than TextLM cause an infinite
loop, because null is returned but the childLM never finishes. This is
a special feature of getChildLM(): It is a sort of iterator over the
childLMs but it does not advance to the next childLM except when the
current childLM is finished. With this change the childLM declares
itself finished immediately, without contributing any breakposs. A
real null implementation. :-)
A way must be found to let childLMs other than TextLM contribute to
the Knuth algorithm. Some LMs simply contribute a box. Others,
esp. InlineStackingLM, contribute text elements from their own TextLM
childLMs. These must be forwarded to the LineLM, and the LineLM must
be able to request hyphenation from those TextLMs. This is not
trivial. I expect that Luca is working on it. If not, someone else
must take it up.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: InlineLMs
Posted by Chris Bowditch <bo...@hotmail.com>.
Simon Pepping wrote:
> Inline area generating LMs and Inline area containing LMs
> and their corresponding FO nodes
> =========================================================
>
> In the listings below the LMs are followed by the FO nodes that
> generate them.
Thanks for the summary Simon.
<snip/>
> Note that Luca's patch causes a loop on this block. The null
> implementation of AbstractLayoutManager.getNextKnuthElement causes
> this. It should be modified to finish the LM:
Great stuff. Do you think Luca's patch is ready to be committed with this
change? Or is more testing required?
Thanks,
Chris