Re: Line LM, Inline LM and LAST_AREA
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=63msgNo=11296
Re: Line LM, Inline LM and LAST_AREA
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=63msgNo=11296
Re: Line LM, Inline LM and LAST_AREA
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
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 ?xml version=1.0 encoding=UTF-8? !-- Copyright 2005 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- $Id: block_border_padding.xml 265720 2005-09-01 13:29:28Z jeremias $ -- testcase info p This test checks inlines with border and padding properties. /p /info fo fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=normal page-width=5in page-height=5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:flow flow-name=xsl-region-body font-size=10pt fo:block margin=0pt background-color=orange Demonstrates various uses of fo:inline !--fo:inline font-size=smaller background-color=yellowstart fo:inlinefo:blockblock/fo:blockfo:inline cont/fo:inline --with borders and padding. /fo:block fo:block background-color=silver margin=2pt 0pt 2pt 0pt To fo:inline border=solid 1pt red background-color=yellowemphasize/fo:inline a word we give it a 1pt border and a background. /fo:block fo:block background-color=silver margin=10pt 0pt 10pt 0pt Demonstrates a big border fo:inline border=solid 5pt red padding=5pt background-color=yellowinline with border=solid 5pt red padding=5pt/fo:inline extending over the small allocation rectangle to the top and bottom. /fo:block fo:block background-color=silver margin=10pt 0pt 10pt 0pt Demonstrates fo:inline border-style=solid border-width=1pt 2pt 3pt 4pt border-color=red padding=1pt 2pt 3pt 4pt background-color=yellowunsymmetric borders and padding/fo:inline but the baselines should align. /fo:block fo:block background-color=silver margin=10pt 0pt 10pt 0pt font-size=20pt Big border fo:inline border=solid 5pt red padding=5pt background-color=yellow font-size=8ptbut a smaller font. This rectangle is/fo:inline incorrect!! /fo:block fo:block background-color=silver margin=3pt 0pt 3pt 0pt This demonstrates a long inline fo:inline border=solid 1pt red padding=1pt background-color=yellowwith .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./fo:inline Back to normal here. /fo:block fo:block background-color=silver margin=3pt 0pt 3pt 0pt This demonstrates correct line breaking of lt;fo:inlinegt; as this fits exactly on a line. This demonstrates correct line breaking of lt;fo:inlinegt; as this fits exactly on a fo:inline border=solid 1pt red padding-start=2pt padding-end=2pt background-color=yellowline. Not really as we started a fo:inline with border/padding just before the word line which forces it to the next line./fo:inline /fo:block fo:block background-color=silver margin=3pt 0pt 3pt 0pt Demonstrates nested fo:inline border=solid 2pt red padding-start=2pt padding-end=2pt background-color=yellowinlines fo:inline border=solid 1pt green padding-start=2pt padding-end=2pt background-color=orangefinishing together /fo:inline /fo:inline /fo:block /fo:flow /fo:page-sequence
Re: Line LM, Inline LM and LAST_AREA
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
