DO NOT REPLY [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 --- Comment #4 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 07:31:03 EST --- (In reply to comment #3) At least there should be some configuration available to the end user to tell FOP to use some default line break in such special cases it becomes specific to the customer who is using FOP. Just because of some special character the entire PDF generation should not be put in stake. Isn't it ? If given a choice to the customer to choose from set of options, to get rid of this situation then it is better, rather than crashing. Very right indeed. So, if no one objects, I will apply the patch as proposed. FOP will no longer crash, but simply show a '#' for such unassigned codepoints in the output. Treating them as regular alphabetic characters seems to be safe enough for the time being. Customization of and/or more refined configuration possibilities for the Unicode line-breaking algorithm is something that is still on the wish-list for the longer term. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49848] keep-together.within-line=always does not work with nested fo:inline
https://issues.apache.org/bugzilla/show_bug.cgi?id=49848
--- Comment #1 from Andreas L. Delmelle adelme...@apache.org 2011-01-07
07:38:42 EST ---
Studying this issue closer, it seems to originate in TextLM, line 708:
...
} else if (inWhitespace) {
processWhitespace(alignment, sequence, true);
...
The literal 'true' means that when finishing the TextLM element list, it is
assumed that there is always supposed to be a break opportunity at the end,
while in reality, this obviously depends...
Using a literal 'true' as parameter value, we get a sequence of
Glue-Penalty-Glue for the space before the nested inline. This produces a break
opportunity that is used by the LineBreakingAlgorithm.
Using '!keepTogether' instead, produces only an auxiliary box in this case and
seems to resolve it.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 --- Comment #4 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 07:31:03 EST --- Very right indeed. So, if no one objects, I will apply the patch as proposed. FOP will no longer crash, but simply show a '#' for such unassigned codepoints in the output. Treating them as regular alphabetic characters seems to be safe enough for the time being. Would it not be better to use character FFFD, 'Replacement Character', �, for this? Simon
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On 07 Jan 2011, at 14:17, Simon Pepping wrote: Hi Simon, On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: So, if no one objects, I will apply the patch as proposed. FOP will no longer crash, but simply show a '#' for such unassigned codepoints in the output. Treating them as regular alphabetic characters seems to be safe enough for the time being. Would it not be better to use character FFFD, 'Replacement Character', �, for this? Interesting. In the context of linebreaking, that comes down to basically the same thing. U+FFFD has linebreak class 'AI' or 'Ambiguous', which is currently also converted to 'Alphabetic' as part of the initial conversions. Are you suggesting that we substitute the codepoint in the actual text content (rather than leave it there, and further rely on the default treatment of 'missing glyphs')? Regards, Andreas ---
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
I think so. The use of # is mostly historical due to lack of Unicode support initially. At least I believe so. The first fonts were WinAnsi only. IMO, it makes sense to make that transition. However, for single-byte fonts, we might still need to use #. Not sure. On 07.01.2011 14:17:42 Simon Pepping wrote: On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 --- Comment #4 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 07:31:03 EST --- Very right indeed. So, if no one objects, I will apply the patch as proposed. FOP will no longer crash, but simply show a '#' for such unassigned codepoints in the output. Treating them as regular alphabetic characters seems to be safe enough for the time being. Would it not be better to use character FFFD, 'Replacement Character', ?, for this? Simon Jeremias Maerki
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On Fri, Jan 07, 2011 at 02:38:49PM +0100, Andreas Delmelle wrote: On 07 Jan 2011, at 14:17, Simon Pepping wrote: Hi Simon, On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: So, if no one objects, I will apply the patch as proposed. FOP will no longer crash, but simply show a '#' for such unassigned codepoints in the output. Treating them as regular alphabetic characters seems to be safe enough for the time being. Would it not be better to use character FFFD, 'Replacement Character', �, for this? Interesting. In the context of linebreaking, that comes down to basically the same thing. U+FFFD has linebreak class 'AI' or 'Ambiguous', which is currently also converted to 'Alphabetic' as part of the initial conversions. Are you suggesting that we substitute the codepoint in the actual text content (rather than leave it there, and further rely on the default treatment of 'missing glyphs')? I had not yet thought so far. I reflected on the use of '#' as the replacement character for missing glyphs. Is that not particular to FOP, and should we not conform to Unicode and use the Unicode replacement character in such situations? Really replacing the character in the text would go very far. A missing glyph is usually dependent on the chosen font, while the character itself is quite valid. In this case, however, the character itself is invalid, in the sense that the code point has not been assigned to a character in Unicode. (The bug report calls 1F7E a Greek extended character, but the Unicode chart for Greek extended characters, http://www.unicode.org/charts/PDF/U1F00.pdf, shows no character assignment for this code point.) That means that it does not even have properties, such as a linebreaking class. Using class 'Ambiguous' seems the right solution for that problem. Simon
RE: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
I've been trying to see if I can modify the source to eliminate the fonts that come packaged with it. I'm not sure why it needs to include Courier, Helvetica, etc. I would think they're just a waste of space if FOP is designed to use custom fonts or installed fonts. I pass in custom fonts using only Lucida which comes in one file for normal, one for bold, one for unicode, and should be a different one for italic which I haven't needed yet. I'm passing in the files that came with Windows XP in the fonts folder, l_10646.ttf for unicode. For FOP to display a unicode character for the 'glyph not found' error rather than one of standard ascii, it should come packaged with a unicode font set. I print the #x25A1; character to my reports and passing in the l_10646.ttf font that works fine. -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Friday, January 07, 2011 8:44 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException. I think so. The use of # is mostly historical due to lack of Unicode support initially. At least I believe so. The first fonts were WinAnsi only. IMO, it makes sense to make that transition. However, for single-byte fonts, we might still need to use #. Not sure. On 07.01.2011 14:17:42 Simon Pepping wrote: On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 --- Comment #4 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 07:31:03 EST --- Very right indeed. So, if no one objects, I will apply the patch as proposed. FOP will no longer crash, but simply show a '#' for such unassigned codepoints in the output. Treating them as regular alphabetic characters seems to be safe enough for the time being. Would it not be better to use character FFFD, 'Replacement Character', ?, for this? Simon Jeremias Maerki
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On 07.01.2011 15:06:19 Eric Douglas wrote: I've been trying to see if I can modify the source to eliminate the fonts that come packaged with it. I'm not sure why it needs to include Courier, Helvetica, etc. The PDF specification requires support for the so-called Base 14 fonts. And so does the PostScript spec. We don't actually include the fonts, just the font metrics. So this hardly needs any space. I would think they're just a waste of space if FOP is designed to use custom fonts or installed fonts. I pass in custom fonts using only Lucida which comes in one file for normal, one for bold, one for unicode, and should be a different one for italic which I haven't needed yet. I'm passing in the files that came with Windows XP in the fonts folder, l_10646.ttf for unicode. For FOP to display a unicode character for the 'glyph not found' error rather than one of standard ascii, it should come packaged with a unicode font set. I print the #x25A1; character to my reports and passing in the l_10646.ttf font that works fine. -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Friday, January 07, 2011 8:44 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException. I think so. The use of # is mostly historical due to lack of Unicode support initially. At least I believe so. The first fonts were WinAnsi only. IMO, it makes sense to make that transition. However, for single-byte fonts, we might still need to use #. Not sure. On 07.01.2011 14:17:42 Simon Pepping wrote: On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 --- Comment #4 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 07:31:03 EST --- Very right indeed. So, if no one objects, I will apply the patch as proposed. FOP will no longer crash, but simply show a '#' for such unassigned codepoints in the output. Treating them as regular alphabetic characters seems to be safe enough for the time being. Would it not be better to use character FFFD, 'Replacement Character', ?, for this? Simon Jeremias Maerki Jeremias Maerki
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On Fri, Jan 07, 2011 at 02:44:13PM +0100, Jeremias Maerki wrote: I think so. The use of # is mostly historical due to lack of Unicode support initially. At least I believe so. The first fonts were WinAnsi only. IMO, it makes sense to make that transition. However, for single-byte fonts, we might still need to use #. Not sure. Then it might be better to use '?', which many tools use for that purpose. Let us put that on our wish list. It is not part of the fix for this bug report. Simon On 07.01.2011 14:17:42 Simon Pepping wrote: On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 --- Comment #4 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 07:31:03 EST --- Very right indeed. So, if no one objects, I will apply the patch as proposed. FOP will no longer crash, but simply show a '#' for such unassigned codepoints in the output. Treating them as regular alphabetic characters seems to be safe enough for the time being. Would it not be better to use character FFFD, 'Replacement Character', ?, for this?
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On 07 Jan 2011, at 14:58, Simon Pepping wrote: snip / I had not yet thought so far. I reflected on the use of '#' as the replacement character for missing glyphs. Is that not particular to FOP, and should we not conform to Unicode and use the Unicode replacement character in such situations? OK, I see now. That's indeed FOP legacy, and it seems preferable to show U+FFFD in such cases, if possible. As for the effort involved, it could turn out to be fairly straightforward to change this behavior. The # replacement char is hardcoded as org.apache.fop.fonts.Typeface.NOT_FOUND, which is used in only three places (the mapChar() implementations of Font, SingleByteFont and MultiByteFont). snip / ...PDF/U1F00.pdf, shows no character assignment for this code point.) That means that it does not even have properties, such as a linebreaking class. Using class 'Ambiguous' seems the right solution for that problem. OK, I will make sure this is reflected in the code-comment. Regards, Andreas ---
Custom FOP
That seems odd, to include information for fonts which are never used. I'll just ignore that then. It just seemed like that would be putting a lot into the jar which will never be needed. I'm running in webstart, referencing fop.jar in the jnlp, so anything in the jar has to be copied to the client. My next task is print preview. I'm using custom windows and embedding org.apache.fop.render.awt.viewer.PreviewPanel. That works except I have to create it with a useragent and a renderer which takes forever. I'm wondering if I can use a version of this class without a useragent or a renderer. If I can pass in a rendered document as an array of pages as images instead of a renderable object, can I still do the scale resizing? Other than the zoom in the preview there's no reason I need a renderable object here. I'm keeping a copy of the renderable source on the server while displaying the preview. Sending the output to a printer or generating a PDF can be done on the server. I'm saving the PDF to the client but I'm getting the output from FOP as the byte stream so I just copy bytes to the client and save them. The renderer, transformer, etc should never have to exist on the client. -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Friday, January 07, 2011 9:35 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException. On 07.01.2011 15:06:19 Eric Douglas wrote: I've been trying to see if I can modify the source to eliminate the fonts that come packaged with it. I'm not sure why it needs to include Courier, Helvetica, etc. The PDF specification requires support for the so-called Base 14 fonts. And so does the PostScript spec. We don't actually include the fonts, just the font metrics. So this hardly needs any space.
DO NOT REPLY [Bug 43166] unclosed border on nested inlines
https://issues.apache.org/bugzilla/show_bug.cgi?id=43166 Simon Pepping spepp...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Simon Pepping spepp...@apache.org 2011-01-07 10:48:08 EST --- Works OK now, probably due to the improvements in revision 1052561. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: DO NOT REPLY [Bug 48380] ClassCastException when using fox:widow-content-limit
Your patch seems OK to me. Even though the conditionals handle some tricky navigation through the list, this is the best way to use the similarities between the two methods. Will you apply it? Simon On Wed, Jan 05, 2011 at 02:01:55PM -0500, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=48380 --- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2011-01-05 14:01:49 EST --- Created an attachment (id=26460) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26460) proposed patch to ElementListUtils.java Apologies for the late response... I noticed the issue did not occur with fox:orphan-content-limit, since that triggers a call to ElementListUtils.removeLegalBreaksFromEnd(), which was equipped to deal with SpaceElements, contrary to the method removeLegalBreaks(), where the exception was thrown. Seems like the implementations of both methods were meant to be analogous, but got out of alignment. Proposal is to fix this by merging the implementations into one private method, as they were almost identical anyway (apart from 3-4 lines, which can be handled rather gracefully through conditionals). For now, the proposed fix does not alter the behavior in any way, except by avoiding the potential ClassCastException, although it did get me wondering whether the treatment of spaces is always correct here... Think: consecutive/adjoining spaces with a different precedence value, and whether it is correct to just add the space's optimum width. Theoretically, it seems possible that we leave in a break-opportunity that turns out (= after space-resolution) to leave less content before the break than the constraint specifies, because we counted 2 spaces here, of which only one is retained in the eventual output (?) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49186] Empty fo:inline objects with id attribute generate blank line
https://issues.apache.org/bugzilla/show_bug.cgi?id=49186 --- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 12:18:10 EST --- Not immediately dismissing this, but it did get me wondering which situation is wrong. FOP does not generate an area for empty inlines if they have no id or markers that should be tracked, which is why there is a difference between the two cases. Now, if we have: fo:block white-space-treatment=preserve fo:blockThere should be a blank line between this block/fo:block fo:blockand this block/fo:block /fo:block The output is rendered, as expected, with a line in between both blocks containing only a single space character. Same without white-space preservation, but only a zero-width space fo:block fo:blockThere should be a blank line between this block/fo:block #x200B; fo:blockand this block/fo:block /fo:block Checking http://www.w3.org/TR/xsl/#area-inline, it seems like even empty inlines are in fact supposed to generate an area (= content/allocation rectangle), regardless of whether an id or marker is present (?). If that is so, then /that/ would be the case that needs fixing, contrary to what the bug description indicates. The only way to really avoid that spurious blank space, would be to set the font-size of the empty inline to 0pt. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: DO NOT REPLY [Bug 48380] ClassCastException when using fox:widow-content-limit
On 07 Jan 2011, at 17:03, Simon Pepping wrote: Your patch seems OK to me. Even though the conditionals handle some tricky navigation through the list, this is the best way to use the similarities between the two methods. Will you apply it? Sure, will do! Regards Andreas
DO NOT REPLY [Bug 48534] java.lang.StringIndexOutOfBoundsException
https://issues.apache.org/bugzilla/show_bug.cgi?id=48534 --- Comment #3 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 13:33:50 EST --- The crash is indeed a bug. However, I believe it is also erroneous to have the following property specifications (appearing twice in the sample document, and causing the issue): hyphenation-character= hyphenation-push-character-count= hyphenation-remain-character-count= Whether this should be treated as a recoverable error could be made to depend on the 'strict-validation' config option. If validation is relaxed, then we could just use the initial values. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
RE: DO NOT REPLY [Bug 49186] Empty fo:inline objects with id attribute generate blank line
I try not to let it do anything by default so I don't have to worry about anything changing in a future version. I write programs which create my xml input, I'm not trying to read in text like a book, so I don't have any linefeeds. All text blocks fit on one line. I don't worry about where text ends up on the page because I've already calculated that. All my blocks use absolute positioning. Sometimes blocks have automatic stuff like padding, like this line spacing you describe. I get around it with code like this. fo:block-container xsl:attribute name=text-alignstart/xsl:attribute xsl:attribute name=padding-top0px/xsl:attribute xsl:attribute name=padding-bottom0px/xsl:attribute xsl:attribute name=padding-right0px/xsl:attribute xsl:attribute name=linefeed-treatmentpreserve/xsl:attribute For a block with no text in it, for other purposes, you can throw in one of these. fo:block xsl:attribute name=line-height0/xsl:attribute A lot of people put xsl tags in line as you've done there with white-space-treatment, but I think it's easier to read if you split them out to their own tags. -Original Message- From: bugzi...@apache.org [mailto:bugzi...@apache.org] Sent: Friday, January 07, 2011 12:18 PM To: fop-dev@xmlgraphics.apache.org Subject: DO NOT REPLY [Bug 49186] Empty fo:inline objects with id attribute generate blank line https://issues.apache.org/bugzilla/show_bug.cgi?id=49186 --- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 12:18:10 EST --- Not immediately dismissing this, but it did get me wondering which situation is wrong. FOP does not generate an area for empty inlines if they have no id or markers that should be tracked, which is why there is a difference between the two cases. Now, if we have: fo:block white-space-treatment=preserve fo:blockThere should be a blank line between this block/fo:block fo:blockand this block/fo:block /fo:block The output is rendered, as expected, with a line in between both blocks containing only a single space character. Same without white-space preservation, but only a zero-width space fo:block fo:blockThere should be a blank line between this block/fo:block #x200B; fo:blockand this block/fo:block /fo:block Checking http://www.w3.org/TR/xsl/#area-inline, it seems like even empty inlines are in fact supposed to generate an area (= content/allocation rectangle), regardless of whether an id or marker is present (?). If that is so, then /that/ would be the case that needs fixing, contrary to what the bug description indicates. The only way to really avoid that spurious blank space, would be to set the font-size of the empty inline to 0pt. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48380] ClassCastException when using fox:widow-content-limit
https://issues.apache.org/bugzilla/show_bug.cgi?id=48380 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 16:18:15 EST --- Fixed in Trunk. See: http://svn.apache.org/viewvc?rev=1056513view=rev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: DO NOT REPLY [Bug 49186] Empty fo:inline objects with id attribute generate blank line
On 07 Jan 2011, at 20:13, Eric Douglas wrote: Hi snip / A lot of people put xsl tags in line as you've done there with white-space-treatment, but I think it's easier to read if you split them out to their own tags. Actually, I was just writing plain FO (= what results after applying the XSLT). Regards, Andreas ---
DO NOT REPLY [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Andreas L. Delmelle adelme...@apache.org 2011-01-07 16:28:06 EST --- Fixed in Trunk. See: http://svn.apache.org/viewvc?rev=1056518view=rev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
RE: DO NOT REPLY [Bug 49186] Empty fo:inline objects with id attribute generate blank line
Interesting. I write it out neatly in the xsl. I don't normally look at the fo. I run embedded code where I normally run a transform with an output result created from the FOP handler so I get out a document and any fo generated would stay within the transformer. If I run that same transform with an empty byte stream result it gets the fo, so I have done that a few times and saved the fo code to files which I never look at unless there's an error to debug. I see that fo does combine the attributes. Of course writing code in fo wouldn't make much sense since it has the xml input in it unless you're printing a document where nothing changes. -Original Message- From: Andreas Delmelle [mailto:andreas.delme...@telenet.be] Sent: Friday, January 07, 2011 4:28 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: DO NOT REPLY [Bug 49186] Empty fo:inline objects with id attribute generate blank line On 07 Jan 2011, at 20:13, Eric Douglas wrote: Hi snip / A lot of people put xsl tags in line as you've done there with white-space-treatment, but I think it's easier to read if you split them out to their own tags. Actually, I was just writing plain FO (= what results after applying the XSLT). Regards, Andreas ---
