Re: InlineLMs

2004-06-03 Thread Luca Furini

Simon, thanks for all the information.

At the moment, I am working on LeafNodeLM (now fo:leader works)
and InlineStackingLM.
I think I'll be able to post a second patch next week.

Regards
Luca




Re: InlineLMs

2004-06-01 Thread Chris Bowditch
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



Re: InlineLMs

2004-06-01 Thread Simon Pepping
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



InlineLMs

2004-05-28 Thread Simon Pepping
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:#00
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=svgSVG/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-contentXfo:inline 
background-color=redX/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=svgfo:inline 
background-color=redSVG/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