Re: Error areas pending text probably lost
So there is nothing that I can really do but when the problem appears change my source fo ( or source xml in my case) Thanks for the help. Abhi --- J.Pietschmann [EMAIL PROTECTED] wrote: Andreas L. Delmelle wrote: Nested inlines... My guess is: there's the bugger! Correct. Can you try rendering again, but replacing the inner fo:inline in the above snippet with an fo:wrapper, Won't work. The problem is as follows: The line layout is called with a bunch of characters. It is scanned for possible line breaks, more or less whitespace (which is incomplete in itself). If the character sequence is exhausted before a break possibility is encountered but there's still space left in the line, the text snippet processed so far is stored in the pending area list, because it might be wrapped to the next line. Upon the next call, scanning proceeds, and if the line is full without finding a break possiblity, processing is unwound unto the block, which generates a new line. This new line grabs the pending area list from the previous line and adds it to itself, because it's word content which had been wrapped. The problem occurs if the overflowed line is at the end of the page, because the block layout code which would otherwise generate a new line returns up to the page layout loop. New block areas are created, the link to the line with the non-empty pending area list is lost, and the new line starts without the wrapped text. The error message is generated in the renderer which simply looks at the pending area list of the line, which should have been emptied. The problem occurs rarely because it only happens if a word is fragmented so that the pending area list is filled. Because some code accumulates the SAX character events, only inline FOs which mark parts of a word may cause this. The only way around the bug is to eliminate the inline FOs, or fine tune display space in order to avoid having the content in question falling at the edge of a page. A similar, but code-wise unrelated bug occurs when an inline graphic is added which is too high to fit the available space on the page: the text already in the line is lost. Fortunately, FOP can't cope with dynamic line height anyway, so people rarely do this. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Error areas pending text probably lost
I am generating PDFs from a XML using FOP. I am getting an error saying [ERROR] Areas pending, text probably lost in line this applies in all the cases except when I look at the PDF and see that the word after 'when' is missing the first letter. Is there a way to fix this problem or why am I getting this error? Any help will be appreciated. Thanks, Abhi __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
-Original Message- From: Abhijit Junnare [mailto:[EMAIL PROTECTED] I am generating PDFs from a XML using FOP. I am getting an error saying [ERROR] Areas pending, text probably lost in line this applies in all the cases except when I look at the PDF and see that the word after 'when' is missing the first letter. Is there a way to fix this problem or why am I getting this error? Hmm. Can you try running this with the '-d' option, and send us more of the output? Of course, a sample fo-snippet could also help. From this, I can only tell where the error happens(*), not exactly why it is happening. Thanks, Andreas (*) fop.layout.LineArea.render() - line 372 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error areas pending text probably lost
Abhijit Junnare wrote: I am generating PDFs from a XML using FOP. I am getting an error saying [ERROR] Areas pending, text probably lost in line this applies in all the cases except when I look at the PDF and see that the word after 'when' is missing the first letter. Is there a way to fix this problem or why am I getting this error? This problem was seen a few times on older versions of FOP. What version are you using? A quick scan of the archives revealed this related thread: http://marc.theaimsgroup.com/?l=fop-userm=105536043405456w=2 Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
Below is the FO that comes out when I run my xml and xsl through xalan. Right now I use a xml and xsl to gene rate the PDF. I can see that the first letter is there in the FO but it is lost when rendering through FOP. Also this line appears at the end of a page and the word 'Condition' appears on the next page but the letter 'C' is missing from it. Is there any thing I can do for this not to happen. I am not able to run with the -d option coz I am not sure if I can use two options at a time as I use a userconfiguration file to embeed one font and hence need to use -c option. Let me know how I can use both options and I will give it a try. Thanks, Abhi FO SNIPPET fo:block line-height=1.2em space-before=5pt color=black start-indent=from-parent(start-indent) + 12pt fo:inline font-weight=bold font-style=italic font-size=10pt font-family=Helvetica text-align=left color=blackSome Title/fo:inline fo:inline color=black space-before.conditionality=discard This applies in all the cases except when fo:inline font-family=Helvetica font-weight=bold font-variant=small-caps font-size=12ptCondition 4/fo:inline of terms and conditions is true /fo:inline /fo:block __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
version number Re: Error areas pending text probably lost
Sorry I forgot to mention that. But i am using fop-0.20.5 version __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
Can't you remove font-variant=small-caps from your XSL? -Original Message- From: Abhijit Junnare [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 10:53 AM To: [EMAIL PROTECTED] Subject: RE: Error areas pending text probably lost Below is the FO that comes out when I run my xml and xsl through xalan. Right now I use a xml and xsl to gene rate the PDF. I can see that the first letter is there in the FO but it is lost when rendering through FOP. Also this line appears at the end of a page and the word 'Condition' appears on the next page but the letter 'C' is missing from it. Is there any thing I can do for this not to happen. I am not able to run with the -d option coz I am not sure if I can use two options at a time as I use a userconfiguration file to embeed one font and hence need to use -c option. Let me know how I can use both options and I will give it a try. Thanks, Abhi FO SNIPPET fo:block line-height=1.2em space-before=5pt color=black start-indent=from-parent(start-indent) + 12pt fo:inline font-weight=bold font-style=italic font-size=10pt font-family=Helvetica text-align=left color=blackSome Title/fo:inline fo:inline color=black space-before.conditionality=discard This applies in all the cases except when fo:inline font-family=Helvetica font-weight=bold font-variant=small-caps font-size=12ptCondition 4/fo:inline of terms and conditions is true /fo:inline /fo:block __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This message contains information that may be privileged or confidential and is the property of the Cap Gemini/Ernst Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
No I cannot. We have a strict formatting specification and so I cannoot remove the small-caps formatting style. Any other suggestions? --- Forget, Pascal [EMAIL PROTECTED] wrote: Can't you remove font-variant=small-caps from your XSL? __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
-Original Message- From: Abhijit Junnare [mailto:[EMAIL PROTECTED] snip / fo:inline color=black space-before.conditionality=discard This applies in all the cases except when fo:inline font-family=Helvetica font-weight=bold font-variant=small-caps font-size=12ptCondition 4/fo:inline of terms and conditions is true /fo:inline /fo:block Nested inlines... My guess is: there's the bugger! Can you try rendering again, but replacing the inner fo:inline in the above snippet with an fo:wrapper, like: fo:inline color=black ... This applies in all the cases except when fo:wrapper font-family=Helvetica ... Condition 4/fo:wrapper of terms and conditions is true/fo:inline /fo:block And let us know if that removes the error? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
I tried replacing the inner fo:inline with fo:wrapper but the result is the same. The text is still lost. any more ideas? --- Andreas L. Delmelle [EMAIL PROTECTED] wrote: -Original Message- From: Abhijit Junnare [mailto:[EMAIL PROTECTED] snip / fo:inline color=black space-before.conditionality=discard This applies in all the cases except when fo:inline font-family=Helvetica font-weight=bold font-variant=small-caps font-size=12ptCondition 4/fo:inline of terms and conditions is true /fo:inline /fo:block Nested inlines... My guess is: there's the bugger! Can you try rendering again, but replacing the inner fo:inline in the above snippet with an fo:wrapper, like: fo:inline color=black ... This applies in all the cases except when fo:wrapper font-family=Helvetica ... Condition 4/fo:wrapper of terms and conditions is true/fo:inline /fo:block And let us know if that removes the error? Cheers, Andreas __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
-Original Message- From: Forget, Pascal [mailto:[EMAIL PROTECTED] Can't you remove font-variant=small-caps from your XSL? Silly question maybe, but what exactly would that achieve? Hmm. Could indeed be just that... AFAIK 0.20.5 uses simulated small-caps (regular caps at 80% the font-size), so probably it's got something to do with the role of this in the calculations. (The first character wouldn't be subject to the scaling, which could explain its mystical status --disappearing as it does ;) ) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
So??? But I need to use small-caps so I cant give up on that. --- Andreas L. Delmelle [EMAIL PROTECTED] wrote: Can't you remove font-variant=small-caps from your XSL? Silly question maybe, but what exactly would that achieve? Hmm. Could indeed be just that... AFAIK 0.20.5 uses simulated small-caps (regular caps at 80% the font-size), so probably it's got something to do with the role of this in the calculations. (The first character wouldn't be subject to the scaling, which could explain its mystical status --disappearing as it does ;) ) Cheers, Andreas __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error areas pending text probably lost
Andreas L. Delmelle wrote: Nested inlines... My guess is: there's the bugger! Correct. Can you try rendering again, but replacing the inner fo:inline in the above snippet with an fo:wrapper, Won't work. The problem is as follows: The line layout is called with a bunch of characters. It is scanned for possible line breaks, more or less whitespace (which is incomplete in itself). If the character sequence is exhausted before a break possibility is encountered but there's still space left in the line, the text snippet processed so far is stored in the pending area list, because it might be wrapped to the next line. Upon the next call, scanning proceeds, and if the line is full without finding a break possiblity, processing is unwound unto the block, which generates a new line. This new line grabs the pending area list from the previous line and adds it to itself, because it's word content which had been wrapped. The problem occurs if the overflowed line is at the end of the page, because the block layout code which would otherwise generate a new line returns up to the page layout loop. New block areas are created, the link to the line with the non-empty pending area list is lost, and the new line starts without the wrapped text. The error message is generated in the renderer which simply looks at the pending area list of the line, which should have been emptied. The problem occurs rarely because it only happens if a word is fragmented so that the pending area list is filled. Because some code accumulates the SAX character events, only inline FOs which mark parts of a word may cause this. The only way around the bug is to eliminate the inline FOs, or fine tune display space in order to avoid having the content in question falling at the edge of a page. A similar, but code-wise unrelated bug occurs when an inline graphic is added which is too high to fit the available space on the page: the text already in the line is lost. Fortunately, FOP can't cope with dynamic line height anyway, so people rarely do this. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
-Original Message- From: Abhijit Junnare [mailto:[EMAIL PROTECTED] I tried replacing the inner fo:inline with fo:wrapper but the result is the same. The text is still lost. any more ideas? I can't seem to reproduce this at first glance... Can you provide us with a bit more context? FYI: appending your supplied block snippet to the simple.fo example file that comes with FOP gave no problems at all with 0.20.5. (1.0-dev still had problems with the small-caps and seems to swallow some text after a linebreak...) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
-Original Message- From: Abhijit Junnare [mailto:[EMAIL PROTECTED] So??? But I need to use small-caps so I cant give up on that. Sorry, this one was meant more as an explanation of what could be the source of the behaviour (--for future reference :) ) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Error areas pending text probably lost
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] snip / Won't work. The problem is as follows: snip .. with kind permission ;) / Yes siree! He 'dze' man :) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error areas pending text probably lost
Andreas L. Delmelle wrote: I can't seem to reproduce this at first glance... Can you provide us with a bit more context? See Bug #13464 J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
