[jira] [Assigned] (FOP-2173) [PATCH] SVG postscript crash
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2173: --- Assignee: Chris Bowditch > [PATCH] SVG postscript crash > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: fop.xconf, svgcrash.patch, test.fo > > > SVG text postscript crash using multibyte characters -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2173: Description: When more than 255 characters are used from within SVG and a custom Font the Postscript generated is invalid. This is evident either as a crash in evince (Linux) or missing characters in Windows version of Ghostview. The problem is likely to be evident on printers as well. (was: SVG text postscript crash using multibyte characters) Summary: [PATCH] Invalid Postscript created with SVG and custom fonts (was: [PATCH] SVG postscript crash) > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2173: Description: When more than 255 characters are used from within SVG and a custom Font the Postscript generated is invalid. This is evident either as a crash in evince (Linux) or missing characters in Windows version of Ghostview. The problem is likely to be evident on printers as well. (was: SVG text postscript crash using multibyte characters) Summary: [PATCH] Invalid Postscript created with SVG and custom fonts (was: [PATCH] SVG postscript crash) > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534019#comment-13534019 ] Chris Bowditch commented on FOP-2173: - Hi Simon, Thanks for your patch. When running your test file I didn't get a crash as you originally described using Ghostview. Instead I got the following warnings: Can't find (or can't open) font file C:\Program Files\gs\gs8.53\Resource/Font/DejaVuSans_1. Can't find (or can't open) font file DejaVuSans_1. Querying operating system for font files... Didn't find this font on the system! Substituting font Courier for DejaVuSans_1. Visually I noticed that some characters were missing from the second set. Looking at the code changes themselves, I can see you've introduced a couple of checkstyle errors related to the order of imports. That's easy to fix but please check that yourself next time. Committed in revision 1422992 > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534019#comment-13534019 ] Chris Bowditch commented on FOP-2173: - Hi Simon, Thanks for your patch. When running your test file I didn't get a crash as you originally described using Ghostview. Instead I got the following warnings: Can't find (or can't open) font file C:\Program Files\gs\gs8.53\Resource/Font/DejaVuSans_1. Can't find (or can't open) font file DejaVuSans_1. Querying operating system for font files... Didn't find this font on the system! Substituting font Courier for DejaVuSans_1. Visually I noticed that some characters were missing from the second set. Looking at the code changes themselves, I can see you've introduced a couple of checkstyle errors related to the order of imports. That's easy to fix but please check that yourself next time. Committed in revision 1422992 > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2173. - Resolution: Fixed > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2173: Fix Version/s: trunk > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Fix For: trunk > > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534019#comment-13534019 ] Chris Bowditch commented on FOP-2173: - Hi Simon, Thanks for your patch. When running your test file I didn't get a crash as you originally described using Ghostview. Instead I got the following warnings: Can't find (or can't open) font file C:\Program Files\gs\gs8.53\Resource/Font/DejaVuSans_1. Can't find (or can't open) font file DejaVuSans_1. Querying operating system for font files... Didn't find this font on the system! Substituting font Courier for DejaVuSans_1. Visually I noticed that some characters were missing from the second set. Looking at the code changes themselves, I can see you've introduced a couple of checkstyle errors related to the order of imports. That's easy to fix but please check that yourself next time. Committed in revision 1422992 > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2173. - Resolution: Fixed > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2173) [PATCH] Invalid Postscript created with SVG and custom fonts
[ https://issues.apache.org/jira/browse/FOP-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2173: Fix Version/s: trunk > [PATCH] Invalid Postscript created with SVG and custom fonts > > > Key: FOP-2173 > URL: https://issues.apache.org/jira/browse/FOP-2173 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Fix For: trunk > > Attachments: fop.xconf, svgcrash.patch, test.fo > > > When more than 255 characters are used from within SVG and a custom Font the > Postscript generated is invalid. This is evident either as a crash in evince > (Linux) or missing characters in Windows version of Ghostview. The problem is > likely to be evident on printers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2174) [PATCH] When using SVG drawings, if no content-width and content-height is specified, 72 will be used instead of the source-resolution option.
[ https://issues.apache.org/jira/browse/FOP-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2174: Assignee: Chris Bowditch > [PATCH] When using SVG drawings, if no content-width and content-height is > specified, 72 will be used instead of the source-resolution option. > -- > > Key: FOP-2174 > URL: https://issues.apache.org/jira/browse/FOP-2174 > Project: Fop > Issue Type: Bug > Components: images >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Chris Bowditch >Priority: Minor > Fix For: trunk > > Attachments: output-144.pdf, patch.diff, test.fo > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2174) [PATCH] When using SVG drawings, if no content-width and content-height is specified, 72 will be used instead of the source-resolution option.
[ https://issues.apache.org/jira/browse/FOP-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13535966#comment-13535966 ] Chris Bowditch commented on FOP-2174: - Hi Rob, Thanks for your patch. The test FO uses an image file basi2c08.png. Can you upload that also? There is also an additional FindBugs warning introduced by your changes: Should org.apache.fop.layoutmgr.inline.ImageLayout$DefaultLength be a _static_ inner class? Thanks, Chris > [PATCH] When using SVG drawings, if no content-width and content-height is > specified, 72 will be used instead of the source-resolution option. > -- > > Key: FOP-2174 > URL: https://issues.apache.org/jira/browse/FOP-2174 > Project: Fop > Issue Type: Bug > Components: images >Affects Versions: trunk >Reporter: Robert Meyer >Priority: Minor > Fix For: trunk > > Attachments: output-144.pdf, patch.diff, test.fo > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2160) [PATCH] writing-mode="rl" causing null-pointer-exception
[ https://issues.apache.org/jira/browse/FOP-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2160: Priority: Blocker Summary: [PATCH] writing-mode="rl" causing null-pointer-exception (was: [PATCH] writing-mode="lr" causing null-pointer-exception) > [PATCH] writing-mode="rl" causing null-pointer-exception > > > Key: FOP-2160 > URL: https://issues.apache.org/jira/browse/FOP-2160 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1 > Environment: Operating System: All > Platform: All >Reporter: james quest >Priority: Blocker > Attachments: patch.diff, stack > > > i have seen that this fo causes a null-pointer-exception at fop1.1rc1. > the same fo is perfectly fine if writing-mode="lr" or not specified > http://www.w3.org/1999/XSL/Format"; font-family="Arial" > writing-mode="rl"> > > master-name="a4"> >margin-right="10mm" margin-left="10mm"/> > > > > > وكلما > More text leader-pattern="dots"/> > > > > > attached is the stack trace. > if you remove *any* of these 3 things, then there is no issue either > 1. > 2. > 3. text-align-last="justify" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2160) [PATCH] writing-mode="rl" causing null-pointer-exception
[ https://issues.apache.org/jira/browse/FOP-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536000#comment-13536000 ] Chris Bowditch commented on FOP-2160: - Hi Rob, I concur that your patch fixes the NPE. However, I don't think the test file is laid out correctly. "More Text" is not fully right aligned. It could be that the variation factor not being applied is the cause of the incorrect placement so further investigation to determine why it is null in this case is required. Thanks, Chris > [PATCH] writing-mode="rl" causing null-pointer-exception > > > Key: FOP-2160 > URL: https://issues.apache.org/jira/browse/FOP-2160 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1 > Environment: Operating System: All > Platform: All >Reporter: james quest >Priority: Blocker > Attachments: patch.diff, stack > > > i have seen that this fo causes a null-pointer-exception at fop1.1rc1. > the same fo is perfectly fine if writing-mode="lr" or not specified > http://www.w3.org/1999/XSL/Format"; font-family="Arial" > writing-mode="rl"> > > master-name="a4"> >margin-right="10mm" margin-left="10mm"/> > > > > > وكلما > More text leader-pattern="dots"/> > > > > > attached is the stack trace. > if you remove *any* of these 3 things, then there is no issue either > 1. > 2. > 3. text-align-last="justify" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-1976) [PATCH] last simple-page-master not chosen when force-page-count=odd
[ https://issues.apache.org/jira/browse/FOP-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536004#comment-13536004 ] Chris Bowditch commented on FOP-1976: - Hi Matthias, Thanks for pointing out the flaw in the current logic. Can you upload a test FO file that demonstrates the issue? Thanks, Chris > [PATCH] last simple-page-master not chosen when force-page-count=odd > > > Key: FOP-1976 > URL: https://issues.apache.org/jira/browse/FOP-1976 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Mehdi Houshmand > Attachments: pagebreaker.patch > > > If force-page-count="odd" and the first page has an overflowing region onto a > second page, then the 3rd and last page should use the page-position="last" > simple-page-master in the conditional-page-master-reference. However, it was > using the "rest". > I'm having a few issues with the apache git server, so I'll attach the patch > when the issues have been resolved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-1976) [PATCH] last simple-page-master not chosen when force-page-count=odd
[ https://issues.apache.org/jira/browse/FOP-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536004#comment-13536004 ] Chris Bowditch commented on FOP-1976: - Hi Matthias, Thanks for pointing out the flaw in the current logic. Can you upload a test FO file that demonstrates the issue? Thanks, Chris > [PATCH] last simple-page-master not chosen when force-page-count=odd > > > Key: FOP-1976 > URL: https://issues.apache.org/jira/browse/FOP-1976 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Mehdi Houshmand > Attachments: pagebreaker.patch > > > If force-page-count="odd" and the first page has an overflowing region onto a > second page, then the 3rd and last page should use the page-position="last" > simple-page-master in the conditional-page-master-reference. However, it was > using the "rest". > I'm having a few issues with the apache git server, so I'll attach the patch > when the issues have been resolved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2172) [PATCH] PDF image not rotated in PS/AFP
[ https://issues.apache.org/jira/browse/FOP-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2172: --- Assignee: Chris Bowditch > [PATCH] PDF image not rotated in PS/AFP > --- > > Key: FOP-2172 > URL: https://issues.apache.org/jira/browse/FOP-2172 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: 128521~e9e94ba4.PDF, rotate.patch, test.fo > > > There is a rotate command inside pdf files that is not operated on by the pdf > plugin, so when PS or AFP is created the image is not rotated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2172) [PATCH] PDF image not rotated in PS/AFP
[ https://issues.apache.org/jira/browse/FOP-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536058#comment-13536058 ] Chris Bowditch commented on FOP-2172: - Hi Simon, Many thanks for the patch. It looks fine apart from checkstyle warnings about trailing spaces in ImageConverterPDF2G2D.java Applied in revision 1423905 Thanks, Chris > [PATCH] PDF image not rotated in PS/AFP > --- > > Key: FOP-2172 > URL: https://issues.apache.org/jira/browse/FOP-2172 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: 128521~e9e94ba4.PDF, rotate.patch, test.fo > > > There is a rotate command inside pdf files that is not operated on by the pdf > plugin, so when PS or AFP is created the image is not rotated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2172) [PATCH] PDF image not rotated in PS/AFP
[ https://issues.apache.org/jira/browse/FOP-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2172. - Resolution: Fixed Fix Version/s: trunk > [PATCH] PDF image not rotated in PS/AFP > --- > > Key: FOP-2172 > URL: https://issues.apache.org/jira/browse/FOP-2172 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Fix For: trunk > > Attachments: 128521~e9e94ba4.PDF, rotate.patch, test.fo > > > There is a rotate command inside pdf files that is not operated on by the pdf > plugin, so when PS or AFP is created the image is not rotated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2174) [PATCH] When using SVG drawings, if no content-width and content-height is specified, 72 will be used instead of the source-resolution option.
[ https://issues.apache.org/jira/browse/FOP-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13543940#comment-13543940 ] Chris Bowditch commented on FOP-2174: - Thanks for the updates patch Rob. I have committed it however there was a minor checktyle issue reported related to the "?" ending the line instead of starting a new line. Patch applied in revision 1428918 > [PATCH] When using SVG drawings, if no content-width and content-height is > specified, 72 will be used instead of the source-resolution option. > -- > > Key: FOP-2174 > URL: https://issues.apache.org/jira/browse/FOP-2174 > Project: Fop > Issue Type: Bug > Components: images >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Chris Bowditch >Priority: Minor > Fix For: trunk > > Attachments: basi2c08.png, output-144-expected.pdf, output-144.pdf, > patch2.diff, patch.diff, test.fo > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2174) [PATCH] When using SVG drawings, if no content-width and content-height is specified, 72 will be used instead of the source-resolution option.
[ https://issues.apache.org/jira/browse/FOP-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2174. - Resolution: Fixed > [PATCH] When using SVG drawings, if no content-width and content-height is > specified, 72 will be used instead of the source-resolution option. > -- > > Key: FOP-2174 > URL: https://issues.apache.org/jira/browse/FOP-2174 > Project: Fop > Issue Type: Bug > Components: images >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Chris Bowditch >Priority: Minor > Fix For: trunk > > Attachments: basi2c08.png, output-144-expected.pdf, output-144.pdf, > patch2.diff, patch.diff, test.fo > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2189) Apache FOP 1.0 Multithreading Problems - Too many open files err24
[
https://issues.apache.org/jira/browse/FOP-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557259#comment-13557259
]
Chris Bowditch commented on FOP-2189:
-
The FontFileReader class has been refactored in trunk. Both the constructors
listed above have been removed in favour of the init method that beens renamed
into the constructor. That doesnt contain an explicit call to close, but the
classes calling FontFileReader such as TTFFontLoader now call close in their
finally block, e.g.
InputStream in = resourceResolver.getResource(this.fontFileURI);
try {
TTFFile ttf = new TTFFile(useKerning, useAdvanced);
FontFileReader reader = new FontFileReader(in);
boolean supported = ttf.readFont(reader, ttcFontName);
if (!supported) {
throw new IOException("TrueType font is not supported: " +
fontFileURI);
}
buildFont(ttf, ttcFontName);
loaded = true;
} finally {
IOUtils.closeQuietly(in);
}
Therefore I believe this issue is resolved in trunk and this bug can be closed.
You will need to upgrade to trunk to your resolve the problem in your
environment.
> Apache FOP 1.0 Multithreading Problems - Too many open files err24
> --
>
> Key: FOP-2189
> URL: https://issues.apache.org/jira/browse/FOP-2189
> Project: Fop
> Issue Type: Bug
> Components: pdf
>Affects Versions: 1.0
> Environment: HP Unix
>Reporter: Joey Ezekiel
> Labels: Exception, Font", IOException, PDF, error
>
> We use Apache FOP to convert a whole lot of XML's to AFP's and PDF's. Our
> current load would be around 25k files per run on a HP-UX system. We have 12
> threads in total that are used to initialize and trigger the FOP conversion
> in a producer-consumer fashion. Recently there have been multiple failures
> during conversion and when looked up, we've received generic FOP errors like:
> **ERROR,2460364,FOToPDF_Thread_11,FOP Exception, something.pdf,Failed to
> resolve font with embed-url './Fonts/arial.ttf'**
> or its an error failing to load the font metrics file although the files are
> intact with the right permissions. Many other PDF's are generated so this
> can't be the problem.
> We also wind up with:
> **java.io.FileNotFoundException: /PDF/2013030002/something.pdf (Too many
> open files (errno:24))**
> judging by the logs and volume being processed, this looks like an FOP
> problem. I've read that FOP has had this issue in the past with the font
> files. There have been instances where Apache has opened each font file
> multiple times and not closed the handles resulting in a large number of open
> files. This was supposed to be fixed, but if it still persists, what would be
> a good and quick solution to this?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (FOP-2189) Apache FOP 1.0 Multithreading Problems - Too many open files err24
[
https://issues.apache.org/jira/browse/FOP-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557259#comment-13557259
]
Chris Bowditch edited comment on FOP-2189 at 1/18/13 3:08 PM:
--
The FontFileReader class has been refactored in trunk. Both the constructors
listed above have been removed in favour of the init method thats been renamed
into the constructor. That doesnt contain an explicit call to close, but the
classes calling FontFileReader such as TTFFontLoader now call close in their
finally block, e.g.
InputStream in = resourceResolver.getResource(this.fontFileURI);
try {
TTFFile ttf = new TTFFile(useKerning, useAdvanced);
FontFileReader reader = new FontFileReader(in);
boolean supported = ttf.readFont(reader, ttcFontName);
if (!supported) {
throw new IOException("TrueType font is not supported: " +
fontFileURI);
}
buildFont(ttf, ttcFontName);
loaded = true;
} finally {
IOUtils.closeQuietly(in);
}
Therefore I believe this issue is resolved in trunk and this bug can be closed.
You will need to upgrade to trunk to your resolve the problem in your
environment.
was (Author: cbowditch):
The FontFileReader class has been refactored in trunk. Both the
constructors listed above have been removed in favour of the init method that
beens renamed into the constructor. That doesnt contain an explicit call to
close, but the classes calling FontFileReader such as TTFFontLoader now call
close in their finally block, e.g.
InputStream in = resourceResolver.getResource(this.fontFileURI);
try {
TTFFile ttf = new TTFFile(useKerning, useAdvanced);
FontFileReader reader = new FontFileReader(in);
boolean supported = ttf.readFont(reader, ttcFontName);
if (!supported) {
throw new IOException("TrueType font is not supported: " +
fontFileURI);
}
buildFont(ttf, ttcFontName);
loaded = true;
} finally {
IOUtils.closeQuietly(in);
}
Therefore I believe this issue is resolved in trunk and this bug can be closed.
You will need to upgrade to trunk to your resolve the problem in your
environment.
> Apache FOP 1.0 Multithreading Problems - Too many open files err24
> --
>
> Key: FOP-2189
> URL: https://issues.apache.org/jira/browse/FOP-2189
> Project: Fop
> Issue Type: Bug
> Components: pdf
>Affects Versions: 1.0
> Environment: HP Unix
>Reporter: Joey Ezekiel
> Labels: Exception, Font", IOException, PDF, error
>
> We use Apache FOP to convert a whole lot of XML's to AFP's and PDF's. Our
> current load would be around 25k files per run on a HP-UX system. We have 12
> threads in total that are used to initialize and trigger the FOP conversion
> in a producer-consumer fashion. Recently there have been multiple failures
> during conversion and when looked up, we've received generic FOP errors like:
> **ERROR,2460364,FOToPDF_Thread_11,FOP Exception, something.pdf,Failed to
> resolve font with embed-url './Fonts/arial.ttf'**
> or its an error failing to load the font metrics file although the files are
> intact with the right permissions. Many other PDF's are generated so this
> can't be the problem.
> We also wind up with:
> **java.io.FileNotFoundException: /PDF/2013030002/something.pdf (Too many
> open files (errno:24))**
> judging by the logs and volume being processed, this looks like an FOP
> problem. I've read that FOP has had this issue in the past with the font
> files. There have been instances where Apache has opened each font file
> multiple times and not closed the handles resulting in a large number of open
> files. This was supposed to be fixed, but if it still persists, what would be
> a good and quick solution to this?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2189) Apache FOP 1.0 Multithreading Problems - Too many open files err24
[ https://issues.apache.org/jira/browse/FOP-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2189. - Resolution: Fixed Fix Version/s: trunk > Apache FOP 1.0 Multithreading Problems - Too many open files err24 > -- > > Key: FOP-2189 > URL: https://issues.apache.org/jira/browse/FOP-2189 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.0 > Environment: HP Unix >Reporter: Joey Ezekiel > Labels: Exception, Font", IOException, PDF, error > Fix For: trunk > > > We use Apache FOP to convert a whole lot of XML's to AFP's and PDF's. Our > current load would be around 25k files per run on a HP-UX system. We have 12 > threads in total that are used to initialize and trigger the FOP conversion > in a producer-consumer fashion. Recently there have been multiple failures > during conversion and when looked up, we've received generic FOP errors like: > **ERROR,2460364,FOToPDF_Thread_11,FOP Exception, something.pdf,Failed to > resolve font with embed-url './Fonts/arial.ttf'** > or its an error failing to load the font metrics file although the files are > intact with the right permissions. Many other PDF's are generated so this > can't be the problem. > We also wind up with: > **java.io.FileNotFoundException: /PDF/2013030002/something.pdf (Too many > open files (errno:24))** > judging by the logs and volume being processed, this looks like an FOP > problem. I've read that FOP has had this issue in the past with the font > files. There have been instances where Apache has opened each font file > multiple times and not closed the handles resulting in a large number of open > files. This was supposed to be fixed, but if it still persists, what would be > a good and quick solution to this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2204) copy from PDF returns PUA characters
[ https://issues.apache.org/jira/browse/FOP-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570117#comment-13570117 ] Chris Bowditch commented on FOP-2204: - There's some technical insight related to this issue from Vincent on the following thread: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/201301.mbox/%3c510a3810.5070...@gmail.com%3e > copy from PDF returns PUA characters > > > Key: FOP-2204 > URL: https://issues.apache.org/jira/browse/FOP-2204 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1, trunk >Reporter: Glenn Adams >Assignee: Glenn Adams > > when generating PDF that contains embedded fonts in which dynamic PUA > characters have been assigned, copy operations from a PDF viewer result in > those PUA characters being exported in a manner that precludes subsequent > correct display; this primarily affects the PDF output when complex script > features are used with fonts that do not have a CMAP entry for every > referenced glyph -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581324#comment-13581324
]
Chris Bowditch commented on FOP-2211:
-
Hi Alex,
I agree that Print Streams can get very large and holding them in memory is not
a good idea. Actually for cloud environments we don't plan to hold such files
in memory, but rather in a virtual file system, one that is ring fenced for
each tenant. Unlike a file system, where every tenant can see the files for
every other tenant on the system, the virtual file system protects against
this. The virtual file system is typically implemented using a Database.
Hopefully this helps clarifies our intentions from a requirements perspective.
I cannot comment on the lower level details.
Thanks,
Chris
> [PATCH] Fix & improve the handling of temporary files using the new URI
> resource resolvers
> --
>
> Key: FOP-2211
> URL: https://issues.apache.org/jira/browse/FOP-2211
> Project: Fop
> Issue Type: Bug
> Components: general
>Affects Versions: trunk
>Reporter: Alexios Giotis
> Fix For: trunk
>
> Attachments: fop.patch, xgc.patch
>
>
> As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
> of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
> temp files has changed from:
> {code}
> File tmpFile = File.createTempFile();
> // Write and read from the file
> tmpFile.delete();
> {code}
> to:
> {code}
> File tmpFile = new File(System.getProperty("java.io.tmpdir"),
> counterStartingFrom1AsString);
> tmpFile.deleteOnExit();
> // Write and read from the file
> {code}
> This is fine when FOP is executed from the command line (which I guess this
> is how most people use it) but it introduces a number of bad side effects for
> long running processes that use FOP embedded.
>
> 1. Different FOP processes can't be executed in parallel on the same system
> because creating the same temp file fails.
> 2. If the JVM is not normally terminated, the temp files are never deleted
> and the next invocation of the JVM fails to run.
> 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
> files both on disk and a reference in memory.
> There should not be a need to implement a custom resource resolver when using
> FOP embedded in order to fix those issues. The default implementation should
> work at least as good as it worked in FOP 1.1 or earlier.
> Attached are 2 patches, one for XGC and one for FOP that should fix and
> improve the handling of at least the temporary files.
> For reference, [1] lists some reasons for implementing the new URI resource
> resolvers.
> [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583091#comment-13583091
]
Chris Bowditch commented on FOP-2211:
-
Hi Alexios.
A Virtual File System is a really useful tool in a cloud environment as
different components running on different physical machines can talk to each
other and read/write data to shared resources, without having to rely on shared
drives.
It may be unlikely that a temp file written by tenant A can be read by tenant
B, but compliance dictates that we should put safeguards in place to esnure 0%
risk of such an occurance, We have the virtual file system which is partitioned
by tenant so why not use that? Just need an interface in FOP to allow temp
files to be handled in a way other than temp files. Of course that interface
should not prevent temporary data still being handled in temp files, so we will
look to make the necessary revisions to ensure both use cases are possible.
Thanks,
Chris
> [PATCH] Fix & improve the handling of temporary files using the new URI
> resource resolvers
> --
>
> Key: FOP-2211
> URL: https://issues.apache.org/jira/browse/FOP-2211
> Project: Fop
> Issue Type: Bug
> Components: general
>Affects Versions: trunk
>Reporter: Alexios Giotis
> Fix For: trunk
>
> Attachments: fop.patch, xgc.patch
>
>
> As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
> of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
> temp files has changed from:
> {code}
> File tmpFile = File.createTempFile();
> // Write and read from the file
> tmpFile.delete();
> {code}
> to:
> {code}
> File tmpFile = new File(System.getProperty("java.io.tmpdir"),
> counterStartingFrom1AsString);
> tmpFile.deleteOnExit();
> // Write and read from the file
> {code}
> This is fine when FOP is executed from the command line (which I guess this
> is how most people use it) but it introduces a number of bad side effects for
> long running processes that use FOP embedded.
>
> 1. Different FOP processes can't be executed in parallel on the same system
> because creating the same temp file fails.
> 2. If the JVM is not normally terminated, the temp files are never deleted
> and the next invocation of the JVM fails to run.
> 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
> files both on disk and a reference in memory.
> There should not be a need to implement a custom resource resolver when using
> FOP embedded in order to fix those issues. The default implementation should
> work at least as good as it worked in FOP 1.1 or earlier.
> Attached are 2 patches, one for XGC and one for FOP that should fix and
> improve the handling of at least the temporary files.
> For reference, [1] lists some reasons for implementing the new URI resource
> resolvers.
> [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (FOP-2211) [PATCH] Fix & improve the handling of temporary files using the new URI resource resolvers
[
https://issues.apache.org/jira/browse/FOP-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583091#comment-13583091
]
Chris Bowditch edited comment on FOP-2211 at 2/21/13 10:43 AM:
---
Hi Alexios.
A Virtual File System is a really useful tool in a cloud environment as
different components running on different physical machines can talk to each
other and read/write data to shared resources, without having to rely on shared
drives.
It may be unlikely that a temp file written by tenant A can be read by tenant
B, but compliance dictates that we should put safeguards in place to ensure 0%
risk of such an occurance, We have the virtual file system which is partitioned
by tenant so why not use that? Just need an interface in FOP to allow temp
files to be handled in a way other than temp files. Of course that interface
should not prevent temporary data still being handled in temp files, so we will
look to make the necessary revisions to ensure both use cases are possible.
Thanks,
Chris
was (Author: cbowditch):
Hi Alexios.
A Virtual File System is a really useful tool in a cloud environment as
different components running on different physical machines can talk to each
other and read/write data to shared resources, without having to rely on shared
drives.
It may be unlikely that a temp file written by tenant A can be read by tenant
B, but compliance dictates that we should put safeguards in place to esnure 0%
risk of such an occurance, We have the virtual file system which is partitioned
by tenant so why not use that? Just need an interface in FOP to allow temp
files to be handled in a way other than temp files. Of course that interface
should not prevent temporary data still being handled in temp files, so we will
look to make the necessary revisions to ensure both use cases are possible.
Thanks,
Chris
> [PATCH] Fix & improve the handling of temporary files using the new URI
> resource resolvers
> --
>
> Key: FOP-2211
> URL: https://issues.apache.org/jira/browse/FOP-2211
> Project: Fop
> Issue Type: Bug
> Components: general
>Affects Versions: trunk
>Reporter: Alexios Giotis
> Fix For: trunk
>
> Attachments: fop.patch, xgc.patch
>
>
> As written in http://markmail.org/message/zelumstxxsdyvkcz , after the merge
> of the Temp_URI_Resolution branch (Sept 2012), the actual pattern of using
> temp files has changed from:
> {code}
> File tmpFile = File.createTempFile();
> // Write and read from the file
> tmpFile.delete();
> {code}
> to:
> {code}
> File tmpFile = new File(System.getProperty("java.io.tmpdir"),
> counterStartingFrom1AsString);
> tmpFile.deleteOnExit();
> // Write and read from the file
> {code}
> This is fine when FOP is executed from the command line (which I guess this
> is how most people use it) but it introduces a number of bad side effects for
> long running processes that use FOP embedded.
>
> 1. Different FOP processes can't be executed in parallel on the same system
> because creating the same temp file fails.
> 2. If the JVM is not normally terminated, the temp files are never deleted
> and the next invocation of the JVM fails to run.
> 3. deleteOnExit() keeps for the life of the JVM an unknown number of temp
> files both on disk and a reference in memory.
> There should not be a need to implement a custom resource resolver when using
> FOP embedded in order to fix those issues. The default implementation should
> work at least as good as it worked in FOP 1.1 or earlier.
> Attached are 2 patches, one for XGC and one for FOP that should fix and
> improve the handling of at least the temporary files.
> For reference, [1] lists some reasons for implementing the new URI resource
> resolvers.
> [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2215) [PATCH] fox:external-document NullPointerException for IF
[ https://issues.apache.org/jira/browse/FOP-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2215: --- Assignee: Chris Bowditch > [PATCH] fox:external-document NullPointerException for IF > - > > Key: FOP-2215 > URL: https://issues.apache.org/jira/browse/FOP-2215 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: image.pdf, npe.patch, test.fo > > > fop test.fo -if application/pdf out.if gives java.lang.NullPointerException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FOP-2215) [PATCH] fox:external-document NullPointerException for IF
[ https://issues.apache.org/jira/browse/FOP-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FOP-2215 started by Chris Bowditch. > [PATCH] fox:external-document NullPointerException for IF > - > > Key: FOP-2215 > URL: https://issues.apache.org/jira/browse/FOP-2215 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: image.pdf, npe.patch, test.fo > > > fop test.fo -if application/pdf out.if gives java.lang.NullPointerException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2215) [PATCH] NullPointerException when generating IF with fox:external-document
[ https://issues.apache.org/jira/browse/FOP-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2215: Summary: [PATCH] NullPointerException when generating IF with fox:external-document (was: [PATCH] fox:external-document NullPointerException for IF) > [PATCH] NullPointerException when generating IF with fox:external-document > --- > > Key: FOP-2215 > URL: https://issues.apache.org/jira/browse/FOP-2215 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: image.pdf, npe.patch, test.fo > > > fop test.fo -if application/pdf out.if gives java.lang.NullPointerException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2215) [PATCH] NullPointerException when generating IF with fox:external-document
[ https://issues.apache.org/jira/browse/FOP-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2215. - Resolution: Fixed Fix Version/s: trunk > [PATCH] NullPointerException when generating IF with fox:external-document > --- > > Key: FOP-2215 > URL: https://issues.apache.org/jira/browse/FOP-2215 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Fix For: trunk > > Attachments: image.pdf, npe.patch, test.fo > > > fop test.fo -if application/pdf out.if gives java.lang.NullPointerException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2215) [PATCH] NullPointerException when generating IF with fox:external-document
[ https://issues.apache.org/jira/browse/FOP-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585880#comment-13585880 ] Chris Bowditch commented on FOP-2215: - Thanks for the patch Simon. Fix committed in revision 1449718 > [PATCH] NullPointerException when generating IF with fox:external-document > --- > > Key: FOP-2215 > URL: https://issues.apache.org/jira/browse/FOP-2215 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: image.pdf, npe.patch, test.fo > > > fop test.fo -if application/pdf out.if gives java.lang.NullPointerException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2214) [PATCH] Thin dashed border look like dots
[ https://issues.apache.org/jira/browse/FOP-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2214: --- Assignee: Chris Bowditch > [PATCH] Thin dashed border look like dots > - > > Key: FOP-2214 > URL: https://issues.apache.org/jira/browse/FOP-2214 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: afpborder.patch, border.patch, test.fo > > > At border-width="1pt" dashes are too short -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2214) [PATCH] Thin dashed border look like dots
[ https://issues.apache.org/jira/browse/FOP-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585918#comment-13585918 ] Chris Bowditch commented on FOP-2214: - Hi Simon, Many Thanks for sending the patch. All looks ok, however I note that you've written unit tests for PS and PDF but not for AFP, despite the AFP changes being in a separate class. That seems inconsistent to me. Any chance you could write an AFP equivalent unit test? Thanks, Chris > [PATCH] Thin dashed border look like dots > - > > Key: FOP-2214 > URL: https://issues.apache.org/jira/browse/FOP-2214 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: afpborder.patch, border.patch, test.fo > > > At border-width="1pt" dashes are too short -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2214) [PATCH] Thin dashed border look like dots
[ https://issues.apache.org/jira/browse/FOP-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593318#comment-13593318 ] Chris Bowditch commented on FOP-2214: - Thanks Simon, Patch applied in revision: 1452734 > [PATCH] Thin dashed border look like dots > - > > Key: FOP-2214 > URL: https://issues.apache.org/jira/browse/FOP-2214 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: afpborder.patch, afpbordertest.patch, border.patch, > test.fo > > > At border-width="1pt" dashes are too short -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2217) [PATCH] Image scaling change .was adversely affecting other image types
[ https://issues.apache.org/jira/browse/FOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2217: --- Assignee: Chris Bowditch > [PATCH] Image scaling change .was adversely affecting other image types > > > Key: FOP-2217 > URL: https://issues.apache.org/jira/browse/FOP-2217 > Project: Fop > Issue Type: Bug >Reporter: Robert Meyer >Assignee: Chris Bowditch > Attachments: patch.diff > > > A patch which will be posted shortly addresses several issues revolving > around a change made to the ImageLayout class to resolve a scaling issue. > This subsequently adversely affected other image types which needed to be > changed. This patch removes the existing code changes and employs a fix to > resolve the original issue related to SVG not converting to the correct unit. > I have also removed a test case which was added for the ImageLayout class as > this no longer applies. A follow up patch will be created for the XGC project > to remove the fix related for this issue as that also no longer applies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2217) [PATCH] Image scaling change .was adversely affecting other image types
[ https://issues.apache.org/jira/browse/FOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593443#comment-13593443 ] Chris Bowditch commented on FOP-2217: - Thanks for the patch Rob. However, I cant find any trace of the new fix. This patch just seems to revert the previous change for FOP-2174 and nothing more. Thanks, Chris > [PATCH] Image scaling change .was adversely affecting other image types > > > Key: FOP-2217 > URL: https://issues.apache.org/jira/browse/FOP-2217 > Project: Fop > Issue Type: Bug >Reporter: Robert Meyer >Assignee: Chris Bowditch > Attachments: patch.diff > > > A patch which will be posted shortly addresses several issues revolving > around a change made to the ImageLayout class to resolve a scaling issue. > This subsequently adversely affected other image types which needed to be > changed. This patch removes the existing code changes and employs a fix to > resolve the original issue related to SVG not converting to the correct unit. > I have also removed a test case which was added for the ImageLayout class as > this no longer applies. A follow up patch will be created for the XGC project > to remove the fix related for this issue as that also no longer applies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2217) [PATCH] Image scaling change was adversely affecting other image types
[ https://issues.apache.org/jira/browse/FOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2217: Summary: [PATCH] Image scaling change was adversely affecting other image types (was: [PATCH] Image scaling change .was adversely affecting other image types ) > [PATCH] Image scaling change was adversely affecting other image types > --- > > Key: FOP-2217 > URL: https://issues.apache.org/jira/browse/FOP-2217 > Project: Fop > Issue Type: Bug >Reporter: Robert Meyer >Assignee: Chris Bowditch > Attachments: patch2.diff, patch.diff > > > A patch which will be posted shortly addresses several issues revolving > around a change made to the ImageLayout class to resolve a scaling issue. > This subsequently adversely affected other image types which needed to be > changed. This patch removes the existing code changes and employs a fix to > resolve the original issue related to SVG not converting to the correct unit. > I have also removed a test case which was added for the ImageLayout class as > this no longer applies. A follow up patch will be created for the XGC project > to remove the fix related for this issue as that also no longer applies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2217) [PATCH] Image scaling change was adversely affecting other image types
[ https://issues.apache.org/jira/browse/FOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2217. - Resolution: Fixed Fix Version/s: trunk Thanks Rob. Patch applied in revision 1452859 > [PATCH] Image scaling change was adversely affecting other image types > --- > > Key: FOP-2217 > URL: https://issues.apache.org/jira/browse/FOP-2217 > Project: Fop > Issue Type: Bug >Reporter: Robert Meyer >Assignee: Chris Bowditch > Fix For: trunk > > Attachments: patch2.diff, patch.diff > > > A patch which will be posted shortly addresses several issues revolving > around a change made to the ImageLayout class to resolve a scaling issue. > This subsequently adversely affected other image types which needed to be > changed. This patch removes the existing code changes and employs a fix to > resolve the original issue related to SVG not converting to the correct unit. > I have also removed a test case which was added for the ImageLayout class as > this no longer applies. A follow up patch will be created for the XGC project > to remove the fix related for this issue as that also no longer applies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-850) TTF Reader fails
[ https://issues.apache.org/jira/browse/FOP-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-850. Resolution: Fixed Fix Version/s: 1.0 Thanks Rob. Lets mark this as resolved then > TTF Reader fails > > > Key: FOP-850 > URL: https://issues.apache.org/jira/browse/FOP-850 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: 0.20.5 > Environment: Operating System: All > Platform: PC >Reporter: Peter Schäfer > Fix For: 1.0 > > Attachments: BERLIN.TTF > > > Reading fonts/BERLIN.TTF... > Number of glyphs in font: 119 > Unicode cmap table not present > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.RangeCheck(ArrayList.java:507) > at java.util.ArrayList.get(ArrayList.java:324) > at org.apache.fop.fonts.TTFFile.createCMaps(TTFFile.java:449) > at org.apache.fop.fonts.TTFFile.readFont(TTFFile.java:439) > at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:222) > at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:184) > I found that the TrueType file contains a "cmap" table with platformID=3 and > encodingId=0 (Windows Symbol encoding, or whatever). > TTFReader expects encodingId = 1. However, the table contains readable data in > the correct format (format 4). After patching TTFFile.java, it created a > perfectly valid metrics file. > I might suggest that you apply this patch to org.apache.fop.fonts.TTFFile, > line 185: >if (cmap_pid == 3 && (cmap_eid == 1 || cmap_eid == 0)) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2151) maven dependency has wrong avalon group id
[ https://issues.apache.org/jira/browse/FOP-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2151. - Resolution: Fixed Thanks for noticing Marcel. Resolving bug > maven dependency has wrong avalon group id > -- > > Key: FOP-2151 > URL: https://issues.apache.org/jira/browse/FOP-2151 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: 1.1 > Environment: Operating System: > Platform: PC >Reporter: Lloyd > > The maven pom for fop 1.1 uses incorrect dependency for avalon framework. > With 4.2.0 the the group id changed to avalon-framework from > org.apache.avalon.framework > workaround: update pom as follows > > org.apache.xmlgraphics > fop > 1.1 > > > avalon-framework-api > org.apache.avalon.framework > > > avalon-framework-impl > org.apache.avalon.framework > > > > > >avalon-framework >avalon-framework-api >4.2.0 > > >avalon-framework >avalon-framework-impl >4.2.0 > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-1099) footnotes within tables and listsl get lost
[ https://issues.apache.org/jira/browse/FOP-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626457#comment-13626457 ] Chris Bowditch commented on FOP-1099: - The W3C XSL-FO sub group has been suspended, so we aren't going to get an answer from them any time soon. I suggest we drive the behaviour from user/customer requirements instead. I have a customer that wants to be able to repeat footnotes for every page that a table spans. Putting the footnote in the header is the perfect way to achieve this. If the user didnt want it repeating for every page, they can move the footnote into the first table-row after the table-header. So making the footnotes in headers repeat give the user the choice of which behaviour they want. Therefore it makes sense to implement footnotes in headers so that they repeat, allowing either requirement to be fulfilled. > footnotes within tables and listsl get lost > --- > > Key: FOP-1099 > URL: https://issues.apache.org/jira/browse/FOP-1099 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: other > Platform: Other >Reporter: gerhard oettl > Attachments: b37579_2.patch, b37579.diff, b37579.diff, > bugzilla37579.patch, dorfchronik.fo, dorfchronik.fo.list3, > dorfchronik.fo.table3, footnote.fo, footnotes.080502.diff, footnotespatch, > fussnote.fo, table_list_footnotes.diff > > > Footnote outside of tables works, inside table-cell not. > The compliance page only speaks about restrictions within multicolumn > documents. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-2235) Pagination failure when using initial-page-number attribute
[ https://issues.apache.org/jira/browse/FOP-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2235. --- Resolution: Not A Problem This is not a bug. See FAQ: http://xmlgraphics.apache.org/fop/faq.html#blank-page-between-page-sequences Please ask on the user mailing list before raising bugs if there is any doubt in future. Thanks Chris > Pagination failure when using initial-page-number attribute > --- > > Key: FOP-2235 > URL: https://issues.apache.org/jira/browse/FOP-2235 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1 > Environment: Windows 7 64bit Professional HUN > running on Oralce Virtualbox 4.2.10 r84104 > running on 64bit Ubuntu 12.04 LTS Host machine >Reporter: Szeak > Attachments: test.fo > > > Using multiple page-sequences with initial-page-namber attribute fails > pagination. > On page-sequence, where initial-page-number used, FOP inserts a blank page > (with static contents, like headers, footers, etc.) to the end of the > previous page-sequence. > See attached example FO. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2240) [PATCH] PDF docs missing xconf encryption
[ https://issues.apache.org/jira/browse/FOP-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13637964#comment-13637964 ] Chris Bowditch commented on FOP-2240: - Hi Simon, Thanks for the patch. What about encryption-length? Did you check that could be specified in the fop.xconf file. Thanks, Chris > [PATCH] PDF docs missing xconf encryption > - > > Key: FOP-2240 > URL: https://issues.apache.org/jira/browse/FOP-2240 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: pdfdoc.patch > > > xconf info not in http://xmlgraphics.apache.org/fop/trunk/pdfencryption.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2240) [PATCH] PDF docs missing xconf encryption
[ https://issues.apache.org/jira/browse/FOP-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638010#comment-13638010 ] Chris Bowditch commented on FOP-2240: - Thanks Simon. Committed in rev 1470514 > [PATCH] PDF docs missing xconf encryption > - > > Key: FOP-2240 > URL: https://issues.apache.org/jira/browse/FOP-2240 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: pdfdoc.patch > > > xconf info not in http://xmlgraphics.apache.org/fop/trunk/pdfencryption.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2240) [PATCH] PDF docs missing xconf encryption
[ https://issues.apache.org/jira/browse/FOP-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2240. - Resolution: Fixed Assignee: Chris Bowditch > [PATCH] PDF docs missing xconf encryption > - > > Key: FOP-2240 > URL: https://issues.apache.org/jira/browse/FOP-2240 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: pdfdoc.patch > > > xconf info not in http://xmlgraphics.apache.org/fop/trunk/pdfencryption.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2210) [PATCH] Complex script IF to output missing glyphs
[ https://issues.apache.org/jira/browse/FOP-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2210: --- Assignee: Chris Bowditch > [PATCH] Complex script IF to output missing glyphs > -- > > Key: FOP-2210 > URL: https://issues.apache.org/jira/browse/FOP-2210 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: csspeedtrunk.patch, fop.xconf, test.fo > > > fop test.fo -c fop.xconf -if application/pdf expected.if.xml > fop -c fop.xconf -ifin expected.if.xml out.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2210) [PATCH] Complex script IF to output missing glyphs
[ https://issues.apache.org/jira/browse/FOP-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638052#comment-13638052 ] Chris Bowditch commented on FOP-2210: - Hi Simon, Thanks for your patch. There is no unit test present and it is recommended that you provide one. Also there are some checkstyle warnings, whilst not directly introduced by your changes, should be resolved since you change the line on which they occur, e.g. AddWord method in TextArea has a checkstyle warning about spaces after the brackets. You added a new parameter, which didn't cause the warning but as you are changing the same line I must insist you also resolve the checkstyle warning. Thanks, Chris > [PATCH] Complex script IF to output missing glyphs > -- > > Key: FOP-2210 > URL: https://issues.apache.org/jira/browse/FOP-2210 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: csspeedtrunk.patch, fop.xconf, test.fo > > > fop test.fo -c fop.xconf -if application/pdf expected.if.xml > fop -c fop.xconf -ifin expected.if.xml out.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2228) [PATCH] PDF page missing from Postscript output
[ https://issues.apache.org/jira/browse/FOP-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2228: --- Assignee: Chris Bowditch > [PATCH] PDF page missing from Postscript output > --- > > Key: FOP-2228 > URL: https://issues.apache.org/jira/browse/FOP-2228 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: new.pdf, pdfmissing.patch, test.fo > > > PDF is missing from output > fop test.fo -ps out.ps -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2228) [PATCH] PDF page missing from Postscript output
[ https://issues.apache.org/jira/browse/FOP-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638077#comment-13638077 ] Chris Bowditch commented on FOP-2228: - Thanks for the patch Simon. Applied in revision: 1470565 > [PATCH] PDF page missing from Postscript output > --- > > Key: FOP-2228 > URL: https://issues.apache.org/jira/browse/FOP-2228 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: new.pdf, pdfmissing.patch, test.fo > > > PDF is missing from output > fop test.fo -ps out.ps -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2228) [PATCH] PDF page missing from Postscript output
[ https://issues.apache.org/jira/browse/FOP-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2228. - Resolution: Fixed > [PATCH] PDF page missing from Postscript output > --- > > Key: FOP-2228 > URL: https://issues.apache.org/jira/browse/FOP-2228 > Project: Fop > Issue Type: Bug >Reporter: simon steiner >Assignee: Chris Bowditch > Attachments: new.pdf, pdfmissing.patch, test.fo > > > PDF is missing from output > fop test.fo -ps out.ps -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FOP-2210) [PATCH] Complex script IF to output missing glyphs
[ https://issues.apache.org/jira/browse/FOP-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch reassigned FOP-2210: --- Assignee: (was: Chris Bowditch) > [PATCH] Complex script IF to output missing glyphs > -- > > Key: FOP-2210 > URL: https://issues.apache.org/jira/browse/FOP-2210 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: csspeedtrunk2.patch, csspeedtrunk.patch, fop.xconf, > test.fo > > > fop test.fo -c fop.xconf -if application/pdf expected.if.xml > fop -c fop.xconf -ifin expected.if.xml out.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2210) [PATCH] Complex script IF to output missing glyphs
[ https://issues.apache.org/jira/browse/FOP-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641575#comment-13641575 ] Chris Bowditch commented on FOP-2210: - See comment from Glenn Adams on an improved implementation: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/201304.mbox/%3cCACQ=j+fgqe4g3am1gnsqcvj9bsqrmjbnhgtacjfvo_pdz4q...@mail.gmail.com%3e > [PATCH] Complex script IF to output missing glyphs > -- > > Key: FOP-2210 > URL: https://issues.apache.org/jira/browse/FOP-2210 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: csspeedtrunk2.patch, csspeedtrunk.patch, fop.xconf, > test.fo > > > fop test.fo -c fop.xconf -if application/pdf expected.if.xml > fop -c fop.xconf -ifin expected.if.xml out.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2242) PDF generation is very slow when document contains svg:text
[ https://issues.apache.org/jira/browse/FOP-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644549#comment-13644549 ] Chris Bowditch commented on FOP-2242: - When FOP is rendering SVG, if the font isn't found it may have to resort to stroking the text which is much slower than just using fonts to draw the glyphs. That's probably what happened. I will close this bug if the issue is resolved for you. > PDF generation is very slow when document contains svg:text > --- > > Key: FOP-2242 > URL: https://issues.apache.org/jira/browse/FOP-2242 > Project: Fop > Issue Type: Bug > Components: fonts, pdf, svg >Affects Versions: 1.1 > Environment: linux x86_64 (OpenSUSE 12.2) >Reporter: Thomas Mitterfellner > Labels: fonts, pdf, svg, text > Attachments: fo_style.xsl, test.xml > > > PDF generation is very slow when the document contains svg:text elements. > When I remove the svg:text elements, the pdf generation is very fast. > I attached the xml and xsl files to test the behavior. When lines 314-343 are > commented out (svg:text elements), pdf generation is quick. > Note: a single svg:text element is sufficient to slow down the generation > process. > If there is any further information I should provide in order to tackle this > problem, I'll try to provide it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FOP-2242) PDF generation is very slow when document contains svg:text
[ https://issues.apache.org/jira/browse/FOP-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-2242. - Resolution: Not A Problem > PDF generation is very slow when document contains svg:text > --- > > Key: FOP-2242 > URL: https://issues.apache.org/jira/browse/FOP-2242 > Project: Fop > Issue Type: Bug > Components: fonts, pdf, svg >Affects Versions: 1.1 > Environment: linux x86_64 (OpenSUSE 12.2) >Reporter: Thomas Mitterfellner > Labels: fonts, pdf, svg, text > Attachments: fo_style.xsl, test.xml > > > PDF generation is very slow when the document contains svg:text elements. > When I remove the svg:text elements, the pdf generation is very fast. > I attached the xml and xsl files to test the behavior. When lines 314-343 are > commented out (svg:text elements), pdf generation is quick. > Note: a single svg:text element is sufficient to slow down the generation > process. > If there is any further information I should provide in order to tackle this > problem, I'll try to provide it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-2242) PDF generation is very slow when document contains svg:text
[ https://issues.apache.org/jira/browse/FOP-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2242. --- > PDF generation is very slow when document contains svg:text > --- > > Key: FOP-2242 > URL: https://issues.apache.org/jira/browse/FOP-2242 > Project: Fop > Issue Type: Bug > Components: fonts, pdf, svg >Affects Versions: 1.1 > Environment: linux x86_64 (OpenSUSE 12.2) >Reporter: Thomas Mitterfellner > Labels: fonts, pdf, svg, text > Attachments: fo_style.xsl, test.xml > > > PDF generation is very slow when the document contains svg:text elements. > When I remove the svg:text elements, the pdf generation is very fast. > I attached the xml and xsl files to test the behavior. When lines 314-343 are > commented out (svg:text elements), pdf generation is quick. > Note: a single svg:text element is sufficient to slow down the generation > process. > If there is any further information I should provide in order to tackle this > problem, I'll try to provide it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2221) [PATCH] Make overflow messages easier to read and fix wrong/ missing messages
[ https://issues.apache.org/jira/browse/FOP-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656026#comment-13656026 ] Chris Bowditch commented on FOP-2221: - Hi Simon, Its not clear to me, which of the 3 patch files attached a committer is supposed to apply? Are they all cummaltive? It so it would be better if you could combine them. If not, could you delete the ones that are no longer relevant? Furthermore, I notice that you don't yet have an ICLA file at [1] Since you've submitted a few patches now you really ought to file one, see [2] on how to do that. Thanks, Chris [1] http://people.apache.org/committer-index.html [2] http://www.apache.org/licenses/#clas > [PATCH] Make overflow messages easier to read and fix wrong/ missing messages > - > > Key: FOP-2221 > URL: https://issues.apache.org/jira/browse/FOP-2221 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: overflow-message.fo, overflowsmessage2.patch, > overflowsmessage5.patch, overflowsmsg8svn.patch > > > Users find it difficult to read over flow messages, patch shows element name > and easier to read message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2267) fo:table nested in fo:inline cause overflow at the end of page
[ https://issues.apache.org/jira/browse/FOP-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13693037#comment-13693037 ] Chris Bowditch commented on FOP-2267: - Hi Json, Please don't report further bugs here. If you are sure the second issue is a bug, then please open a new JIRA issue for it, making sure to provide a sample FO to replicate it. If you aren't sure its a bug, please post your sample FO to the mailing list fop-us...@xmlgraphics.apache.org. Thanks, Chris > fo:table nested in fo:inline cause overflow at the end of page > -- > > Key: FOP-2267 > URL: https://issues.apache.org/jira/browse/FOP-2267 > Project: Fop > Issue Type: Bug >Affects Versions: 0.95, 1.1 > Environment: Windows 7 >Reporter: Json > Attachments: data-was-lots-at-the-end-of-a-page.fo, > data-was-lots-at-the-end-of-a-page.png, test.fo, TestResult(error).png > > > I'm using FOP 0.95. In case the number of row in my table is over 100 rows > (multipages). The row at the end of page is lost > occasionally ? Please help me ! (Please see 'TestResult(error).png') -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-2269) fo:marker for subtotals by page
[ https://issues.apache.org/jira/browse/FOP-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2269. --- Resolution: Invalid Please don't raise bugs to ask questions. Please post your question to the mailing list fop-us...@xmlgraphics.apache.org. I don't believe there is a way to do what you need. The values to put in markers have to come from the input XML. Unfortunately when creating the XML or during XSLT stage you aren't aware of page boundaries, so you can't create a page only sub total, only sub totals for the entire table/document sub section so far. Thanks, Chris > fo:marker for subtotals by page > --- > > Key: FOP-2269 > URL: https://issues.apache.org/jira/browse/FOP-2269 > Project: Fop > Issue Type: Bug >Reporter: Lisdiana Rodriguez Alvarado >Priority: Blocker > > Hi, > I'm working in a project that must generate a PDF Invoice using a XML as > source. > I'm using FOP 1.1 and the PDFs are generated almost like I expect, but my > current problem is that each page must show subtotals. I need these totals by > page, not accumulative. I'm trying using fo:retrieve-marker > (retrieve-boundary="page") in the page footer and also with > fo:retrieve-table-marker(retrieve-boundary-within-table="page") in the footer > of a table. However in both cases, subtotals contains not just the > accumulative in the current page but the amounts in the previous ones. > I've been looking samples but I can't find what I'm doing wrong. I need to > know if it's possible to do what I need to, and if so, I need a sample or > guide to know how to "reset" the subtotals in every page. > Thanks in advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2252) [PATCH] OpenType CFF support for FOP
[ https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2252: Summary: [PATCH] OpenType CFF support for FOP (was: OpenType CFF support for FOP) > [PATCH] OpenType CFF support for FOP > > > Key: FOP-2252 > URL: https://issues.apache.org/jira/browse/FOP-2252 > Project: Fop > Issue Type: New Feature > Components: fonts >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer > Attachments: AlexBrushRegular.otf, fontbox-1.8.0-SNAPSHOT.jar, > output.pdf, patch-240713.diff, SourceSansProBold.otf > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2277) java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723552#comment-13723552 ] Chris Bowditch commented on FOP-2277: - Hi Leo, Please attach an XSL-FO File that demonstrates the problem. Thanks, Chris > java.lang.NullPointerException > -- > > Key: FOP-2277 > URL: https://issues.apache.org/jira/browse/FOP-2277 > Project: Fop > Issue Type: Bug > Components: fo tree >Affects Versions: 1.1 > Environment: Fedora 19, 64 bit >Reporter: Leo > > NullPointException occurs > java org.apache.fop.hyphenation.HyphenationTree > input 'f' and then 'test' > Exception in thread "main" java.lang.NullPointerException > at > org.apache.fop.hyphenation.HyphenationTree.main(HyphenationTree.java:646) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-2278) java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2278. --- Resolution: Duplicate This appears to be a duplicate of FOP-2277. The fact that the issue occurs with slightly different characters shouldn't matter. Although its difficult to be certain without an XSL-FO File. If you feel stroingly that this is a unique issue compared to FOP-2277 then feel free to re-open, but you must provide an XSL-FO File to demonstrate the issue. > java.lang.NullPointerException > -- > > Key: FOP-2278 > URL: https://issues.apache.org/jira/browse/FOP-2278 > Project: Fop > Issue Type: Bug > Components: fo tree >Affects Versions: 1.1 > Environment: Fedora 19, 64 bit >Reporter: Leo > > NullPointException occurs > run this in command line > java org.apache.fop.hyphenation.HyphenationTree > enter 'h' and then 'test' using keyboard > Exception in thread "main" java.lang.NullPointerException > at > org.apache.fop.hyphenation.HyphenationTree.main(HyphenationTree.java:646) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2277) java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723563#comment-13723563 ] Chris Bowditch commented on FOP-2277: - I'm sorry but I don't understand what you mean. FOP takes XSL-FO as input, so do you mean: f test If its easy to replicate then why do you hesitate to provide the XSL-FO file? > java.lang.NullPointerException > -- > > Key: FOP-2277 > URL: https://issues.apache.org/jira/browse/FOP-2277 > Project: Fop > Issue Type: Bug > Components: fo tree >Affects Versions: 1.1 > Environment: Fedora 19, 64 bit >Reporter: Leo > > NullPointException occurs > java org.apache.fop.hyphenation.HyphenationTree > input 'f' and then 'test' > Exception in thread "main" java.lang.NullPointerException > at > org.apache.fop.hyphenation.HyphenationTree.main(HyphenationTree.java:646) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2277) java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723573#comment-13723573 ] Chris Bowditch commented on FOP-2277: - Sorry I see what you mean now. You try to run HyphenationTree class, main method. What classpath are you using. If you don't specify one then it is likely to fail... > java.lang.NullPointerException > -- > > Key: FOP-2277 > URL: https://issues.apache.org/jira/browse/FOP-2277 > Project: Fop > Issue Type: Bug > Components: fo tree >Affects Versions: 1.1 > Environment: Fedora 19, 64 bit >Reporter: Leo > > NullPointException occurs > java org.apache.fop.hyphenation.HyphenationTree > input 'f' and then 'test' > Exception in thread "main" java.lang.NullPointerException > at > org.apache.fop.hyphenation.HyphenationTree.main(HyphenationTree.java:646) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2277) java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723718#comment-13723718 ] Chris Bowditch commented on FOP-2277: - You need to specify option l to road the hyphenation patterns first before you try to use them with option f or option h. That said the code could be improved to output a more helpful message > java.lang.NullPointerException > -- > > Key: FOP-2277 > URL: https://issues.apache.org/jira/browse/FOP-2277 > Project: Fop > Issue Type: Bug > Components: fo tree >Affects Versions: 1.1 > Environment: Fedora 19, 64 bit >Reporter: Leo > > NullPointException occurs > java org.apache.fop.hyphenation.HyphenationTree > input 'f' and then 'test' > Exception in thread "main" java.lang.NullPointerException > at > org.apache.fop.hyphenation.HyphenationTree.main(HyphenationTree.java:646) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2292) [PATCH] NullPointerException after page IPD change
[ https://issues.apache.org/jira/browse/FOP-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2292: Summary: [PATCH] NullPointerException after page IPD change (was: NullPointerException after page IPD change) > [PATCH] NullPointerException after page IPD change > -- > > Key: FOP-2292 > URL: https://issues.apache.org/jira/browse/FOP-2292 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: trunk >Reporter: Seifeddine Dridi > Attachments: idea.patch, thelem.rar > > > The error occurs when FOP detects an IPD change and redoes phase 1 of the > layout process. A NullPointerException is fired in > getNextBlockListChangedIPD() at line 820, it seems that getPosition() is > returning null. > Can anyone confirm this issue? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FOP-2295) AFP TLE tags are not added to next page
[ https://issues.apache.org/jira/browse/FOP-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2295. --- Resolution: Invalid This is not a bug. If you want the TLE on every page then add it as a child of the page definition element, i.e. fo:simple-page-master. TLEs that are children of fo:page-sequence are only output at the start of the sequence by design as that is what some users require. > AFP TLE tags are not added to next page > --- > > Key: FOP-2295 > URL: https://issues.apache.org/jira/browse/FOP-2295 > Project: Fop > Issue Type: Bug > Components: awt renderer >Affects Versions: 1.1 >Reporter: Kirils Belahs > > If we have more than one page, TLE tags are added only to first page. > Example: > > > ... > will produce tags on first page, and will not on subsequent pages of this > page-sequences. To check tags afp viewer was used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759071#comment-13759071 ] Chris Bowditch commented on FOP-2293: - Hi All, I agree with the interpretation of when an attribute should be prefixed with the namespace, i.e. not required when on an element in the same namespace. I'm also unclear on Glenn's concerns about this enhancement, and would appreciate it if Glenn could clarify. >From a requirements perspective, Whitespace Management would be a very useful >edition to folks using FOP to create Print streams destined for traditional >fulfilment patterns. To maximize the available space on the page, adverts are >placed on a best fit basis. So an implementation that meets this requirement >gets a high level +1 from me. Although I wouldn't want it to be bodged and it >should fit within project best practises and architecture. Thanks for the contribution! Chris > Whitespace management extension > --- > > Key: FOP-2293 > URL: https://issues.apache.org/jira/browse/FOP-2293 > Project: Fop > Issue Type: New Feature > Components: general >Affects Versions: trunk >Reporter: Seifeddine Dridi >Priority: Minor > Labels: XSL-FO > Fix For: trunk > > Attachments: bestfit.fo, doc.pdf, multiple-feasible-nodes.fo, > patch.patch, patch-rev1.1.patch, patch-rev1.patch > > > I have been working on an extension for whitespace management, similar to > what's described here: > http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement > The logic of the extension is very simple: the user defines a set of > alternatives that he wishes to insert at the end of a page, then if there is > enough space left, FOP will pick the alternative that best matches the user's > selection criteria (first fit, smallest fit, biggest fit). > This is my first work on FOP and it took me almost 2 months to reach this > stage in development. But it's not the end of course, so I'm relying on your > feedback to improve it. > Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-1749) [PATCH] infinite loop in footnotes (see also #47424)
[ https://issues.apache.org/jira/browse/FOP-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800523#comment-13800523 ] Chris Bowditch commented on FOP-1749: - Hi Alexey, Many thanks for your patch. Since it adds new files into the repository you really need to complete an ICLA Form and subit to the Apache Secretary as described here: http://www.apache.org/licenses/#clas Thanks, Chris > [PATCH] infinite loop in footnotes (see also #47424) > > > Key: FOP-1749 > URL: https://issues.apache.org/jira/browse/FOP-1749 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: Heidi Vanparys > Attachments: bug47424.patch, c.fo, fop-1749-2106-combined.diff, > fop-1749.diff, fop-1749-top-offset.diff > > > This patch solves the problem of an infinite loop in footnotes as reported in > FOP-1678. > The infinite loop occurred in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.getFootnoteSplit(int, int, > int, int, boolean). > This patch does not solve the problem of another infinite loop in footnotes > as reported in bugs 48063 and 48162. This infinite loop occurs in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.createFootnotePages(KnuthPageNode). > The test attached to 48063 is converted to a testcase and added to the list > of disabled testcases. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (FOP-1749) [PATCH] infinite loop in footnotes (see also #47424)
[ https://issues.apache.org/jira/browse/FOP-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800523#comment-13800523 ] Chris Bowditch edited comment on FOP-1749 at 10/21/13 10:36 AM: Hi Alexey, Many thanks for your patch. Since it adds new files into the repository you really need to complete an ICLA Form and submit to the Apache Secretary as described here: http://www.apache.org/licenses/#clas Thanks, Chris was (Author: cbowditch): Hi Alexey, Many thanks for your patch. Since it adds new files into the repository you really need to complete an ICLA Form and subit to the Apache Secretary as described here: http://www.apache.org/licenses/#clas Thanks, Chris > [PATCH] infinite loop in footnotes (see also #47424) > > > Key: FOP-1749 > URL: https://issues.apache.org/jira/browse/FOP-1749 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: Heidi Vanparys > Attachments: bug47424.patch, c.fo, fop-1749-2106-combined.diff, > fop-1749.diff, fop-1749-top-offset.diff > > > This patch solves the problem of an infinite loop in footnotes as reported in > FOP-1678. > The infinite loop occurred in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.getFootnoteSplit(int, int, > int, int, boolean). > This patch does not solve the problem of another infinite loop in footnotes > as reported in bugs 48063 and 48162. This infinite loop occurs in > org.apache.fop.layoutmgr.PageBreakingAlgorithm.createFootnotePages(KnuthPageNode). > The test attached to 48063 is converted to a testcase and added to the list > of disabled testcases. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-1976) [PATCH] last simple-page-master not chosen when force-page-count=odd
[ https://issues.apache.org/jira/browse/FOP-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1976: Attachment: smaller3page.fo I've attached an example provided by Rob Sargent on the user mailing list. The page-sequence has force-page-count="even" A blank fourth page is added, but the last page master is not used. > [PATCH] last simple-page-master not chosen when force-page-count=odd > > > Key: FOP-1976 > URL: https://issues.apache.org/jira/browse/FOP-1976 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Mehdi Houshmand > Attachments: pagebreaker.patch, smaller3page.fo > > > If force-page-count="odd" and the first page has an overflowing region onto a > second page, then the 3rd and last page should use the page-position="last" > simple-page-master in the conditional-page-master-reference. However, it was > using the "rest". > I'm having a few issues with the apache git server, so I'll attach the patch > when the issues have been resolved. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2308) text-transform="capitalize" assumes input text is lowercase
[ https://issues.apache.org/jira/browse/FOP-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808900#comment-13808900 ] Chris Bowditch commented on FOP-2308: - Hi All, I don't think Luis was randomly deviating from the XSL 1.1 specification, as suggested above. XSL 1.1 doesn't define the behaviour for the rest of the word when using text-transform="capitalize" Whether or not we should follow CSS2 to the letter seems less clear to me. At least in HTML you can use Javascript to achieve what you need. What is clear is that the use case of an acronym within a sentence is an edge case. if you know you have an acronym in a sentence and also want to ensure the first letter of each word is capitalized then you could do something like: a sentence to be capitalized in FOP That seems reasonable for an edge case scenario like acronyms within sentences to be capitalized. Without adjusting the rest of the word the usefulness of the capitalize function is greatly deminished, and having the entire word processed is far more useful. After all text-transform="lowercase" and text-transform="uppercase" processes the entire word, so it seems reasonable that Capitalize should do the same. Thanks, Chris > text-transform="capitalize" assumes input text is lowercase > --- > > Key: FOP-2308 > URL: https://issues.apache.org/jira/browse/FOP-2308 > Project: Fop > Issue Type: Bug >Reporter: Luis Bernardo > Fix For: trunk > > Attachments: test.fo > > > CAPITALIZE should output > Capitalize, not CAPITALIZE as it does currently. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2308) text-transform="capitalize" assumes input text is lowercase
[ https://issues.apache.org/jira/browse/FOP-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809401#comment-13809401 ] Chris Bowditch commented on FOP-2308: - Hi Alexey, You are quite right about the spec. However, this direction in the CSS2 spec seems somewhat arbitrary and inconsistent with the behaviour of the other values of text-transform. Maybe thats to handle the edge case of an acronym within a capitalized sentence, but I still believe it would be more useful if text-transform processed all characters in the word when using capitalize. I find most users expect a common sense approach and don't usually take the time to read specifications. Anyway, the change has been reverted at your and Pascal's request. Thanks, Chris > text-transform="capitalize" assumes input text is lowercase > --- > > Key: FOP-2308 > URL: https://issues.apache.org/jira/browse/FOP-2308 > Project: Fop > Issue Type: Bug >Reporter: Luis Bernardo > Fix For: trunk > > Attachments: test.fo > > > CAPITALIZE should output > Capitalize, not CAPITALIZE as it does currently. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2322) [PATCH] Type1 Font with Custom Encoding not visible in Postscript output
[ https://issues.apache.org/jira/browse/FOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2322: Attachment: (was: CMC72510.PFB) > [PATCH] Type1 Font with Custom Encoding not visible in Postscript output > > > Key: FOP-2322 > URL: https://issues.apache.org/jira/browse/FOP-2322 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: fop.xconf, test.fo, trunktype1customenc.patch > > > fop test.fo -c fop.xconf -ps out.ps > No afm is given so fop writes out standard encoding which postscript doesnt > like -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2322) [PATCH] Type1 Font with Custom Encoding not visible in Postscript output
[ https://issues.apache.org/jira/browse/FOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2322: Attachment: (was: CMC72510.PFM) > [PATCH] Type1 Font with Custom Encoding not visible in Postscript output > > > Key: FOP-2322 > URL: https://issues.apache.org/jira/browse/FOP-2322 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: fop.xconf, test.fo, trunktype1customenc.patch > > > fop test.fo -c fop.xconf -ps out.ps > No afm is given so fop writes out standard encoding which postscript doesnt > like -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (FOP-2330) Example shown on FOP homepage is not achievable using FOP
Chris Bowditch created FOP-2330: --- Summary: Example shown on FOP homepage is not achievable using FOP Key: FOP-2330 URL: https://issues.apache.org/jira/browse/FOP-2330 Project: Fop Issue Type: Bug Affects Versions: trunk Reporter: Chris Bowditch Example shown on home page http://xmlgraphics.apache.org/fop/, under "Demonstration" section uses side floats, which aren't supported by FOP. You can tell side floats are used by the text flowing round the image. We should revise this to have XSL-FO that can be rendered by FOP. This was pointed out by qbd...@vt.edu -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FOP-2332) PS renderer does not embed fonts-glyphs for characters not present on the first page
[ https://issues.apache.org/jira/browse/FOP-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882871#comment-13882871 ] Chris Bowditch commented on FOP-2332: - In addition to what Luis requested I would add the following: In order for an accurate subset of glyphs to be created, normally the following element needs to be added to the fop.xconf file: true This option tells FOP to scan the entire document again to refine font and image usage. In my experience that also corrects the problems with faulty subsets being created. Thanks, Chris > PS renderer does not embed fonts-glyphs for characters not present on the > first page > > > Key: FOP-2332 > URL: https://issues.apache.org/jira/browse/FOP-2332 > Project: Fop > Issue Type: Bug > Components: ps >Affects Versions: 1.1, trunk >Reporter: Nik Lutz >Priority: Minor > > Documents with multiple pages cannot be generated safely using embedded > fonts because not all character/glyphs are embedded in the document. > While debugging I discovered that the postscript renderer embeds/writes the > font-glyphs after parsing the first page. After parsing/writing any adjacent > page the imbedded is not updated (the FontInfo object would reference the > additional characters), so any character not present on the first page cannot > be displayed properly because the glyphs are not embedded. > Unfortunately setting EmbeddingMode to FULL did not work as workaround for me. > regards nik lutz -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FOP-2353) [PATCH] PDF-A preflight warnings
[ https://issues.apache.org/jira/browse/FOP-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933069#comment-13933069 ] Chris Bowditch commented on FOP-2353: - Hi Simon, Thanks for the patch, but can you update the description with a little more detail please, e.g. What is the preflight warning(s) that you are trying to fix with this patch? Thanks, Chris > [PATCH] PDF-A preflight warnings > > > Key: FOP-2353 > URL: https://issues.apache.org/jira/browse/FOP-2353 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: Arial.ttf, fop.xconf, pdfa1a.patch, test.fo, > xgcpdfa1a.patch > > > adobe acrobat 9 pdfa prelight reports warnings when using pdfa1a > fop test.fo -c fop.xconf out.pdf -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (FOP-2361) There are blank spaces between two tags in pdf file's content
[ https://issues.apache.org/jira/browse/FOP-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2361. --- Closing this as I believe Luis answered your question. In future, please direct questions to the fop-users mailing list and do not abuse the bug database. If you're not sure, then please still ask first on fop-users list and open a bug only if directed to do so. Thanks > There are blank spaces between two tags in pdf file's content > - > > Key: FOP-2361 > URL: https://issues.apache.org/jira/browse/FOP-2361 > Project: Fop > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Json > Attachments: Pdf result.jpg, htmlsource.html, the result display on > browser.jpg, the result of Fo.txt > > > I want to convert html tags to fo tags by Apache FO 1.1 . But when I convert > two tags to two tags , there are the blank spaces between > two tags. > For Example : > 1)The result when I open html file on browser : > ABCDEFGGHSG TRASGRSA FEGT ASFEFDFSDASA(correct) > 2) After I convert it to pdf by Apache FO 1.1. The pdf output is : > A B CDEFGGHSG TRASGRSA FEGT AS FE FDFSDASA(incorrect) > For more details please see the attachment. Please help me !!! > P/S : I think that these blank spaces will appear between an open tag and a > close tag -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13999853#comment-13999853 ] Chris Bowditch commented on FOP-2354: - Vincent, You raise a good point about performance. I think we should measure the performance impact so we can make an informed decision. I've asked Rob to run some numbers when he gets a chance. Thanks, Chris > [PATCH] Subset support for Type 1 fonts > --- > > Key: FOP-2354 > URL: https://issues.apache.org/jira/browse/FOP-2354 > Project: Fop > Issue Type: New Feature > Components: fonts >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer > Fix For: trunk > > Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo > > > This patch adds subsetting support to Type 1 fonts. Currently the only two > supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998667#comment-13998667 ] Chris Bowditch commented on FOP-2354: - Hi Rob, Why did you change the default not to subset? This isn't consistent with True Type fonts which are subset by default. Most users will want the most compact output file possible, with full embedding only required for some edge cases, e.g. Archiving or Authoring the generated document. Thanks, Chris > [PATCH] Subset support for Type 1 fonts > --- > > Key: FOP-2354 > URL: https://issues.apache.org/jira/browse/FOP-2354 > Project: Fop > Issue Type: New Feature > Components: fonts >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer > Fix For: trunk > > Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo > > > This patch adds subsetting support to Type 1 fonts. Currently the only two > supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-1099) [PATCH] footnotes within tables and lists get lost
[ https://issues.apache.org/jira/browse/FOP-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1099: Summary: [PATCH] footnotes within tables and lists get lost (was: footnotes within tables and listsl get lost) > [PATCH] footnotes within tables and lists get lost > -- > > Key: FOP-1099 > URL: https://issues.apache.org/jira/browse/FOP-1099 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Affects Versions: trunk > Environment: Operating System: other > Platform: Other >Reporter: gerhard oettl > Attachments: b37579.diff, b37579.diff, b37579_2.patch, > bugzilla37579.patch, dorfchronik.fo, dorfchronik.fo.list3, > dorfchronik.fo.table3, footnote.fo, footnoteintable.patch, > footnotes.080502.diff, footnotespatch, fussnote.fo, > table_list_footnotes.diff, vtest.fo > > > Footnote outside of tables works, inside table-cell not. > The compliance page only speaks about restrictions within multicolumn > documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-1976) last simple-page-master not chosen when force-page-count=odd
[ https://issues.apache.org/jira/browse/FOP-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1976: Summary: last simple-page-master not chosen when force-page-count=odd (was: [PATCH] last simple-page-master not chosen when force-page-count=odd) > last simple-page-master not chosen when force-page-count=odd > > > Key: FOP-1976 > URL: https://issues.apache.org/jira/browse/FOP-1976 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Mehdi Houshmand > Attachments: pagebreaker.patch, smaller3page.fo > > > If force-page-count="odd" and the first page has an overflowing region onto a > second page, then the 3rd and last page should use the page-position="last" > simple-page-master in the conditional-page-master-reference. However, it was > using the "rest". > I'm having a few issues with the apache git server, so I'll attach the patch > when the issues have been resolved. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FOP-1976) last simple-page-master not chosen when force-page-count=odd
[ https://issues.apache.org/jira/browse/FOP-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14053766#comment-14053766 ] Chris Bowditch commented on FOP-1976: - I've committed a change based on Matthias's suggestion in revision: 1608489 This only addresses the problem when the start page != 1, not the issue of force-page-count="end-on-even" being handled the same as force-page-count="even" However, I feel that problem is out of scope for this bug, as it was originally opened to deal with the last page master not being selected for force-page-count="odd" (or even) Please feel free to open a separate JIRA regarding the difference between end-on-even and even. > last simple-page-master not chosen when force-page-count=odd > > > Key: FOP-1976 > URL: https://issues.apache.org/jira/browse/FOP-1976 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Mehdi Houshmand > Attachments: pagebreaker.patch, smaller3page.fo > > > If force-page-count="odd" and the first page has an overflowing region onto a > second page, then the 3rd and last page should use the page-position="last" > simple-page-master in the conditional-page-master-reference. However, it was > using the "rest". > I'm having a few issues with the apache git server, so I'll attach the patch > when the issues have been resolved. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-1976) last simple-page-master not chosen when force-page-count=odd
[ https://issues.apache.org/jira/browse/FOP-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch resolved FOP-1976. - Resolution: Fixed Fix Version/s: trunk > last simple-page-master not chosen when force-page-count=odd > > > Key: FOP-1976 > URL: https://issues.apache.org/jira/browse/FOP-1976 > Project: Fop > Issue Type: Bug > Components: layout/unqualified >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Mehdi Houshmand > Fix For: trunk > > Attachments: pagebreaker.patch, smaller3page.fo > > > If force-page-count="odd" and the first page has an overflowing region onto a > second page, then the 3rd and last page should use the page-position="last" > simple-page-master in the conditional-page-master-reference. However, it was > using the "rest". > I'm having a few issues with the apache git server, so I'll attach the patch > when the issues have been resolved. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2436) [PATCH] Merging of Tagged (Accessible) PDF
[ https://issues.apache.org/jira/browse/FOP-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2436: Summary: [PATCH] Merging of Tagged (Accessible) PDF (was: Merging of Tagged (Accessible) PDF) > [PATCH] Merging of Tagged (Accessible) PDF > -- > > Key: FOP-2436 > URL: https://issues.apache.org/jira/browse/FOP-2436 > Project: Fop > Issue Type: New Feature >Reporter: Thanasis Giannimaras > Attachments: example.pdf, fop.patch, fop.xconf, pdfplugin.patch, > pdfpluginbinaryfiles.zip, test.fo > > > This patch allows the merging of Tagged PDF. > Known Limitations : > -Only PDF with marked-content sequences in the page content stream are > supported. Marked-content sequences in content stream other than the content > stream of the page are not supported. > -Repeated headers and footers are not completely supported. Example: 2-page > pdf including table that spans both pages with repeated header. If you merge > the second page, the table header will be visible in the pdf but the reader > will ignore it (same principle applies for repeated footers). > In order to use this feature, accessibility must be enabled in the > configuration file and the source pdf must be accessible (tagged). > The fo, configuration and the source pdf of a simple example is included. > Also included, are the pdf-plugin junit tests. Necessary jars and pdf are > included in the pdfpluginbinaryfiles zip. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2536) [PATCH] Varying table border thickness in PDF output
[ https://issues.apache.org/jira/browse/FOP-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974038#comment-14974038 ] Chris Bowditch commented on FOP-2536: - Hi Martin, many thanks for submitting an improvement for the border painting. I've not studied your code yet, but since you are adding new files to the repository you will need to complete an ICLA as described at [1] before this patch could be accepted. Thanks, Chris [1] http://www.apache.org/licenses/#clas > [PATCH] Varying table border thickness in PDF output > > > Key: FOP-2536 > URL: https://issues.apache.org/jira/browse/FOP-2536 > Project: FOP > Issue Type: Improvement > Components: renderer/pdf >Reporter: Martin Leitner > Attachments: Polygon.java, patch-FOP-2434.diff > > > As already pointed out in a comment to the original issue, this is a problem > with the PDF viewers. FOP generates the borders correctly. The viewers render > border segments correctly when they are rectangles, but they make mistakes > when the segments are more general polygons. In my patch, I am splitting the > polygons into rectangles, covering as much of the polygon as possible, write > the rectangles to the PDF, then write the remaining triangles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2591) OTTFile.readName() returns incorrect name
[ https://issues.apache.org/jira/browse/FOP-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201706#comment-15201706 ] Chris Bowditch commented on FOP-2591: - Hi Eric, Thanks for your contribution. Can you attach a patch instead of a Java File. Thanks, Chris > OTTFile.readName() returns incorrect name > - > > Key: FOP-2591 > URL: https://issues.apache.org/jira/browse/FOP-2591 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.0, trunk, 2.1 > Environment: linux >Reporter: Eric Lim > Attachments: OTFFile.java > > > OTTFile.readName() returns the "FamilyName", not the "FullName". This issue > causes auto-detect font feature to select the wrong font. > For example, if I select "FreeSerif", FOP may choose > /usr/share/fonts/opentype/freefont/FreeSerifItalic.otf > because the triplet for the above font file is "FreeSerif,normal,400" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2591) [PATCH] OTTFile.readName() returns incorrect name
[ https://issues.apache.org/jira/browse/FOP-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2591: Summary: [PATCH] OTTFile.readName() returns incorrect name (was: OTTFile.readName() returns incorrect name) > [PATCH] OTTFile.readName() returns incorrect name > - > > Key: FOP-2591 > URL: https://issues.apache.org/jira/browse/FOP-2591 > Project: FOP > Issue Type: Bug > Components: font/opentype >Affects Versions: 2.0, trunk, 2.1 > Environment: linux >Reporter: Eric Lim > Attachments: OTFFile.java, OTFFile.java.patch > > > OTTFile.readName() returns the "FamilyName", not the "FullName". This issue > causes auto-detect font feature to select the wrong font. > For example, if I select "FreeSerif", FOP may choose > /usr/share/fonts/opentype/freefont/FreeSerifItalic.otf > because the triplet for the above font file is "FreeSerif,normal,400" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2601) [PATCH] Cannot resolve fonts from custom URI schemes
[ https://issues.apache.org/jira/browse/FOP-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-2601: Summary: [PATCH] Cannot resolve fonts from custom URI schemes (was: Cannot resolve fonts from custom URI schemes) > [PATCH] Cannot resolve fonts from custom URI schemes > > > Key: FOP-2601 > URL: https://issues.apache.org/jira/browse/FOP-2601 > Project: FOP > Issue Type: Bug >Affects Versions: 2.1 >Reporter: adam Retter > Attachments: fop-last-modified-resolution.patch, > xmlgraphics-commons-last-modified-resolution.patch > > > I attach two patches (one for xmlgraphics-commons and one for fop) that allow > fonts to be resolved from custom URI schemes. Previously this only worked if > you disabled font caching, because the font cache tries to get the last > modified date using java.io.File, which will fail for fonts that are resolved > from locations other than the filesystem. The fix is relatively trivial, > basically the UriResolver needs to also be able to resolve the last modified > date of the resource or return -1 if it is not possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2601) [PATCH] Cannot resolve fonts from custom URI schemes
[ https://issues.apache.org/jira/browse/FOP-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245279#comment-15245279 ] Chris Bowditch commented on FOP-2601: - Hi Adam, thanks for submitting the patch. I don't like the fact that you've changed the ResourceResolver and TempResourceResolver interfaces. Don't forget that this is used by every user implementation that embeds FOP in their own application. I wonder if there is a way to support custom URI schemes without the need to expose getLastModified Date from these interfaces? Thanks > [PATCH] Cannot resolve fonts from custom URI schemes > > > Key: FOP-2601 > URL: https://issues.apache.org/jira/browse/FOP-2601 > Project: FOP > Issue Type: Bug >Affects Versions: 2.1 >Reporter: adam Retter > Attachments: fop-last-modified-resolution.patch, > xmlgraphics-commons-last-modified-resolution.patch > > > I attach two patches (one for xmlgraphics-commons and one for fop) that allow > fonts to be resolved from custom URI schemes. Previously this only worked if > you disabled font caching, because the font cache tries to get the last > modified date using java.io.File, which will fail for fonts that are resolved > from locations other than the filesystem. The fix is relatively trivial, > basically the UriResolver needs to also be able to resolve the last modified > date of the resource or return -1 if it is not possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2601) [PATCH] Cannot resolve fonts from custom URI schemes
[ https://issues.apache.org/jira/browse/FOP-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2601. --- Resolution: Duplicate Thanks Simon. The patch proposed in FOP-2532 is preferred to this one, since it doesn't change interfaces that users may have implemented. Closing as a duplicate > [PATCH] Cannot resolve fonts from custom URI schemes > > > Key: FOP-2601 > URL: https://issues.apache.org/jira/browse/FOP-2601 > Project: FOP > Issue Type: Bug >Affects Versions: 2.1 >Reporter: adam Retter > Attachments: fop-last-modified-resolution.patch, > xmlgraphics-commons-last-modified-resolution.patch > > > I attach two patches (one for xmlgraphics-commons and one for fop) that allow > fonts to be resolved from custom URI schemes. Previously this only worked if > you disabled font caching, because the font cache tries to get the last > modified date using java.io.File, which will fail for fonts that are resolved > from locations other than the filesystem. The fix is relatively trivial, > basically the UriResolver needs to also be able to resolve the last modified > date of the resource or return -1 if it is not possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2607) PDF encryption encrypts the link target
[ https://issues.apache.org/jira/browse/FOP-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2607. --- Resolution: Duplicate FOP-2279 was closed as a duplicate of FOP-916. Why have you opened a new ticket. If you want an update on FOP-916 it makes more sense to comment there as the fop-dev list receives copies of comments on any bug in the bug tracker. Closing this as a duplicate of FOP-916 > PDF encryption encrypts the link target > --- > > Key: FOP-2607 > URL: https://issues.apache.org/jira/browse/FOP-2607 > Project: FOP > Issue Type: Bug > Components: unqualified >Affects Versions: 1.0, 1.1, 2.0, 2.1 > Environment: Linux, running JDK-1.8 >Reporter: Darryl Beckett > > When using the element to create an external link, the link > content is encrypted when encryption is enabled. > This has previously been brought up in issue FOP-2279, where examples were > given, and a solution was proposed but as of the latest release (2.1) this > still seems to be an issue. > I can correct the issue by applying the fix proposed in the above issue but > this means creating my own custom build of the engine which i really do not > want to keep doing. > Are there any plans to correct this problem in the main release trunk as I > really think that it is a major bug in the engine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2610) XSL-FO - Center Text not working
[ https://issues.apache.org/jira/browse/FOP-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318290#comment-15318290 ] Chris Bowditch commented on FOP-2610: - Please can you add the XSL-FO File so we can replicate the problem. Please also specify the version of FOP you are using. Thanks > XSL-FO - Center Text not working > > > Key: FOP-2610 > URL: https://issues.apache.org/jira/browse/FOP-2610 > Project: FOP > Issue Type: Bug >Reporter: atalante dev >Priority: Minor > Attachments: screenshot-1.png > > > In my XSL-FO, I am having problems centering text as it breaks the > footnote-line2 into 2 sentences as opposed to going the full length of the > page and then breaking the sentence once it runs out of room. > You can see the attachments -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2611) Fonts in the class path makes fonts listing fail
[ https://issues.apache.org/jira/browse/FOP-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2611. --- Resolution: Duplicate > Fonts in the class path makes fonts listing fail > > > Key: FOP-2611 > URL: https://issues.apache.org/jira/browse/FOP-2611 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: 2.1 > Environment: $ uname -a > Linux - 3.16.0-73-generic #95~14.04.1-Ubuntu SMP Thu Jun 9 08:00:04 UTC 2016 > x86_64 x86_64 x86_64 GNU/Linux > $ java -version > java version "1.8.0_77" > Java(TM) SE Runtime Environment (build 1.8.0_77-b03) > Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) >Reporter: Maxime Bégnis > > When using fonts embedded in a .jar file in the class path > (https://xmlgraphics.apache.org/fop/2.1/fonts.html#autodetect), fonts listing > fails with this exception: > org.apache.fop.cli.Main startFOP > GRAVE: Exception > java.lang.IllegalArgumentException: URI is not hierarchical > at java.io.File.(File.java:418) > at org.apache.fop.fonts.FontCache.addFont(FontCache.java:335) > at > org.apache.fop.fonts.autodetect.FontInfoFinder.getFontInfoFromCustomFont(FontInfoFinder.java:157) > at > org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:269) > at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63) > at > org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:110) > at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229) > at > org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82) > at > org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147) > at > org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127) > at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170) > at > org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187) > at org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75) > at > org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135) > at org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:105) > at > org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350) > at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:107) > at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104) > at org.apache.fop.apps.Fop.(Fop.java:78) > at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:182) > at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:107) > at org.apache.fop.cli.Main.startFOP(Main.java:186) > at org.apache.fop.cli.Main.main(Main.java:217) > Steps to reproduce: > 1. delete FOP's fonts cache (on Linux: "~/.fop/fop-fonts.cache") > 2. include a .jar file containing a font as described in > https://xmlgraphics.apache.org/fop/2.1/fonts.html#autodetect > in the FOP's class path > 3. run FOP > I found a way around this by using a custom resolver that will discard any > "jar: ..." URI. > I use fonts in a jar file for them to be taken into account by JEuclid (I > didn't find any other way so far). > I finally made this work by duplicating the fonts in the jar file in a > regular folder (so I must maintain 2 copies of each file). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2525) [PATCH] Memory leak present when using Truetype Collection (.ttc)
[ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348259#comment-15348259 ] Chris Bowditch commented on FOP-2525: - If you aren't using the Complex Scripts feature then you can work around this problem by disabling Complex Scripts, see: http://xmlgraphics.apache.org/fop/trunk/complexscripts.html#Disabling-complex-scripts > [PATCH] Memory leak present when using Truetype Collection (.ttc) > - > > Key: FOP-2525 > URL: https://issues.apache.org/jira/browse/FOP-2525 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 > Environment: At least Mac and Linux, both Oracle VM and OpenJDK >Reporter: Jeremy Smith >Priority: Minor > Attachments: FOP-2525.patch, FOP_patch_heap-usage.png > > > When a TrueType Collection file is used to specify custom fonts, and a > long-running FopFactory is used to create FOP instances to process many FO > input documents, millions of > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances > get created which are never collected. Thus the heap continues to grow, > leading to eventual GC thrashing or crash. > When the same fonts are used, but extracted from the TTC file, the issue does > not occur, and the instances of those classes are collected normally. > The issue can be seen by repeatedly processing a document with a config.xml > which specifies fonts inside of a Truetype Collection file. Attaching > VisualVM to such a process will show continuous heap growth and millions of > aforementioned instances whose numbers never decrease. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2615) "Intermediate Format"
[ https://issues.apache.org/jira/browse/FOP-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch closed FOP-2615. --- Resolution: Not A Bug Please don't use the bug tracker to ask questions. Please use the User Mailing list instead. Thanks > "Intermediate Format" > -- > > Key: FOP-2615 > URL: https://issues.apache.org/jira/browse/FOP-2615 > Project: FOP > Issue Type: Test > Environment: >Reporter: Shishir >Priority: Minor > > Hi, > could you please provide an example that how to use "Intermediate Format" > using java?(Not via command line). > Has the solution given on below link fully implemented in FOP 2.1? Will it > support all features supported by direct format? > http://people.apache.org/~jeremias/fop/benchmark-2009-02-13/ > Thanks & Regards, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2625) Allow Attachments for PDF/A-3
[ https://issues.apache.org/jira/browse/FOP-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379493#comment-15379493 ] Chris Bowditch commented on FOP-2625: - Can you attach a sample FO file that demonstrates the issue? > Allow Attachments for PDF/A-3 > - > > Key: FOP-2625 > URL: https://issues.apache.org/jira/browse/FOP-2625 > Project: FOP > Issue Type: Bug > Components: renderer/pdf >Affects Versions: 2.1 > Environment: probably any >Reporter: Stefan Hegny >Priority: Minor > Labels: pdf, pdf/a > > Embedded files should be allowed for PDF/A-3, e.g. required by the german > "Zugferd" invoice standard, but: > SEVERE: Exception > org.apache.fop.apps.FOPException: PDF/A-3b does not allow embedded files. > org.apache.fop.pdf.PDFConformanceException: PDF/A-3b does not allow embedded > files. > at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) > at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) > at org.apache.fop.cli.Main.startFOP(Main.java:186) > at org.apache.fop.cli.Main.main(Main.java:217) > Caused by: org.apache.fop.pdf.PDFConformanceException: PDF/A-3b does not > allow embedded files. > at > org.apache.fop.pdf.PDFProfile.verifyEmbeddedFilesAllowed(PDFProfile.java:336) > at > org.apache.fop.render.pdf.PDFRenderingUtil.addEmbeddedFile(PDFRenderingUtil.java:651) > at > org.apache.fop.render.pdf.PDFDocumentHandler.handleExtensionObject(PDFDocumentHandler.java:318) > at > org.apache.fop.render.intermediate.util.IFDocumentHandlerProxy.handleExtensionObject(IFDocumentHandlerProxy.java:192) > at > org.apache.fop.render.intermediate.IFRenderer.processOffDocumentItem(IFRenderer.java:325) > at > org.apache.fop.area.RenderPagesModel.handleOffDocumentItem(RenderPagesModel.java:232) > at > org.apache.fop.area.AreaTreeHandler.addOffDocumentItem(AreaTreeHandler.java:376) > at > org.apache.fop.area.AreaTreeHandler.wrapAndAddExtensionAttachments(AreaTreeHandler.java:245) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2624) FO to RTF conversion adds unnecessary \cell after ... when it is nested inside any table cell
[ https://issues.apache.org/jira/browse/FOP-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379497#comment-15379497 ] Chris Bowditch commented on FOP-2624: - Can you attach a complete XSL-FO file that demonstrates the issue? Thanks > FO to RTF conversion adds unnecessary \cell after > ... when it is nested inside any table cell > > > Key: FOP-2624 > URL: https://issues.apache.org/jira/browse/FOP-2624 > Project: FOP > Issue Type: Bug >Affects Versions: 1.1 >Reporter: jaydeep V > > I am trying to convert from FO to RTF here, The version of FOP i am using is > 1.1 > let say below is my FO > ... > ... > > > > > > > > > • > > > test data > > > ...(similarly many list items).. > > ..(some more fo:block div data).. > > > > > here immediately after the RTF is addind '\cell', Because of > that even though there is some data after list block RTF treats it as end of > table cell. > so Rest of the data after list block won't be visible in RTF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
