[jira] [Commented] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL
[ https://issues.apache.org/jira/browse/FOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680164#comment-14680164 ] Robert Meyer commented on FOP-2486: --- Change applied: http://svn.apache.org/viewvc?view=revisionrevision=1695082 [PATCH] Soft font support for TrueType fonts in PCL --- Key: FOP-2486 URL: https://issues.apache.org/jira/browse/FOP-2486 Project: FOP Issue Type: Improvement Components: renderer/pcl Affects Versions: trunk Reporter: Robert Meyer Fix For: trunk Attachments: patch.diff, patch2.diff, rasterized.pcl, softfonts.pcl Currently all fonts (except a limited set of native fonts) are rastered for PCL output. This has the problem of the documents being large in size and should FOP be used in the cloud, rendering to PCL would not be possible as it's using AWT. This patch in part resolves this problem by converting TrueType fonts to PCL soft fonts. This allows the size to be much smaller and has been a standard feature since PCL 5. [EDIT] For all other fonts which are not TrueType it will still revert back to being rasterized. It will currently default to using soft fonts for TrueType fonts but this can overriden by using text-renderingbitmap/text-rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL
[ https://issues.apache.org/jira/browse/FOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer closed FOP-2486. - Resolution: Fixed [PATCH] Soft font support for TrueType fonts in PCL --- Key: FOP-2486 URL: https://issues.apache.org/jira/browse/FOP-2486 Project: FOP Issue Type: Improvement Components: renderer/pcl Affects Versions: trunk Reporter: Robert Meyer Fix For: trunk Attachments: patch.diff, patch2.diff, rasterized.pcl, softfonts.pcl Currently all fonts (except a limited set of native fonts) are rastered for PCL output. This has the problem of the documents being large in size and should FOP be used in the cloud, rendering to PCL would not be possible as it's using AWT. This patch in part resolves this problem by converting TrueType fonts to PCL soft fonts. This allows the size to be much smaller and has been a standard feature since PCL 5. [EDIT] For all other fonts which are not TrueType it will still revert back to being rasterized. It will currently default to using soft fonts for TrueType fonts but this can overriden by using text-renderingbitmap/text-rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL
[ https://issues.apache.org/jira/browse/FOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2486: -- Attachment: patch2.diff I've added a new patch and will commit this shortly to the temp_pclsoftfonts branch. I will start a vote shortly on merging in this functionality. [PATCH] Soft font support for TrueType fonts in PCL --- Key: FOP-2486 URL: https://issues.apache.org/jira/browse/FOP-2486 Project: FOP Issue Type: Improvement Components: renderer/pcl Affects Versions: trunk Reporter: Robert Meyer Fix For: trunk Attachments: patch.diff, patch2.diff, rasterized.pcl, softfonts.pcl Currently all fonts (except a limited set of native fonts) are rastered for PCL output. This has the problem of the documents being large in size and should FOP be used in the cloud, rendering to PCL would not be possible as it's using AWT. This patch in part resolves this problem by converting TrueType fonts to PCL soft fonts. This allows the size to be much smaller and has been a standard feature since PCL 5. [EDIT] For all other fonts which are not TrueType it will still revert back to being rasterized. It will currently default to using soft fonts for TrueType fonts but this can overriden by using text-renderingbitmap/text-rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL
[ https://issues.apache.org/jira/browse/FOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14653773#comment-14653773 ] Robert Meyer edited comment on FOP-2486 at 8/4/15 3:03 PM: --- I've added a new patch with improvements and bug fixes to my original patch. I will commit this shortly to the temp_pclsoftfonts branch and will start a vote shortly on merging in this functionality. was (Author: rmeyer): I've added a new patch and will commit this shortly to the temp_pclsoftfonts branch. I will start a vote shortly on merging in this functionality. [PATCH] Soft font support for TrueType fonts in PCL --- Key: FOP-2486 URL: https://issues.apache.org/jira/browse/FOP-2486 Project: FOP Issue Type: Improvement Components: renderer/pcl Affects Versions: trunk Reporter: Robert Meyer Fix For: trunk Attachments: patch.diff, patch2.diff, rasterized.pcl, softfonts.pcl Currently all fonts (except a limited set of native fonts) are rastered for PCL output. This has the problem of the documents being large in size and should FOP be used in the cloud, rendering to PCL would not be possible as it's using AWT. This patch in part resolves this problem by converting TrueType fonts to PCL soft fonts. This allows the size to be much smaller and has been a standard feature since PCL 5. [EDIT] For all other fonts which are not TrueType it will still revert back to being rasterized. It will currently default to using soft fonts for TrueType fonts but this can overriden by using text-renderingbitmap/text-rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2494) Unable to use Ubuntu Mono Font
[
https://issues.apache.org/jira/browse/FOP-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650397#comment-14650397
]
Robert Meyer commented on FOP-2494:
---
Fixed in http://svn.apache.org/viewvc?view=revisionrevision=1693719
Unable to use Ubuntu Mono Font
--
Key: FOP-2494
URL: https://issues.apache.org/jira/browse/FOP-2494
Project: FOP
Issue Type: Bug
Components: font/opentype
Affects Versions: 2.0
Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer
Attachments: output.pdf, patch.diff
I want to use the Ubuntu Mono font, which is installed on my system. But FOP
throws an exception when it is auto-detecting the fonts:
{code}
Unable to load font file:
file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
java.lang.ArrayIndexOutOfBoundsException: 1047
at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
at
org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
at
org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
at
org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
at
org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
at
org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
at
org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
at org.apache.fop.apps.Fop.init(Fop.java:78)
at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
{code}
The same exception is thrown for other variants of the font (bold, italic,
etc).
Note that this font can be downloaded freely from http://font.ubuntu.com/
The latest version of the font is 0.80, and that is what I have installed on
my system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FOP-2494) Unable to use Ubuntu Mono Font
[
https://issues.apache.org/jira/browse/FOP-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Meyer updated FOP-2494:
--
Attachment: output.pdf
patch.diff
I've attached the patch and will apply this shortly. I've also attached a
document showing all the ubuntu fonts embedded in a document to show they're
working.
Unable to use Ubuntu Mono Font
--
Key: FOP-2494
URL: https://issues.apache.org/jira/browse/FOP-2494
Project: FOP
Issue Type: Bug
Components: font/opentype
Affects Versions: 2.0
Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer
Attachments: output.pdf, patch.diff
I want to use the Ubuntu Mono font, which is installed on my system. But FOP
throws an exception when it is auto-detecting the fonts:
{code}
Unable to load font file:
file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
java.lang.ArrayIndexOutOfBoundsException: 1047
at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
at
org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
at
org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
at
org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
at
org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
at
org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
at
org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
at org.apache.fop.apps.Fop.init(Fop.java:78)
at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
{code}
The same exception is thrown for other variants of the font (bold, italic,
etc).
Note that this font can be downloaded freely from http://font.ubuntu.com/
The latest version of the font is 0.80, and that is what I have installed on
my system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2494) Unable to use Ubuntu Mono Font
[
https://issues.apache.org/jira/browse/FOP-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649983#comment-14649983
]
Robert Meyer commented on FOP-2494:
---
I've been investigating this and have found the method we were using to
identify the number of character names in the post table was flawed. In the
case of the UbuntuMono-R.ttf font there are 1296 characters. 258 of these come
under the standard encoding whereas everything else should have an associated
name in the table. Unfortunately what we were doing was to read the post table
and use the glyph ID array to determine how many of those are greater than 258
by looping through them. The problem here is the fact that the indexes aren't
necessarily in a complete order. Therefore although we may count only 1046
characters that are greater than 258, the index array may do the following:
1,2,3,5,6,7,9,10,11,12...etc
The maximum glyph ID in this case is 1315, which minus 258 is 1057. As such a
fix for this will be to set the size of the Strings array (and subsequently
read) upon the maximum glyph index taken from that set. It's a fairly simple
fix and will post a patch and commit after I've done some further testing
tomorrow.
Unable to use Ubuntu Mono Font
--
Key: FOP-2494
URL: https://issues.apache.org/jira/browse/FOP-2494
Project: FOP
Issue Type: Bug
Components: font/opentype
Affects Versions: 2.0
Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer
I want to use the Ubuntu Mono font, which is installed on my system. But FOP
throws an exception when it is auto-detecting the fonts:
{code}
Unable to load font file:
file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
java.lang.ArrayIndexOutOfBoundsException: 1047
at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
at
org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
at
org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
at
org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
at
org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
at
org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
at
org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
at org.apache.fop.apps.Fop.init(Fop.java:78)
at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
{code}
The same exception is thrown for other variants of the font (bold, italic,
etc).
Note that this font can be downloaded freely from http://font.ubuntu.com/
The latest version of the font is 0.80, and that is what I have installed on
my system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2494) Unable to use Ubuntu Mono Font
[
https://issues.apache.org/jira/browse/FOP-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649996#comment-14649996
]
Robert Meyer commented on FOP-2494:
---
I've spent a bit of time looking at this and have found that the method by
which we set the size of the glyph strings array is flawed. In the case of the
UbuntuMono-R.ttf font there are 1296 glyphs. The post table which is used to
store the names of the characters with their associated glyph index. What we
were doing was looping through the index array (which precedes the name array)
and counting the number of glyphs with ID's greater than 258 (the number of
glyphs in the default encoding). This would work fine if the glyph index array
was always complete but in this case it's not e.g.
1,2,3,5,6,9,10,11,12 etc...
The maximum glyph ID in this font is 1315 which, minus 258, equals 1057 which
is the actual number of names in the array. Because we were only counting them
we only got 1046, hence the error. As such to fix this it's simply a case of
setting the character name array to the maximum glyph ID found minus 258. I'll
post a patch tomorrow after I have done some further testing.
Unable to use Ubuntu Mono Font
--
Key: FOP-2494
URL: https://issues.apache.org/jira/browse/FOP-2494
Project: FOP
Issue Type: Bug
Components: font/opentype
Affects Versions: 2.0
Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer
I want to use the Ubuntu Mono font, which is installed on my system. But FOP
throws an exception when it is auto-detecting the fonts:
{code}
Unable to load font file:
file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
java.lang.ArrayIndexOutOfBoundsException: 1047
at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
at
org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
at
org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
at
org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
at
org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
at
org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
at
org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
at org.apache.fop.apps.Fop.init(Fop.java:78)
at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
{code}
The same exception is thrown for other variants of the font (bold, italic,
etc).
Note that this font can be downloaded freely from http://font.ubuntu.com/
The latest version of the font is 0.80, and that is what I have installed on
my system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (FOP-2494) Unable to use Ubuntu Mono Font
[
https://issues.apache.org/jira/browse/FOP-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Meyer updated FOP-2494:
--
Comment: was deleted
(was: I've been investigating this and have found the method we were using to
identify the number of character names in the post table was flawed. In the
case of the UbuntuMono-R.ttf font there are 1296 characters. 258 of these come
under the standard encoding whereas everything else should have an associated
name in the table. Unfortunately what we were doing was to read the post table
and use the glyph ID array to determine how many of those are greater than 258
by looping through them. The problem here is the fact that the indexes aren't
necessarily in a complete order. Therefore although we may count only 1046
characters that are greater than 258, the index array may do the following:
1,2,3,5,6,7,9,10,11,12...etc
The maximum glyph ID in this case is 1315, which minus 258 is 1057. As such a
fix for this will be to set the size of the Strings array (and subsequently
read) upon the maximum glyph index taken from that set. It's a fairly simple
fix and will post a patch and commit after I've done some further testing
tomorrow.)
Unable to use Ubuntu Mono Font
--
Key: FOP-2494
URL: https://issues.apache.org/jira/browse/FOP-2494
Project: FOP
Issue Type: Bug
Components: font/opentype
Affects Versions: 2.0
Environment: Ubuntu 14.04, Java 8u45
Reporter: Harshad
Assignee: Robert Meyer
I want to use the Ubuntu Mono font, which is installed on my system. But FOP
throws an exception when it is auto-detecting the fonts:
{code}
Unable to load font file:
file:/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf
java.lang.ArrayIndexOutOfBoundsException: 1047
at org.apache.fop.fonts.truetype.OpenFont.readPostScript(OpenFont.java:1320)
at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:736)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
at
org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
at
org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:97)
at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
at
org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
at
org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
at
org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
at
org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
at org.apache.fop.area.RenderPagesModel.init(RenderPagesModel.java:75)
at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
at org.apache.fop.area.AreaTreeHandler.init(AreaTreeHandler.java:105)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
at org.apache.fop.fo.FOTreeBuilder.init(FOTreeBuilder.java:107)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
at org.apache.fop.apps.Fop.init(Fop.java:78)
at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:240)
{code}
The same exception is thrown for other variants of the font (bold, italic,
etc).
Note that this font can be downloaded freely from http://font.ubuntu.com/
The latest version of the font is 0.80, and that is what I have installed on
my system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FOP-2499) [PATCH] PDF/UA warnings for nested elements
[ https://issues.apache.org/jira/browse/FOP-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2499: -- Summary: [PATCH] PDF/UA warnings for nested elements (was: PDF/UA warnings for nested elements) [PATCH] PDF/UA warnings for nested elements --- Key: FOP-2499 URL: https://issues.apache.org/jira/browse/FOP-2499 Project: FOP Issue Type: Bug Affects Versions: trunk Reporter: Thanasis Giannimaras Attachments: after.pdf, before.pdf, fop.xconf, pdfua.patch, test.fo PDF with nested elements (and PDF/UA mode enabled) are giving out warnings when validated by http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac.html (Inappropriate use of a type structure element warnings). This approach tries to solve the issue, by renaming the outermost structure element into a grouping element of type DIV. To notice the warning try to validate before pdf with accessibility checker mentioned above -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2486) Soft font support for TrueType fonts in PCL
[ https://issues.apache.org/jira/browse/FOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2486: -- Attachment: softfonts.pcl rasterized.pcl Attached two examples of before and after the changes. Soft font support for TrueType fonts in PCL --- Key: FOP-2486 URL: https://issues.apache.org/jira/browse/FOP-2486 Project: FOP Issue Type: Improvement Components: renderer/pcl Affects Versions: trunk Reporter: Robert Meyer Fix For: trunk Attachments: patch.diff, rasterized.pcl, softfonts.pcl Currently all fonts (except a limited set of native fonts) are rastered for PCL output. This has the problem of the documents being large in size and should FOP be used in the cloud, rendering to PCL would not be possible as it's using AWT. This patch in part resolves this problem by converting TrueType fonts to PCL soft fonts. This allows the size to be much smaller and has been a standard feature since PCL 5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2486) [PATCH] Soft font support for TrueType fonts in PCL
[ https://issues.apache.org/jira/browse/FOP-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2486: -- Description: Currently all fonts (except a limited set of native fonts) are rastered for PCL output. This has the problem of the documents being large in size and should FOP be used in the cloud, rendering to PCL would not be possible as it's using AWT. This patch in part resolves this problem by converting TrueType fonts to PCL soft fonts. This allows the size to be much smaller and has been a standard feature since PCL 5. [EDIT] For all other fonts which are not TrueType it will still revert back to being rasterized. It will currently default to using soft fonts for TrueType fonts but this can overriden by using text-renderingbitmap/text-rendering. was: Currently all fonts (except a limited set of native fonts) are rastered for PCL output. This has the problem of the documents being large in size and should FOP be used in the cloud, rendering to PCL would not be possible as it's using AWT. This patch in part resolves this problem by converting TrueType fonts to PCL soft fonts. This allows the size to be much smaller and has been a standard feature since PCL 5. [PATCH] Soft font support for TrueType fonts in PCL --- Key: FOP-2486 URL: https://issues.apache.org/jira/browse/FOP-2486 Project: FOP Issue Type: Improvement Components: renderer/pcl Affects Versions: trunk Reporter: Robert Meyer Fix For: trunk Attachments: patch.diff, rasterized.pcl, softfonts.pcl Currently all fonts (except a limited set of native fonts) are rastered for PCL output. This has the problem of the documents being large in size and should FOP be used in the cloud, rendering to PCL would not be possible as it's using AWT. This patch in part resolves this problem by converting TrueType fonts to PCL soft fonts. This allows the size to be much smaller and has been a standard feature since PCL 5. [EDIT] For all other fonts which are not TrueType it will still revert back to being rasterized. It will currently default to using soft fonts for TrueType fonts but this can overriden by using text-renderingbitmap/text-rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2460) Subsetting OTF font leads to PDF errors when viewing / incorrect characters
[ https://issues.apache.org/jira/browse/FOP-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2460: -- Description: When attempting to generate a document whilst subsetting the VilleroyBoch-Regular.otf font, different viewers will either show errors, no text or lead to incorrect or corrupt characters being drawn. I currentlty believe this is down to either a subroutine not being copied from the original font leading to a invalid reference, or the subroutine does not contain valid data. When looking at this font in FontForge, 3 characters in a hello world example I used were missing which backs up this hypothesis. [EDIT] I've removed the font as I did not check if there were copyright issues by making it public domain. I will work when I am able to do so but keep the font privately unless I hear otherwise from the user who originally posted the problem was: When attempting to generate a document whilst subsetting the VilleroyBoch-Regular.otf font, different viewers will either show errors, no text or lead to incorrect or corrupt characters being drawn. The font has been attached. I currentlty believe this is down to either a subroutine not being copied from the original font leading to a invalid reference, or the subroutine does not contain valid data. When looking at this font in FontForge, 3 characters in a hello world example I used were missing which backs up this hypothesis. Subsetting OTF font leads to PDF errors when viewing / incorrect characters --- Key: FOP-2460 URL: https://issues.apache.org/jira/browse/FOP-2460 Project: Fop Issue Type: Bug Components: font/opentype Affects Versions: trunk Reporter: Robert Meyer When attempting to generate a document whilst subsetting the VilleroyBoch-Regular.otf font, different viewers will either show errors, no text or lead to incorrect or corrupt characters being drawn. I currentlty believe this is down to either a subroutine not being copied from the original font leading to a invalid reference, or the subroutine does not contain valid data. When looking at this font in FontForge, 3 characters in a hello world example I used were missing which backs up this hypothesis. [EDIT] I've removed the font as I did not check if there were copyright issues by making it public domain. I will work when I am able to do so but keep the font privately unless I hear otherwise from the user who originally posted the problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (FOP-2460) Subsetting OTF font leads to PDF errors when viewing / incorrect characters
[ https://issues.apache.org/jira/browse/FOP-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2460: -- Comment: was deleted (was: Attached the font in question.) Subsetting OTF font leads to PDF errors when viewing / incorrect characters --- Key: FOP-2460 URL: https://issues.apache.org/jira/browse/FOP-2460 Project: Fop Issue Type: Bug Components: font/opentype Affects Versions: trunk Reporter: Robert Meyer When attempting to generate a document whilst subsetting the VilleroyBoch-Regular.otf font, different viewers will either show errors, no text or lead to incorrect or corrupt characters being drawn. I currentlty believe this is down to either a subroutine not being copied from the original font leading to a invalid reference, or the subroutine does not contain valid data. When looking at this font in FontForge, 3 characters in a hello world example I used were missing which backs up this hypothesis. [EDIT] I've removed the font as I did not check if there were copyright issues by making it public domain. I will work when I am able to do so but keep the font privately unless I hear otherwise from the user who originally posted the problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2460) Subsetting OTF font leads to PDF errors when viewing / incorrect characters
[ https://issues.apache.org/jira/browse/FOP-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2460: -- Attachment: (was: VilleroyBoch-Regular.otf) Subsetting OTF font leads to PDF errors when viewing / incorrect characters --- Key: FOP-2460 URL: https://issues.apache.org/jira/browse/FOP-2460 Project: Fop Issue Type: Bug Components: font/opentype Affects Versions: trunk Reporter: Robert Meyer When attempting to generate a document whilst subsetting the VilleroyBoch-Regular.otf font, different viewers will either show errors, no text or lead to incorrect or corrupt characters being drawn. The font has been attached. I currentlty believe this is down to either a subroutine not being copied from the original font leading to a invalid reference, or the subroutine does not contain valid data. When looking at this font in FontForge, 3 characters in a hello world example I used were missing which backs up this hypothesis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2460) Subsetting OTF font leads to PDF errors when viewing / incorrect characters
[ https://issues.apache.org/jira/browse/FOP-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2460: -- Attachment: VilleroyBoch-Regular.otf Attached the font in question. Subsetting OTF font leads to PDF errors when viewing / incorrect characters --- Key: FOP-2460 URL: https://issues.apache.org/jira/browse/FOP-2460 Project: Fop Issue Type: Bug Components: font/opentype Affects Versions: trunk Reporter: Robert Meyer Attachments: VilleroyBoch-Regular.otf When attempting to generate a document whilst subsetting the VilleroyBoch-Regular.otf font, different viewers will either show errors, no text or lead to incorrect or corrupt characters being drawn. The font has been attached. I currentlty believe this is down to either a subroutine not being copied from the original font leading to a invalid reference, or the subroutine does not contain valid data. When looking at this font in FontForge, 3 characters in a hello world example I used were missing which backs up this hypothesis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2460) Subsetting OTF font leads to PDF errors when viewing / incorrect characters
Robert Meyer created FOP-2460: - Summary: Subsetting OTF font leads to PDF errors when viewing / incorrect characters Key: FOP-2460 URL: https://issues.apache.org/jira/browse/FOP-2460 Project: Fop Issue Type: Bug Components: font/opentype Affects Versions: trunk Reporter: Robert Meyer When attempting to generate a document whilst subsetting the VilleroyBoch-Regular.otf font, different viewers will either show errors, no text or lead to incorrect or corrupt characters being drawn. The font has been attached. I currentlty believe this is down to either a subroutine not being copied from the original font leading to a invalid reference, or the subroutine does not contain valid data. When looking at this font in FontForge, 3 characters in a hello world example I used were missing which backs up this hypothesis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14007217#comment-14007217 ] Robert Meyer commented on FOP-2354: --- Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1597112 [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2354. --- Resolution: Fixed [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2354: -- Attachment: patch.diff New patch for adding Type 1 subset support. Various changes include: - Name resolution improvements - Memory efficiency improvements - Some re-factoring - Default is now not to subset I'll start a vote in a couple of days to give everyone a chance to look at it if they get a chance. [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2354: -- Attachment: patch.diff [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2354: -- Attachment: (was: patch.diff) [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FOP-2354) Subset support for Type 1 fonts
Robert Meyer created FOP-2354: - Summary: Subset support for Type 1 fonts Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2354: -- Summary: [PATCH] Subset support for Type 1 fonts (was: Subset support for Type 1 fonts) [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, patch.diff This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2354: -- Attachment: (was: patch.diff) [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2354: -- Attachment: patch.diff Re-uploaded patch as the existing version had a mis-placed apache license section. [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, patch.diff This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (FOP-2260) [PATCH] Smart quotes broken in RTF if at start of text
[ https://issues.apache.org/jira/browse/FOP-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer reassigned FOP-2260: - Assignee: Robert Meyer [PATCH] Smart quotes broken in RTF if at start of text -- Key: FOP-2260 URL: https://issues.apache.org/jira/browse/FOP-2260 Project: Fop Issue Type: Bug Components: rtf Affects Versions: 1.1 Reporter: Christopher Lowdon Assignee: Robert Meyer Priority: Minor Labels: patch Attachments: mypatch.diff When you have a quote at the start of your string, it is transformed into a smart quote incorrectly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FOP-2260) [PATCH] Smart quotes broken in RTF if at start of text
[ https://issues.apache.org/jira/browse/FOP-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912744#comment-13912744 ] Robert Meyer commented on FOP-2260: --- Sorry in the delay getting to this. The patch has been applied: http://svn.apache.org/viewvc?view=revisionrevision=1571989 Thanks for your contribution! [PATCH] Smart quotes broken in RTF if at start of text -- Key: FOP-2260 URL: https://issues.apache.org/jira/browse/FOP-2260 Project: Fop Issue Type: Bug Components: rtf Affects Versions: 1.1 Reporter: Christopher Lowdon Assignee: Robert Meyer Priority: Minor Labels: patch Attachments: mypatch.diff When you have a quote at the start of your string, it is transformed into a smart quote incorrectly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FOP-2260) [PATCH] Smart quotes broken in RTF if at start of text
[ https://issues.apache.org/jira/browse/FOP-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2260. --- Resolution: Fixed [PATCH] Smart quotes broken in RTF if at start of text -- Key: FOP-2260 URL: https://issues.apache.org/jira/browse/FOP-2260 Project: Fop Issue Type: Bug Components: rtf Affects Versions: 1.1 Reporter: Christopher Lowdon Assignee: Robert Meyer Priority: Minor Labels: patch Attachments: mypatch.diff When you have a quote at the start of your string, it is transformed into a smart quote incorrectly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (FOP-2350) Implement support for page-master types other than the simple variant for RTF output
Robert Meyer created FOP-2350: - Summary: Implement support for page-master types other than the simple variant for RTF output Key: FOP-2350 URL: https://issues.apache.org/jira/browse/FOP-2350 Project: Fop Issue Type: New Feature Components: rtf Affects Versions: trunk Reporter: Robert Meyer RTF currently only supports simple-page-masters. The RTF specification has support for different page sizes and orientations per page so this feature should be possible to support and implement. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2321) Latest fop snapshot crashes when processing rindolf-spec.fo
[ https://issues.apache.org/jira/browse/FOP-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2321: -- Attachment: patch.diff After investigating this issue, it stems from the fact that the RTF code cannot handle anything other than a simple-page-master reference. This is due to the limitation of the RTF implementation we have and without adding this feature will unfortunately remain like that. In the case of the original FO specification file, the page-sequence is referencing a page-sequence-master with a repeatable-page-master. The null pointer exception occurs because it tries to read the flow object after looking up and failing to find a simple-page-master with the master-reference provided. I originally created a patch to warn the user if the flow was null and recommend to changing the FO to using a simple-page-master reference in the page-sequence-master. A side effect of this though was that it bypassed trying to read the flow and continued to create the document successfully without it! As such I've simply removed the warning from the patch to only create the page-master if the flow is not null which seems to work fine. I'll apply this patch shortly. I've created another issue for the missing feature in RTF to support other page-master types: https://issues.apache.org/jira/browse/FOP-2350 Latest fop snapshot crashes when processing rindolf-spec.fo --- Key: FOP-2321 URL: https://issues.apache.org/jira/browse/FOP-2321 Project: Fop Issue Type: Bug Affects Versions: trunk Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 . Reporter: Shlomi Fish Attachments: patch.diff, rindolf-spec.fo.xz When I run this command I get this output (I will attach rindolf-spec.fo soon). I am using /home/shlomif/apps/fop/fop-20131126/fop : shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo -rtf lib/docbook/4/rtf/rindolf-spec.rtf Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener processEvent WARNING: Only simple-page-masters are supported on page-sequences. Using default simple-page-master from page-sequence-master body. (See position 2:26400) Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP SEVERE: Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:177) at org.apache.fop.cli.Main.main(Main.java:208) Caused by: java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285) ... 3 more - java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at
[jira] [Assigned] (FOP-2321) Latest fop snapshot crashes when processing rindolf-spec.fo
[ https://issues.apache.org/jira/browse/FOP-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer reassigned FOP-2321: - Assignee: Robert Meyer Latest fop snapshot crashes when processing rindolf-spec.fo --- Key: FOP-2321 URL: https://issues.apache.org/jira/browse/FOP-2321 Project: Fop Issue Type: Bug Affects Versions: trunk Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 . Reporter: Shlomi Fish Assignee: Robert Meyer Attachments: patch.diff, rindolf-spec.fo.xz When I run this command I get this output (I will attach rindolf-spec.fo soon). I am using /home/shlomif/apps/fop/fop-20131126/fop : shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo -rtf lib/docbook/4/rtf/rindolf-spec.rtf Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener processEvent WARNING: Only simple-page-masters are supported on page-sequences. Using default simple-page-master from page-sequence-master body. (See position 2:26400) Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP SEVERE: Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:177) at org.apache.fop.cli.Main.main(Main.java:208) Caused by: java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285) ... 3 more - java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at
[jira] [Commented] (FOP-2321) Latest fop snapshot crashes when processing rindolf-spec.fo
[ https://issues.apache.org/jira/browse/FOP-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13913049#comment-13913049 ] Robert Meyer commented on FOP-2321: --- Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1572109 I'll set this issue to resolved as it fixes the exception. The other issue I created is there should support for other page-masters be added in future. Latest fop snapshot crashes when processing rindolf-spec.fo --- Key: FOP-2321 URL: https://issues.apache.org/jira/browse/FOP-2321 Project: Fop Issue Type: Bug Affects Versions: trunk Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 . Reporter: Shlomi Fish Assignee: Robert Meyer Attachments: patch.diff, rindolf-spec.fo.xz When I run this command I get this output (I will attach rindolf-spec.fo soon). I am using /home/shlomif/apps/fop/fop-20131126/fop : shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo -rtf lib/docbook/4/rtf/rindolf-spec.rtf Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener processEvent WARNING: Only simple-page-masters are supported on page-sequences. Using default simple-page-master from page-sequence-master body. (See position 2:26400) Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP SEVERE: Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:177) at org.apache.fop.cli.Main.main(Main.java:208) Caused by: java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285) ... 3 more - java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at
[jira] [Updated] (FOP-2321) [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo
[ https://issues.apache.org/jira/browse/FOP-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2321: -- Summary: [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo (was: Latest fop snapshot crashes when processing rindolf-spec.fo) [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo --- Key: FOP-2321 URL: https://issues.apache.org/jira/browse/FOP-2321 Project: Fop Issue Type: Bug Affects Versions: trunk Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 . Reporter: Shlomi Fish Assignee: Robert Meyer Attachments: patch.diff, rindolf-spec.fo.xz When I run this command I get this output (I will attach rindolf-spec.fo soon). I am using /home/shlomif/apps/fop/fop-20131126/fop : shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo -rtf lib/docbook/4/rtf/rindolf-spec.rtf Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener processEvent WARNING: Only simple-page-masters are supported on page-sequences. Using default simple-page-master from page-sequence-master body. (See position 2:26400) Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP SEVERE: Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:177) at org.apache.fop.cli.Main.main(Main.java:208) Caused by: java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285) ... 3 more - java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at
[jira] [Resolved] (FOP-2321) [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo
[ https://issues.apache.org/jira/browse/FOP-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2321. --- Resolution: Fixed [PATCH] Latest fop snapshot crashes when processing rindolf-spec.fo --- Key: FOP-2321 URL: https://issues.apache.org/jira/browse/FOP-2321 Project: Fop Issue Type: Bug Affects Versions: trunk Environment: Mageia Linux Cauldron (what will become Mageia Linux 4) x86-64 with java-1.7.0-openjdk-headless-1.7.0.60-2.4.3.2.mga4 . Reporter: Shlomi Fish Assignee: Robert Meyer Attachments: patch.diff, rindolf-spec.fo.xz When I run this command I get this output (I will attach rindolf-spec.fo soon). I am using /home/shlomif/apps/fop/fop-20131126/fop : shlomif[homepage@default]:$trunk$ fop -fo lib/docbook/4/fo/rindolf-spec.fo -rtf lib/docbook/4/rtf/rindolf-spec.rtf Nov 27, 2013 10:10:24 AM org.apache.fop.events.LoggingEventListener processEvent WARNING: Only simple-page-masters are supported on page-sequences. Using default simple-page-master from page-sequence-master body. (See position 2:26400) Nov 27, 2013 10:10:24 AM org.apache.fop.cli.Main startFOP SEVERE: Exception org.apache.fop.apps.FOPException java.lang.NullPointerException at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:288) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:177) at org.apache.fop.cli.Main.main(Main.java:208) Caused by: java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285) ... 3 more - java.lang.NullPointerException at org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221) at org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:121) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:335) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:178) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:285) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
[jira] [Updated] (FOP-2339) [PATCH] GIF to PS transparency is black
[ https://issues.apache.org/jira/browse/FOP-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2339: -- Attachment: test.fo asf-logo-nt.tif After applying the change I get the following exception with another image when generating postscript: Caused by: java.lang.ClassCastException: org.apache.xmlgraphics.image.codec.tiff.TIFFImage cannot be cast to java.awt.image.BufferedImage I've attached a test.fo with the asf-logo-nt.tif to reproduce. [PATCH] GIF to PS transparency is black --- Key: FOP-2339 URL: https://issues.apache.org/jira/browse/FOP-2339 Project: Fop Issue Type: Bug Reporter: simon steiner Attachments: asf-logo-nt.tif, fop-gif-scaling-bug.gif, giftrans.patch, test.fo, test.fo fop test.fo -ps out.ps -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (FOP-2339) [PATCH] GIF to PS transparency is black
[ https://issues.apache.org/jira/browse/FOP-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13913127#comment-13913127 ] Robert Meyer edited comment on FOP-2339 at 2/26/14 4:45 PM: Hi Simon, After applying the patch I get the following exception with another image when generating postscript: Caused by: java.lang.ClassCastException: org.apache.xmlgraphics.image.codec.tiff.TIFFImage cannot be cast to java.awt.image.BufferedImage I've attached a test.fo with the asf-logo-nt.tif to reproduce. was (Author: rmeyer): After applying the change I get the following exception with another image when generating postscript: Caused by: java.lang.ClassCastException: org.apache.xmlgraphics.image.codec.tiff.TIFFImage cannot be cast to java.awt.image.BufferedImage I've attached a test.fo with the asf-logo-nt.tif to reproduce. [PATCH] GIF to PS transparency is black --- Key: FOP-2339 URL: https://issues.apache.org/jira/browse/FOP-2339 Project: Fop Issue Type: Bug Reporter: simon steiner Attachments: asf-logo-nt.tif, fop-gif-scaling-bug.gif, giftrans.patch, test.fo, test.fo fop test.fo -ps out.ps -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (FOP-2344) AFP issue
Robert Meyer created FOP-2344: - Summary: AFP issue Key: FOP-2344 URL: https://issues.apache.org/jira/browse/FOP-2344 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk When you have an FO which contains various SVG elements of different colors, certain elements such as text and boxes do not have their respective colors set correctly and instead are left at the color of the last element. This causes a problem if for example you have a grey box and black text on top. FOP will draw the box using the grey color and then use the same color for the text, rendering it invisible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2344) [PATCH] SVG elements bleed colour between elements when outputting to AFP
[ https://issues.apache.org/jira/browse/FOP-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2344: -- Summary: [PATCH] SVG elements bleed colour between elements when outputting to AFP (was: AFP issue) [PATCH] SVG elements bleed colour between elements when outputting to AFP - Key: FOP-2344 URL: https://issues.apache.org/jira/browse/FOP-2344 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: afp-test.fo, output-after.afp, output-before.afp, patch.diff When you have an FO which contains various SVG elements of different colors, certain elements such as text and boxes do not have their respective colors set correctly and instead are left at the color of the last element. This causes a problem if for example you have a grey box and black text on top. FOP will draw the box using the grey color and then use the same color for the text, rendering it invisible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2344) AFP issue
[ https://issues.apache.org/jira/browse/FOP-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2344: -- Attachment: patch.diff output-before.afp output-after.afp afp-test.fo Attached example FO, patch and two AFP's showing before and after patch. AFP issue - Key: FOP-2344 URL: https://issues.apache.org/jira/browse/FOP-2344 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: afp-test.fo, output-after.afp, output-before.afp, patch.diff When you have an FO which contains various SVG elements of different colors, certain elements such as text and boxes do not have their respective colors set correctly and instead are left at the color of the last element. This causes a problem if for example you have a grey box and black text on top. FOP will draw the box using the grey color and then use the same color for the text, rendering it invisible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2344) [PATCH] SVG bleeds color between elements when outputting to AFP
[ https://issues.apache.org/jira/browse/FOP-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2344: -- Summary: [PATCH] SVG bleeds color between elements when outputting to AFP (was: [PATCH] SVG elements bleed colour between elements when outputting to AFP) [PATCH] SVG bleeds color between elements when outputting to AFP Key: FOP-2344 URL: https://issues.apache.org/jira/browse/FOP-2344 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: afp-test.fo, output-after.afp, output-before.afp, patch.diff When you have an FO which contains various SVG elements of different colors, certain elements such as text and boxes do not have their respective colors set correctly and instead are left at the color of the last element. This causes a problem if for example you have a grey box and black text on top. FOP will draw the box using the grey color and then use the same color for the text, rendering it invisible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FOP-2344) [PATCH] SVG bleeds color between elements when outputting to AFP
[ https://issues.apache.org/jira/browse/FOP-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2344. --- Resolution: Fixed [PATCH] SVG bleeds color between elements when outputting to AFP Key: FOP-2344 URL: https://issues.apache.org/jira/browse/FOP-2344 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: afp-test.fo, output-after.afp, output-before.afp, patch.diff When you have an FO which contains various SVG elements of different colors, certain elements such as text and boxes do not have their respective colors set correctly and instead are left at the color of the last element. This causes a problem if for example you have a grey box and black text on top. FOP will draw the box using the grey color and then use the same color for the text, rendering it invisible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FOP-2344) [PATCH] SVG bleeds color between elements when outputting to AFP
[ https://issues.apache.org/jira/browse/FOP-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13904138#comment-13904138 ] Robert Meyer commented on FOP-2344: --- Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1569381 [PATCH] SVG bleeds color between elements when outputting to AFP Key: FOP-2344 URL: https://issues.apache.org/jira/browse/FOP-2344 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: afp-test.fo, output-after.afp, output-before.afp, patch.diff When you have an FO which contains various SVG elements of different colors, certain elements such as text and boxes do not have their respective colors set correctly and instead are left at the color of the last element. This causes a problem if for example you have a grey box and black text on top. FOP will draw the box using the grey color and then use the same color for the text, rendering it invisible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FOP-2341) [PATCH] Infinite loop when smaller used with a zero length font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903116#comment-13903116 ] Robert Meyer commented on FOP-2341: --- Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1568925 [PATCH] Infinite loop when smaller used with a zero length font-size --- Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Attachments: _test.fo, patch.diff Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FOP-2341) [PATCH] Infinite loop when smaller used with a zero length font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2341. --- Resolution: Fixed [PATCH] Infinite loop when smaller used with a zero length font-size --- Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Attachments: _test.fo, patch.diff Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2341) Infinite loop when smaller used with a zero length font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2341: -- Attachment: patch.diff I've uploaded a patch of a potential fix. It simply ensures that the previous step font size is not the same as the current to prevent it endlessly cycling. Alternatively I think this check could be placed in the while(..) definition. I've tested it and it seems to work fine. Infinite loop when smaller used with a zero length font-size --- Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Attachments: _test.fo, patch.diff Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FOP-2341) [PATCH] Infinite loop when smaller used with a zero length font-size
[ https://issues.apache.org/jira/browse/FOP-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2341: -- Summary: [PATCH] Infinite loop when smaller used with a zero length font-size (was: Infinite loop when smaller used with a zero length font-size ) [PATCH] Infinite loop when smaller used with a zero length font-size --- Key: FOP-2341 URL: https://issues.apache.org/jira/browse/FOP-2341 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.95, trunk Reporter: MOHD Priority: Critical Labels: font-size, infinite-loop, smaller Attachments: _test.fo, patch.diff Original Estimate: 1m Remaining Estimate: 1m My local FOP engine is hang when below scenario was occur. fo:block font-style=normal font-size=10mmpt role=html:div fo:inline baseline-shift=super font-size=smaller role=html:supth/fo:inlineof each month. /fo:block Please give some suggestion if any one has solution for this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FOP-2252) [PATCH] OpenType CFF support for FOP
[ https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896733#comment-13896733 ] Robert Meyer commented on FOP-2252: --- I have made some changes to the OTF patch to remove the need for patching fontbox. This will allow FOP to now use the latest version of fontbox and not a patched custom version. http://svn.apache.org/viewvc?view=revisionrevision=1566674 [PATCH] OpenType CFF support for FOP Key: FOP-2252 URL: https://issues.apache.org/jira/browse/FOP-2252 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: AlexBrushRegular.otf, SourceSansProBold.otf, fontbox-1.8.0-SNAPSHOT.jar, fop.xconf, output.pdf, patch-240713.diff, test.fo, test.pdf -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (FOP-2322) [PATCH] Type1 Font with Custom Encoding not visible in Postscript output
[ https://issues.apache.org/jira/browse/FOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer reassigned FOP-2322: - Assignee: Robert Meyer [PATCH] Type1 Font with Custom Encoding not visible in Postscript output Key: FOP-2322 URL: https://issues.apache.org/jira/browse/FOP-2322 Project: Fop Issue Type: Bug Reporter: simon steiner Assignee: Robert Meyer Attachments: fop.xconf, test.fo, trunktype1customenc.patch fop test.fo -c fop.xconf -ps out.ps No afm is given so fop writes out standard encoding which postscript doesnt like I cant share our customer fonts -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2322) [PATCH] Type1 Font with Custom Encoding not visible in Postscript output
[ https://issues.apache.org/jira/browse/FOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839984#comment-13839984 ] Robert Meyer commented on FOP-2322: --- After being able to test this with the font in question I was able to verify this patch and am able to confirm it resolves the issue. Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1548054 Thanks for your contribution! [PATCH] Type1 Font with Custom Encoding not visible in Postscript output Key: FOP-2322 URL: https://issues.apache.org/jira/browse/FOP-2322 Project: Fop Issue Type: Bug Reporter: simon steiner Assignee: Robert Meyer Attachments: fop.xconf, test.fo, trunktype1customenc.patch fop test.fo -c fop.xconf -ps out.ps No afm is given so fop writes out standard encoding which postscript doesnt like I cant share our customer fonts -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-2322) [PATCH] Type1 Font with Custom Encoding not visible in Postscript output
[ https://issues.apache.org/jira/browse/FOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2322. --- Resolution: Fixed [PATCH] Type1 Font with Custom Encoding not visible in Postscript output Key: FOP-2322 URL: https://issues.apache.org/jira/browse/FOP-2322 Project: Fop Issue Type: Bug Reporter: simon steiner Assignee: Robert Meyer Attachments: fop.xconf, test.fo, trunktype1customenc.patch fop test.fo -c fop.xconf -ps out.ps No afm is given so fop writes out standard encoding which postscript doesnt like I cant share our customer fonts -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-1069) No error message on illegal/unknown values on a property
[ https://issues.apache.org/jira/browse/FOP-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-1069. --- Resolution: Fixed No error message on illegal/unknown values on a property Key: FOP-1069 URL: https://issues.apache.org/jira/browse/FOP-1069 Project: Fop Issue Type: Bug Components: fo tree Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Jeremias Maerki Assignee: Robert Meyer Attachments: fix-20131203.diff, patch.diff, test2.fo I've written border=solit 1pt into an FO file. When I realized my typo I went looking for an error message but didn't find one. I looked around to fix this myself but didn't find the right spot in reasonable time as I'm concentrating on other stuff right now. I'm posting it here so it doesn't get lost. FOP should notify the user that it has found a value it cannot deal with, especially if this is an enum value. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-1069) No error message on illegal/unknown values on a property
[ https://issues.apache.org/jira/browse/FOP-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839053#comment-13839053 ] Robert Meyer commented on FOP-1069: --- Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1547838 No error message on illegal/unknown values on a property Key: FOP-1069 URL: https://issues.apache.org/jira/browse/FOP-1069 Project: Fop Issue Type: Bug Components: fo tree Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Jeremias Maerki Assignee: Robert Meyer Attachments: fix-20131203.diff, patch.diff, test2.fo I've written border=solit 1pt into an FO file. When I realized my typo I went looking for an error message but didn't find one. I looked around to fix this myself but didn't find the right spot in reasonable time as I'm concentrating on other stuff right now. I'm posting it here so it doesn't get lost. FOP should notify the user that it has found a value it cannot deal with, especially if this is an enum value. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (FOP-2323) NPE caused by missing local subroutine index in private dictonary of OTF font
Robert Meyer created FOP-2323: - Summary: NPE caused by missing local subroutine index in private dictonary of OTF font Key: FOP-2323 URL: https://issues.apache.org/jira/browse/FOP-2323 Project: Fop Issue Type: Bug Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk This issue was found by using a font which did not have a local subroutine index which is normally located in the private dictionary. A check has now been added to handle this eventuality and use a blank subroutine index instead. The font in question which triggered this was called RebusScript.otf -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2323) NPE caused by missing local subroutine index in private dictonary of OTF font
[ https://issues.apache.org/jira/browse/FOP-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2323: -- Attachment: patch.diff Attached patch for this issue NPE caused by missing local subroutine index in private dictonary of OTF font - Key: FOP-2323 URL: https://issues.apache.org/jira/browse/FOP-2323 Project: Fop Issue Type: Bug Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: patch.diff This issue was found by using a font which did not have a local subroutine index which is normally located in the private dictionary. A check has now been added to handle this eventuality and use a blank subroutine index instead. The font in question which triggered this was called RebusScript.otf -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-2323) NPE caused by missing local subroutine index in private dictonary of OTF font
[ https://issues.apache.org/jira/browse/FOP-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2323. --- Resolution: Fixed NPE caused by missing local subroutine index in private dictonary of OTF font - Key: FOP-2323 URL: https://issues.apache.org/jira/browse/FOP-2323 Project: Fop Issue Type: Bug Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: patch.diff This issue was found by using a font which did not have a local subroutine index which is normally located in the private dictionary. A check has now been added to handle this eventuality and use a blank subroutine index instead. The font in question which triggered this was called RebusScript.otf -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2323) NPE caused by missing local subroutine index in private dictonary of OTF font
[ https://issues.apache.org/jira/browse/FOP-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837520#comment-13837520 ] Robert Meyer commented on FOP-2323: --- Patch applied http://svn.apache.org/viewvc?view=revisionrevision=1547330 NPE caused by missing local subroutine index in private dictonary of OTF font - Key: FOP-2323 URL: https://issues.apache.org/jira/browse/FOP-2323 Project: Fop Issue Type: Bug Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: patch.diff This issue was found by using a font which did not have a local subroutine index which is normally located in the private dictionary. A check has now been added to handle this eventuality and use a blank subroutine index instead. The font in question which triggered this was called RebusScript.otf -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-1069) No error message on illegal/unknown values on a property
[ https://issues.apache.org/jira/browse/FOP-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-1069: -- Attachment: fix-20131203.diff Sorry for my lateness with getting back to this issue. I looked at this briefly but didn't manage to update it before I went on an extended holiday to the US. The issue was caused by the validation line being placed within the loop for each property value component. For instance, the word black on border will result in a null property result, but the other parts may result in a property being returned. Because of this a warning was being displayed even if the property was found to be valid. As such, I have moved the line for validation outside of the loop and the check is now done after each component part has been processed rather than individually. A slight change is that using this method makes it impossible to identify which part of the property is at fault and so the values which can be read are added to a string and used in the warning e.g. WARNING: Invalid property value encountered in border=black solit (See position 11:46) It should provide ample enough information to look at the line and fix the issue. On your original example it now works fine. I'll go ahead and commit this tomorrow unless you have any other comments. No error message on illegal/unknown values on a property Key: FOP-1069 URL: https://issues.apache.org/jira/browse/FOP-1069 Project: Fop Issue Type: Bug Components: fo tree Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Jeremias Maerki Assignee: Robert Meyer Attachments: fix-20131203.diff, patch.diff, test2.fo I've written border=solit 1pt into an FO file. When I realized my typo I went looking for an error message but didn't find one. I looked around to fix this myself but didn't find the right spot in reasonable time as I'm concentrating on other stuff right now. I'm posting it here so it doesn't get lost. FOP should notify the user that it has found a value it cannot deal with, especially if this is an enum value. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-1069) No error message on illegal/unknown values on a property
[ https://issues.apache.org/jira/browse/FOP-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812877#comment-13812877 ] Robert Meyer commented on FOP-1069: --- Thanks Glenn. I will take a look at this tomorrow. No error message on illegal/unknown values on a property Key: FOP-1069 URL: https://issues.apache.org/jira/browse/FOP-1069 Project: Fop Issue Type: Bug Components: fo tree Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Jeremias Maerki Assignee: Robert Meyer Attachments: patch.diff, test2.fo I've written border=solit 1pt into an FO file. When I realized my typo I went looking for an error message but didn't find one. I looked around to fix this myself but didn't find the right spot in reasonable time as I'm concentrating on other stuff right now. I'm posting it here so it doesn't get lost. FOP should notify the user that it has found a value it cannot deal with, especially if this is an enum value. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2260) [PATCH] Smart quotes broken in RTF if at start of text
[ https://issues.apache.org/jira/browse/FOP-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801634#comment-13801634 ] Robert Meyer commented on FOP-2260: --- Hi Christopher, I have taken a quick look at this and am unable to reproduce the issue using the default font. Which font are you using where this effect occurs? Also, would it be possible to post up a couple of simple examples showing this issue? Thanks [PATCH] Smart quotes broken in RTF if at start of text -- Key: FOP-2260 URL: https://issues.apache.org/jira/browse/FOP-2260 Project: Fop Issue Type: Bug Components: rtf Affects Versions: 1.1 Reporter: Christopher Lowdon Priority: Minor Labels: patch Attachments: mypatch.diff When you have a quote at the start of your string, it is transformed into a smart quote incorrectly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-2104) [PATCH] RTF renderer barfs when fo:table-row is missing inside fo-table-header
[ https://issues.apache.org/jira/browse/FOP-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2104. --- Resolution: Fixed Assignee: Robert Meyer Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1534582 [PATCH] RTF renderer barfs when fo:table-row is missing inside fo-table-header -- Key: FOP-2104 URL: https://issues.apache.org/jira/browse/FOP-2104 Project: Fop Issue Type: Bug Components: rtf Affects Versions: trunk Environment: Operating System: All Platform: PC Reporter: Gisbert Assignee: Robert Meyer Attachments: patch.diff, patch.diff, t1.zip In RTF, using fo:table-cell as direct children of fo:table-header (without intervening fo:table-row) causes the FOPException ... RTFHandler: startCell null. In PDF, it works flawlessly (which it should, as far as I understand the FO specs). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (FOP-2299) [PATCH] Non Unicode named glyphs not loaded for Type1 fonts
[ https://issues.apache.org/jira/browse/FOP-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer reassigned FOP-2299: - Assignee: Robert Meyer [PATCH] Non Unicode named glyphs not loaded for Type1 fonts --- Key: FOP-2299 URL: https://issues.apache.org/jira/browse/FOP-2299 Project: Fop Issue Type: Bug Reporter: simon steiner Assignee: Robert Meyer Attachments: 8731X___.AFM, 8731X___.INF, 8731X___.PFB, 8731X___.PFM, fop.xconf, test.fo, unicodemissing.patch Glyphs without unicode name are not loaded fop test.fo -c fop.xconf out.pdf -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-2299) [PATCH] Non Unicode named glyphs not loaded for Type1 fonts
[ https://issues.apache.org/jira/browse/FOP-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2299. --- Resolution: Fixed Thanks for your contribution. Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1534195 [PATCH] Non Unicode named glyphs not loaded for Type1 fonts --- Key: FOP-2299 URL: https://issues.apache.org/jira/browse/FOP-2299 Project: Fop Issue Type: Bug Reporter: simon steiner Assignee: Robert Meyer Attachments: 8731X___.AFM, 8731X___.INF, 8731X___.PFB, 8731X___.PFM, fop.xconf, test.fo, unicodemissing.patch Glyphs without unicode name are not loaded fop test.fo -c fop.xconf out.pdf -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (FOP-2304) SVG line clipping not correct when outputting to Postscript
Robert Meyer created FOP-2304: - Summary: SVG line clipping not correct when outputting to Postscript Key: FOP-2304 URL: https://issues.apache.org/jira/browse/FOP-2304 Project: Fop Issue Type: Bug Components: ps Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Lines that should be clipped are being drawn. This is because an intersect of two shapes are being used to determine if clipping needs to occur, but with lines this always returns false. I will add examples and a patch shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript
[ https://issues.apache.org/jira/browse/FOP-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2304: -- Attachment: output.ps SVG line clipping not correct when outputting to Postscript --- Key: FOP-2304 URL: https://issues.apache.org/jira/browse/FOP-2304 Project: Fop Issue Type: Bug Components: ps Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Attachments: output.pdf, output.ps Lines that should be clipped are being drawn. This is because an intersect of two shapes are being used to determine if clipping needs to occur, but with lines this always returns false. I will add examples and a patch shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript
[ https://issues.apache.org/jira/browse/FOP-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2304: -- Attachment: (was: output.ps) SVG line clipping not correct when outputting to Postscript --- Key: FOP-2304 URL: https://issues.apache.org/jira/browse/FOP-2304 Project: Fop Issue Type: Bug Components: ps Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Attachments: output.pdf, output.ps Lines that should be clipped are being drawn. This is because an intersect of two shapes are being used to determine if clipping needs to occur, but with lines this always returns false. I will add examples and a patch shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript
[ https://issues.apache.org/jira/browse/FOP-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2304: -- Attachment: output.pdf output2.ps output.ps Attached are several examples. Output1.pdf shows that it is working correctly to PDF. It is expected that the gradient is not being drawn correctly in Postscript hence it is black, however the white lines exceed the limit of circle when instead they should have been clipped. The correct output for Postscript without the current radial shading support should be that of output2.ps. I have a fix and will post it shortly. SVG line clipping not correct when outputting to Postscript --- Key: FOP-2304 URL: https://issues.apache.org/jira/browse/FOP-2304 Project: Fop Issue Type: Bug Components: ps Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Attachments: output.pdf, output.ps Lines that should be clipped are being drawn. This is because an intersect of two shapes are being used to determine if clipping needs to occur, but with lines this always returns false. I will add examples and a patch shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript
[ https://issues.apache.org/jira/browse/FOP-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2304: -- Attachment: (was: output2.ps) SVG line clipping not correct when outputting to Postscript --- Key: FOP-2304 URL: https://issues.apache.org/jira/browse/FOP-2304 Project: Fop Issue Type: Bug Components: ps Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Attachments: output.pdf, output.ps Lines that should be clipped are being drawn. This is because an intersect of two shapes are being used to determine if clipping needs to occur, but with lines this always returns false. I will add examples and a patch shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript
[ https://issues.apache.org/jira/browse/FOP-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2304: -- Attachment: output2.ps SVG line clipping not correct when outputting to Postscript --- Key: FOP-2304 URL: https://issues.apache.org/jira/browse/FOP-2304 Project: Fop Issue Type: Bug Components: ps Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Attachments: output2.ps, output.pdf, output.ps Lines that should be clipped are being drawn. This is because an intersect of two shapes are being used to determine if clipping needs to occur, but with lines this always returns false. I will add examples and a patch shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (FOP-2304) SVG line clipping not correct when outputting to Postscript
[ https://issues.apache.org/jira/browse/FOP-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2304: -- Attachment: patch.diff Patch file has been attached which includes the adding of an intersecting line test case. SVG line clipping not correct when outputting to Postscript --- Key: FOP-2304 URL: https://issues.apache.org/jira/browse/FOP-2304 Project: Fop Issue Type: Bug Components: ps Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Attachments: output2.ps, output.pdf, output.ps, patch.diff Lines that should be clipped are being drawn. This is because an intersect of two shapes are being used to determine if clipping needs to occur, but with lines this always returns false. I will add examples and a patch shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FOP-2304) SVG line clipping not correct when outputting to Postscript
[ https://issues.apache.org/jira/browse/FOP-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2304. --- Resolution: Fixed Fix Version/s: trunk Patched applied http://svn.apache.org/viewvc?view=revisionrevision=1533516 SVG line clipping not correct when outputting to Postscript --- Key: FOP-2304 URL: https://issues.apache.org/jira/browse/FOP-2304 Project: Fop Issue Type: Bug Components: ps Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Fix For: trunk Attachments: output2.ps, output.pdf, output.ps, patch.diff Lines that should be clipped are being drawn. This is because an intersect of two shapes are being used to determine if clipping needs to occur, but with lines this always returns false. I will add examples and a patch shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FOP-2275) [PATCH] Quadratic Bézier curves not properly rendered
[ https://issues.apache.org/jira/browse/FOP-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745036#comment-13745036 ] Robert Meyer commented on FOP-2275: --- patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1515840 [PATCH] Quadratic Bézier curves not properly rendered - Key: FOP-2275 URL: https://issues.apache.org/jira/browse/FOP-2275 Project: Fop Issue Type: Bug Components: pdf Reporter: Vincent Hennebert Attachments: patch.diff, quadratic-bezier.fo, quadratic-bezier.pdf, quadratic-bezier.svg Quadratic Bézier curves (q command in SVG) are rendered in PDF using cubic Bézier operators (the y PDF operator). That gives a wrong result. -- 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-2275) [PATCH] Quadratic Bézier curves not properly rendered
[ https://issues.apache.org/jira/browse/FOP-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2275. --- Resolution: Fixed Fix Version/s: trunk [PATCH] Quadratic Bézier curves not properly rendered - Key: FOP-2275 URL: https://issues.apache.org/jira/browse/FOP-2275 Project: Fop Issue Type: Bug Components: pdf Reporter: Vincent Hennebert Fix For: trunk Attachments: patch.diff, quadratic-bezier.fo, quadratic-bezier.pdf, quadratic-bezier.svg Quadratic Bézier curves (q command in SVG) are rendered in PDF using cubic Bézier operators (the y PDF operator). That gives a wrong result. -- 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-2275) [PATCH] Quadratic Bézier curves not properly rendered
[ https://issues.apache.org/jira/browse/FOP-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2275: -- Summary: [PATCH] Quadratic Bézier curves not properly rendered (was: Quadratic Bézier curves not properly rendered) [PATCH] Quadratic Bézier curves not properly rendered - Key: FOP-2275 URL: https://issues.apache.org/jira/browse/FOP-2275 Project: Fop Issue Type: Bug Components: pdf Reporter: Vincent Hennebert Attachments: patch.diff, quadratic-bezier.fo, quadratic-bezier.pdf, quadratic-bezier.svg Quadratic Bézier curves (q command in SVG) are rendered in PDF using cubic Bézier operators (the y PDF operator). That gives a wrong result. -- 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-2275) Quadratic Bézier curves not properly rendered
[ https://issues.apache.org/jira/browse/FOP-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2275: -- Attachment: patch.diff I have come up with a patch for this issue. It involves converting the Quadratic to a Cubic curve. To do this, I needed to use the last drawn position in the calculation, hence creating the lastX and lastY variables which are set on the other drawing commands. It seems to work well and now matches the SVG drawing. Let me know what you think. Quadratic Bézier curves not properly rendered - Key: FOP-2275 URL: https://issues.apache.org/jira/browse/FOP-2275 Project: Fop Issue Type: Bug Components: pdf Reporter: Vincent Hennebert Attachments: patch.diff, quadratic-bezier.fo, quadratic-bezier.pdf, quadratic-bezier.svg Quadratic Bézier curves (q command in SVG) are rendered in PDF using cubic Bézier operators (the y PDF operator). That gives a wrong result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2252) OpenType CFF support for FOP
[ https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2252: -- Attachment: (was: 24052013-otfcff.patch) OpenType CFF support for FOP Key: FOP-2252 URL: https://issues.apache.org/jira/browse/FOP-2252 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Attachments: AlexBrushRegular.otf, fontbox-1.8.0-SNAPSHOT.jar, output.pdf, patch-240713.diff, SourceSansProBold.otf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2252) OpenType CFF support for FOP
[ https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2252: -- Attachment: SourceSansProBold.otf AlexBrushRegular.otf fontbox-1.8.0-SNAPSHOT.jar patch-240713.diff I have attached the final patch for adding OTF CFF support. To build, you need the modified version of fontbox (attached) which should go in the lib directory with the distribution. The fontbox changes have been put forward as a series of patches and are reliant upon the PDF-Box community to push them through. Due to the time frame being unknown when that will happen and included with a disibutrion, I've posted the already modified version here with the patch. There are two fonts which are used in unit tests. These are free open source fonts which apparently are compatible with Apache licensing. For PostScript support, I will shortly be adding a new patch to XMLGraphics for a new subroutine which is required to re-encode each font. This patch will be made dependant on that. The patch is a large one (10k+ lines), but a proportion of that is related to renaming several files to fit with the new OpenFont naming structure with CFF and TTF subclasses. OpenType CFF support for FOP Key: FOP-2252 URL: https://issues.apache.org/jira/browse/FOP-2252 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Attachments: 24052013-otfcff.patch, AlexBrushRegular.otf, fontbox-1.8.0-SNAPSHOT.jar, output.pdf, patch-240713.diff, SourceSansProBold.otf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-1278) PNG causes NPE for RTF output
[ https://issues.apache.org/jira/browse/FOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-1278: -- Attachment: test.fo I know this is an old bug, but thought I'd just investigate to see whether this is still reproducible and if it's worth keeping this open. I have attached the following FO and am not getting the NPE for which this bug was originally raised for. It now creates the RTF without error, however if you open the RTF instead of finding the image, some text in the RTF is written as the following: org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic$ExternalGraphicException org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic$ExternalGraphicException: The tag fo:external-graphic does not support png - image type. I guess that means this can be closed? PNG causes NPE for RTF output - Key: FOP-1278 URL: https://issues.apache.org/jira/browse/FOP-1278 Project: Fop Issue Type: Bug Components: rtf Affects Versions: trunk Environment: Operating System: other Platform: Other Reporter: Chris Bowditch Attachments: moon.png, test.fo Attached PNG causes a NPE when rendering to RTF. Submitted by Dominic Brugger (brugger.at.puzzle.ch) Stack trace below: SEVERE: Error while handling an external-graphic: null java.lang.NullPointerException at org.apache.commons.io.IOUtils.copy(IOUtils.java:920) at org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:215) at org.apache.fop.image.AbstractFopImage.loadDefaultOriginalData (AbstractFopImage.java:223) at org.apache.fop.image.ImageIOImage.loadOriginalData (ImageIOImage.java:217) at org.apache.fop.image.AbstractFopImage.load (AbstractFopImage.java:174) at org.apache.fop.render.rtf.RTFHandler.image(RTFHandler.java:1131) at org.apache.fop.render.rtf.RTFHandler.invokeDeferredEvent (RTFHandler.java:1492) at org.apache.fop.render.rtf.RTFHandler.recurseFONode (RTFHandler.java:1616) at org.apache.fop.render.rtf.RTFHandler.recurseFONode (RTFHandler.java:1687) at org.apache.fop.render.rtf.RTFHandler.recurseFONode (RTFHandler.java:1687) at org.apache.fop.render.rtf.RTFHandler.recurseFONode (RTFHandler.java:1639) at org.apache.fop.render.rtf.RTFHandler.endPageSequence (RTFHandler.java: -- 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-1333) External graphic doesnt size properly with height set at 100%
[ https://issues.apache.org/jira/browse/FOP-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673190#comment-13673190 ] Robert Meyer commented on FOP-1333: --- Another old one, but seemingly still valid today. I am sure this issue has come up elsewhere on the message board before now. I think the block is taking into consideration the line spacing even though there is no text. If you specify the parent block of the image to have font-size=0, the image fills the complete height I think this is a bit of a grey area with regard to whether the block takes into consideration line spacing if there is no text. Again, not sure if this should be left open as this is unlikely to be changed unless someone has some strong views on removing line spacing with no text. External graphic doesnt size properly with height set at 100% - Key: FOP-1333 URL: https://issues.apache.org/jira/browse/FOP-1333 Project: Fop Issue Type: Bug Components: general Affects Versions: 0.93 Environment: Operating System: other Platform: PC Reporter: Barry Pearce Attachments: logo.jpg, test.pdf The following XSL-FO causes a complaint about the graphics being out of limits and DOES NOT render at the scaled size. The specification states that a height of 100% should cause the area to be set at the same size of the parent (which should be the size of extent in this case. ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=Form page-width=210mm page-height=297mm margin-top=10mm margin-bottom=10mm margin-left=10mm margin-right=10mm padding=0 fo:region-body margin=0 margin-top=32mm padding=0/ fo:region-before extent=32mm margin=0 padding=0/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=Form fo:static-content flow-name=xsl-region-before fo:block text-align=center height=100% width=100% border-style=solid border-color=orange border-width=0.25mm fo:external-graphic border-style=solid border-color=black border-width=0.25mm scaling=uniform scaling-method=resample-any-method height=100% content-height=scale-to-fit src=logo.jpg / /fo:block /fo:static-content fo:flow flow-name=xsl-region-body fo:block-container height=100% width=100% border-style=solid border-color=blue border-width=0.25mm fo:block text-align=center font-size=20pt font-family=serif line-height=30pt LOGO CHECK /fo:block /fo:block-container /fo:flow /fo:page-sequence /fo:root -- 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-2252) OpenType CFF support to FOP
Robert Meyer created FOP-2252: - Summary: OpenType CFF support to FOP Key: FOP-2252 URL: https://issues.apache.org/jira/browse/FOP-2252 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2252) OpenType CFF support to FOP
[ https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2252: -- Attachment: output.pdf 24052013-otfcff.patch This patch is a work in progress for OTF CFF support within FOP. At present the code supports both full embedding and subset embedding of standard and CID-Keyed fonts. There are still bug fixes and improvements to be made though, so again this is a work in progress patch just to keep everyone here updated. Although the code is not final, if you do have any comments regarding the code, I would welcome them. I have set up a github with the help of Peter Hancock for this feature in case you want to test it. This can be found here: https://github.com/rmeyerth/fop/tree/B-01338/open_type_cff_support_trunk Changes have been made to fontbox and should hopefully be posted soon as a patch. A complete rewrite for the CharStringRenderer was made quite early on and that has already been committed to the project. I will update this issue when I have any new updates to share. OpenType CFF support to FOP --- Key: FOP-2252 URL: https://issues.apache.org/jira/browse/FOP-2252 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Attachments: 24052013-otfcff.patch, output.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2252) OpenType CFF support to FOP
[ https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2252: -- Attachment: (was: output.pdf) OpenType CFF support to FOP --- Key: FOP-2252 URL: https://issues.apache.org/jira/browse/FOP-2252 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Attachments: 24052013-otfcff.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2252) OpenType CFF support to FOP
[ https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2252: -- Attachment: output.pdf Here is an example of a PDF with subsetted OTF CFF for both standard and CID-Keyed fonts. For some reason, it doesn't seem to display correctly in my web browser PDF viewer (that might be related to my Linux machine). If you download it however in Adobe Acrobat, Ghostscript, Evince etc. then you should see everything correctly. OpenType CFF support to FOP --- Key: FOP-2252 URL: https://issues.apache.org/jira/browse/FOP-2252 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Attachments: 24052013-otfcff.patch, output.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2252) OpenType CFF support for FOP
[ https://issues.apache.org/jira/browse/FOP-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2252: -- Summary: OpenType CFF support for FOP (was: OpenType CFF support to FOP) OpenType CFF support for FOP Key: FOP-2252 URL: https://issues.apache.org/jira/browse/FOP-2252 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Attachments: 24052013-otfcff.patch, output.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FOP-850) TTF Reader fails
[
https://issues.apache.org/jira/browse/FOP-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13603285#comment-13603285
]
Robert Meyer commented on FOP-850:
--
As I am looking at fonts at the moment, I thought I would take a quick look at
this. This issue seems to have been resolved as it no longer complains with the
provided font. Also, looking in the code, it appears cmap encoding is being
handled for both values 0 and 1:
if (cmapPID == 3 cmapEID == 1) {
cmapUniOffset = cmapOffset;
}
if (cmapPID == 3 cmapEID == 0) {
symbolMapOffset = cmapOffset;
}
This was added back in 2009. I would therefore recommend this issue be closed.
TTF Reader fails
Key: FOP-850
URL: https://issues.apache.org/jira/browse/FOP-850
Project: Fop
Issue Type: Bug
Components: general
Affects Versions: 0.20.5
Environment: Operating System: All
Platform: PC
Reporter: Peter Schäfer
Attachments: BERLIN.TTF
Reading fonts/BERLIN.TTF...
Number of glyphs in font: 119
Unicode cmap table not present
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:507)
at java.util.ArrayList.get(ArrayList.java:324)
at org.apache.fop.fonts.TTFFile.createCMaps(TTFFile.java:449)
at org.apache.fop.fonts.TTFFile.readFont(TTFFile.java:439)
at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:222)
at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:184)
I found that the TrueType file contains a cmap table with platformID=3 and
encodingId=0 (Windows Symbol encoding, or whatever).
TTFReader expects encodingId = 1. However, the table contains readable data in
the correct format (format 4). After patching TTFFile.java, it created a
perfectly valid metrics file.
I might suggest that you apply this patch to org.apache.fop.fonts.TTFFile,
line 185:
if (cmap_pid == 3 (cmap_eid == 1 || cmap_eid == 0))
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2217) Image scaling change .was adversely affecting other image types
[ https://issues.apache.org/jira/browse/FOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2217: -- Description: A patch which will be posted shortly addresses several issues revolving around a change made to the ImageLayout class to resolve a scaling issue. This subsequently adversely affected other image types which needed to be changed. This patch removes the existing code changes and employs a fix to resolve the original issue related to SVG not converting to the correct unit. I have also removed a test case which was added for the ImageLayout class as this no longer applies. A follow up patch will be created for the XGC project to remove the fix related for this issue as that also no longer applies. Summary: Image scaling change .was adversely affecting other image types (was: Image scaling change was adversely affecting cd ..) Image scaling change .was adversely affecting other image types Key: FOP-2217 URL: https://issues.apache.org/jira/browse/FOP-2217 Project: Fop Issue Type: Bug Reporter: Robert Meyer A patch which will be posted shortly addresses several issues revolving around a change made to the ImageLayout class to resolve a scaling issue. This subsequently adversely affected other image types which needed to be changed. This patch removes the existing code changes and employs a fix to resolve the original issue related to SVG not converting to the correct unit. I have also removed a test case which was added for the ImageLayout class as this no longer applies. A follow up patch will be created for the XGC project to remove the fix related for this issue as that also no longer applies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2217) Image scaling change .was adversely affecting other image types
[ https://issues.apache.org/jira/browse/FOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2217: -- Attachment: patch.diff Attached patch file for the changes. Image scaling change .was adversely affecting other image types Key: FOP-2217 URL: https://issues.apache.org/jira/browse/FOP-2217 Project: Fop Issue Type: Bug Reporter: Robert Meyer Attachments: patch.diff A patch which will be posted shortly addresses several issues revolving around a change made to the ImageLayout class to resolve a scaling issue. This subsequently adversely affected other image types which needed to be changed. This patch removes the existing code changes and employs a fix to resolve the original issue related to SVG not converting to the correct unit. I have also removed a test case which was added for the ImageLayout class as this no longer applies. A follow up patch will be created for the XGC project to remove the fix related for this issue as that also no longer applies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FOP-2217) Image scaling change was adversely affecting cd ..
Robert Meyer created FOP-2217: - Summary: Image scaling change was adversely affecting cd .. Key: FOP-2217 URL: https://issues.apache.org/jira/browse/FOP-2217 Project: Fop Issue Type: Bug Reporter: Robert Meyer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FOP-2217) [PATCH] Image scaling change .was adversely affecting other image types
[ https://issues.apache.org/jira/browse/FOP-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2217: -- Summary: [PATCH] Image scaling change .was adversely affecting other image types (was: Image scaling change .was adversely affecting other image types ) [PATCH] Image scaling change .was adversely affecting other image types Key: FOP-2217 URL: https://issues.apache.org/jira/browse/FOP-2217 Project: Fop Issue Type: Bug Reporter: Robert Meyer Attachments: patch.diff A patch which will be posted shortly addresses several issues revolving around a change made to the ImageLayout class to resolve a scaling issue. This subsequently adversely affected other image types which needed to be changed. This patch removes the existing code changes and employs a fix to resolve the original issue related to SVG not converting to the correct unit. I have also removed a test case which was added for the ImageLayout class as this no longer applies. A follow up patch will be created for the XGC project to remove the fix related for this issue as that also no longer applies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FOP-2219) XGC change removal as it is no longer needed with the image scaling change in FOP
Robert Meyer created FOP-2219: - Summary: 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 -- 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-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:all-tabpanel ] Robert Meyer updated FOP-2219: -- Attachment: patch.diff Attached patch to remove scaling change 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-2181) 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 ] Robert Meyer updated FOP-2181: -- Attachment: patch.diff Added a patch including a unit test for the ImageLayout class. I have also included a small change to the class relating to a rounding issue which caused certain resolutions to not scale properly. 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 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-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 ] Robert Meyer updated FOP-2181: -- Summary: [PATCH] Add a test case for the recent fix made in FOP-2174 and XGC-76 regarding source resolution scaling with SVG and images (was: Add a test case for the recent fix made in FOP-2174 and XGC-76 regarding source resolution scaling with SVG and images) [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 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] [Created] (FOP-2207) fo:external-graphic when using a PDF was being scaled incorrectly based on source resolution
Robert Meyer created FOP-2207: - Summary: fo:external-graphic when using a PDF was being scaled incorrectly based on source resolution Key: FOP-2207 URL: https://issues.apache.org/jira/browse/FOP-2207 Project: Fop Issue Type: Bug Components: images Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Fix For: trunk When using fo:external-graphic referencing a PDF page and also specifying a source resolution, the PDF page would not appear as expected as a full size image and instead being scaled according to this value. This is because of a recent fix regarding the source resolution and images scaling correctly. I will post an example and patch shortly to the fop-pdf-images 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-2207) fo:external-graphic when using a PDF was being scaled incorrectly based on source resolution
[ https://issues.apache.org/jira/browse/FOP-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2207: -- Attachment: patch.diff test.fo fop.xconf example.pdf before.pdf after.pdf The attached example uses a source resolution of 144 which is double the standard. From the before.pdf, you can see that it is scaling the pdf image even though it shouldn't be. The fix results in the correct scaling. fo:external-graphic when using a PDF was being scaled incorrectly based on source resolution Key: FOP-2207 URL: https://issues.apache.org/jira/browse/FOP-2207 Project: Fop Issue Type: Bug Components: images Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Fix For: trunk Attachments: after.pdf, before.pdf, example.pdf, fop.xconf, patch.diff, test.fo When using fo:external-graphic referencing a PDF page and also specifying a source resolution, the PDF page would not appear as expected as a full size image and instead being scaled according to this value. This is because of a recent fix regarding the source resolution and images scaling correctly. I will post an example and patch shortly to the fop-pdf-images 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-2207) fo:external-graphic when using a PDF was being scaled incorrectly based on source resolution
[ https://issues.apache.org/jira/browse/FOP-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13572537#comment-13572537 ] Robert Meyer commented on FOP-2207: --- I didn't know where to put this, but if this belongs against XMLGraphicsCommons, I would be grateful if someone could move it there. fo:external-graphic when using a PDF was being scaled incorrectly based on source resolution Key: FOP-2207 URL: https://issues.apache.org/jira/browse/FOP-2207 Project: Fop Issue Type: Bug Components: images Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Priority: Minor Fix For: trunk Attachments: after.pdf, before.pdf, example.pdf, fop.xconf, patch.diff, test.fo When using fo:external-graphic referencing a PDF page and also specifying a source resolution, the PDF page would not appear as expected as a full size image and instead being scaled according to this value. This is because of a recent fix regarding the source resolution and images scaling correctly. I will post an example and patch shortly to the fop-pdf-images 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] [Created] (FOP-2181) Add a test case for the recent fix made in FOP-2174 and XGC-76 regarding source resolution scaling with SVG and images
Robert Meyer created FOP-2181: - Summary: 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 -- 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-2044) Hyphenation of Uppercase Words, Combined with Underlines
[ https://issues.apache.org/jira/browse/FOP-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2044: -- Attachment: patch.diff I managed to spend a bit of time on this last night. The patch includes a new hyphenation test case. 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] [Updated] (FOP-2044) Hyphenation of Uppercase Words, Combined with Underlines
[ https://issues.apache.org/jira/browse/FOP-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer updated FOP-2044: -- Attachment: output.pdf After having a go this morning I think I have got it working and it seems to pass all the tests. I have attached an output.pdf file to show the original example with the changes. I did have to remove two fills from before the OCF_SUCCESS though to get it to work, otherwise there is not enough space. The code at present is very rough and needs a bit of work and more testing before I would consider it for a patch. It probably won't be today, but i'll post an update to the issue when done. 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, 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] [Assigned] (FOP-2179) New checkstyle and findbugs issues introduced after recent patch
[ https://issues.apache.org/jira/browse/FOP-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer reassigned FOP-2179: - Assignee: Robert Meyer New checkstyle and findbugs issues introduced after recent patch Key: FOP-2179 URL: https://issues.apache.org/jira/browse/FOP-2179 Project: Fop Issue Type: Bug Components: general Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer A recent patch submitted by myself has introduced several checkstyle warnings and one findbugs issue. I have resolved these and will post a patch shortly against this Jira issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
