Re: Hyphetation broken with last commits
On Sun, Dec 18, 2005 at 11:10:37AM +0100, Andreas L Delmelle wrote: On Dec 18, 2005, at 06:16, Manuel Mall wrote: Does it mean because the Knuth algorithm removes all glues after a linebreak (and we also remove all glues at the end of a paragraph) a nbsp should not be modelled not like this: pen p=INF glue w=... but like this: box w=0 aux=true pen p=INF glue w=... box w=0 aux=true with the leading box preventing removal at the beginning of a line, the trailing box prevents removal at the end of a paragraph, and the penalty prevents a line break. As far as my understanding of the Knuth algorithm goes, that might be a way to solve it. Even better would be to make the creation of the auxiliary zero-width boxes conditional --depending on whether there are already other boxes surrounding the nbsp (if at all possible). It's really only in the cases where there are no preceding/following boxes that we need special treatment, no? In case of surrounding non- whitespace, the first model would seem to be sufficient. That is indeed the way to solve it. The more I think about this, the more complicated it becomes. Maybe the Knuth algorithm requires that when there are multiple characters which are suppressed at linebreak, they are considered together, much like we do in space resolution in page breaking. One should avoid the situation glue - glue, if the first glue is to be suppressed when the second glue is a chosen line break. It should be a single glue, or a sequence like glue #1 - penalty - glue #2 - box - PENALTY - glue #3 if glue #1 and glue #3, i.e. the glues that remain around a line break, are not zero. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Hyphetation broken with last commits
On Sun, 18 Dec 2005 08:21 pm, Simon Pepping wrote: On Sun, Dec 18, 2005 at 11:10:37AM +0100, Andreas L Delmelle wrote: On Dec 18, 2005, at 06:16, Manuel Mall wrote: Does it mean because the Knuth algorithm removes all glues after a linebreak (and we also remove all glues at the end of a paragraph) a nbsp should not be modelled not like this: pen p=INF glue w=... but like this: box w=0 aux=true pen p=INF glue w=... box w=0 aux=true with the leading box preventing removal at the beginning of a line, the trailing box prevents removal at the end of a paragraph, and the penalty prevents a line break. As far as my understanding of the Knuth algorithm goes, that might be a way to solve it. Even better would be to make the creation of the auxiliary zero-width boxes conditional --depending on whether there are already other boxes surrounding the nbsp (if at all possible). It's really only in the cases where there are no preceding/following boxes that we need special treatment, no? In case of surrounding non- whitespace, the first model would seem to be sufficient. That is indeed the way to solve it. The more I think about this, the more complicated it becomes. Maybe the Knuth algorithm requires that when there are multiple characters which are suppressed at linebreak, they are considered together, much like we do in space resolution in page breaking. One should avoid the situation glue - glue, if the first glue is to be suppressed when the second glue is a chosen line break. It should be a single glue, or a sequence like glue #1 - penalty - glue #2 - box - PENALTY - glue #3 if glue #1 and glue #3, i.e. the glues that remain around a line break, are not zero. The simple glue - glue is not a problem as only glue elements directly following a box are legal break points. But the other scenarios above are tricky and yes I agree that consecutive whitespace should be accumulated into a single glue element even if they cross inline boundaries. Which is an interesting problem in itself especially as this may involve a change in font(-size) and the individual spaces we accumulate may have different widths. A particularly interesting scenario is an inline with a border: ...fo:inline border=... text1 /fo:inline text2 Here we don't want to break at the space after text1 because that would push a solitary border to the next line but if we break at the space before text2 the space after text1 must also be removed (assuming the default whitespace related property settings). Currently we generate something like (simplified): box for text1 glue box for border glue but what is needed is more like: box for text1 box for border gluefor both spaces This reorders / merges elements across inline boundaries and makes the mapping of the Knuth elements back to the inline text fragments for area tree generation very interesting (or shall we say challenging?). You are probably aware of my discussions with Luca on this topic (redesigning the Knuth element generation for paragraphs). Its these messy situations which so far have eluded my attempts to come up with a clean solution. Simon Manuel
Renderer interface for Viewports
This is mainly for Jeremias: While working with the AFP Renderer I had some struggles with the FOP renderer interfaces (which I haven't changed so far). The problems are largely related to Viewport positioning. Firstly the area tree does not carry enough direct information. There are no reference-orientation, writing-mode, block-progression-direction, inline-progression-direction traits for example. Secondly all positioning seems to be expected to be done via the Coordinate Transformation Matrix (which is carried in the area tree). But the CTM approach does not fit well into AFP. AFP wants actual rotation info (0, 90, 180, 270), i.e. it allows to set the coordinate system origin to one of the 4 corners of the page box (with the corresponding implicit change of i-p-direction and b-p-direction). So, when in AFP I have to render a Block/Region Viewport I need to set the origin to the appropriate corner of the page depending on the reference-orientation of the Viewport and then have to use offsets from that corner to where the Viewport sits on the page. These offsets can be easily calculated from the Viewport content rectangle for a given orientation. You recently introduced the startVP and endVP functions into the renderers but their parameters are CTM and Clip. I need reference orientation and Viewport content rectangle. What I ended up doing was to make copies of the renderBlockViewport and renderRegionViewport functions into the AFP Renderer which call my own versions of startVP / endVP which have a different signature. I was also forced to reverse engineer the value of reference-orientation from the factors stored in the CTM (yuk). I think this needs improvement but what is the best strategy here? Manuel
