[jira] [Commented] (FOP-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header
[ https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527667#comment-13527667 ] Luis Bernardo commented on FOP-1840: applied patch 12559043: http://svn.apache.org/viewvc?view=revision&revision=1419183 > [PATCH] Region-Body Column balancing incorrect if content is table with header > -- > > Key: FOP-1840 > URL: https://issues.apache.org/jira/browse/FOP-1840 > Project: Fop > Issue Type: Improvement > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: a.kovacs >Assignee: fop-dev > Attachments: b49801_dirty_hack.patch, b49801.fo, balancing-fos.zip, > fo.xml, patch.diff, test-after.pdf, test-before.pdf > > > To reproduce bug please do the following: > Use: > > Fill the region-body with content like : > ...(content is table with header) .. > ... (one line (summary)) .. > If the content is made of normal blocks the columns are balanced before the > span="all" summary line. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table without headers the columns are balanced correct. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table with header the columns are not balanced correct. > (the right one is shorter.) > HeaderHeader > 123456567890 > 234567678901 > 345678 > 456789 > Summary: 1234567890 > The "computeDemerits()" algorithm is wrong in class > "BalancingColumnBreakingAlgorithm". > The "fullLen" value is to short. Exactly the replicated header width is > missing. In the "par" list the header is contained only once although the > header is displayed in every column. (in the example twice) > Solution could be to place the header as many times in the "par" list as many > columns exist, or to count the existing one header as many times as needed. -- 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-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header
[ https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527667#comment-13527667 ] Luis Bernardo commented on FOP-1840: applied patch 12559043: http://svn.apache.org/viewvc?view=revision&revision=1419183 > [PATCH] Region-Body Column balancing incorrect if content is table with header > -- > > Key: FOP-1840 > URL: https://issues.apache.org/jira/browse/FOP-1840 > Project: Fop > Issue Type: Improvement > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: a.kovacs >Assignee: fop-dev > Attachments: b49801_dirty_hack.patch, b49801.fo, balancing-fos.zip, > fo.xml, patch.diff, test-after.pdf, test-before.pdf > > > To reproduce bug please do the following: > Use: > > Fill the region-body with content like : > ...(content is table with header) .. > ... (one line (summary)) .. > If the content is made of normal blocks the columns are balanced before the > span="all" summary line. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table without headers the columns are balanced correct. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table with header the columns are not balanced correct. > (the right one is shorter.) > HeaderHeader > 123456567890 > 234567678901 > 345678 > 456789 > Summary: 1234567890 > The "computeDemerits()" algorithm is wrong in class > "BalancingColumnBreakingAlgorithm". > The "fullLen" value is to short. Exactly the replicated header width is > missing. In the "par" list the header is contained only once although the > header is displayed in every column. (in the example twice) > Solution could be to place the header as many times in the "par" list as many > columns exist, or to count the existing one header as many times as needed. -- 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-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header
[ https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530458#comment-13530458 ] Luis Bernardo commented on FOP-1840: you need to have the for the balancing algorithm to kick in (you can check that without it computeDemerits() never gets called). without it means you don't want balancing. regarding the example balance-4.fo, I agree that at first is puzzling but upon close inspection one sees that although there are span="all" blocks they are not in the right place and the balancing algorithm is not called at all for the content that matters. the result is the same as not having them at all. see attached edited balance-4-*.fo.xml files. > [PATCH] Region-Body Column balancing incorrect if content is table with header > -- > > Key: FOP-1840 > URL: https://issues.apache.org/jira/browse/FOP-1840 > Project: Fop > Issue Type: Improvement > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: a.kovacs >Assignee: fop-dev > Attachments: b49801_dirty_hack.patch, b49801.fo, > balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, > balance-4.fo.xml, balance-4.pdf, balancing-fos.zip, fix.diff, fo.xml, > patch.diff, test-after.pdf, test-before.pdf > > > To reproduce bug please do the following: > Use: > > Fill the region-body with content like : > ...(content is table with header) .. > ... (one line (summary)) .. > If the content is made of normal blocks the columns are balanced before the > span="all" summary line. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table without headers the columns are balanced correct. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table with header the columns are not balanced correct. > (the right one is shorter.) > HeaderHeader > 123456567890 > 234567678901 > 345678 > 456789 > Summary: 1234567890 > The "computeDemerits()" algorithm is wrong in class > "BalancingColumnBreakingAlgorithm". > The "fullLen" value is to short. Exactly the replicated header width is > missing. In the "par" list the header is contained only once although the > header is displayed in every column. (in the example twice) > Solution could be to place the header as many times in the "par" list as many > columns exist, or to count the existing one header as many times as needed. -- 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-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header
[ https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530458#comment-13530458 ] Luis Bernardo commented on FOP-1840: you need to have the for the balancing algorithm to kick in (you can check that without it computeDemerits() never gets called). without it means you don't want balancing. regarding the example balance-4.fo, I agree that at first is puzzling but upon close inspection one sees that although there are span="all" blocks they are not in the right place and the balancing algorithm is not called at all for the content that matters. the result is the same as not having them at all. see attached edited balance-4-*.fo.xml files. > [PATCH] Region-Body Column balancing incorrect if content is table with header > -- > > Key: FOP-1840 > URL: https://issues.apache.org/jira/browse/FOP-1840 > Project: Fop > Issue Type: Improvement > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: a.kovacs >Assignee: fop-dev > Attachments: b49801_dirty_hack.patch, b49801.fo, > balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, > balance-4.fo.xml, balance-4.pdf, balancing-fos.zip, fix.diff, fo.xml, > patch.diff, test-after.pdf, test-before.pdf > > > To reproduce bug please do the following: > Use: > > Fill the region-body with content like : > ...(content is table with header) .. > ... (one line (summary)) .. > If the content is made of normal blocks the columns are balanced before the > span="all" summary line. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table without headers the columns are balanced correct. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table with header the columns are not balanced correct. > (the right one is shorter.) > HeaderHeader > 123456567890 > 234567678901 > 345678 > 456789 > Summary: 1234567890 > The "computeDemerits()" algorithm is wrong in class > "BalancingColumnBreakingAlgorithm". > The "fullLen" value is to short. Exactly the replicated header width is > missing. In the "par" list the header is contained only once although the > header is displayed in every column. (in the example twice) > Solution could be to place the header as many times in the "par" list as many > columns exist, or to count the existing one header as many times as needed. -- 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-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header
[ https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-1840: --- Attachment: balance-4-none.fo.xml balance-4-edited.fo.xml > [PATCH] Region-Body Column balancing incorrect if content is table with header > -- > > Key: FOP-1840 > URL: https://issues.apache.org/jira/browse/FOP-1840 > Project: Fop > Issue Type: Improvement > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: a.kovacs >Assignee: fop-dev > Attachments: b49801_dirty_hack.patch, b49801.fo, > balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, > balance-4-edited.fo.xml, balance-4.fo.xml, balance-4-none.fo.xml, > balance-4.pdf, balancing-fos.zip, fix.diff, fo.xml, patch.diff, > test-after.pdf, test-before.pdf > > > To reproduce bug please do the following: > Use: > > Fill the region-body with content like : > ...(content is table with header) .. > ... (one line (summary)) .. > If the content is made of normal blocks the columns are balanced before the > span="all" summary line. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table without headers the columns are balanced correct. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table with header the columns are not balanced correct. > (the right one is shorter.) > HeaderHeader > 123456567890 > 234567678901 > 345678 > 456789 > Summary: 1234567890 > The "computeDemerits()" algorithm is wrong in class > "BalancingColumnBreakingAlgorithm". > The "fullLen" value is to short. Exactly the replicated header width is > missing. In the "par" list the header is contained only once although the > header is displayed in every column. (in the example twice) > Solution could be to place the header as many times in the "par" list as many > columns exist, or to count the existing one header as many times as needed. -- 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-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header
[ https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-1840: --- Attachment: balance-4-none.fo.xml balance-4-edited.fo.xml > [PATCH] Region-Body Column balancing incorrect if content is table with header > -- > > Key: FOP-1840 > URL: https://issues.apache.org/jira/browse/FOP-1840 > Project: Fop > Issue Type: Improvement > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: a.kovacs >Assignee: fop-dev > Attachments: b49801_dirty_hack.patch, b49801.fo, > balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, > balance-4-edited.fo.xml, balance-4.fo.xml, balance-4-none.fo.xml, > balance-4.pdf, balancing-fos.zip, fix.diff, fo.xml, patch.diff, > test-after.pdf, test-before.pdf > > > To reproduce bug please do the following: > Use: > > Fill the region-body with content like : > ...(content is table with header) .. > ... (one line (summary)) .. > If the content is made of normal blocks the columns are balanced before the > span="all" summary line. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table without headers the columns are balanced correct. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table with header the columns are not balanced correct. > (the right one is shorter.) > HeaderHeader > 123456567890 > 234567678901 > 345678 > 456789 > Summary: 1234567890 > The "computeDemerits()" algorithm is wrong in class > "BalancingColumnBreakingAlgorithm". > The "fullLen" value is to short. Exactly the replicated header width is > missing. In the "par" list the header is contained only once although the > header is displayed in every column. (in the example twice) > Solution could be to place the header as many times in the "par" list as many > columns exist, or to count the existing one header as many times as needed. -- 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-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header
[ https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530494#comment-13530494 ] Luis Bernardo commented on FOP-1840: applied attachment 12560540 (patch): http://svn.apache.org/viewvc?view=revision&revision=1421038 > [PATCH] Region-Body Column balancing incorrect if content is table with header > -- > > Key: FOP-1840 > URL: https://issues.apache.org/jira/browse/FOP-1840 > Project: Fop > Issue Type: Improvement > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: a.kovacs >Assignee: fop-dev > Attachments: b49801_dirty_hack.patch, b49801.fo, > balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, > balance-4-edited.fo.xml, balance-4.fo.xml, balance-4-none.fo.xml, > balance-4.pdf, balancing-fos.zip, fix.diff, fo.xml, patch.diff, > test-after.pdf, test-before.pdf > > > To reproduce bug please do the following: > Use: > > Fill the region-body with content like : > ...(content is table with header) .. > ... (one line (summary)) .. > If the content is made of normal blocks the columns are balanced before the > span="all" summary line. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table without headers the columns are balanced correct. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table with header the columns are not balanced correct. > (the right one is shorter.) > HeaderHeader > 123456567890 > 234567678901 > 345678 > 456789 > Summary: 1234567890 > The "computeDemerits()" algorithm is wrong in class > "BalancingColumnBreakingAlgorithm". > The "fullLen" value is to short. Exactly the replicated header width is > missing. In the "par" list the header is contained only once although the > header is displayed in every column. (in the example twice) > Solution could be to place the header as many times in the "par" list as many > columns exist, or to count the existing one header as many times as needed. -- 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-1840) [PATCH] Region-Body Column balancing incorrect if content is table with header
[ https://issues.apache.org/jira/browse/FOP-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530494#comment-13530494 ] Luis Bernardo commented on FOP-1840: applied attachment 12560540 (patch): http://svn.apache.org/viewvc?view=revision&revision=1421038 > [PATCH] Region-Body Column balancing incorrect if content is table with header > -- > > Key: FOP-1840 > URL: https://issues.apache.org/jira/browse/FOP-1840 > Project: Fop > Issue Type: Improvement > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: a.kovacs >Assignee: fop-dev > Attachments: b49801_dirty_hack.patch, b49801.fo, > balance-2-expected.pdf, balance-2.fo, balance-2.pdf, balance-3.fo.xml, > balance-4-edited.fo.xml, balance-4.fo.xml, balance-4-none.fo.xml, > balance-4.pdf, balancing-fos.zip, fix.diff, fo.xml, patch.diff, > test-after.pdf, test-before.pdf > > > To reproduce bug please do the following: > Use: > > Fill the region-body with content like : > ...(content is table with header) .. > ... (one line (summary)) .. > If the content is made of normal blocks the columns are balanced before the > span="all" summary line. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table without headers the columns are balanced correct. > like: > 123456456789 > 234567567890 > 345678678901 > Summary: 1234567890 > If the content is a table with header the columns are not balanced correct. > (the right one is shorter.) > HeaderHeader > 123456567890 > 234567678901 > 345678 > 456789 > Summary: 1234567890 > The "computeDemerits()" algorithm is wrong in class > "BalancingColumnBreakingAlgorithm". > The "fullLen" value is to short. Exactly the replicated header width is > missing. In the "par" list the header is contained only once although the > header is displayed in every column. (in the example twice) > Solution could be to place the header as many times in the "par" list as many > columns exist, or to count the existing one header as many times as needed. -- 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-2178) incomplete kerning when complex script features are enabled
[ https://issues.apache.org/jira/browse/FOP-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo closed FOP-2178. -- the issue has been fixed. thanks. > incomplete kerning when complex script features are enabled > --- > > Key: FOP-2178 > URL: https://issues.apache.org/jira/browse/FOP-2178 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1 >Reporter: Glenn Adams >Assignee: Glenn Adams > Fix For: trunk > > Attachments: kerningissue.fo.xml, kerningissue.pdf > > > alternate kerning pairs are missed when kerning with complex script features > enabled -- 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-1738) break-before="page" in table-row
[ https://issues.apache.org/jira/browse/FOP-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo reassigned FOP-1738: -- Assignee: Luis Bernardo > break-before="page" in table-row > > > Key: FOP-1738 > URL: https://issues.apache.org/jira/browse/FOP-1738 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: guillaume >Assignee: Luis Bernardo > Attachments: break.fo, break_new.pdf, break_old.pdf > > > Updating my fop version to fop trunk, I found a difference using > break-before="page" in a table-row. > The break is not done (in my old version -svn 712095- this break was done). -- 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-1738) break-before="page" in table-row
[ https://issues.apache.org/jira/browse/FOP-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1738. Resolution: Fixed Fix Version/s: trunk this is not reproducible in trunk anymore. the current output matches the break_old.pdf. I don't know what commit fixed this... > break-before="page" in table-row > > > Key: FOP-1738 > URL: https://issues.apache.org/jira/browse/FOP-1738 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk > Environment: Operating System: Windows XP > Platform: PC >Reporter: guillaume >Assignee: Luis Bernardo > Fix For: trunk > > Attachments: break.fo, break_new.pdf, break_old.pdf > > > Updating my fop version to fop trunk, I found a difference using > break-before="page" in a table-row. > The break is not done (in my old version -svn 712095- this break was done). -- 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-1597) break-after not honored
[ https://issues.apache.org/jira/browse/FOP-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1597. Resolution: Fixed Fix Version/s: trunk this is not reproducible in trunk anymore. the output for the example is as described, with a second empty page and the second block in the third page > break-after not honored > --- > > Key: FOP-1597 > URL: https://issues.apache.org/jira/browse/FOP-1597 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 0.95 > Environment: Operating System: Windows Server 2003 > Platform: PC >Reporter: Georg Datterl > Fix For: trunk > > Attachments: publication.fo > > > With break-after="odd-page" there should be one empty page and the second > block should start on page 3. > FOP 0.94 gets it wrong since it creates one empty page when break-after is > set to even-page, and indeed two empty pages with odd-page, instead of > respectively 0 and 1. > FOP 0.95 doesn’t seem to honor the break at all. -- 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-1714) Image processing makes FOP really slow
[ https://issues.apache.org/jira/browse/FOP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1714. Resolution: Fixed Fix Version/s: trunk this has been fixed in trunk for a long time; as such marking as resolved > Image processing makes FOP really slow > -- > > Key: FOP-1714 > URL: https://issues.apache.org/jira/browse/FOP-1714 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: 0.95 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Jonathan Levinson > Fix For: trunk > > Attachments: test.fo, test-image.png > > > In investigating a problem in the display of PNG images in FOP, I discovered > that image processing was really slow. > Examining the code in a debugger the surprise is that the source of slowness > is > not the rendering of the image (which is done through Java’s JAI) but in the > steps leading up to the rendering of the image. > For a simple FO page, with a single PNG image FOP takes 90 seconds. Remove > the > image and FOP takes 1 second. RenderX takes a second as well with our without > the image. > So the addition of a single image to an FO page results in extreme slowness – > two orders of magnitude slower than RenderX XEP. -- 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-1872) External document is clipped when rotated
[ https://issues.apache.org/jira/browse/FOP-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-1872: --- Attachment: portrait.pdf portrait.fo landscape.pdf landscape.fo example attached > External document is clipped when rotated > - > > Key: FOP-1872 > URL: https://issues.apache.org/jira/browse/FOP-1872 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.0 > Environment: Operating System: Linux > Platform: PC >Reporter: Krister Wicksell > Attachments: landscape.fo, landscape.pdf, portrait.fo, portrait.pdf > > > When I use fox:external-document and a reference-orientation of 90 degrees > the content is clipped to width of the page. The external document is A4 > landscape so I rotate it to get it as portrait. So the document is rotated > and the page size is correct but the content of the page is clipped and don't > fill the whole height. > I have traced the problem to ExternalDocumentLayoutManager.createPage(...). > I think the line: > RegionViewport rv = new RegionViewport(referenceRect); > should be replaced by: > RegionViewport rv = new RegionViewport(new Rectangle(0, 0, imageSize.width, > imageSize.height)); > Is this correct? -- 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-2187) Generating pdf works awt & png crashes when overflow hidden
[ https://issues.apache.org/jira/browse/FOP-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2187. Resolution: Fixed Fix Version/s: (was: 1.1) trunk Assignee: Luis Bernardo http://svn.apache.org/viewvc?view=revision&revision=1434992 > Generating pdf works awt & png crashes when overflow hidden > --- > > Key: FOP-2187 > URL: https://issues.apache.org/jira/browse/FOP-2187 > Project: Fop > Issue Type: Bug > Components: images >Affects Versions: 1.1 > Environment: windows >Reporter: Janez Jere >Assignee: Luis Bernardo > Fix For: trunk > > > without overflow="hidden" png is generated, pdf works in all cases > command: > fop.bat -xml test.xml -xsl test.fo aa.pdf # works > fop.bat -xml test.xml -xsl test.fo -png aa.pn # ERROR (NullPointer @ Area > test.xml: > > test.fo: > > xmlns:fo="http://www.w3.org/1999/XSL/Format"; > xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> > > > > page-width="210mm" margin="0" > > > > > > > > > > > > foo > > > > > > > > SEVERE: Error while rendering page 1. Reason: java.lang.NullPointerException > java.lang.NullPointerException > at java.awt.geom.Area.(Area.java:108) > at > org.apache.fop.render.java2d.Java2DGraphicsState.updateClip(Java2DGraphicsState.java:250) > at > org.apache.fop.render.java2d.Java2DPainter.clipRect(Java2DPainter.java:173) > at > org.apache.fop.render.java2d.Java2DPainter.startViewport(Java2DPainter.java:128) > at > org.apache.fop.render.intermediate.AbstractIFPainter.startViewport(AbstractIFPainter.java:111) > at > org.apache.fop.render.intermediate.IFGraphicContext$Viewport.start(IFGraphicContext.java:184) > at > org.apache.fop.render.intermediate.IFRenderer.startViewport(IFRenderer.java:890) > at > org.apache.fop.render.intermediate.IFRenderer.startVParea(IFRenderer.java:878) > at > org.apache.fop.render.intermediate.IFRenderer.renderBlockViewport(IFRenderer.java:844) > at > org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:578) > at > org.apache.fop.render.intermediate.IFRenderer.renderBlock(IFRenderer.java:980) > at > org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:546) -- 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] [Created] (FOP-2190) decrease PDF file size when CS are enabled
Luis Bernardo created FOP-2190: -- Summary: decrease PDF file size when CS are enabled Key: FOP-2190 URL: https://issues.apache.org/jira/browse/FOP-2190 Project: Fop Issue Type: Improvement Components: pdf Affects Versions: 1.1, trunk Reporter: Luis Bernardo when CS are enabled, the current code may make use of the operators Td and Tj in situations where TJ would be appropriate leading to an increase in file size. note: this happens in the PDFPainter.drawText(). -- 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-2190) decrease PDF file size when CS are enabled
[ https://issues.apache.org/jira/browse/FOP-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2190: --- Attachment: fop-2190.patch the attached patch tries to address the issue by switching back and forth between drawTextWithDX and drawTextWidthDP depending on the elements in the dp[][] array. included is also a cleaning of the dp[][] to only include the elements that have a non default value > decrease PDF file size when CS are enabled > --- > > Key: FOP-2190 > URL: https://issues.apache.org/jira/browse/FOP-2190 > Project: Fop > Issue Type: Improvement > Components: pdf >Affects Versions: 1.1, trunk >Reporter: Luis Bernardo > Attachments: fop-2190.patch > > > when CS are enabled, the current code may make use of the operators Td and Tj > in situations where TJ would be appropriate leading to an increase in file > size. note: this happens in the PDFPainter.drawText(). -- 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-2190) decrease PDF file size when CS are enabled
[ https://issues.apache.org/jira/browse/FOP-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559507#comment-13559507 ] Luis Bernardo commented on FOP-2190: in my tests performance was greatly improved by this change. I did not measure though how memory allocation was impacted. the test was the following: - use a long text document (around 100 pages) with the Arial font - generate the PDF using the servlet that ships with FOP, making sure it uses a proper configured fop.xconf (i.e., uses the Arial font and does not disable CS) - use ab (apache benchmark) to make 100 requests and look at the time measurements (after allowing for warm up) note that I also added some time measurements inside the servlet to confirm the improvement in performance was not due to reduced HTTP transfer times (i.e., was really in the generation of the document) it is possible that some different tests show other results. > decrease PDF file size when CS are enabled > --- > > Key: FOP-2190 > URL: https://issues.apache.org/jira/browse/FOP-2190 > Project: Fop > Issue Type: Improvement > Components: pdf >Affects Versions: 1.1, trunk >Reporter: Luis Bernardo > Attachments: fop-2190.patch > > > when CS are enabled, the current code may make use of the operators Td and Tj > in situations where TJ would be appropriate leading to an increase in file > size. note: this happens in the PDFPainter.drawText(). -- 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-2198) misspelled word an
[ https://issues.apache.org/jira/browse/FOP-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2198. Resolution: Fixed http://svn.apache.org/viewvc?rev=1437802&view=rev > misspelled word an > -- > > Key: FOP-2198 > URL: https://issues.apache.org/jira/browse/FOP-2198 > Project: Fop > Issue Type: Bug > Components: documentation >Affects Versions: 1.1 >Reporter: Sebul >Priority: Minor > > In http://xmlgraphics.apache.org/fop/1.1/fonts.html#register > The attribute "encoding-mode" is optional an may have the following values: > I think that 'an' is misspel of 'and' -- 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-2198) misspelled word an
[ https://issues.apache.org/jira/browse/FOP-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo closed FOP-2198. -- typo corrected > misspelled word an > -- > > Key: FOP-2198 > URL: https://issues.apache.org/jira/browse/FOP-2198 > Project: Fop > Issue Type: Bug > Components: documentation >Affects Versions: 1.1 >Reporter: Sebul >Priority: Minor > > In http://xmlgraphics.apache.org/fop/1.1/fonts.html#register > The attribute "encoding-mode" is optional an may have the following values: > I think that 'an' is misspel of 'and' -- 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-2156) PNG and GIF image generation fails in RTF documents
[ https://issues.apache.org/jira/browse/FOP-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561292#comment-13561292 ] Luis Bernardo commented on FOP-2156: the issue is not understood at the moment. but add this to the fop.xconf, before the element: see if it makes a difference. apparently this image loader is taking precedence with RTF. > PNG and GIF image generation fails in RTF documents > --- > > Key: FOP-2156 > URL: https://issues.apache.org/jira/browse/FOP-2156 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: 1.1 > Environment: Operating System: All > Platform: PC >Reporter: Carl Zetterberg > > Tomcat 6 > java 1.7 > Fop 1.1 > xmlgraphics-commons-1.5.jar > width="auto" > height="auto" content-width="80%" content-height="auto" /> > will produce: > org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic$ExternalGraphicException: > The tag does not support gif - image type > both for PNG and GIF files when producing RTF documents > The same environment and XSL produce PDF that are ok. > Switching back to fop 1.0 and xmlgraphics-commons-1.4.jar resolves the > problem. -- 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-2199) providem misspel?
[ https://issues.apache.org/jira/browse/FOP-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo closed FOP-2199. -- typo fixed > providem misspel? > - > > Key: FOP-2199 > URL: https://issues.apache.org/jira/browse/FOP-2199 > Project: Fop > Issue Type: Bug > Components: documentation >Affects Versions: 1.1 >Reporter: Sebul > Labels: documentation > > In http://xmlgraphics.apache.org/fop/1.1/fonts.html > The JAR files can be added to fop by providem them in the classpath, e.g. > copying them into the lib/ directory. > providem ? -- 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-2199) providem misspel?
[ https://issues.apache.org/jira/browse/FOP-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2199. Resolution: Fixed fixed in http://svn.apache.org/viewvc?rev=1438214&view=rev > providem misspel? > - > > Key: FOP-2199 > URL: https://issues.apache.org/jira/browse/FOP-2199 > Project: Fop > Issue Type: Bug > Components: documentation >Affects Versions: 1.1 >Reporter: Sebul > Labels: documentation > > In http://xmlgraphics.apache.org/fop/1.1/fonts.html > The JAR files can be added to fop by providem them in the classpath, e.g. > copying them into the lib/ directory. > providem ? -- 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-2156) PNG and GIF image generation fails in RTF documents
[ https://issues.apache.org/jira/browse/FOP-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13562085#comment-13562085 ] Luis Bernardo commented on FOP-2156: can you please provide an example that works with fop-1.0? > PNG and GIF image generation fails in RTF documents > --- > > Key: FOP-2156 > URL: https://issues.apache.org/jira/browse/FOP-2156 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: 1.1 > Environment: Operating System: All > Platform: PC >Reporter: Carl Zetterberg > > Tomcat 6 > java 1.7 > Fop 1.1 > xmlgraphics-commons-1.5.jar > width="auto" > height="auto" content-width="80%" content-height="auto" /> > will produce: > org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic$ExternalGraphicException: > The tag does not support gif - image type > both for PNG and GIF files when producing RTF documents > The same environment and XSL produce PDF that are ok. > Switching back to fop 1.0 and xmlgraphics-commons-1.4.jar resolves the > problem. -- 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-2156) PNG and GIF image generation fails in RTF documents
[ https://issues.apache.org/jira/browse/FOP-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13563191#comment-13563191 ] Luis Bernardo commented on FOP-2156: I am unable to reproduce the behavior with fop-1.0. Tried in Mac, Linux and Windows and always get a blank page (the image, which apparently was embedded, is not visible). Can you provide your output RTF produced with 1.0? Also, can you convert your PNG to JPEG and see if it works? > PNG and GIF image generation fails in RTF documents > --- > > Key: FOP-2156 > URL: https://issues.apache.org/jira/browse/FOP-2156 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: 1.1 > Environment: Operating System: All > Platform: PC >Reporter: Carl Zetterberg > > Tomcat 6 > java 1.7 > Fop 1.1 > xmlgraphics-commons-1.5.jar > width="auto" > height="auto" content-width="80%" content-height="auto" /> > will produce: > org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic$ExternalGraphicException: > The tag does not support gif - image type > both for PNG and GIF files when producing RTF documents > The same environment and XSL produce PDF that are ok. > Switching back to fop 1.0 and xmlgraphics-commons-1.4.jar resolves the > problem. -- 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-2044) [PATCH] Hyphenation of Uppercase Words, Combined with Underlines
[ https://issues.apache.org/jira/browse/FOP-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13563699#comment-13563699 ] Luis Bernardo commented on FOP-2044: the patch is a bit involved but seems to work well. but I am not sure the behavior implemented is the desired one in some corner cases. the implementation applies the remainCharCount and pushCharCount values (the minimum number of characters to allow before and after a break point) to all words when in my view should only apply to the beginning of the first and the end of the last words. an example: INFLATED_EGOS. I think INFLATED_E-GOS should be allowed but the patch does not allow because E-GOS is not allowed (if remainCharCount is 2). comments? > [PATCH] Hyphenation of Uppercase Words, Combined with Underlines > > > Key: FOP-2044 > URL: https://issues.apache.org/jira/browse/FOP-2044 > Project: Fop > Issue Type: Improvement > Components: general >Affects Versions: 1.0 > Environment: Operating System: All > Platform: All >Reporter: Thomas Schraitle >Assignee: Robert Meyer > Attachments: output.pdf, patch.diff, uppercase-hyphen.fo, > uppercase-hyphen.pdf > > > Consider the attached FO file which combines words of lowercase and uppercase > letters. > As it is expected, the word "expected" is hyphenated correctly (example 2). > Also the uppercase "SUCCESS". Even combined with underlines before and after > the word (see example 4 and 5). > However, if there is another word (like OCF_SUCCESS) the word isn't > hyphenated at all anymore. I don't know if this is an expected behaviour or > an issue in the hyphenation patterns. Interestingly, XEP from RenderX > hyphenates it as "OCF_SUC-CESS". As far as I know, they use also the TeX > hyphenation patterns as FOP. -- 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] [Created] (FOP-2200) page selection in multi-page TIFF does not work
Luis Bernardo created FOP-2200: -- Summary: page selection in multi-page TIFF does not work Key: FOP-2200 URL: https://issues.apache.org/jira/browse/FOP-2200 Project: Fop Issue Type: Bug Affects Versions: 1.1, 1.0, 0.95, trunk Reporter: Luis Bernardo the selection of a page of a multi-page TIFF by appending #page=page_number to the image source, as described in the graphics page, does not work with trunk or any other release. -- 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-2201) The PDF output contains XSL-FO syntax
[ https://issues.apache.org/jira/browse/FOP-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565985#comment-13565985 ] Luis Bernardo commented on FOP-2201: I did not try your code but I don't think the issue is with FOP. There are two things you can try to check that (I just tried them): a) run from the command line, after converting the xml and xsl to fo: fop -xml fop.xml -xsl fop.xsl -foout fop.fo fop -fo fop.fo -pdf fop-new.pdf b) there is a Java example in examples/embedding/java/ExampleXML2PDF.java that you can try instead of your code; just replace the xml and xsl file paths by your files and adapt the output pdf file path. In both cases the resulting PDF does not show the problems you see in your output. > The PDF output contains XSL-FO syntax > - > > Key: FOP-2201 > URL: https://issues.apache.org/jira/browse/FOP-2201 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 > Environment: Java 7.11/Windows 7 >Reporter: lance campbell > Labels: issue, transformation > Fix For: 1.1 > > > The PDF that is generated contains XSL-FO syntax at random places. To view > the issue go to the below pdf and do a search for ":block": > http://illinois.edu/lance/fop.pdf > To recreate the issue use the following files: > http://illinois.edu/lance/fop.xml > http://illinois.edu/lance/fop.xsl > http://illinois.edu/lance/fop.java > Put the files fop.xml and fop.xsl in /temp/ . The java will pull in the two > files and output /temp/fop.pdf . I believe this is a memory issue. If you > cut the size of the XML document down it works fine. -- 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-2201) The PDF output contains XSL-FO syntax
[ https://issues.apache.org/jira/browse/FOP-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2201. Resolution: Invalid I did not try this in Windows with Java 7 but in principle this is not a bug. > The PDF output contains XSL-FO syntax > - > > Key: FOP-2201 > URL: https://issues.apache.org/jira/browse/FOP-2201 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 > Environment: Java 7.11/Windows 7 >Reporter: lance campbell > Labels: issue, transformation > Fix For: 1.1 > > > The PDF that is generated contains XSL-FO syntax at random places. To view > the issue go to the below pdf and do a search for ":block": > http://illinois.edu/lance/fop.pdf > To recreate the issue use the following files: > http://illinois.edu/lance/fop.xml > http://illinois.edu/lance/fop.xsl > http://illinois.edu/lance/fop.java > Put the files fop.xml and fop.xsl in /temp/ . The java will pull in the two > files and output /temp/fop.pdf . I believe this is a memory issue. If you > cut the size of the XML document down it works fine. -- 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-2200) page selection in multi-page TIFF does not work
[ https://issues.apache.org/jira/browse/FOP-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2200. Resolution: Not A Problem selection of a page from a multi-page TIFF does work if the image loader is ImageLoaderImageIO. this may require disabling ImageLoaderRawCCITTFax which does not support the feature and usually takes precedence over ImageLoaderImageIO. website has been updated: http://svn.apache.org/viewvc?view=revision&revision=1442438 > page selection in multi-page TIFF does not work > --- > > Key: FOP-2200 > URL: https://issues.apache.org/jira/browse/FOP-2200 > Project: Fop > Issue Type: Bug >Affects Versions: 0.95, 1.0, 1.1, trunk >Reporter: Luis Bernardo > > the selection of a page of a multi-page TIFF by appending #page=page_number > to the image source, as described in the graphics page, does not work with > trunk or any other release. -- 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-2200) page selection in multi-page TIFF does not work
[ https://issues.apache.org/jira/browse/FOP-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo closed FOP-2200. -- there is a simple work-around so this is a non-issue > page selection in multi-page TIFF does not work > --- > > Key: FOP-2200 > URL: https://issues.apache.org/jira/browse/FOP-2200 > Project: Fop > Issue Type: Bug >Affects Versions: 0.95, 1.0, 1.1, trunk >Reporter: Luis Bernardo > > the selection of a page of a multi-page TIFF by appending #page=page_number > to the image source, as described in the graphics page, does not work with > trunk or any other release. -- 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-2206) Add support for CS placement and escapement data in PS renderer.
[ https://issues.apache.org/jira/browse/FOP-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572462#comment-13572462 ] Luis Bernardo commented on FOP-2206: unit test added: http://svn.apache.org/viewvc?view=revision&revision=1442992 > Add support for CS placement and escapement data in PS renderer. > > > Key: FOP-2206 > URL: https://issues.apache.org/jira/browse/FOP-2206 > Project: Fop > Issue Type: Task > Components: ps >Affects Versions: 1.1, trunk >Reporter: Glenn Adams >Assignee: Glenn Adams > Fix For: trunk > > > Implement support for dp[][] in PSPainter#drawText. -- 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-2169) Documentation is misleading
[ https://issues.apache.org/jira/browse/FOP-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2169. Resolution: Invalid this is indeed correct for Type 1 fonts, also known as PostScript fonts. on the other hand, TTF can be either subset or full embedded. > Documentation is misleading > --- > > Key: FOP-2169 > URL: https://issues.apache.org/jira/browse/FOP-2169 > Project: Fop > Issue Type: Bug > Components: ps >Affects Versions: trunk > Environment: Operating System: Linux > Platform: PC >Reporter: ssteiner > > http://xmlgraphics.apache.org/fop/trunk/fonts.html > says "When embedding PostScript fonts, the entire font is always embedded." > Specific character embedded is supported -- 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-2169) Documentation is misleading
[ https://issues.apache.org/jira/browse/FOP-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo closed FOP-2169. -- the web page was updated to make the fact clear. > Documentation is misleading > --- > > Key: FOP-2169 > URL: https://issues.apache.org/jira/browse/FOP-2169 > Project: Fop > Issue Type: Bug > Components: ps >Affects Versions: trunk > Environment: Operating System: Linux > Platform: PC >Reporter: ssteiner > > http://xmlgraphics.apache.org/fop/trunk/fonts.html > says "When embedding PostScript fonts, the entire font is always embedded." > Specific character embedded is supported -- 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-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579610#comment-13579610 ] Luis Bernardo edited comment on FOP-2213 at 2/15/13 11:59 PM: -- In FOP 1.1 we get the right (i.e., the same as in 1.0) kerning with -nocs (CS are enabled by default). If CS are enabled then glyph positioning uses the GPOS tables if they are available. There is no guarantee that the positioning will match the old kerning although one would expect it to be so (at least similar). This needs further investigation. was (Author: lmpmbernardo): In FOP-1.1 we get the right (i.e., the same as in 1.0) kerning with -nocs (CS are enabled by default). If CS are enabled then glyph positioning uses the GPOS tables if they are available. There is no guarantee that the positioning will match the old kerning although one would expect it to be so (at least similar). This needs further investigation. > Kerning is no longer applied > > > Key: FOP-2213 > URL: https://issues.apache.org/jira/browse/FOP-2213 > Project: Fop > Issue Type: Bug > Components: fonts >Affects Versions: 1.1, trunk >Reporter: Vincent Hennebert > Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo > > > See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph > as expected, while it's not the case with FOP 1.1. -- 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-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579610#comment-13579610 ] Luis Bernardo commented on FOP-2213: In FOP-1.1 we get the right (i.e., the same as in 1.0) kerning with -nocs (CS are enabled by default). If CS are enabled then glyph positioning uses the GPOS tables if they are available. There is no guarantee that the positioning will match the old kerning although one would expect it to be so (at least similar). This needs further investigation. > Kerning is no longer applied > > > Key: FOP-2213 > URL: https://issues.apache.org/jira/browse/FOP-2213 > Project: Fop > Issue Type: Bug > Components: fonts >Affects Versions: 1.1, trunk >Reporter: Vincent Hennebert > Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo > > > See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph > as expected, while it's not the case with FOP 1.1. -- 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-2213) Kerning is no longer applied
[ https://issues.apache.org/jira/browse/FOP-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2213: --- Attachment: kerning-v2_1.1-cs.pdf kerning-v2_1.1-nocs.pdf kerning-v2.fo The attached example (kerning-v2.fo) uses the Arial font (font not provided) side to side with DejaVu. Since with Arial the kerning seems to be the same with or without CS the issue may be with the lack of a GPOS table in the DejaVu font. > Kerning is no longer applied > > > Key: FOP-2213 > URL: https://issues.apache.org/jira/browse/FOP-2213 > Project: Fop > Issue Type: Bug > Components: fonts >Affects Versions: 1.1, trunk >Reporter: Vincent Hennebert > Attachments: fop.xconf, kerning_1.0.pdf, kerning_1.1.pdf, kerning.fo, > kerning-v2_1.1-cs.pdf, kerning-v2_1.1-nocs.pdf, kerning-v2.fo > > > See attached example. With FOP 1.0 the dot can be seen 'inside' the Y glyph > as expected, while it's not the case with FOP 1.1. -- 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-2044) [PATCH] Hyphenation of Uppercase Words, Combined with Underlines
[ https://issues.apache.org/jira/browse/FOP-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582654#comment-13582654 ] Luis Bernardo commented on FOP-2044: patch 12563269 (above) applied: http://svn.apache.org/viewvc?view=revision&revision=1448469. not resolving issue yet since I think comment from 2013-01-27 should be addressed. > [PATCH] Hyphenation of Uppercase Words, Combined with Underlines > > > Key: FOP-2044 > URL: https://issues.apache.org/jira/browse/FOP-2044 > Project: Fop > Issue Type: Improvement > Components: general >Affects Versions: 1.0 > Environment: Operating System: All > Platform: All >Reporter: Thomas Schraitle >Assignee: Robert Meyer > Attachments: output.pdf, patch.diff, uppercase-hyphen.fo, > uppercase-hyphen.pdf > > > Consider the attached FO file which combines words of lowercase and uppercase > letters. > As it is expected, the word "expected" is hyphenated correctly (example 2). > Also the uppercase "SUCCESS". Even combined with underlines before and after > the word (see example 4 and 5). > However, if there is another word (like OCF_SUCCESS) the word isn't > hyphenated at all anymore. I don't know if this is an expected behaviour or > an issue in the hyphenation patterns. Interestingly, XEP from RenderX > hyphenates it as "OCF_SUC-CESS". As far as I know, they use also the TeX > hyphenation patterns as FOP. -- 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-2183) [PATCH] Use event producer when Colour Profile in PNG Image is bad
[ https://issues.apache.org/jira/browse/FOP-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2183. Resolution: Fixed Fix Version/s: trunk patch applied: http://svn.apache.org/viewvc?view=revision&revision=1448479 and http://svn.apache.org/viewvc?view=revision&revision=1448483 > [PATCH] Use event producer when Colour Profile in PNG Image is bad > -- > > Key: FOP-2183 > URL: https://issues.apache.org/jira/browse/FOP-2183 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: eventProducerforwarn.patch, Lethal.png, oddpng.fo, > xgc.patch > > > Instead of printing warning in XGC we should be using event producer when > called from fop -- 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-2181) [PATCH] Add a test case for the recent fix made in FOP-2174 and XGC-76 regarding source resolution scaling with SVG and images
[ https://issues.apache.org/jira/browse/FOP-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2181. Resolution: Fixed Fix Version/s: trunk patch applied: http://svn.apache.org/viewvc?view=revision&revision=1448484 > [PATCH] Add a test case for the recent fix made in FOP-2174 and XGC-76 > regarding source resolution scaling with SVG and images > -- > > Key: FOP-2181 > URL: https://issues.apache.org/jira/browse/FOP-2181 > Project: Fop > Issue Type: Test > Components: images, svg >Affects Versions: trunk >Reporter: Robert Meyer >Priority: Minor > Fix For: trunk > > Attachments: patch.diff > > -- 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-2177) [PATCH] If a right aligned image exceeds a table cells bounds, it will overflow in the wrong direction
[ https://issues.apache.org/jira/browse/FOP-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583683#comment-13583683 ] Luis Bernardo commented on FOP-2177: the output-old.pdf can be obtained with fop 1.0; I think the behavior in 1.0 makes more sense that the current one in trunk and 1.1. > [PATCH] If a right aligned image exceeds a table cells bounds, it will > overflow in the wrong direction > -- > > Key: FOP-2177 > URL: https://issues.apache.org/jira/browse/FOP-2177 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer >Priority: Minor > Attachments: house_blank.gif, output-old.pdf, output-trunk.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] [Resolved] (FOP-2177) [PATCH] If a right aligned image exceeds a table cells bounds, it will overflow in the wrong direction
[ https://issues.apache.org/jira/browse/FOP-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2177. Resolution: Fixed Fix Version/s: trunk patch applied: http://svn.apache.org/viewvc?view=revision&revision=1448860 > [PATCH] If a right aligned image exceeds a table cells bounds, it will > overflow in the wrong direction > -- > > Key: FOP-2177 > URL: https://issues.apache.org/jira/browse/FOP-2177 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer >Priority: Minor > Fix For: trunk > > Attachments: house_blank.gif, output-old.pdf, output-trunk.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] [Resolved] (FOP-1353) hyphenation inside block in FOP works only for pure alphabetical characters
[ https://issues.apache.org/jira/browse/FOP-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1353. Resolution: Fixed Fix Version/s: trunk If Andreas comment is correct, and I think it is (i.e., hyphenation of a number makes no sense) then this issue has been fixed by the patch applied to FOP-2044. > hyphenation inside block in FOP works only for pure alphabetical characters > --- > > Key: FOP-1353 > URL: https://issues.apache.org/jira/browse/FOP-1353 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: 0.93 > Environment: Operating System: Windows XP > Platform: Other >Reporter: Anuja > Fix For: trunk > > Attachments: hyphenation_issues.fo, hyphenation_issues.pdf > > > Hyphenate does not work correctly when the data in the block has numeric > characters or commas... > In the example below, only the data in the first table-row gets hyphenated > correctly > > http://www.w3.org/1999/XSL/Format"; > xmlns:datetime="http://exslt.org/dates-and-times"; writing-mode="lr-tb" text- > align="start" role="html"> > > height="11in"> >bottom="1.5in" margin-left=" 0.25in" page-width="8.5in" page-height="11in"/> >align="before"/> >align="after"/> > > > > > > >language="en" space-before.conditionality="retain" space-before="0.5in"/> > > >language="en" space-after.conditionality="retain" space-after="0.5in"/> > > > > Hyphenation for this table data works - when all the data > is non numeric > > > > > > > > > language="en">HyphenationOfThisBlockWorksNicelyUnlessWhenThereIsNoCommaOrNumeri > cDataBeforeIt > > > > > > language="en">HyphenationOfThisBlockWorksNicely,OnlyForTheBlockBeforeTheCommaIn > TheBlockData > > > > > > language="en">12345678901234567890123456789012345678901234567890123456789012345 > 6789012345678901234567890 > > > > > > > > > > > > > -- 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-1353) hyphenation inside block in FOP works only for pure alphabetical characters
[ https://issues.apache.org/jira/browse/FOP-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-1353: --- Attachment: hyphenation_issues-after-fop-2044.pdf > hyphenation inside block in FOP works only for pure alphabetical characters > --- > > Key: FOP-1353 > URL: https://issues.apache.org/jira/browse/FOP-1353 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: 0.93 > Environment: Operating System: Windows XP > Platform: Other >Reporter: Anuja > Fix For: trunk > > Attachments: hyphenation_issues-after-fop-2044.pdf, > hyphenation_issues.fo, hyphenation_issues.pdf > > > Hyphenate does not work correctly when the data in the block has numeric > characters or commas... > In the example below, only the data in the first table-row gets hyphenated > correctly > > http://www.w3.org/1999/XSL/Format"; > xmlns:datetime="http://exslt.org/dates-and-times"; writing-mode="lr-tb" text- > align="start" role="html"> > > height="11in"> >bottom="1.5in" margin-left=" 0.25in" page-width="8.5in" page-height="11in"/> >align="before"/> >align="after"/> > > > > > > >language="en" space-before.conditionality="retain" space-before="0.5in"/> > > >language="en" space-after.conditionality="retain" space-after="0.5in"/> > > > > Hyphenation for this table data works - when all the data > is non numeric > > > > > > > > > language="en">HyphenationOfThisBlockWorksNicelyUnlessWhenThereIsNoCommaOrNumeri > cDataBeforeIt > > > > > > language="en">HyphenationOfThisBlockWorksNicely,OnlyForTheBlockBeforeTheCommaIn > TheBlockData > > > > > > language="en">12345678901234567890123456789012345678901234567890123456789012345 > 6789012345678901234567890 > > > > > > > > > > > > > -- 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-2123) Right align doesn't work as expected with page-number-citation
[ https://issues.apache.org/jira/browse/FOP-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2123. Resolution: Fixed Fix Version/s: trunk issue apparently fixed by FOP-2177 patch > Right align doesn't work as expected with page-number-citation > -- > > Key: FOP-2123 > URL: https://issues.apache.org/jira/browse/FOP-2123 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Giuseppe Briotti > Fix For: trunk > > Attachments: testcases.zip, test-out.1.0.zip, > test-out-after-fop-2177.tar.gz > > > Following the Pascal's suggestion, I report this is that seems to be a bug. > The discussion started in FOP users mailing list. > Right align is not correctly honored if the block is not large enough and/or > if it contains fo:page-number-citation. > This problem seems to be related to fo:page-number-citation, block size, text > alignement and keep-together.within-line="always". > The behaviour is diffent comparing 0.95 and 1.1rc1. > In the attached zip 4 cases are presented (fo, pdf from 0.95 and pdf from > 1.1): > A. this is the starting case: > keep-together.within-line="always", text-align="right", > fo:page-number-citation > B. > keep-together.within-line="auto", text-align="right", fo:page-number-citation > C. > keep-together.within-line="always", text-align="left", fo:page-number-citation > D. > keep-together.within-line="always", text-align="right", > fo:page-number-citation replaced by more text (a number, instead of the > computed page number). -- 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-2123) Right align doesn't work as expected with page-number-citation
[ https://issues.apache.org/jira/browse/FOP-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2123: --- Attachment: test-out-after-fop-2177.tar.gz > Right align doesn't work as expected with page-number-citation > -- > > Key: FOP-2123 > URL: https://issues.apache.org/jira/browse/FOP-2123 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: trunk > Environment: Operating System: All > Platform: PC >Reporter: Giuseppe Briotti > Fix For: trunk > > Attachments: testcases.zip, test-out.1.0.zip, > test-out-after-fop-2177.tar.gz > > > Following the Pascal's suggestion, I report this is that seems to be a bug. > The discussion started in FOP users mailing list. > Right align is not correctly honored if the block is not large enough and/or > if it contains fo:page-number-citation. > This problem seems to be related to fo:page-number-citation, block size, text > alignement and keep-together.within-line="always". > The behaviour is diffent comparing 0.95 and 1.1rc1. > In the attached zip 4 cases are presented (fo, pdf from 0.95 and pdf from > 1.1): > A. this is the starting case: > keep-together.within-line="always", text-align="right", > fo:page-number-citation > B. > keep-together.within-line="auto", text-align="right", fo:page-number-citation > C. > keep-together.within-line="always", text-align="left", fo:page-number-citation > D. > keep-together.within-line="always", text-align="right", > fo:page-number-citation replaced by more text (a number, instead of the > computed page number). -- 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-2177) [PATCH] If a right aligned image exceeds a table cells bounds, it will overflow in the wrong direction
[ https://issues.apache.org/jira/browse/FOP-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584494#comment-13584494 ] Luis Bernardo commented on FOP-2177: there was indeed a similar problem with text, which is described in FOP-2123, but I think this patch also fixed it. FOP-2123 has attached new output that shows the desired result. > [PATCH] If a right aligned image exceeds a table cells bounds, it will > overflow in the wrong direction > -- > > Key: FOP-2177 > URL: https://issues.apache.org/jira/browse/FOP-2177 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer >Priority: Minor > Fix For: trunk > > Attachments: house_blank.gif, output-old.pdf, output-trunk.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-1815) Table cells with span and background-color have wrong border width
[ https://issues.apache.org/jira/browse/FOP-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-1815: --- Attachment: fop-input.pdf this was generated with trunk but the output is the same as in 1.0; zooming in one can see the borders have the same width even though that does not seem to be the case at 100% zoom. > Table cells with span and background-color have wrong border width > -- > > Key: FOP-1815 > URL: https://issues.apache.org/jira/browse/FOP-1815 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Toby S > Attachments: fop-input.pdf, fop-input.xml > > > A table cell with background-color and number-columns-spanned > 1 has thinner > border lines than other cells. -- 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-1815) Table cells with span and background-color have wrong border width
[ https://issues.apache.org/jira/browse/FOP-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-1815. Resolution: Won't Fix This issue is real but it is a problem with the viewers, not with FOP although FOP could do things differently in a way that would not cause this problem (FOP may draw a continuous line as a series of shorter segments all of the same width but many viewers do not display the same width at all zoom resolutions). Since usually there are ways to achieve the desired output doing things differently there are no plans to rewrite the border drawing code in the foreseeable future. > Table cells with span and background-color have wrong border width > -- > > Key: FOP-1815 > URL: https://issues.apache.org/jira/browse/FOP-1815 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.0 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Toby S > Attachments: fop-input.pdf, fop-input.xml > > > A table cell with background-color and number-columns-spanned > 1 has thinner > border lines than other cells. -- 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-2177) [PATCH] If a right aligned image exceeds a table cells bounds, it will overflow in the wrong direction
[ https://issues.apache.org/jira/browse/FOP-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592833#comment-13592833 ] Luis Bernardo commented on FOP-2177: the output of this example is correct in trunk now (it was not correct with FOP 1.1). > [PATCH] If a right aligned image exceeds a table cells bounds, it will > overflow in the wrong direction > -- > > Key: FOP-2177 > URL: https://issues.apache.org/jira/browse/FOP-2177 > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: trunk >Reporter: Robert Meyer >Assignee: Robert Meyer >Priority: Minor > Fix For: trunk > > Attachments: house_blank.gif, output-old.pdf, output-trunk.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-2219) XGC change removal as it is no longer needed with the image scaling change in FOP
[ https://issues.apache.org/jira/browse/FOP-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592880#comment-13592880 ] Luis Bernardo commented on FOP-2219: applied: http://svn.apache.org/viewvc?view=revision&revision=1452610 > XGC change removal as it is no longer needed with the image scaling change in > FOP > - > > Key: FOP-2219 > URL: https://issues.apache.org/jira/browse/FOP-2219 > Project: Fop > Issue Type: Bug > Components: images >Reporter: Robert Meyer > Attachments: patch.diff > > -- 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-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 ] Luis Bernardo updated FOP-2214: --- Fix Version/s: trunk > [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 > Fix For: trunk > > 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] [Resolved] (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 ] Luis Bernardo resolved FOP-2214. Resolution: Fixed resolving since patches have been applied. > [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] [Resolved] (FOP-2044) [PATCH] Hyphenation of Uppercase Words, Combined with Underlines
[ https://issues.apache.org/jira/browse/FOP-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2044. Resolution: Fixed Fix Version/s: trunk applied patch 12571399: http://svn.apache.org/viewvc?view=revision&revision=1457168 > [PATCH] Hyphenation of Uppercase Words, Combined with Underlines > > > Key: FOP-2044 > URL: https://issues.apache.org/jira/browse/FOP-2044 > Project: Fop > Issue Type: Improvement > Components: general >Affects Versions: 1.0 > Environment: Operating System: All > Platform: All >Reporter: Thomas Schraitle >Assignee: Robert Meyer > Fix For: trunk > > Attachments: output.pdf, patch2.diff, patch.diff, > uppercase-hyphen.fo, uppercase-hyphen.pdf > > > Consider the attached FO file which combines words of lowercase and uppercase > letters. > As it is expected, the word "expected" is hyphenated correctly (example 2). > Also the uppercase "SUCCESS". Even combined with underlines before and after > the word (see example 4 and 5). > However, if there is another word (like OCF_SUCCESS) the word isn't > hyphenated at all anymore. I don't know if this is an expected behaviour or > an issue in the hyphenation patterns. Interestingly, XEP from RenderX > hyphenates it as "OCF_SUC-CESS". As far as I know, they use also the TeX > hyphenation patterns as FOP. -- 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=13604036#comment-13604036 ] Luis Bernardo commented on FOP-2221: patch applied: http://svn.apache.org/viewvc?view=revision&revision=1457180 note: make sure to provide a svn patch in the future; also a test example would help document the change. > [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 > Attachments: overflowsmessage2.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] [Resolved] (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:all-tabpanel ] Luis Bernardo resolved FOP-2221. Resolution: Fixed Fix Version/s: trunk > [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: overflowsmessage2.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] [Resolved] (FOP-2224) [PATCH] NPE for SVG text in AFP
[ https://issues.apache.org/jira/browse/FOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2224. Resolution: Fixed Fix Version/s: trunk patch applied: http://svn.apache.org/viewvc?view=revision&revision=1457183 note: please provide a svn patch in the future. > [PATCH] NPE for SVG text in AFP > --- > > Key: FOP-2224 > URL: https://issues.apache.org/jira/browse/FOP-2224 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: afpnpe.patch, fop.xconf, npe.fo > > > Text position needs to be reset so correct font can be chosen > fop npe.fo -c fop.xconf -afp out.afp -- 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-2223) [PATCH] Lines do not span to the end in rounded border cells in AFP
[ https://issues.apache.org/jira/browse/FOP-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2223. Resolution: Fixed Fix Version/s: trunk patch applied: http://svn.apache.org/viewvc?view=revision&revision=1457188 > [PATCH] Lines do not span to the end in rounded border cells in AFP > --- > > Key: FOP-2223 > URL: https://issues.apache.org/jira/browse/FOP-2223 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: afproundbordertrunk.patch, test.fo > > > fop test.fo -afp out.afp -- 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-2216) [PATCH] PDF forms are offset
[ https://issues.apache.org/jira/browse/FOP-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2216: --- Attachment: test-after.pdf test-before.pdf test.fo the patch works with the test.fo example provided, however it does not seem to work with the original simpletest.fo that the patch author provided... can you please provide the output PDF before and after the patch and a fix if necessary? > [PATCH] PDF forms are offset > > > Key: FOP-2216 > URL: https://issues.apache.org/jira/browse/FOP-2216 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: foppdfform.patch, pdfplugintrunkform.patch, > simpletest.fo, test-after.pdf, test-before.pdf, test.fo, tsform.pdf > > > PDF forms widgets are offset from pdf image in pdf-plugin -- 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-2216) [PATCH] PDF forms are offset
[ https://issues.apache.org/jira/browse/FOP-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604342#comment-13604342 ] Luis Bernardo commented on FOP-2216: patch applied (http://svn.apache.org/viewvc?view=revision&revision=1457280 and http://svn.apache.org/viewvc?view=revision&revision=1457282) since it does work in some cases. waiting for possible fix for the original simpletest.fo case. > [PATCH] PDF forms are offset > > > Key: FOP-2216 > URL: https://issues.apache.org/jira/browse/FOP-2216 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: foppdfform.patch, pdfplugintrunkform.patch, > simpletest.fo, test-after.pdf, test-before.pdf, test.fo, tsform.pdf > > > PDF forms widgets are offset from pdf image in pdf-plugin -- 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-2216) [PATCH] PDF forms are offset
[ https://issues.apache.org/jira/browse/FOP-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2216. Resolution: Fixed Fix Version/s: trunk > [PATCH] PDF forms are offset > > > Key: FOP-2216 > URL: https://issues.apache.org/jira/browse/FOP-2216 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: foppdfform.patch, pdfplugintrunkform2.patch, > pdfplugintrunkform.patch, simpletest-after.pdf, simpletest-before.pdf, > simpletest.fo, test-after.pdf, test-before.pdf, test.fo, tsform.pdf > > > PDF forms widgets are offset from pdf image in pdf-plugin -- 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-2216) [PATCH] PDF forms are offset
[ https://issues.apache.org/jira/browse/FOP-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2216: --- Attachment: simpletest-after.pdf simpletest-before.pdf patch applied (http://svn.apache.org/viewvc?view=revision&revision=1458068); output for simpletest.fo attached. > [PATCH] PDF forms are offset > > > Key: FOP-2216 > URL: https://issues.apache.org/jira/browse/FOP-2216 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Attachments: foppdfform.patch, pdfplugintrunkform2.patch, > pdfplugintrunkform.patch, simpletest-after.pdf, simpletest-before.pdf, > simpletest.fo, test-after.pdf, test-before.pdf, test.fo, tsform.pdf > > > PDF forms widgets are offset from pdf image in pdf-plugin -- 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] [Reopened] (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:all-tabpanel ] Luis Bernardo reopened FOP-2221: changes need to be revisited -- reopening issue. > [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: overflowsmessage2.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-2231) typo
[ https://issues.apache.org/jira/browse/FOP-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614703#comment-13614703 ] Luis Bernardo commented on FOP-2231: that's a good point but I don't think any decision has been made regarding the proper way to say FOP, i.e., whether to say it as a word (I happen to say it that way) or to say it as individual letters. maybe this is the time to have a vote and make it official? as an example, PNG is officially known as ping although most of us refer to it as individual letters (I do); so what is official may not be what is used in the end but at least would help resolve issues like this. > typo > > > Key: FOP-2231 > URL: https://issues.apache.org/jira/browse/FOP-2231 > Project: Fop > Issue Type: Bug > Components: documentation >Affects Versions: 1.1 >Reporter: Sebul > Labels: documentation > > http://xmlgraphics.apache.org/fop/1.1/anttask.html > To call FOP tasks within Ant, first add a FOP task definition to your Ant > build file. One method of defining the task is as follows: > a FOP ? an FOP -- 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-2222) Incorrect page break in cell
[ https://issues.apache.org/jira/browse/FOP-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614739#comment-13614739 ] Luis Bernardo commented on FOP-: I may be mistaken, but probably o.a.f.layoutmgr.table.TableStepper is the class to look at. In particular the getCombinedKnuthElementsForRowGroup() method may be involved. > Incorrect page break in cell > > > Key: FOP- > URL: https://issues.apache.org/jira/browse/FOP- > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1, trunk >Reporter: Nico > Attachments: test-two-cells.fo, test-two-cells.pdf > > > In a table with one row and two cells, spanning across multiple pages, the > pages break are not what should be expected. (I don't know if it's by design > or a bug). > Please see the attached .fo and .pdf. > Test case : the first cell has blocks with 120mm height. The second cell has > blocks with 100mm heights. The page height is 266mm > First page : each cell contains his two blocks on the page > second page : after the first page break, the fist cell show only the one > block where two is expected. The second block, which is on page 3, should fit > on page 2. > Is it standard behaviour ? Thanks. -- 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=13632241#comment-13632241 ] Luis Bernardo commented on FOP-2221: second patch applied: http://svn.apache.org/viewvc?view=revision&revision=1468239 > [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: overflowsmessage2.patch, overflowsmessage5.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-2230) RowSpanning will not effect, if there is not a column with all rows
[ https://issues.apache.org/jira/browse/FOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634995#comment-13634995 ] Luis Bernardo commented on FOP-2230: RTF output looks the same (when viewed with Libre Office). > RowSpanning will not effect, if there is not a column with all rows > --- > > Key: FOP-2230 > URL: https://issues.apache.org/jira/browse/FOP-2230 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 >Reporter: Markus Sticker > Attachments: table_error_expected.pdf, table_error.fo, > table_error.pdf, table_error.rtf > > > RowSpanning will not effect, if there is not a column with all rows -- 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-2241) Plugin for PDF-embedding does not support custom UriResolver
[ https://issues.apache.org/jira/browse/FOP-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13639723#comment-13639723 ] Luis Bernardo commented on FOP-2241: Can you provide a sample FO file that shows the problem? Do you have the same issue when you run from the command line? > Plugin for PDF-embedding does not support custom UriResolver > > > Key: FOP-2241 > URL: https://issues.apache.org/jira/browse/FOP-2241 > Project: Fop > Issue Type: Bug > Components: images >Affects Versions: 1.1 > Environment: Linux, but should not matter >Reporter: Daniela Kruse > > http://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images/trunk/src/java/org/apache/fop/render/pdf/pdfbox/PreloaderPDF.java > This class seems not to support the custom uri loader set on creation: > setURIResolver(new DatafileURIResolver(fopFactory.getURIResolver())); > Resulting stack trace is: > ERROR: '' > javax.xml.transform.TransformerException: java.lang.NullPointerException > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:736) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:340) > at ch.invoca.represent.fop.Fo2PDF.convertFO2PDF(Fo2PDF.java:82) > at > ch.invoca.bapi.delivery.post.PostBarcodeHelper.integratePdfFO(PostBarcodeHelper.java:452) > at > ch.invoca.bapi.delivery.post.PostBarcodeHelper.main(PostBarcodeHelper.java:607) > Caused by: java.lang.NullPointerException > at > org.apache.fop.datatypes.URISpecification.getURL(URISpecification.java:47) > at > org.apache.fop.datatypes.URISpecification.escapeURI(URISpecification.java:117) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.deriveDocumentURI(PreloaderPDF.java:95) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.loadPDF(PreloaderPDF.java:110) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.preloadImage(PreloaderPDF.java:83) > at > org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:175) > at > org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:128) > at > org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:122) > at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:81) > at org.apache.fop.fo.FObj.processNode(FObj.java:124) > at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280) > at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175) > at > com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:208) > at > com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:281) > at > com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:247) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:606) > at > com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:183) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:353) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2717) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:489) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:631) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:727) > ... 4 more > - > java.lang.NullPointerException > at > org.apache.fop.datatypes.URISpecification.getURL(URISpecification.java:47) > at > org.apache.fop.datatypes.URISpecification.escapeURI(URISpecification.java:117) > at > org.apache.fop.render.
[jira] [Commented] (FOP-2222) Incorrect page break in cell
[ https://issues.apache.org/jira/browse/FOP-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13639759#comment-13639759 ] Luis Bernardo commented on FOP-: Assuming the issue is the one described in the above link then I think the algorithm may suffer from the same problem that was causing FOP-1840, i.e., an algorithm that makes decisions too soon based on wrong (incomplete) information. In that case the approach used to fix FOP-1840 may also work. > Incorrect page break in cell > > > Key: FOP- > URL: https://issues.apache.org/jira/browse/FOP- > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1, trunk >Reporter: Nico > Attachments: test-two-cells.fo, test-two-cells.pdf > > > In a table with one row and two cells, spanning across multiple pages, the > pages break are not what should be expected. (I don't know if it's by design > or a bug). > Please see the attached .fo and .pdf. > Test case : the first cell has blocks with 120mm height. The second cell has > blocks with 100mm heights. The page height is 266mm > First page : each cell contains his two blocks on the page > second page : after the first page break, the fist cell show only the one > block where two is expected. The second block, which is on page 3, should fit > on page 2. > Is it standard behaviour ? Thanks. -- 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=13642251#comment-13642251 ] Luis Bernardo commented on FOP-2242: FOP works with FO, not with XML and XSL. FOP can receive as input XML and XSL but that is provided as a convenience feature and any performance issue should be reported with FO. In any case, I do not see a performance difference generating PDF from your XML and XSL, or generating first FO and then PDF form that. Commenting out the svg:text in the FO led to a better time (as expected) but the difference was not significative. What time differences do you measure in the very slow versus very fast? > 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-2232) too much bullets, if several fo:blocks inside a list-item-body
[ https://issues.apache.org/jira/browse/FOP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642264#comment-13642264 ] Luis Bernardo commented on FOP-2232: how many bullets do you see? with what viewer and OS? on a Mac with either TextEdit or OpenOffice I see none (which is not right, but brings up the point that we need to know what viewer is being used). > too much bullets, if several fo:blocks inside a list-item-body > -- > > Key: FOP-2232 > URL: https://issues.apache.org/jira/browse/FOP-2232 > Project: Fop > Issue Type: Bug > Components: rtf >Affects Versions: trunk >Reporter: Markus Sticker > Attachments: ListItem_error.fo, ListItem_error.fo.pdf, > ListItem_error.fo.rtf > > > If more than one block is inside a list-item-body for each block a bullet > will be shown. -- 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-2243) Typo in "/usr/bin/fop" breaks fop
[ https://issues.apache.org/jira/browse/FOP-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642268#comment-13642268 ] Luis Bernardo commented on FOP-2243: this needs to be brought up with the OpenSuSE packagers. the fop script provided by FOP is not the one used by OpenSuSE. > Typo in "/usr/bin/fop" breaks fop > - > > Key: FOP-2243 > URL: https://issues.apache.org/jira/browse/FOP-2243 > Project: Fop > Issue Type: Bug > Components: general >Affects Versions: 1.1 > Environment: OpenSuSE 12.3 >Reporter: Johan Persson > Original Estimate: 10m > Remaining Estimate: 10m > > In the "/usr/bin/fop" start script there is a list of needed jars. Among them > it is listed so: > xml-commons-jaxp-1.3.apis > There is s typo in this since the installed jar is actually named > xml-commons-jaxp-1.3-apis > The error is that there should be a hyphen (-) instead of a period after the > version number. > Reproducible: Always > The fix is obvious correct the name of the JAR. Patch below. fop.OLD is the > existing fop with error > --- /usr/bin/fop.OLD2013-04-25 13:31:30.614395317 +0200 > +++ /usr/bin/fop2013-04-25 13:31:56.952600172 +0200 > @@ -33,7 +33,7 @@ > # Rest of the configuration > MAIN_CLASS=org.apache.fop.cli.Main > -BASE_JARS="xmlgraphics-fop xmlgraphics-commons commons-logging commons-io > avalon-framework batik-all xml-commons-jaxp-1.3.apis > xml-commons-jaxp-1.3-apis-ext" > +BASE_JARS="xmlgraphics-fop xmlgraphics-commons commons-logging commons-io > avalon-framework batik-all xml-commons-jaxp-1.3-apis > xml-commons-jaxp-1.3-apis-ext" > # Set parameters > set_jvm -- 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-2241) Plugin for PDF-embedding does not support custom UriResolver
[ https://issues.apache.org/jira/browse/FOP-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2241. Resolution: Cannot Reproduce I cannot reproduce the issue so I think you must have a problem with your code. The attached example works for me with fop 1.1. > Plugin for PDF-embedding does not support custom UriResolver > > > Key: FOP-2241 > URL: https://issues.apache.org/jira/browse/FOP-2241 > Project: Fop > Issue Type: Bug > Components: images >Affects Versions: 1.1 > Environment: Linux, but should not matter >Reporter: Daniela Kruse > > http://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images/trunk/src/java/org/apache/fop/render/pdf/pdfbox/PreloaderPDF.java > This class seems not to support the custom uri loader set on creation: > setURIResolver(new DatafileURIResolver(fopFactory.getURIResolver())); > Resulting stack trace is: > ERROR: '' > javax.xml.transform.TransformerException: java.lang.NullPointerException > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:736) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:340) > at ch.invoca.represent.fop.Fo2PDF.convertFO2PDF(Fo2PDF.java:82) > at > ch.invoca.bapi.delivery.post.PostBarcodeHelper.integratePdfFO(PostBarcodeHelper.java:452) > at > ch.invoca.bapi.delivery.post.PostBarcodeHelper.main(PostBarcodeHelper.java:607) > Caused by: java.lang.NullPointerException > at > org.apache.fop.datatypes.URISpecification.getURL(URISpecification.java:47) > at > org.apache.fop.datatypes.URISpecification.escapeURI(URISpecification.java:117) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.deriveDocumentURI(PreloaderPDF.java:95) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.loadPDF(PreloaderPDF.java:110) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.preloadImage(PreloaderPDF.java:83) > at > org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:175) > at > org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:128) > at > org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:122) > at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:81) > at org.apache.fop.fo.FObj.processNode(FObj.java:124) > at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280) > at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175) > at > com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:208) > at > com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:281) > at > com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:247) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:606) > at > com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:183) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:353) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2717) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:489) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:631) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:727) > ... 4 more > - > java.lang.NullPointerException > at > org.apache.fop.datatypes.URISpecification.getURL(URISpecification.java:47) > at > org.apache.fop.datatypes.URISpecification.escapeURI(URISpecification.java:117) > at > org.apache.fop.render.pdf.pdfbox.Pr
[jira] [Updated] (FOP-2241) Plugin for PDF-embedding does not support custom UriResolver
[ https://issues.apache.org/jira/browse/FOP-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2241: --- Attachment: uriresolver.fo FOToOutputFormatUsingCustomURIResolver.java MyResolver.java attached example that works with fop-pdf-images plugin. > Plugin for PDF-embedding does not support custom UriResolver > > > Key: FOP-2241 > URL: https://issues.apache.org/jira/browse/FOP-2241 > Project: Fop > Issue Type: Bug > Components: images >Affects Versions: 1.1 > Environment: Linux, but should not matter >Reporter: Daniela Kruse > Attachments: FOToOutputFormatUsingCustomURIResolver.java, > MyResolver.java, uriresolver.fo > > > http://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images/trunk/src/java/org/apache/fop/render/pdf/pdfbox/PreloaderPDF.java > This class seems not to support the custom uri loader set on creation: > setURIResolver(new DatafileURIResolver(fopFactory.getURIResolver())); > Resulting stack trace is: > ERROR: '' > javax.xml.transform.TransformerException: java.lang.NullPointerException > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:736) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:340) > at ch.invoca.represent.fop.Fo2PDF.convertFO2PDF(Fo2PDF.java:82) > at > ch.invoca.bapi.delivery.post.PostBarcodeHelper.integratePdfFO(PostBarcodeHelper.java:452) > at > ch.invoca.bapi.delivery.post.PostBarcodeHelper.main(PostBarcodeHelper.java:607) > Caused by: java.lang.NullPointerException > at > org.apache.fop.datatypes.URISpecification.getURL(URISpecification.java:47) > at > org.apache.fop.datatypes.URISpecification.escapeURI(URISpecification.java:117) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.deriveDocumentURI(PreloaderPDF.java:95) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.loadPDF(PreloaderPDF.java:110) > at > org.apache.fop.render.pdf.pdfbox.PreloaderPDF.preloadImage(PreloaderPDF.java:83) > at > org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:175) > at > org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:128) > at > org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:122) > at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:81) > at org.apache.fop.fo.FObj.processNode(FObj.java:124) > at > org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:280) > at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175) > at > com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:208) > at > com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:281) > at > com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:247) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:606) > at > com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:183) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:353) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2717) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:489) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:631) > at > com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:727) > ... 4 more > - > java.lang.NullPointerException > at > org.apache.fop.datatypes.URISpecification.getURL(URISpecification.java:47) > at > org.apac
[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=13644158#comment-13644158 ] Luis Bernardo commented on FOP-2242: I cannot reproduce that behavior. On a Mac the difference I see is 3.2 secs vs 3.7 secs, also with fop 1.1... Can you try in a different machine? Are you using the version that comes with SuSE or you got the one provided by the FOP project? > 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-2230) RowSpanning will not effect, if there is not a column with all rows
[ https://issues.apache.org/jira/browse/FOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2230. Resolution: Not A Problem flagging as resolved since everyone seems to agree the behavior is valid. > RowSpanning will not effect, if there is not a column with all rows > --- > > Key: FOP-2230 > URL: https://issues.apache.org/jira/browse/FOP-2230 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 >Reporter: Markus Sticker > Attachments: table_error_expected.pdf, table_error.fo, > table_error.pdf, table_error.rtf > > > RowSpanning will not effect, if there is not a column with all rows -- 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-2238) [PATCH] JBIG2 PDF not shown in PS
[ https://issues.apache.org/jira/browse/FOP-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2238. Resolution: Fixed Fix Version/s: trunk patch applied in http://svn.apache.org/viewvc?view=revision&revision=1477369. please make sure to provide a svn patch in the future. > [PATCH] JBIG2 PDF not shown in PS > - > > Key: FOP-2238 > URL: https://issues.apache.org/jira/browse/FOP-2238 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: jbig2.pdf, test.fo, xgcJBIG2.patch > > > fop test.fo -ps out.ps > JBIG2 image is not shown, jar from > http://code.google.com/p/jbig2-imageio/downloads/list is also needed -- 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-2244) [PATCH] Encrypted image colorspace fails
[ https://issues.apache.org/jira/browse/FOP-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2244. Resolution: Fixed Fix Version/s: trunk patch applied in http://svn.apache.org/viewvc?view=revision&revision=1477861 > [PATCH] Encrypted image colorspace fails > > > Key: FOP-2244 > URL: https://issues.apache.org/jira/browse/FOP-2244 > Project: Fop > Issue Type: Bug >Reporter: simon steiner > Fix For: trunk > > Attachments: 1000611~b411bd60.GIF, fop.xconf, svngifinpdf.patch, > test.fo > > > fop test.fo out.pdf -c fop.xconf > java.lang.IllegalStateException: No object number could be obtained for a PDF > object -- 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] [Created] (FOP-2245) height attribute on external-graphic with percentage value behaves incorrectly
Luis Bernardo created FOP-2245: -- Summary: height attribute on external-graphic with percentage value behaves incorrectly Key: FOP-2245 URL: https://issues.apache.org/jira/browse/FOP-2245 Project: Fop Issue Type: Bug Reporter: Luis Bernardo when the height attribute on an external-graphic element has a percentage as a value and the enclosing element has no height set the resulting FOP behavior is incorrect. -- 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-2245) height attribute on external-graphic with percentage value behaves incorrectly
[ https://issues.apache.org/jira/browse/FOP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2245: --- Attachment: external-graphic_height_percentage.fo the example, which can use an image from test/resources/images, when generating PDF results in a document with the image not visible > height attribute on external-graphic with percentage value behaves incorrectly > -- > > Key: FOP-2245 > URL: https://issues.apache.org/jira/browse/FOP-2245 > Project: Fop > Issue Type: Bug >Reporter: Luis Bernardo > Attachments: external-graphic_height_percentage.fo > > > when the height attribute on an external-graphic element has a percentage as > a value and the enclosing element has no height set the resulting FOP > behavior is incorrect. -- 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-2245) height attribute on external-graphic with percentage value behaves incorrectly
[ https://issues.apache.org/jira/browse/FOP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2245. Resolution: Fixed Fix Version/s: trunk fixed in http://svn.apache.org/viewvc?view=revision&revision=1477872 > height attribute on external-graphic with percentage value behaves incorrectly > -- > > Key: FOP-2245 > URL: https://issues.apache.org/jira/browse/FOP-2245 > Project: Fop > Issue Type: Bug >Reporter: Luis Bernardo > Fix For: trunk > > Attachments: external-graphic_height_percentage.fo > > > when the height attribute on an external-graphic element has a percentage as > a value and the enclosing element has no height set the resulting FOP > behavior is incorrect. -- 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-2222) Incorrect page break in cell
[ https://issues.apache.org/jira/browse/FOP-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646964#comment-13646964 ] Luis Bernardo commented on FOP-: I know the column balancing method is not involved. What I meant to say is that I suspect that the algorithm that is used to decide the cell page breaks is the same or suffers from the same problems that the previous algorithm used for column balancing had. That algorithm was recently changed (see FOP-1840) and I think the new approach used there may also be useful for the cell page break problem you are facing. > Incorrect page break in cell > > > Key: FOP- > URL: https://issues.apache.org/jira/browse/FOP- > Project: Fop > Issue Type: Bug > Components: page-master/layout >Affects Versions: 1.1, trunk >Reporter: Nico > Attachments: test-two-cells.fo, test-two-cells.pdf > > > In a table with one row and two cells, spanning across multiple pages, the > pages break are not what should be expected. (I don't know if it's by design > or a bug). > Please see the attached .fo and .pdf. > Test case : the first cell has blocks with 120mm height. The second cell has > blocks with 100mm heights. The page height is 266mm > First page : each cell contains his two blocks on the page > second page : after the first page break, the fist cell show only the one > block where two is expected. The second block, which is on page 3, should fit > on page 2. > Is it standard behaviour ? Thanks. -- 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-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:all-tabpanel ] Luis Bernardo updated FOP-2221: --- Attachment: overflow-message-0.fo attached sample fo with many examples of overflow in static regions. > [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-0.fo, 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-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=13656487#comment-13656487 ] Luis Bernardo commented on FOP-2221: patch overflowsmsg8svn.patch applied: http://svn.apache.org/viewvc?view=revision&revision=1482140. > [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-0.fo, 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] [Created] (FOP-2248) add support for AES 256 PDF encryption
Luis Bernardo created FOP-2248: -- Summary: add support for AES 256 PDF encryption Key: FOP-2248 URL: https://issues.apache.org/jira/browse/FOP-2248 Project: Fop Issue Type: New Feature Reporter: Luis Bernardo Priority: Minor AES 256 PDF encryption is described in PDF 1.7 Extension Level 3. -- 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-2248) add support for AES 256 PDF encryption
[ https://issues.apache.org/jira/browse/FOP-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661439#comment-13661439 ] Luis Bernardo commented on FOP-2248: committed: http://svn.apache.org/viewvc?view=revision&revision=1484190. Note: The above commit implements AES 256 PDF encryption as described in PDF 1.7 Extension Level 3 and supported by Adobe Acrobat/Reader 9 (and higher). This first proposal for AES 256 encryption was shown to have some shortcomings and was not accepted by the ISO committee that oversees the PDF spec. A second proposal described in PDF 1.7 Extension Level 8, and which will be part of PDF 2.0 exists but the spec is not publicly available. The first Adobe product to support this second implementation of AES 256 is Acrobat/Reader 10. The current commit only implements the first proposal. > add support for AES 256 PDF encryption > -- > > Key: FOP-2248 > URL: https://issues.apache.org/jira/browse/FOP-2248 > Project: Fop > Issue Type: New Feature >Reporter: Luis Bernardo >Priority: Minor > > AES 256 PDF encryption is described in PDF 1.7 Extension Level 3. -- 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-2248) add support for AES 256 PDF encryption
[ https://issues.apache.org/jira/browse/FOP-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo updated FOP-2248: --- Attachment: test.pdf fop.xconf attached an example fop.xconf to use the new encryption. also attached a sample document encrypted. the password is "userpassword". > add support for AES 256 PDF encryption > -- > > Key: FOP-2248 > URL: https://issues.apache.org/jira/browse/FOP-2248 > Project: Fop > Issue Type: New Feature >Reporter: Luis Bernardo >Priority: Minor > Attachments: fop.xconf, test.pdf > > > AES 256 PDF encryption is described in PDF 1.7 Extension Level 3. -- 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-2248) add support for AES 256 PDF encryption
[ https://issues.apache.org/jira/browse/FOP-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2248. Resolution: Implemented Fix Version/s: trunk > add support for AES 256 PDF encryption > -- > > Key: FOP-2248 > URL: https://issues.apache.org/jira/browse/FOP-2248 > Project: Fop > Issue Type: New Feature >Reporter: Luis Bernardo >Priority: Minor > Fix For: trunk > > Attachments: fop.xconf, test.pdf > > > AES 256 PDF encryption is described in PDF 1.7 Extension Level 3. -- 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-2247) Vertical table border differs width, when horizontal border is omitted
[ https://issues.apache.org/jira/browse/FOP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663440#comment-13663440 ] Luis Bernardo commented on FOP-2247: This has been discussed in a thread back in November 2012. See http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201211.mbox/%3C1351859386222-37226.post%40n5.nabble.com%3E (read the full thread). The issue is real but is a problem with the viewers, not really with FOP (although FOP could implement borders differently to avoid the issue). So you need to find a workaround, ie., nest tables if needed to obtain the same output but without the thickness issue you see. Changing the way FOP handles borders is a major undertaking and will not be done in the foreseeable future. > Vertical table border differs width, when horizontal border is omitted > -- > > Key: FOP-2247 > URL: https://issues.apache.org/jira/browse/FOP-2247 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 > Environment: Windows 7, JRE1.6 >Reporter: Guest User >Priority: Minor > > Following description applies to PDF view. > When using a table grid to place contents on a page, the border width of the > cell borders differ in their width. This happens when both, top and bottom > border, are omitted. Here is an example, which nicely demonstrates the > effect. See the comment in the code to know, which borders will be painted > wrong: > > http://www.w3.org/1999/XSL/Format";> > > page-width="210mm" page-height="297mm" margin="1cm"> > > > > > > > > >border-bottom="none"> > >border-bottom="none"> > >border-bottom="none"> > > > >border-top="none" border-bottom="none"> white-space-treatment="preserve"> > >border-top="none" border-bottom="none"> white-space-treatment="preserve"> >border-top="none" border-bottom="none"> white-space-treatment="preserve"> > > >border-top="none"> > >border-top="none"> > >border-top="none"> > > > > > > > > > > > > > > > > > > This can be seen on screen and on paper, 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-2247) Vertical table border differs width, when horizontal border is omitted
[ https://issues.apache.org/jira/browse/FOP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2247. Resolution: Won't Fix > Vertical table border differs width, when horizontal border is omitted > -- > > Key: FOP-2247 > URL: https://issues.apache.org/jira/browse/FOP-2247 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 > Environment: Windows 7, JRE1.6 >Reporter: Guest User >Priority: Minor > > Following description applies to PDF view. > When using a table grid to place contents on a page, the border width of the > cell borders differ in their width. This happens when both, top and bottom > border, are omitted. Here is an example, which nicely demonstrates the > effect. See the comment in the code to know, which borders will be painted > wrong: > > http://www.w3.org/1999/XSL/Format";> > > page-width="210mm" page-height="297mm" margin="1cm"> > > > > > > > > >border-bottom="none"> > >border-bottom="none"> > >border-bottom="none"> > > > >border-top="none" border-bottom="none"> white-space-treatment="preserve"> > >border-top="none" border-bottom="none"> white-space-treatment="preserve"> >border-top="none" border-bottom="none"> white-space-treatment="preserve"> > > >border-top="none"> > >border-top="none"> > >border-top="none"> > > > > > > > > > > > > > > > > > > This can be seen on screen and on paper, 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-2247) Vertical table border differs width, when horizontal border is omitted
[ https://issues.apache.org/jira/browse/FOP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663465#comment-13663465 ] Luis Bernardo commented on FOP-2247: With Mac's Preview the thickness is the same, although there is a discontinuity in the border lines between cells. Different viewers have different quirks. > Vertical table border differs width, when horizontal border is omitted > -- > > Key: FOP-2247 > URL: https://issues.apache.org/jira/browse/FOP-2247 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 > Environment: Windows 7, JRE1.6 >Reporter: Guest User >Priority: Minor > > Following description applies to PDF view. > When using a table grid to place contents on a page, the border width of the > cell borders differ in their width. This happens when both, top and bottom > border, are omitted. Here is an example, which nicely demonstrates the > effect. See the comment in the code to know, which borders will be painted > wrong: > > http://www.w3.org/1999/XSL/Format";> > > page-width="210mm" page-height="297mm" margin="1cm"> > > > > > > > > >border-bottom="none"> > >border-bottom="none"> > >border-bottom="none"> > > > >border-top="none" border-bottom="none"> white-space-treatment="preserve"> > >border-top="none" border-bottom="none"> white-space-treatment="preserve"> >border-top="none" border-bottom="none"> white-space-treatment="preserve"> > > >border-top="none"> > >border-top="none"> > >border-top="none"> > > > > > > > > > > > > > > > > > > This can be seen on screen and on paper, 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-2019) PDF: number-columns-spanned problem with borders
[ https://issues.apache.org/jira/browse/FOP-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663477#comment-13663477 ] Luis Bernardo commented on FOP-2019: I don't understand what the issue is with the sample *.fo provided (there seems to be no issue when I look at the generated output). However the issue shown on the image originally provided is a duplicate of FOP-2247. > PDF: number-columns-spanned problem with borders > > > Key: FOP-2019 > URL: https://issues.apache.org/jira/browse/FOP-2019 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: M.H. > Attachments: fop_bug_submit_52585.fo, fop_bug_submit_52585.xml, > fop_bug_submit_52585.xsl, Without_And_With_number-columns-spanned.jpg > > > If a table has a row with multiple columns and the row cells have a border > (top/bottom) the lines look even for all cells in the row. But if the cell > has an additional > number-columns-spanned="2" > attribute, the subsequent cell (here: cell 3) will get different top/bottom > border line (thickness)! > This sound similar to old FOP-1606 (for RTF). > If we remove number-columns-spanned, the border lines look good again (but of > course the text is cut). > So far, we found an ugly workaround by adding "hidden" columns to all tables > with 0pt width for this strange output to "hide". -- 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-2019) PDF: number-columns-spanned problem with borders
[ https://issues.apache.org/jira/browse/FOP-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2019. Resolution: Won't Fix This won't be fixed (see FOP-2247 for more info). > PDF: number-columns-spanned problem with borders > > > Key: FOP-2019 > URL: https://issues.apache.org/jira/browse/FOP-2019 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.0 > Environment: Operating System: All > Platform: PC >Reporter: M.H. > Attachments: fop_bug_submit_52585.fo, fop_bug_submit_52585.xml, > fop_bug_submit_52585.xsl, Without_And_With_number-columns-spanned.jpg > > > If a table has a row with multiple columns and the row cells have a border > (top/bottom) the lines look even for all cells in the row. But if the cell > has an additional > number-columns-spanned="2" > attribute, the subsequent cell (here: cell 3) will get different top/bottom > border line (thickness)! > This sound similar to old FOP-1606 (for RTF). > If we remove number-columns-spanned, the border lines look good again (but of > course the text is cut). > So far, we found an ugly workaround by adding "hidden" columns to all tables > with 0pt width for this strange output to "hide". -- 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=13666347#comment-13666347 ] Luis Bernardo commented on FOP-2189: what about trunk? FOP-2226 seems to be a fix for the issue you describe. > 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] [Resolved] (FOP-2253) Build Failure on Mageia Linux Cauldron (what will be Mageia 4)
[
https://issues.apache.org/jira/browse/FOP-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Bernardo resolved FOP-2253.
Resolution: Not A Problem
This is an issue to be addressed by the Mageia packagers so you should post the
problem in the Mageia bug site.
If you need fop and it is not building in your Linux distro I suggest you get
the official src from the FOP site and build (there are also precompiled
binaries to download).
> Build Failure on Mageia Linux Cauldron (what will be Mageia 4)
> --
>
> Key: FOP-2253
> URL: https://issues.apache.org/jira/browse/FOP-2253
> Project: Fop
> Issue Type: Bug
> Components: general
>Affects Versions: 1.1
> Environment: Mageia Linux 3 Cauldron x86-64
>Reporter: Shlomi Fish
>
> When I run the build on Mageia Linux 3 x86-64 I get these build problems:
> creating package list
> processing package fop-1.1-%mkrel 1
> building binary packages
> Executing(%prep): /bin/sh -e
> /home/shlomif/Download/unpack/Mageia/fop/BUILDROOT/rpm-tmp.7CWPCz
> + umask 022
> + cd /home/shlomif/Download/unpack/Mageia/fop/BUILD
> + '[' 1 -eq 1 ']'
> + '[' 1 -eq 1 ']'
> + '[' 1 -eq 1 ']'
> + cd /home/shlomif/Download/unpack/Mageia/fop/BUILD
> + rm -rf fop-1.1
> + /usr/bin/gzip -dc
> /home/shlomif/Download/unpack/Mageia/fop/SOURCES/fop-1.1-src.tar.gz
> + /usr/bin/tar -xf -
> + STATUS=0
> + '[' 0 -ne 0 ']'
> + cd fop-1.1
> + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
> + echo 'Patch #0 (fop-1.0-manifest.patch):'
> Patch #0 (fop-1.0-manifest.patch):
> + /usr/bin/cat
> /home/shlomif/Download/unpack/Mageia/fop/SOURCES/fop-1.0-manifest.patch
> + /usr/bin/patch -p1 -b --suffix .mani-patch --fuzz=0
> patching file build.xml
> patching file fop.mf
> + echo 'Patch #1 (fop-main.patch):'
> Patch #1 (fop-main.patch):
> + /usr/bin/cat /home/shlomif/Download/unpack/Mageia/fop/SOURCES/fop-main.patch
> + /usr/bin/patch -p0 -b --suffix .main-patch --fuzz=0
> patching file src/java/org/apache/fop/cli/Main.java
> Hunk #1 succeeded at 204 (offset 11 lines).
> + find -name '*.class' -exec rm -f '{}' ';'
> + find -name '*.jar' -exec rm -f '{}' ';'
> + sed -i -e 's|1.4|1.5|g' build.xml
> + ln -s /usr/share/java/qdox.jar lib/build/qdox.jar
> + unzip -q
> /home/shlomif/Download/unpack/Mageia/fop/SOURCES/offo-hyphenation_v2.0.zip
> + mv offo-hyphenation/hyph/af.xml offo-hyphenation/hyph/as.xml
> offo-hyphenation/hyph/bg.xml offo-hyphenation/hyph/bn.xml
> offo-hyphenation/hyph/ca.xml offo-hyphenation/hyph/cop.xml
> offo-hyphenation/hyph/cs.xml offo-hyphenation/hyph/cy.xml
> offo-hyphenation/hyph/da.xml offo-hyphenation/hyph/de_1901.xml
> offo-hyphenation/hyph/de_CH.xml offo-hyphenation/hyph/de.xml
> offo-hyphenation/hyph/el_Polyton.xml offo-hyphenation/hyph/el.xml
> offo-hyphenation/hyph/en_GB.xml offo-hyphenation/hyph/en.xml
> offo-hyphenation/hyph/eo.xml offo-hyphenation/hyph/es.xml
> offo-hyphenation/hyph/et.xml offo-hyphenation/hyph/eu.xml
> offo-hyphenation/hyph/fi.xml offo-hyphenation/hyph/fr.xml
> offo-hyphenation/hyph/ga.xml offo-hyphenation/hyph/gl.xml
> offo-hyphenation/hyph/grc.xml offo-hyphenation/hyph/gu.xml
> offo-hyphenation/hyph/hi.xml offo-hyphenation/hyph/hr.xml
> offo-hyphenation/hyph/hsb.xml offo-hyphenation/hyph/hy.xml
> offo-hyphenation/hyph/ia.xml offo-hyphenation/hyph/id.xml
> offo-hyphenation/hyph/is.xml offo-hyphenation/hyph/it.xml
> offo-hyphenation/hyph/kmr.xml offo-hyphenation/hyph/kn.xml
> offo-hyphenation/hyph/la.xml offo-hyphenation/hyph/lo.xml
> offo-hyphenation/hyph/lt.xml offo-hyphenation/hyph/lv.xml
> offo-hyphenation/hyph/ml.xml offo-hyphenation/hyph/mn.xml
> offo-hyphenation/hyph/mr.xml offo-hyphenation/hyph/nb.xml
> offo-hyphenation/hyph/nl.xml offo-hyphenation/hyph/nn.xml
> offo-hyphenation/hyph/or.xml offo-hyphenation/hyph/pa.xml
> offo-hyphenation/hyph/pl.xml offo-hyphenation/hyph/pt.xml
> offo-hyphenation/hyph/ro.xml offo-hyphenation/hyph/ru.xml
> offo-hyphenation/hyph/sa.xml offo-hyphenation/hyph/sk.xml
> offo-hyphenation/hyph/sl.xml offo-hyphenation/hyph/sr_Cyrl.xml
> offo-hyphenation/hyph/sr_Latn.xml offo-hyphenation/hyph/sv.xml
> offo-hyphenation/hyph/ta.xml offo-hyphenation/hyph/te.xml
> offo-hyphenation/hyph/tk.xml offo-hyphenation/hyph/tr.xml
> offo-hyphenation/hyph/uk.xml offo-hyphenation/hyph/zh_Latn.xml hyph
> + exit 0
> Executing(%build): /bin/sh -e
> /home/shlomif/Download/unpack/Mageia/fop/BUILDROOT/rpm-tmp.fhqisw
> + umask 022
> + cd /home/shlomif/Download/unpack/Mageia/fop/BUILD
> + cd fop-1.1
> + '[' 1 -eq 1 ']'
> + '[' 1 -eq 1 ']'
> + export CLASSPATH=
> + CLASSPATH=
> ++ build-classpath apache-commons-logging apache-commons-io
> xmlgraphics-commons batik-all
> +
> CLASSPATH=:/usr/share/java/apache-commons-logging.jar:/usr/share/java/apache-commons-io.jar:/usr/share/java/xmlgraphics-commons.j
[jira] [Commented] (FOP-2254) Broken URLs in the README for how to build/run
[ https://issues.apache.org/jira/browse/FOP-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668704#comment-13668704 ] Luis Bernardo commented on FOP-2254: Thanks for bringing up this to our attention. This has been fixed. > Broken URLs in the README for how to build/run > -- > > Key: FOP-2254 > URL: https://issues.apache.org/jira/browse/FOP-2254 > Project: Fop > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Shlomi Fish > > The README reads: > [ Quote ] > How do I build FOP? > --- > If you've downloaded a binary distribution, you don't need to build > FOP. > Otherwise, please follow the instructions found here: > http://xmlgraphics.apache.org/fop/stable/compiling.html > How do I run FOP? > - > Simply by typing "fop" on the command-line. Without any parameters you > will receive a screen with instruction on how to call FOP from the > command-line. > For more details, see: > http://xmlgraphics.apache.org/fop/stable/running.html > [ / Quote ] > However, the URL of http://xmlgraphics.apache.org/fop/stable/compiling.html > is broken as is http://xmlgraphics.apache.org/fop/stable/ and > http://xmlgraphics.apache.org/fop/stable/running.html . So I don't know how > to build and run fop. Please fix 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-2254) Broken URLs in the README for how to build/run
[ https://issues.apache.org/jira/browse/FOP-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2254. Resolution: Fixed Fix Version/s: 1.1 > Broken URLs in the README for how to build/run > -- > > Key: FOP-2254 > URL: https://issues.apache.org/jira/browse/FOP-2254 > Project: Fop > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Shlomi Fish > Fix For: 1.1 > > > The README reads: > [ Quote ] > How do I build FOP? > --- > If you've downloaded a binary distribution, you don't need to build > FOP. > Otherwise, please follow the instructions found here: > http://xmlgraphics.apache.org/fop/stable/compiling.html > How do I run FOP? > - > Simply by typing "fop" on the command-line. Without any parameters you > will receive a screen with instruction on how to call FOP from the > command-line. > For more details, see: > http://xmlgraphics.apache.org/fop/stable/running.html > [ / Quote ] > However, the URL of http://xmlgraphics.apache.org/fop/stable/compiling.html > is broken as is http://xmlgraphics.apache.org/fop/stable/ and > http://xmlgraphics.apache.org/fop/stable/running.html . So I don't know how > to build and run fop. Please fix 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-2261) text-align="right" no longer works in combination with white-space="pre"
[ https://issues.apache.org/jira/browse/FOP-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2261. Resolution: Fixed Fix Version/s: trunk this has been fixed in trunk. > text-align="right" no longer works in combination with white-space="pre" > > > Key: FOP-2261 > URL: https://issues.apache.org/jira/browse/FOP-2261 > Project: Fop > Issue Type: Bug > Components: pdf >Affects Versions: 1.1 >Reporter: Nick Heyworth > Fix For: trunk > > > The text is left-aligned instead of right-aligned. This worked in FOP 0.95. > > http://www.w3.org/1999/XSL/Format";> > > > > > > > > > > > This is some rather > long text; it is pre-formatted, but not wrapping, and does not fit on one > line. It should be displayed right-aligned. > > > > > > -- 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-2262) fop-1.1 from the binary distribution crashes (NullPointerException) on a .fo file on x86-64
[ https://issues.apache.org/jira/browse/FOP-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Bernardo resolved FOP-2262. Resolution: Fixed Fix Version/s: trunk I confirm the NPE with 1.1; the issue does not happen anymore with trunk though. > fop-1.1 from the binary distribution crashes (NullPointerException) on a .fo > file on x86-64 > --- > > Key: FOP-2262 > URL: https://issues.apache.org/jira/browse/FOP-2262 > Project: Fop > Issue Type: Bug >Affects Versions: 1.1 > Environment: Mageia Linux Cauldron x86-64 >Reporter: Shlomi Fish > Fix For: trunk > > Attachments: case-for-drug-legalisation--hebrew-v3.fo > > > When I run fop-1.1 from the binary distribution on the .fo file that I will > attach I'm getting this result: > [SHELL] > shlomif@telaviv1:~$ which fop > /home/shlomif/Download/unpack/graphics/fop/bin/fop-1.1/fop > shlomif@telaviv1:~$ fop -fo ./case-for-drug-legalisation--hebrew-v3.fo -pdf > foo.pdf > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Font "Symbol,normal,700" not found. Substituting with > "Symbol,normal,400". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with > "ZapfDingbats,normal,400". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ב" (0x5d1, afii57665) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ע" (0x5e2, afii57682) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ד" (0x5d3, afii57667) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ה" (0x5d4, afii57668) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ל" (0x5dc, afii57676) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ג" (0x5d2, afii57666) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "י" (0x5d9, afii57673) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ז" (0x5d6, afii57670) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.hyphenation.Hyphenator > getHyphenationTree > SEVERE: Couldn't find hyphenation pattern for lang="he". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ה" (0x5d4, afii57668) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ק" (0x5e7, afii57687) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ד" (0x5d3, afii57667) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "מ" (0x5de, afii57678) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ו" (0x5d5, afii57669) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ס" (0x5e1, afii57681) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ר" (0x5e8, afii57688) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "י" (0x5d9, afii57673) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ש" (0x5e9, afii57689) not available in font "Times-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ח" (0x5d7, afii57671) not available in font "Times-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "י" (0x5d9, afii57673) not available in font "Times-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ב" (0x5d1, afii57665) not available in font "Times-Bold". >
[jira] [Commented] (FOP-2262) fop-1.1 from the binary distribution crashes (NullPointerException) on a .fo file on x86-64
[ https://issues.apache.org/jira/browse/FOP-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13676898#comment-13676898 ] Luis Bernardo commented on FOP-2262: btw, if you pass -nocs to fop 1.1 then you get no NPE, and the behavior of 1.0; but since you are using hebrew you will want to use complex scripts. also, in principle you need to use the fop.xconf (which is not apparent from your command line) with the hebrew fonts configured. > fop-1.1 from the binary distribution crashes (NullPointerException) on a .fo > file on x86-64 > --- > > Key: FOP-2262 > URL: https://issues.apache.org/jira/browse/FOP-2262 > Project: Fop > Issue Type: Bug >Affects Versions: 1.1 > Environment: Mageia Linux Cauldron x86-64 >Reporter: Shlomi Fish > Fix For: trunk > > Attachments: case-for-drug-legalisation--hebrew-v3.fo > > > When I run fop-1.1 from the binary distribution on the .fo file that I will > attach I'm getting this result: > [SHELL] > shlomif@telaviv1:~$ which fop > /home/shlomif/Download/unpack/graphics/fop/bin/fop-1.1/fop > shlomif@telaviv1:~$ fop -fo ./case-for-drug-legalisation--hebrew-v3.fo -pdf > foo.pdf > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Font "Symbol,normal,700" not found. Substituting with > "Symbol,normal,400". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with > "ZapfDingbats,normal,400". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ב" (0x5d1, afii57665) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ע" (0x5e2, afii57682) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ד" (0x5d3, afii57667) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ה" (0x5d4, afii57668) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ל" (0x5dc, afii57676) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ג" (0x5d2, afii57666) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "י" (0x5d9, afii57673) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ז" (0x5d6, afii57670) not available in font "Helvetica-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.hyphenation.Hyphenator > getHyphenationTree > SEVERE: Couldn't find hyphenation pattern for lang="he". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ה" (0x5d4, afii57668) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ק" (0x5e7, afii57687) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ד" (0x5d3, afii57667) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "מ" (0x5de, afii57678) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ו" (0x5d5, afii57669) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ס" (0x5e1, afii57681) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ר" (0x5e8, afii57688) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "י" (0x5d9, afii57673) not available in font "Times-Roman". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ש" (0x5e9, afii57689) not available in font "Times-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "ח" (0x5d7, afii57671) not available in font "Times-Bold". > Jun 06, 2013 12:58:34 PM org.apache.fop.events.LoggingEventListener > processEvent > WARNING: Glyph "י" (0x5d9, afii57
