Re: Branch deadline coming up
I've just tried to reproduce that (with an fo:inline specifying a bigger font size) and it came out fine. Would you mind writing a test case for that? On 19.04.2005 22:05:26 Simon Pepping wrote: I noticed that each line in a paragraph has the height of the first line of that paragraph. That is not correct, and may invalidate test files. Jeremias Maerki
Re: Branch deadline coming up
On Wed, Apr 20, 2005 at 05:51:47PM +0200, Luca Furini wrote: Simon Pepping wrote: I am worried about performance. Knuth elements are passed up and down the LM tree, and at each step the Position is wrapped or unwrapped. That probably occurs very many times, and together these operations could require considerable processing time. Perhaps it can be avoided. I do not see a fundamental reason why the whole stack of ancestral LMs should be contained in a Knuth element. Jeremias Maerki wrote: # With just a little additional flexibility in the addAreas() # methods we can probably get rid of the wrapping. A few wrappings could be avoided; for example, I think that the FlowLM could leave the Positions unchanged, as it is the PSLM only child (besides StaticContentLMs). But maybe your idea is much better. PSLM.addAreas would call directly LineLM.addAreas() (or TableContentLM.addAreas(), or ListItemLM.addAreas()) which could make a simple check to see whether there is already a parent area or it must be created calling BlockLM.addAreas(), and so on. The stack of method calls would be turned upside-down. Indeed. Another idea is that PSLM.addAreas calls the addAreas method of each of its children, as it does now, but also passes the page break Position. Then the LMs continue to add areas until one of them reaches the page break Position. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: fo:list-item-label issue
Puppala, Kumar (LNG-DAY) wrote: Thanks for your information. The FO tags that I am using are as shown below. Incase the block in item-label contains lot of data, it does wrap now but in that process, it overwrites the next bullet. I am not sure if there is any other option that I need to use to prevent this from happening. Any thoughts? fo:list-block wrap-option=wrap You can fine-tune the layout using the provisional-label-separation and provisional-distance-between-starts properties. Which FOP version are you using? There was a release with a bug in the calculation for label-end(). J.Pietschmann
RE: fo:list-item-label issue
I am using 0.20.5 Thanks, Kumar Puppala -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 20, 2005 4:23 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: fo:list-item-label issue Puppala, Kumar (LNG-DAY) wrote: Thanks for your information. The FO tags that I am using are as shown below. Incase the block in item-label contains lot of data, it does wrap now but in that process, it overwrites the next bullet. I am not sure if there is any other option that I need to use to prevent this from happening. Any thoughts? fo:list-block wrap-option=wrap You can fine-tune the layout using the provisional-label-separation and provisional-distance-between-starts properties. Which FOP version are you using? There was a release with a bug in the calculation for label-end(). J.Pietschmann
