Re: Line LM, Inline LM and LAST_AREA

[Simon Pepping]

On Tue, Sep 06, 2005 at 12:46:19PM +0200, Luca Furini wrote:
> Manuel Mall wrote:
> 
> I think there is a bit of ambiguity in the names: at the moment, the 
> LAST_AREA flag signals to a LM that it is adding the last inline area in a 
> line, or the last block area in a page, but this can cause confusion with 
> the is-last area trait described by the specs (4.2.2 Common traits). Maybe 
> we can find out a more significant and univocal name.

I think I have used it in the meaning of is-last trait, back in
January, before the page breaking algorithm was applied. I see that
BlockStackingLM now uses isFirst(Pos) and isLast(Pos). I am not sure
why this LM introduces the methods; every LM needs to be able to mark
its areas as first or last, is it not? Anyway, I have always felt that
this needed a review as it seemed to be implemented in a patchy
manner.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Line LM, Inline LM and LAST_AREA

[Manuel Mall]

Hey, its nearly midnight and time to get some sleep - but have to share 
this: had some success with this refactoring - attached a PDF and the 
FO file showing how much of the inline border / padding stuff now 
works. The nested inlines are not 100% right yet, still need to figure 
out a fix for the incorrect inline box sizes and of course the 
conditionality=retain (but thanks to Luca I have an idea how to tackle 
that).

Manuel

On Tue, 6 Sep 2005 08:47 pm, Jeremias Maerki wrote:
> Certainly not, if it solves the problem. Just make certain that it
> doesn't add up too much on memory consumption on LMs that don't need
> the position indexes. Maybe this infrastructure should be extracted
> into its own class and used by the LMs that need it.
>
> On 06.09.2005 14:33:07 Manuel Mall wrote:
> > Jeremias any problems if I "push" this down from BlockStacking LM
> > into Abstract LM so I can make use of it in the Inline LMs?
>
> Jeremias Maerki


inline_border_padding.xml.pdf
Description: Adobe PDF document




  

  This test checks inlines with border and padding properties.

  
  
http://www.w3.org/1999/XSL/Format"; xmlns:svg="http://www.w3.org/2000/svg";>
  

  

  
  

  
Demonstrates various uses of fo:inline with borders and padding.
  
  
To emphasize a word we give it a 1pt border and a background.
  
  
Demonstrates a big border inline with border="solid 5pt red" padding="5pt" extending over the small allocation rectangle to the top and bottom.
  
  
Demonstrates unsymmetric borders and padding but the baselines should align.
  
  
Big border but a smaller font. This rectangle is incorrect!!
  
  
This demonstrates a long inline with .conditionality set to "discard". It has a left and right border at the beginning of the
and the end of the inline only. Any lines in between only have a top and bottom border. Back to normal here.
  
  
This demonstrates correct line breaking of  as this fits exactly on a line.
This demonstrates correct line breaking of  as this fits exactly on a line.
Not really as we started a fo:inline with border/padding just before the word "line" which forces it to the next line.
  
  
Demonstrates nested
  inlines
finishing together

  
  

  

  
  
  

Re: Line LM, Inline LM and LAST_AREA

[Jeremias Maerki]

Certainly not, if it solves the problem. Just make certain that it
doesn't add up too much on memory consumption on LMs that don't need
the position indexes. Maybe this infrastructure should be extracted into
its own class and used by the LMs that need it.

On 06.09.2005 14:33:07 Manuel Mall wrote:
> Jeremias any problems if I "push" this down from BlockStacking LM into 
> Abstract LM so I can make use of it in the Inline LMs?


Jeremias Maerki

Re: Line LM, Inline LM and LAST_AREA

[Manuel Mall]

Luca,

thanks a million.

Jeremias any problems if I "push" this down from BlockStacking LM into 
Abstract LM so I can make use of it in the Inline LMs?

Manuel

On Tue, 6 Sep 2005 07:49 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > 2. I need (nearly) exactly what Jeremias was referring to in your
> > [1] - that is "an indication that the last area for a LM is being
> > generated". In my case I am only interested in inline areas.
> > However, it seems no solution has yet been found for this issue.
> > I'll keep looking then.
>
> If I remember correctly, Jeremias found and implemented a solution:
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listId=63&msgNo=11314
> (message explaining the solution)
>
> http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
>e.org&msgNo=4158 (commit log)
>
> Regards
>  Luca

Re: Line LM, Inline LM and LAST_AREA

[Luca Furini]

Manuel Mall wrote:

2. I need (nearly) exactly what Jeremias was referring to in your [1] - 
that is "an indication that the last area for a LM is being generated". 
In my case I am only interested in inline areas. However, it seems no 
solution has yet been found for this issue. I'll keep looking then.


If I remember correctly, Jeremias found and implemented a solution:

http://nagoya.apache.org/eyebrowse/ReadMsg?listId=63&msgNo=11314
(message explaining the solution)

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=4158 
(commit log)


Regards
Luca

Re: Line LM, Inline LM and LAST_AREA

[Manuel Mall]

Luca,

thanks.

1. You confirmed what I suspected - LAST_AREA means "last area in that 
line"; so may be we should rename it to LAST_AREA_IN_LINE?

2. I need (nearly) exactly what Jeremias was referring to in your [1] - 
that is "an indication that the last area for a LM is being generated". 
In my case I am only interested in inline areas. However, it seems no 
solution has yet been found for this issue. I'll keep looking then.

Manuel

On Tue, 6 Sep 2005 06:46 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > But if we have a long fo:inline stretching multiple lines this seem
> > to give the wrong results from the Inline LM perspective. For
> > example if the fo:inline finishes in the middle of a line followed
> > by more text the Line LM will not set the LAST_AREA flag when
> > calling addAreas on the Inline LM as there are more areas on the
> > line. Therefore the Inline LM "thinks" its not done with yet
> > although it is and the reverse is true on the first line of a
> > multi-line inline.
>
> The LineLM.addAreas() method creates a line at a time (a line for
> each LineBreakPosition), and asks its children to add their inline
> areas for the line area being created.
>
> It sets the LAST_AREA flag if the child LM is the one that created
> the last element placed in this line: for each line, there is one and
> only one child LM that receives a LayoutContext with this flag set,
> unless there are bugs :-)
>
> If the content of an inline is divided among several lines, the
> method InlineLM.addAreas() will be called once per line, and all the
> times (but the last) it will have the LAST_AREA flag on.
>
> Some time ago there was a thread about a similar subject [1]: the
> problem, then, was the opposite, i.e. to find out which is the last
> area generated by a LM, regardless of line breaks.
>
> I think there is a bit of ambiguity in the names: at the moment, the
> LAST_AREA flag signals to a LM that it is adding the last inline area
> in a line, or the last block area in a page, but this can cause
> confusion with the is-last area trait described by the specs (4.2.2
> Common traits). Maybe we can find out a more significant and univocal
> name.
>
> Regards
>  Luca
>
> [1] Markers: Determining the last generated area for a LM,
> http://nagoya.apache.org/eyebrowse/ReadMsg?listId=63&msgNo=11296

Re: Line LM, Inline LM and LAST_AREA

[Luca Furini]

Manuel Mall wrote:

But if we have a long fo:inline stretching multiple lines this seem to 
give the wrong results from the Inline LM perspective. For example if 
the fo:inline finishes in the middle of a line followed by more text the 
Line LM will not set the LAST_AREA flag when calling addAreas on the 
Inline LM as there are more areas on the line. Therefore the Inline LM 
"thinks" its not done with yet although it is and the reverse is true on 
the first line of a multi-line inline.


The LineLM.addAreas() method creates a line at a time (a line for each 
LineBreakPosition), and asks its children to add their inline areas for 
the line area being created.


It sets the LAST_AREA flag if the child LM is the one that created the 
last element placed in this line: for each line, there is one and only one 
child LM that receives a LayoutContext with this flag set, unless there 
are bugs :-)


If the content of an inline is divided among several lines, the method 
InlineLM.addAreas() will be called once per line, and all the times (but 
the last) it will have the LAST_AREA flag on.


Some time ago there was a thread about a similar subject [1]: the problem, 
then, was the opposite, i.e. to find out which is the last area generated 
by a LM, regardless of line breaks.


I think there is a bit of ambiguity in the names: at the moment, the 
LAST_AREA flag signals to a LM that it is adding the last inline area in a 
line, or the last block area in a page, but this can cause confusion with 
the is-last area trait described by the specs (4.2.2 Common traits). Maybe 
we can find out a more significant and univocal name.


Regards
Luca

[1] Markers: Determining the last generated area for a LM, 
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=63&msgNo=11296

Line LM, Inline LM and LAST_AREA

[Manuel Mall]

I am trying to understand the logic related to determining if something 
is the "last area" generated for a LM, in this case for an Inline LM. 
If I understand it correctly the Line LM sets the LAST_AREA flag in the 
context when it generates the last area for a line. The Inline LM then 
checks if the LAST_AREA flag is set and if itself deals with its last 
child LM to determine if this is the last area for it. But if we have a 
long fo:inline stretching multiple lines this seem to give the wrong 
results from the Inline LM perspective. For example if the fo:inline 
finishes in the middle of a line followed by more text the Line LM will 
not set the LAST_AREA flag when calling addAreas on the Inline LM as 
there are more areas on the line. Therefore the Inline LM "thinks" its 
not done with yet although it is and the reverse is true on the first 
line of a multi-line inline.

Overall I am confused and wonder if whoever wrote this (or someone who 
understands this area of the code) can shed some light on it for me 
please.

In short, I need to know when the last area for a fo:inline is created 
and I am not clear at all how to do this.

Thanks

Manuel