[jira] [Updated] (FOP-3058) AFP-Renderer does not honour fill-rule 'nonzero' of SVG path.
[ https://issues.apache.org/jira/browse/FOP-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JYR updated FOP-3058: - Affects Version/s: 0.95 > AFP-Renderer does not honour fill-rule 'nonzero' of SVG path. > - > > Key: FOP-3058 > URL: https://issues.apache.org/jira/browse/FOP-3058 > Project: FOP > Issue Type: Bug > Components: image/svg, renderer/afp >Affects Versions: 0.95, 2.7 >Reporter: JYR >Priority: Major > Attachments: GreenCrossAsAFP.png, GreenCrossAsPDF.png, > TestWithSVGPath-1.7z > > > Hi there, > We have just isolated an interesting bug in the AFP renderer. > We are embedding some SVG graphics in a FO file and the AFP renderer does not > seem to take the "fill-rule" attribute into account. > It seems to ignore the fill-rule 'nonzero' of our path and defaults to > 'evenodd'. > The PDF renderer does honour this fill-rule, but not the AFP renderer. > We have isolated this issue in a test project. Just unpack > [^TestWithSVGPath-1.7z]. All the necessary files are provided. > This is the correct output of the PDF renderer > !GreenCrossAsPDF.png! > This is the output of the AFP renderer. > !GreenCrossAsAFP.png! > FOP integration: > * We are calling FOP via java.exe. > * FOP is configured with an xconf file. > Expected: > * The AFP-Renderer shall honour the 'fill-rule' attribute of the SVG path. > * If the 'fill-rule' attribute is not specified, the AFP-Renderer shall > default to 'nonzero'. > Extract of FO-File > {code:xml} > > http://www.w3.org/2000/svg;> >transform="translate(0 130.394)"> > > > >shape-rendering="crispEdges" d=" > M63.543,-70.709 > h 3.307 > v 11.024 > h -3.307 > z > m-3.858,3.858 > h11.024 > v3.307 > h-11.024 > z > "/> > > > > > > > {code} > We spotted this bug with FOP version 0.95, but it still occurs with FOP 2.7. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (FOP-3058) AFP-Renderer does not honour fill-rule 'nonzero' of SVG path.
[ https://issues.apache.org/jira/browse/FOP-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JYR updated FOP-3058: - Description: Hi there, We have just isolated an interesting bug in the AFP renderer. We are embedding some SVG graphics in a FO file and the AFP renderer does not seem to take the "fill-rule" attribute into account. It seems to ignore the fill-rule 'nonzero' of our path and defaults to 'evenodd'. The PDF renderer does honour this fill-rule, but not the AFP renderer. We have isolated this issue in a test project. Just unpack [^TestWithSVGPath-1.7z]. All the necessary files are provided. This is the correct output of the PDF renderer !GreenCrossAsPDF.png! This is the output of the AFP renderer. !GreenCrossAsAFP.png! FOP integration: * We are calling FOP via java.exe. * FOP is configured with an xconf file. Expected: * The AFP-Renderer shall honour the 'fill-rule' attribute of the SVG path. * If the 'fill-rule' attribute is not specified, the AFP-Renderer shall default to 'nonzero'. Extract of FO-File {code:xml} http://www.w3.org/2000/svg;> {code} We spotted this bug with FOP version 0.95, but it still occurs with FOP 2.7. was: Hi there, We have just isolated an interesting bug in the AFP renderer. We are embedding some SVG graphics in a FO file and the AFP renderer does not seem to take the "fill-rule" attribute into account. It seems to ignore the fill-rule 'nonzero' of our path and defaults to 'evenodd'. The PDF renderer does honour this fill-rule, but not the AFP renderer. We have isolated this issue in a test project. Just deflate [^TestWithSVGPath-1.7z]. All the necessary files are provided. This is the correct output of the PDF renderer !GreenCrossAsPDF.png! This is the output of the AFP renderer. !GreenCrossAsAFP.png! FOP integration: * We are calling FOP via java.exe. * FOP is configured with an xconf file. Expected: * The AFP-Renderer shall honour the 'fill-rule' attribute of the SVG path. * If the 'fill-rule' attribute is not specified, the AFP-Renderer shall default to 'nonzero'. Extract of FO-File {code:xml} http://www.w3.org/2000/svg;> {code} We spotted this bug with FOP version 0.95, but it still occurs with FOP 2.7. > AFP-Renderer does not honour fill-rule 'nonzero' of SVG path. > - > > Key: FOP-3058 > URL: https://issues.apache.org/jira/browse/FOP-3058 > Project: FOP > Issue Type: Bug > Components: image/svg, renderer/afp >Affects Versions: 2.7 >Reporter: JYR >Priority: Major > Attachments: GreenCrossAsAFP.png, GreenCrossAsPDF.png, > TestWithSVGPath-1.7z > > > Hi there, > We have just isolated an interesting bug in the AFP renderer. > We are embedding some SVG graphics in a FO file and the AFP renderer does not > seem to take the "fill-rule" attribute into account. > It seems to ignore the fill-rule 'nonzero' of our path and defaults to > 'evenodd'. > The PDF renderer does honour this fill-rule, but not the AFP renderer. > We have isolated this issue in a test project. Just unpack > [^TestWithSVGPath-1.7z]. All the necessary files are provided. > This is the correct output of the PDF renderer > !GreenCrossAsPDF.png! > This is the output of the AFP renderer. > !GreenCrossAsAFP.png! > FOP integration: > * We are calling FOP via java.exe. > * FOP is configured with an xconf file. > Expected: > * The AFP-Renderer shall honour the 'fill-rule' attribute of the SVG path. > * If the 'fill-rule' attribute is not specified, the AFP-Renderer shall > default to 'nonzero'. > Extract of FO-File > {code:xml} > > http://www.w3.org/2000/svg;> >transform="translate(0 130.394)"> > > > >shape-rendering="crispEdges" d=" > M63.543,-70.709 > h 3.307 > v 11.024 > h -3.307 >
[jira] [Updated] (FOP-3058) AFP-Renderer does not honour fill-rule 'nonzero' of SVG path.
[ https://issues.apache.org/jira/browse/FOP-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JYR updated FOP-3058: - Description: Hi there, We have just isolated an interesting bug in the AFP renderer. We are embedding some SVG graphics in a FO file and the AFP renderer does not seem to take the "fill-rule" attribute into account. It seems to ignore the fill-rule 'nonzero' of our path and defaults to 'evenodd'. The PDF renderer does honour this fill-rule, but not the AFP renderer. We have isolated this issue in a test project. Just deflate [^TestWithSVGPath-1.7z]. All the necessary files are provided. This is the correct output of the PDF renderer !GreenCrossAsPDF.png! This is the output of the AFP renderer. !GreenCrossAsAFP.png! FOP integration: * We are calling FOP via java.exe. * FOP is configured with an xconf file. Expected: * The AFP-Renderer shall honour the 'fill-rule' attribute of the SVG path. * If the 'fill-rule' attribute is not specified, the AFP-Renderer shall default to 'nonzero'. Extract of FO-File {code:xml} http://www.w3.org/2000/svg;> {code} We spotted this bug with FOP version 0.95, but it still occurs with FOP 2.7. was: Hi there, We have just isolated an interesting bug in the AFP renderer. We are embedding some SVG graphics in a FO file and the AFP renderer does not seem to take the "fill-rule" attribute into account. It seems to ignore the fill-rule 'nonzero' of our path and defaults to 'evenodd'. The PDF renderer does honour this fill-rule, but not the AFP renderer. We have isolated this issue in a test project. Just deflate [^TestWithSVGPath-1.7z]. All the necessary files are provided. This is the correct output of the PDF renderer !GreenCrossAsPDF.png! This is the output of the AFP renderer. !GreenCrossAsAFP.png! FOP integration: * We are calling FOP via java.exe. * FOP is configured with an xconf file. Extract of FO-File {code:xml} http://www.w3.org/2000/svg;> {code} We spotted this bug with FOP version 0.95, but it still occurs with FOP 2.7. > AFP-Renderer does not honour fill-rule 'nonzero' of SVG path. > - > > Key: FOP-3058 > URL: https://issues.apache.org/jira/browse/FOP-3058 > Project: FOP > Issue Type: Bug > Components: image/svg, renderer/afp >Affects Versions: 2.7 >Reporter: JYR >Priority: Major > Attachments: GreenCrossAsAFP.png, GreenCrossAsPDF.png, > TestWithSVGPath-1.7z > > > Hi there, > We have just isolated an interesting bug in the AFP renderer. > We are embedding some SVG graphics in a FO file and the AFP renderer does not > seem to take the "fill-rule" attribute into account. > It seems to ignore the fill-rule 'nonzero' of our path and defaults to > 'evenodd'. > The PDF renderer does honour this fill-rule, but not the AFP renderer. > We have isolated this issue in a test project. Just deflate > [^TestWithSVGPath-1.7z]. All the necessary files are provided. > This is the correct output of the PDF renderer > !GreenCrossAsPDF.png! > This is the output of the AFP renderer. > !GreenCrossAsAFP.png! > FOP integration: > * We are calling FOP via java.exe. > * FOP is configured with an xconf file. > Expected: > * The AFP-Renderer shall honour the 'fill-rule' attribute of the SVG path. > * If the 'fill-rule' attribute is not specified, the AFP-Renderer shall > default to 'nonzero'. > Extract of FO-File > {code:xml} > > http://www.w3.org/2000/svg;> >transform="translate(0 130.394)"> > > > >shape-rendering="crispEdges" d=" > M63.543,-70.709 > h 3.307 > v 11.024 > h -3.307 > z > m-3.858,3.858 >
[jira] [Created] (FOP-3058) AFP-Renderer does not honour fill-rule 'nonzero' of SVG path.
JYR created FOP-3058: Summary: AFP-Renderer does not honour fill-rule 'nonzero' of SVG path. Key: FOP-3058 URL: https://issues.apache.org/jira/browse/FOP-3058 Project: FOP Issue Type: Bug Components: image/svg, renderer/afp Affects Versions: 2.7 Reporter: JYR Attachments: GreenCrossAsAFP.png, GreenCrossAsPDF.png, TestWithSVGPath-1.7z Hi there, We have just isolated an interesting bug in the AFP renderer. We are embedding some SVG graphics in a FO file and the AFP renderer does not seem to take the "fill-rule" attribute into account. It seems to ignore the fill-rule 'nonzero' of our path and defaults to 'evenodd'. The PDF renderer does honour this fill-rule, but not the AFP renderer. We have isolated this issue in a test project. Just deflate [^TestWithSVGPath-1.7z]. All the necessary files are provided. This is the correct output of the PDF renderer !GreenCrossAsPDF.png! This is the output of the AFP renderer. !GreenCrossAsAFP.png! FOP integration: * We are calling FOP via java.exe. * FOP is configured with an xconf file. Extract of FO-File {code:xml} http://www.w3.org/2000/svg;> {code} We spotted this bug with FOP version 0.95, but it still occurs with FOP 2.7. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (FOP-1466) About AFP renderer Issues when i try to using Aria Fonts which come from Mainframe
[ https://issues.apache.org/jira/browse/FOP-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner resolved FOP-1466. Resolution: Works for Me > About AFP renderer Issues when i try to using Aria Fonts which come from > Mainframe > -- > > Key: FOP-1466 > URL: https://issues.apache.org/jira/browse/FOP-1466 > Project: FOP > Issue Type: Bug > Components: font/unqualified >Affects Versions: 0.94 > Environment: Operating System: other > Platform: Other >Reporter: feelyn > Attachments: b44024 > > > Exception: > system properly. > java.lang.IllegalArgumentException: Transparent data is longer than 253 > bytes: > [B@2e8e2e8e > at > org.apache.fop.render.afp.modca.PresentationTextData.addTransparentData > (PresentationTextData.java:213) > at org.apache.fop.render.afp.modca.PresentationTextData.createTextData > (PresentationTextData.java:348) > at > org.apache.fop.render.afp.modca.PresentationTextObject.createTextData > (PresentationTextObject.java:128) > at org.apache.fop.render.afp.modca.AbstractPageObject.createText > (AbstractPageObject.java:221) > at org.apache.fop.render.afp.modca.AFPDataStream.createText > (AFPDataStream.java:353) > at org.apache.fop.render.afp.AFPRenderer.renderText > (AFPRenderer.java:1178) > at org.apache.fop.render.AbstractRenderer.renderInlineArea > (AbstractRenderer.java:617) > at org.apache.fop.render.AbstractRenderer.renderLineArea > (AbstractRenderer.java:606) > at org.apache.fop.render.AbstractRenderer.renderBlocks > (AbstractRenderer.java:532) > at org.apache.fop.render.AbstractRenderer.renderBlock > (AbstractRenderer.java:582) > at org.apache.fop.render.AbstractRenderer.renderBlocks > (AbstractRenderer.java:522) > at org.apache.fop.render.AbstractRenderer.renderBlock > (AbstractRenderer.java:582) > at org.apache.fop.render.AbstractRenderer.renderBlocks > (AbstractRenderer.java:522) > at org.apache.fop.render.AbstractRenderer.renderBlock > (AbstractRenderer.java:582) > at org.apache.fop.render.AbstractRenderer.renderBlocks > (AbstractRenderer.java:522) > at org.apache.fop.render.AbstractRenderer.renderFlow > (AbstractRenderer.java:427) > at org.apache.fop.render.AbstractRenderer.renderMainReference > (AbstractRenderer.java:406) > at org.apache.fop.render.AbstractRenderer.renderBodyRegion > (AbstractRenderer.java:340) > at org.apache.fop.render.afp.AFPRenderer.renderRegionViewport > (AFPRenderer.java:431) > at org.apache.fop.render.AbstractRenderer.renderPageAreas > (AbstractRenderer.java:258) > at org.apache.fop.render.afp.AFPRenderer.renderPage > (AFPRenderer.java:585) > at org.apache.fop.area.RenderPagesModel.addPage > (RenderPagesModel.java:120) > at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage > (PageSequenceLayoutManager.java:424) > at org.apache.fop.layoutmgr.PageSequenceLayoutManager.makeNewPage > (PageSequenceLayoutManager.java:377) > at org.apache.fop.layoutmgr.PageBreaker.handleBreakTrait > (PageBreaker.java:492) > at org.apache.fop.layoutmgr.PageBreaker.startPart(PageBreaker.java:398) > at org.apache.fop.layoutmgr.AbstractBreaker.addAreas > (AbstractBreaker.java:420) > at org.apache.fop.layoutmgr.AbstractBreaker.addAreas > (AbstractBreaker.java:370) > at org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262) > at org.apache.fop.layoutmgr.AbstractBreaker.doLayout > (AbstractBreaker.java:345) > at org.apache.fop.layoutmgr.AbstractBreaker.doLayout > (AbstractBreaker.java:263) > at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout > (PageSequenceLayoutManager.java:144) > at org.apache.fop.area.AreaTreeHandler.endPageSequence > (AreaTreeHandler.java:233) > at org.apache.fop.fo.pagination.PageSequence.endOfNode > (PageSequence.java:145) > at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement > (FOTreeBuilder.java:378) > at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194) > at org.apache.xalan.transformer.TransformerIdentityImpl.endElement > (TransformerIdentityImpl.java:1101) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement > (Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$Fragm
Re: [AFP Renderer] Increased document size
Thank you On 25/11/2015 16:59, sdr...@iptech-group.com wrote: Hi, I already did that a long time ago https://issues.apache.org/jira/browse/FOP-2455 -Message d'origine- De : Chris Bowditch [mailto:bowditch_ch...@hotmail.com] Envoyé : mercredi 25 novembre 2015 17:34 À : fop-dev@xmlgraphics.apache.org Objet : Re: [AFP Renderer] Increased document size Hi Seifeddine, Can you log a bug in JIRA please so this issue is not forgotten? Thanks, Chris On 20/11/2015 14:16, sdr...@iptech-group.com wrote: Hello, I’m using FOP Trunk in production and I noticed that the size of AFP documents has substantially increased compared to FOP 1.1. After some debugging, I found out that the issue is located in method equals inside AFPResourceInfo.java; the current code does not handle the case in which the two fields to be compared have null values. As far as I know, two Java instances of the same type are considered equal if they both have null values. Attached to this email, you find all the files you need to reproduce the afore mentioned issue. Thanks, Seifeddine DRIDI
Re: [AFP Renderer] Increased document size
Hi Seifeddine, Can you log a bug in JIRA please so this issue is not forgotten? Thanks, Chris On 20/11/2015 14:16, sdr...@iptech-group.com wrote: Hello, I’m using FOP Trunk in production and I noticed that the size of AFP documents has substantially increased compared to FOP 1.1. After some debugging, I found out that the issue is located in method equals inside AFPResourceInfo.java; the current code does not handle the case in which the two fields to be compared have null values. As far as I know, two Java instances of the same type are considered equal if they both have null values. Attached to this email, you find all the files you need to reproduce the afore mentioned issue. Thanks, Seifeddine DRIDI
RE: [AFP Renderer] Increased document size
Hi, I already did that a long time ago https://issues.apache.org/jira/browse/FOP-2455 -Message d'origine- De : Chris Bowditch [mailto:bowditch_ch...@hotmail.com] Envoyé : mercredi 25 novembre 2015 17:34 À : fop-dev@xmlgraphics.apache.org Objet : Re: [AFP Renderer] Increased document size Hi Seifeddine, Can you log a bug in JIRA please so this issue is not forgotten? Thanks, Chris On 20/11/2015 14:16, sdr...@iptech-group.com wrote: > > Hello, > > Im using FOP Trunk in production and I noticed that the size of AFP > documents has substantially increased compared to FOP 1.1. After some > debugging, I found out that the issue is located in method equals > inside AFPResourceInfo.java; the current code does not handle the case > in which the two fields to be compared have null values. As far as I > know, two Java instances of the same type are considered equal if they > both have null values. > > Attached to this email, you find all the files you need to reproduce > the afore mentioned issue. > > Thanks, > > Seifeddine DRIDI >
[Bug 45822] [PATCH] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=45822 Mehdi Houshmand med1...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Mehdi Houshmand med1...@gmail.com --- Amended and fixed in trunk@1403643. -- You are receiving this mail because: You are the assignee for the bug.
Re: AFP Renderer
Hi everyone, i just started experimenting with fop to generate afp files, and i would like to know how to go about including an overlay in the output afp file. i'd like to embed ressources as a general rule.
[Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 --- Comment #7 from Luis Bernardo lmpmberna...@gmail.com --- Created attachment 28791 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28791action=edit test *.fo file -- You are receiving this mail because: You are the assignee for the bug.
[Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 --- Comment #8 from Luis Bernardo lmpmberna...@gmail.com --- Created attachment 28792 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28792action=edit test *.afp output -- You are receiving this mail because: You are the assignee for the bug.
DO NOT REPLY [Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 --- Comment #6 from Glenn Adams gad...@apache.org 2012-04-24 05:51:37 UTC --- (In reply to comment #5) Well, because I could append the original FO but that would only show a subset of the problem. The issue is a systemic one, concerning how floating point numbers are handled, or not handled as the case may be in some cases, in the AFP rendering system. Coincidentally r1311638, which I've just applied also addresses one of many symptoms of this problem. But this issue isn't present and wouldn't have been noticed when this problem was initially recognised. If you are demanding an FO; playing with Bug#45822 would be sufficient, but again this is only subset of the symptoms. yes, i'm asking for a minimal input FO, an output PDF, and any relevant console log; -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44024] About AFP renderer Issues when i try to using Aria Fonts which come from Mainframe
https://issues.apache.org/bugzilla/show_bug.cgi?id=44024 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #7 from Glenn Adams gad...@apache.org 2012-04-11 06:17:32 UTC --- change status from ASSIGNED to NEW for consistency -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44490] AFP Renderer: Support for clipping is missing
https://issues.apache.org/bugzilla/show_bug.cgi?id=44490 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #2 from Glenn Adams gad...@apache.org 2012-04-11 06:17:54 UTC --- change status from ASSIGNED to NEW for consistency -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 --- Comment #5 from Mehdi Houshmand med1...@gmail.com 2012-04-10 08:50:44 UTC --- Well, because I could append the original FO but that would only show a subset of the problem. The issue is a systemic one, concerning how floating point numbers are handled, or not handled as the case may be in some cases, in the AFP rendering system. Coincidentally r1311638, which I've just applied also addresses one of many symptoms of this problem. But this issue isn't present and wouldn't have been noticed when this problem was initially recognised. If you are demanding an FO; playing with Bug#45822 would be sufficient, but again this is only subset of the symptoms. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45822] [PATCH] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=45822 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P3 |P2 CC||med1...@gmail.com Summary|AFP Renderer: Minor border |[PATCH] AFP Renderer: Minor |Painting Inconsistencies|border Painting ||Inconsistencies --- Comment #8 from Glenn Adams gl...@skynav.com 2012-04-10 14:49:19 UTC --- mehdi, do you plan to commit the attached patch? thanks, g. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45822] [PATCH] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=45822 --- Comment #9 from Glenn Adams gad...@apache.org 2012-04-11 03:20:28 UTC --- increase priority for bugs with a patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 41995] [PATCH] Barcode Support for AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=41995 Glenn Adams gad...@apache.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #15 from Glenn Adams gad...@apache.org 2012-04-11 03:21:49 UTC --- increase priority for bugs with a patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 Glenn Adams gl...@skynav.com changed: What|Removed |Added Severity|minor |enhancement --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-09 18:55:10 UTC --- please provide a test input FO file and an image of currently produced AFP (for those of us who don't have access to an AFP output device -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |NEEDINFO -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 --- Comment #3 from Mehdi Houshmand med1...@gmail.com 2012-04-09 19:02:49 UTC --- This doesn't require a single FO to demonstrate the point, it was more of a marker for illustrating a flaw in how the AFP rendering works. The AFP painter does a lot of arithmetic and the floating-point - integer conversion happens too early, magnifying rounding errors. As always, this just needs time... Sorry if that isn't very helpful -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 --- Comment #4 from Glenn Adams gl...@skynav.com 2012-04-09 19:15:22 UTC --- (In reply to comment #3) This doesn't require a single FO to demonstrate the point, it was more of a marker for illustrating a flaw in how the AFP rendering works. The AFP painter does a lot of arithmetic and the floating-point - integer conversion happens too early, magnifying rounding errors. As always, this just needs time... Sorry if that isn't very helpful when someone gets around to looking at this, it will be important to have a test file that demonstrates the problem; i don't see why you can't construct such a test file -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45822] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=45822 --- Comment #7 from Glenn Adams gl...@skynav.com 2012-04-07 01:41:23 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44024] About AFP renderer Issues when i try to using Aria Fonts which come from Mainframe
https://issues.apache.org/bugzilla/show_bug.cgi?id=44024 --- Comment #6 from Glenn Adams gl...@skynav.com 2012-04-07 01:43:28 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44490] AFP Renderer: Support for clipping is missing
https://issues.apache.org/bugzilla/show_bug.cgi?id=44490 --- Comment #1 from Glenn Adams gl...@skynav.com 2012-04-07 01:44:46 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45821] AFP Renderer doesn't perform Image Clipping
https://issues.apache.org/bugzilla/show_bug.cgi?id=45821 --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-07 01:44:46 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 41995] [PATCH] Barcode Support for AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Comment #14 from Glenn Adams gl...@skynav.com 2012-04-07 01:44:58 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45822] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=45822 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50098] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44024] About AFP renderer Issues when i try to using Aria Fonts which come from Mainframe
https://issues.apache.org/bugzilla/show_bug.cgi?id=44024 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45821] AFP Renderer doesn't perform Image Clipping
https://issues.apache.org/bugzilla/show_bug.cgi?id=45821 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44490] AFP Renderer: Support for clipping is missing
https://issues.apache.org/bugzilla/show_bug.cgi?id=44490 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 41995] [PATCH] Barcode Support for AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=41995 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 31213] [PATCH] AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=31213 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Glenn Adams gl...@skynav.com 2012-04-01 06:29:10 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48185] [PATCH] CMYK text colors are not rendered properly with the AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=48185 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Glenn Adams gl...@skynav.com 2012-04-01 06:31:13 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #10 from Glenn Adams gl...@skynav.com 2012-04-01 06:32:32 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46369] AFP Renderer Extensions not working
https://issues.apache.org/bugzilla/show_bug.cgi?id=46369 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Glenn Adams gl...@skynav.com 2012-04-01 06:35:35 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #11 from Glenn Adams gl...@skynav.com 2012-04-01 06:39:32 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46867] [PATCH] afp:invoke-medium-map extension doesn't work in the AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=46867 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Glenn Adams gl...@skynav.com 2012-04-01 06:41:43 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46278] AFP Renderer doesn't handle fixed with spaces, e.g. thin space #x2009;
https://issues.apache.org/bugzilla/show_bug.cgi?id=46278 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Glenn Adams gl...@skynav.com 2012-04-01 06:49:07 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43041] [PATCH] AFP Renderer - output resolution control
https://issues.apache.org/bugzilla/show_bug.cgi?id=43041 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Glenn Adams gl...@skynav.com 2012-04-01 06:50:13 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 42956] [PATCH] AFP Renderer - No Operation Extension
https://issues.apache.org/bugzilla/show_bug.cgi?id=42956 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Glenn Adams gl...@skynav.com 2012-04-01 06:51:26 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48290] AFP Renderer: AttributeQualifier Triplet occurs before TLE Value
https://issues.apache.org/bugzilla/show_bug.cgi?id=48290 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-01 06:56:21 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48048] [PATCH] AFP renderer outputs incorrect values for GBAR ( Graphics Begin Area )
https://issues.apache.org/bugzilla/show_bug.cgi?id=48048 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-01 06:56:28 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] [PATCH] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #10 from Glenn Adams gl...@skynav.com 2012-04-01 07:04:07 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48456] AFP Renderer: Underline is incorrectly placed when reference-orientation != 0
https://issues.apache.org/bugzilla/show_bug.cgi?id=48456 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-01 07:08:37 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43439] [PATCH] AFP Renderer - TLE value attribute ignored when using area tree input
https://issues.apache.org/bugzilla/show_bug.cgi?id=43439 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Glenn Adams gl...@skynav.com 2012-04-01 07:09:58 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44489] AFP Renderer: Implement break-out mechanism to supported fixed positioned block-containers
https://issues.apache.org/bugzilla/show_bug.cgi?id=44489 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Glenn Adams gl...@skynav.com 2012-04-01 07:10:13 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46276] Justified text rendered poorly in AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=46276 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-01 13:49:43 UTC --- batch transition to closed remaining pre-FOP1.0 resolved bugs -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49060] [PATCH] File Descriptor leak in AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=49060 Peter Hancock peter.hanc...@gmail.com changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49060] [PATCH] File Descriptor leak in AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=49060 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Vincent Hennebert vhenneb...@gmail.com 2010-12-16 14:18:44 EST --- Applied in rev. 1050104: http://svn.apache.org/viewvc?rev=1050104view=rev Thanks! Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45822] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=45822 --- Comment #6 from Mehdi Houshmand med1...@gmail.com 2010-10-25 06:04:32 EDT --- Created an attachment (id=26209) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26209) proposed patch to fix bug# 45822 Changes made: -Code style improvements (removed magic numbers etc...) -Added JUnit tests for testing borders in PDF, PS and AFP -Architectural improvements (made AFP rendering more like PS/PDF by removing anonymous class) -Made dashed borders more resemble a dash rather than a dot -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 50098] New: AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=50098 Summary: AFP Renderer: Minor border Painting Inconsistencies Product: Fop Version: all Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: med1...@gmail.com Because AFP doesn't use floating point numbers to define x,y co-ordinates (like PDF and PS) there are rounding error that cause border inconsistencies. However, because (I presume) most borders are very thin, they are barely visible. This issue became apparent when fixing Bug# 15368. When using dashed borders, this issue is much more visible since it manifests in non-squared borders i.e. there are white-spaces in corners rather than proper squared borders. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45822] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=45822 --- Comment #4 from Mehdi Houshmand med1...@gmail.com 2010-10-14 07:26:36 EDT --- I've had a look at this issue for dashed borders ONLY. There are some inconsistencies between PS/PDF and AFP as to how these borders are drawn. There are a couple issues here: 1) For dashed borders the dash and the white-space between are the same length. This may seem trivial but doesn't quite look right, and isn't the same behaviour as XEP. (This applies to PS/PDF and AFP.) 2) Since PS/PDF have almost identical code (duplicated) for this function (and other methods), there really should be proper centralisation to prevent duplication. Since both PDF and PS classes inherit from BorderPainter.java, if we create a class to sandwich in between this inheritance stack it could contain utility methods such as this. So it will be: BorderPainter-AdobeBorderPainter then either PS/PDF-BorderPainter. I'll make a slight change how both of them draw the borders (the change will make them behave the same). Currently the ratio between dash-whitespace is 1:1, this is implicitly a magic number. I'll make a variable called DASHED_BORDER_SPACE_RATIO that make this configurable, it will also ensure that the output is the same between the various formats. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45822] AFP Renderer: Minor border Painting Inconsistencies
https://issues.apache.org/bugzilla/show_bug.cgi?id=45822 --- Comment #5 from Mehdi Houshmand med1...@gmail.com 2010-10-14 08:30:34 EDT --- After a little further investigation, it appears in this particular instance the middle class AdobeBorderPainter is unnecessary since AFP also needs the same function to define the length of the dash. So this will be put into BorderPainter, so as all classes can inherit this method. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49060] [PATCH] File Descriptor leak in AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=49060 --- Comment #2 from Chris Bowditch bowditch_ch...@hotmail.com 2010-04-08 11:09:48 UTC --- For the benefit of others who are wondering what the purpose of this patch is; If the file is not closed before it is deleted then on some operatin systems, e.g. AIX, an open file handle is left. After creating several thousand AFP File you soon find that the Operating system has exhausted all its Open File Handles. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49060] New: File Descriptor leak in AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=49060 Summary: File Descriptor leak in AFP renderer Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: peter.hanc...@gmail.com When rendering AFP, FOP creates a temp file with name beginning with AFPDataStream_. This file is deleted during the 'document end' cleanup, however a the outputstream to the file is not currently closed first. The attached patch addresses this. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49060] File Descriptor leak in AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=49060 --- Comment #1 from Peter Hancock peter.hanc...@gmail.com 2010-04-07 08:21:59 UTC --- Created an attachment (id=25238) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25238) patch of fix -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49060] [PATCH] File Descriptor leak in AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=49060 Peter Hancock peter.hanc...@gmail.com changed: What|Removed |Added Summary|File Descriptor leak in AFP |[PATCH] File Descriptor |renderer|leak in AFP renderer -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #9 from Peter Hancock peter.hanc...@gmail.com 2010-01-22 01:40:08 UTC --- (In reply to comment #8) I've applied your patches (documentation, too): http://svn.apache.org/viewvc?rev=901793view=rev Thanks for the patch! It is a pleasure to be able to contribute! As for the Unicode blocks we use to determine whether we have to use the em space instead of a normal space for characters which don't provide individual metrics, I think we don't have all that we need, yet. I've stumbled over http://unicode.org/reports/tr11/ which mentions fullwidth and halfwidth characters. However, I could not yet find the location where the information for the destinction for each character can be found. With the font we tested with we got away since the em space equals the normal space increment. For fonts that have western characters, we may not get away with the current set of Unicode Blocks. Not knowing enough about eastern languages is a real impediment for me here. Perhaps we should make the fallback strategy external from where it is applied and perhaps configurable. Maybe the 'char = fallback char' mapping can be externalized in a similiar way to that of the base-14 font metrics. Commiting improvements to this mapping - or even supporting customization of - would then be decoupled from the /src/java codebase. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #5 from Peter Hancock peter.hanc...@gmail.com 2010-01-21 07:35:10 UTC --- Created an attachment (id=24877) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24877) xdocs -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #6 from Peter Hancock peter.hanc...@gmail.com 2010-01-21 07:46:26 UTC --- The attachment 'xdocs' is the corresponding documentation update for the webserver -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #7 from Jeremias Maerki jerem...@apache.org 2010-01-21 08:01:33 UTC --- Thanks for your feedback. We're in agreement, it seems. (In reply to comment #4) snip/ I agree with all of your suggestions. Before you go ahead and commit I wonder how easy it is to configure fop to not embed the font. Is much dev work required do you think? In http://xmlgraphics.apache.org/fop/trunk/fonts.html it is claimed that not supplying an embed-url attribute directs fop not to embed the font, but this is not so, and in fact, fop never seems to have a chance at setting the embeddable flag on an AFP font. When AFPRendererConfigurator constructs the font instance it could set the flag then based on an attribute, but what other information is needed? When I manually set embeddable to false the rendered AFP only declares the font resource and the code page in the MCF structured field. I have not tried printing yet (Our afp printer is playing up for me today) or checked the spec to see if this is ok. If you happen to know that it should work we could perhaps add a boolean-like attribute to the font attribute (respected when type=CIDKeyed or all AFP?) and call AFPFont.setEmbeddable() upon creation (or pass a constructor arg). Otherwise I guess this would be a future unit work. AFP Font referencing should work via the mechanism described under: http://xmlgraphics.apache.org/fop/trunk/fonts.html#embedding (referenced-fonts) At least, I've tested that with outline and bitmap fonts at some point. However, we need to see what happens in the case of CIDKeyed because of the MapCodedFont object. I'll do a test. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 Jeremias Maerki jerem...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Jeremias Maerki jerem...@apache.org 2010-01-21 09:48:08 UTC --- I've applied your patches (documentation, too): http://svn.apache.org/viewvc?rev=901793view=rev Thanks for the patch! I've tested with referenced-fonts and that seems to do what I expect. The MapCodedFont gets generated and should work if the font and the codepage are installed on the target platform. Lacking a full AFP environment I cannot easily test that to the very end. The only thing I noticed is that the viewers don't recognize that the font is double-byte if the fonts are not embedded and not available to the editor. I've added a TODO in MapCodedFont with an idea which might help. In case you look into that class you may want to take a look. As for the Unicode blocks we use to determine whether we have to use the em space instead of a normal space for characters which don't provide individual metrics, I think we don't have all that we need, yet. I've stumbled over http://unicode.org/reports/tr11/ which mentions fullwidth and halfwidth characters. However, I could not yet find the location where the information for the destinction for each character can be found. With the font we tested with we got away since the em space equals the normal space increment. For fonts that have western characters, we may not get away with the current set of Unicode Blocks. Not knowing enough about eastern languages is a real impediment for me here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #3 from Jeremias Maerki jerem...@apache.org 2010-01-20 07:30:29 UTC --- Peter, I've taken a peek at your code. Eclipse had a bit of trouble applying the patch because you renamed AFPFontReader to CharacterSetBuilder, but that was not insurmountable. From the functionality POV I guess this works fine. At least I get nicely formatted Japanese text which seems to be consistent with PDF output generated with Arial Unicode MS. You've asked me off-list if it is correct to get the em space width from the FNO field rather than the FNC field. But I don't see any information on the em space in the FNC field. At any rate, FNO is the right place to get this from IMO. While going through your changes I wondered if it would not have made sense to extract the em space in every case, not just in the double-byte case. That could have reduced the code duplication a bit that is caused by org.apache.fop.afp.fonts.CharacterSetBuilder.DoubleByteLoader. At least the processFontOrientation() method looks like unnecessary code duplication to me. Furthermore, it is a bit strange that you call this unitPerEm in CharacterSetOrientation what is actually the em space increment. Maybe that's what you confused in FNC with. There's a unit per em there but that has a different purpose. I'm wondering if you would agree that using Type 0 (or CIDKeyed) instead of double-byte is a more accurate choice for the font type in the user configuration. Do you think that the fallback character business in the configuration is really necessary? I fear that this is too complicated for users. I don't quite see what it would help. Can you explain why you added this? A few observations while looking into this (not related to your work): - Some of the AFP viewers to quite some time to display the files with the embedded Japanese font, the Papyrus Client being the exception. Maybe that is just so. At least there doesn't seem to be anything technically wrong. - The restriction of the font and codepage names to exactly 8 characters is something we should relax eventually (by creating actual FullyQualifiedNameTriplet instances in MapCodedFont). Probably a remainder from the times where the triplets were not encapsulated in classes. At least there is no such restriction in the AFP specs. If you don't have anything else that you need to address with this patch, I could commit it later this week. I'd like your feedback on my comments above before I do that. I could handle the few changes myself. Since I've already made some local, cosmetic changes locally, that would save my applying the patch a second time. However, if you could update the documentation for the website once we've finalized the above, that'd be appreciated. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #4 from Peter Hancock peter.hanc...@gmail.com 2010-01-20 08:55:17 UTC --- (In reply to comment #3) Peter, I've taken a peek at your code. Thanks for reviewing the patch so quicky! Eclipse had a bit of trouble applying the patch because you renamed AFPFontReader to CharacterSetBuilder, but that was not insurmountable. Sorry about that! You've asked me off-list if it is correct to get the em space width from the FNO field rather than the FNC field. But I don't see any information on the em space in the FNC field. At any rate, FNO is the right place to get this from IMO. Furthermore, it is a bit strange that you call this unitPerEm in CharacterSetOrientation what is actually the em space increment. Maybe that's what you confused in FNC with. There's a unit per em there but that has a different purpose. I was unsure if there was a distinction between 'em space increment' and 'units per em' - now I know. While going through your changes I wondered if it would not have made sense to extract the em space in every case, not just in the double-byte case. That could have reduced the code duplication a bit that is caused by org.apache.fop.afp.fonts.CharacterSetBuilder.DoubleByteLoader. At least the processFontOrientation() method looks like unnecessary code duplication to me. That makes sense - we can remove the now redundant CharacterSetOrientation(int) constructor as well. I'm wondering if you would agree that using Type 0 (or CIDKeyed) instead of double-byte is a more accurate choice for the font type in the user configuration. CIDKeyed then? Do you think that the fallback character business in the configuration is really necessary? I fear that this is too complicated for users. I don't quite see what it would help. Can you explain why you added this? using a fallback character was my first approach and the em space, as recommended by yourself, my second. In retrospect I now totally agree that the fallback character is probably useless and certainly reduces usability. - The restriction of the font and codepage names to exactly 8 characters is something we should relax eventually (by creating actual FullyQualifiedNameTriplet instances in MapCodedFont). Probably a remainder from the times where the triplets were not encapsulated in classes. At least there is no such restriction in the AFP specs. I am looking at this now. I thought it may have been an AFP restriction since I seemed to get a badly formed AFP when I forced through a name of length 6. This will have to be resolved at a later time I guess. If you don't have anything else that you need to address with this patch, I could commit it later this week. I'd like your feedback on my comments above before I do that. I could handle the few changes myself. Since I've already made some local, cosmetic changes locally, that would save my applying the patch a second time. I agree with all of your suggestions. Before you go ahead and commit I wonder how easy it is to configure fop to not embed the font. Is much dev work required do you think? In http://xmlgraphics.apache.org/fop/trunk/fonts.html it is claimed that not supplying an embed-url attribute directs fop not to embed the font, but this is not so, and in fact, fop never seems to have a chance at setting the embeddable flag on an AFP font. When AFPRendererConfigurator constructs the font instance it could set the flag then based on an attribute, but what other information is needed? When I manually set embeddable to false the rendered AFP only declares the font resource and the code page in the MCF structured field. I have not tried printing yet (Our afp printer is playing up for me today) or checked the spec to see if this is ok. If you happen to know that it should work we could perhaps add a boolean-like attribute to the font attribute (respected when type=CIDKeyed or all AFP?) and call AFPFont.setEmbeddable() upon creation (or pass a constructor arg). Otherwise I guess this would be a future unit work. However, if you could update the documentation for the website once we've finalized the above, that'd be appreciated. I will attach this as a second patch to this bug. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 Peter Hancock peter.hanc...@gmail.com changed: What|Removed |Added Attachment #24854|0 |1 is obsolete|| --- Comment #2 from Peter Hancock peter.hanc...@gmail.com 2010-01-19 02:59:38 UTC --- Created an attachment (id=24857) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24857) patch of implementation -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] New: Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 Summary: Implementation of support for double-byte fonts by AFP renderer. Product: Fop Version: 1.0dev Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: fonts AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: peter.hanc...@gmail.com The requirment is detailed here http://wiki.apache.org/xmlgraphics-fop/AFPFonts -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48567] Implementation of support for double-byte fonts by AFP renderer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48567 --- Comment #1 from Peter Hancock peter.hanc...@gmail.com 2010-01-18 07:31:51 UTC --- Created an attachment (id=24854) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24854) Proposed patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] [PATCH] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 Peter Hancock peter.hanc...@gmail.com changed: What|Removed |Added Attachment #24725|0 |1 is obsolete|| --- Comment #7 from Peter Hancock peter.hanc...@gmail.com 2009-12-30 02:35:55 UTC --- Created an attachment (id=24779) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24779) patch of proposed fix -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] [PATCH] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added Summary|afp renderer does not |[PATCH] afp renderer does |respect image color |not respect image color |settings for svg|settings for svg -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48456] New: AFP Renderer: Underline is incorrectly placed when reference-orientation != 0
https://issues.apache.org/bugzilla/show_bug.cgi?id=48456 Summary: AFP Renderer: Underline is incorrectly placed when reference-orientation != 0 Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: bowditch_ch...@hotmail.com Created an attachment (id=24769) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24769) Sample FO to demo the bug When text-align=center and text-decoration=underline are used in combination on a rotated page the underline appears before the actual text. Sample FO attached that demonstrates the issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48456] AFP Renderer: Underline is incorrectly placed when reference-orientation != 0
https://issues.apache.org/bugzilla/show_bug.cgi?id=48456 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Chris Bowditch bowditch_ch...@hotmail.com 2009-12-29 07:17:18 UTC --- committed fix in revision 894416 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #6 from Peter Hancock peter.hanc...@gmail.com 2009-12-17 06:08:15 UTC --- Created an attachment (id=24725) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24725) patch of proposed fix Implements a grayscale color conversion utility that is used when setting the color value on the GOCA stream whilst rendering SVG to AFP in grayscale. WARNING This patch will depend upon an update to xmlgraphics-commons that includes the patch defined in Attachment #24724 of bug 48405 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #5 from Chris Bowditch bowditch_ch...@hotmail.com 2009-11-26 00:24:13 UTC --- Jeremias, our local B+W AFP Printer handles this and converts the colour SVG to B+W on the fly. However, one of our customers with B+W Printers said the AFP failed to print due to the colour in the GOCA objects. We believe this is a bug and should be fixed. Thanks, Chris -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48290] New: AFP Renderer: AttributeQualifier Triplet occurs before TLE Value
https://issues.apache.org/bugzilla/show_bug.cgi?id=48290 Summary: AFP Renderer: AttributeQualifier Triplet occurs before TLE Value Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: bowditch_ch...@hotmail.com Order of AttributeQualifier and Value Triplet were switched for TLE by following commit: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-commits/200910.mbox/%3c20091022132054.a5c7b2388...@eris.apache.org%3e This means TLE structure no longer conforms to AFP specification: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3M5M00/5.82.2?SHELF=APSBK320DT=20010307105730 The fix is fairly straight forward and follows shortly. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48290] AFP Renderer: AttributeQualifier Triplet occurs before TLE Value
https://issues.apache.org/bugzilla/show_bug.cgi?id=48290 --- Comment #1 from Chris Bowditch bowditch_ch...@hotmail.com 2009-11-26 03:23:48 UTC --- bug fix committed in revision 884526 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48290] AFP Renderer: AttributeQualifier Triplet occurs before TLE Value
https://issues.apache.org/bugzilla/show_bug.cgi?id=48290 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48048] [PATCH] AFP renderer outputs incorrect values for GBAR ( Graphics Begin Area )
https://issues.apache.org/bugzilla/show_bug.cgi?id=48048 Jeremias Maerki jerem...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremias Maerki jerem...@apache.org 2009-11-25 07:05:24 UTC --- Thanks for spotting this and sending a patch! It is applied now: http://svn.apache.org/viewvc?rev=884129view=rev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #3 from Venkat Reddy vanukuri.ven...@googlemail.com 2009-11-25 07:39:33 UTC --- I have checked this bug with FOP 0.95 version initially, but later understood that FOPTrunk is having this problem instead of FOP 0.95. The Bitmaps are rendering according the image mode configuration (either b+w or color) in both FOP 0.95 and FOPTrunk. The problem is with SVGs, the image mode is not respected in case of SVGs in FOPTrunk. So, It is a valid bug in FOPTrunk -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #4 from Jeremias Maerki jerem...@apache.org 2009-11-25 12:10:42 UTC --- Peter, I understand the bug report (all colors should ideally be transformed to grayscales when AFP output is configured to 8bit grayscales), but what I'm curious about is whether the current behaviour actually caused a problem on your side. So far I have no reports that the colors cause any problems. The systems seem to be able to handle them correctly, even on a monochrome system. Only the bitmap images are currently reduced in color depth most of all because that has a huge impact on file size. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #1 from Venkat Reddy vanukuri.ven...@googlemail.com 2009-11-24 08:58:35 UTC --- Hi Peter, There is no bug with this functionality. You can have a look at the FO file that I have used... 1. Update the configuration file for the image mode (b+w or color) 2. Run the following command from the command prompt... C:\mywork\FOP\fop-0.95 fop -c C:\fop.xconf -fo C:\mywork\JavaXSLTSamples\XSLFOSamples\hello.fo -afp C:\mywork\JavaXSLTSamples\XSLFOSamples\hellotest.afp According to the mode, the image will be rendered with color or black and white... Thanks, Venkat. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #2 from Venkat Reddy vanukuri.ven...@googlemail.com 2009-11-24 08:59:36 UTC --- Created an attachment (id=24606) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24606) Input FO file -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48237] New: afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 Summary: afp renderer does not respect image color settings for svg Product: Fop Version: 0.95 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: peter.hanc...@gmail.com Created an attachment (id=24564) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24564) sample fo and afp Color svg, declared both inline (fo:instream-foreign-object) and external (fo:external-graphic), are not rendered to afp as black and white under the following fop.xconf configuration: renderer mime=application/x-afp images mode=b+w bits-per-pixel=8/ .. /renderer The attached includes sample xsl-fo and afp output to demonstrate. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48185] New: [PATCH] CMYK text colors are not rendered properly with the AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=48185 Summary: [PATCH] CMYK text colors are not rendered properly with the AFP renderer Product: Fop Version: all Platform: PC OS/Version: Windows Vista Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: vanukuri.ven...@googlemail.com CC: vanukuri.ven...@googlemail.com Depends on: 48167 Created an attachment (id=24524) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24524) CMYK text color patch When trying to use uncalibrated CMYK text colors like... fo:block color=rgb-icc(0, 255, 255, #CMYK, 1, 0, 0, 0)CYAN TEXT/fo:block fo:block color=rgb-icc(0, 255, 0, #CMYK, 1, 0, 1, 0)GREEN TEXT/fo:block These are renderered as blank lines in the AFP output. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48185] [PATCH] CMYK text colors are not rendered properly with the AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=48185 --- Comment #1 from Venkat Reddy vanukuri.ven...@googlemail.com 2009-11-12 06:57:25 UTC --- Created an attachment (id=24525) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24525) CMYK Text color input document -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48185] [PATCH] CMYK text colors are not rendered properly with the AFP renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=48185 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added AssignedTo|fop-...@xmlgraphics.apache. |vhenneb...@gmail.com |org | --- Comment #2 from Chris Bowditch bowditch_ch...@hotmail.com 2009-11-12 07:55:31 UTC --- Hi Vincent, please can you process this patch? Thanks, Chris -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48048] New: [PATCH] AFP renderer outputs incorrect values for GBAR ( Graphics Begin Area )
https://issues.apache.org/bugzilla/show_bug.cgi?id=48048 Summary: [PATCH] AFP renderer outputs incorrect values for GBAR ( Graphics Begin Area ) Product: Fop Version: all Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: d...@dwink.net Created an attachment (id=24414) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24414) Patch Per the AFP GOCA specification at http://www.outputlinks.com/SpecialInterest/AFPColorConsortium/ibm_goca_ha3n1r01.pdf , the GBAR order should output two bytes: 0x68 (the order code) and a 1-byte set of bit flags. The current FOP implementation interprets the specification in a least-significant-bit fashion: bit 0 is the least-valued bit, and bit 1 is the next-least-valued bit to the left. This makes the valid values (in hex) either 0x01 or 0x03, and the constants are set to generate these values. However, according to the preface to the specification (page iv, or #6 in the PDF) , bits are specified with bit 0 meaning the most significant bit. Interpreting the specification this way makes the valid values for the second byte either 0x80 or 0xC0. The attached patch updates the Graphics Begin Area code to use the proper constant values. Many AFP viewers and printers ignore the bit field entirely, but those that interpret it strictly reject FOP's generated AFP output. To reproduce: Render an FO containing an SVG into AFP format; then examine the output using an AFP interpreter or hex editor. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 Adrian Cumiskey d...@cumiskey.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Adrian Cumiskey d...@cumiskey.com 2009-10-22 06:21:17 UTC --- This bug was originally misdiagnosed. The TLE values were not being truncated as Chris suggested. As I see it, Harald is correct in his description of the issue. Triplets are a maximum of 254 bytes, therefore Attribute Value Triplets can legally hold a maximum of 250 bytes including the header. So the solution as I see it is that the value must be truncated to 250 characters and a warning provided. I have now resolved this in trunk. Adrian. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 --- Comment #10 from Chris Bowditch bowditch_ch...@hotmail.com 2009-10-22 08:01:43 UTC --- Thanks for the fix Adrian. You are correct that my original report wasn't technically accurate but then I didn't have time to look into the details. Still I am happy with the final resolution. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 --- Comment #8 from Venkat Reddy vanukuri.ven...@googlemail.com 2009-10-20 07:12:49 UTC --- It is better to warn the user atleast when used more than 254 bytes for the TLE value, so that he will get an idea about the truncation happened because of lengthy input value. (In reply to comment #7) secondly i tried it with a small testcase holding 10 TLEs with increasing value length: input: afp:tag-logical-element name=name250 value= .../ afp:tag-logical-element name=name251 value= ...1/ afp:tag-logical-element name=name252 value= ...12/ afp:tag-logical-element name=name253 value= ...123/ afp:tag-logical-element name=name254 value= ...1234/ afp:tag-logical-element name=name255 value= ...12345/ afp:tag-logical-element name=name256 value= ...123456/ afp:tag-logical-element name=name257 value= ...1234567/ afp:tag-logical-element name=name258 value= ...12345678/ afp:tag-logical-element name=name259 value= ...123456789/ the first failure will be for TLE with name name253 and it just looks like a overflow. $ grep T36 testcase001.dmp T36: Attribute Value [251] T36: Attribute Value [252] T36: Attribute Value [253] T36: Attribute Value [0] T36: Attribute Value [0] T36: Attribute Value [0] T36: Attribute Value [1] T36: Attribute Value [2] T36: Attribute Value [3] T36: Attribute Value [4] in my opinion the best will be to split up such problem TLEs and write out several TLE structed fields with incremented triplet 0x80 'Sequence Number'. Unfortunately i did no java debugging for the last few years i have first to setup eclipse or IntelliJ on my computer. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 --- Comment #4 from Harald G. Henne afput...@web.de 2009-10-19 03:45:36 UTC --- In the world of AFP a TLE is normally written out by the two triplets 0x02 and 0x36. The max lenght of any triplet is 254 bytes and this limit is the reason for the mentioned truncation. On the other side it is quite common to remove any trailing blanks of TLE values. I checked out the current trunk and the produced afp is not valid. my afp dump: 0xD3A090: TLE Tag Logical Element [322] (Offset 34) T02: Fully Qualified Name [6] FQNType:0x0B (Attribute GID) FQNFmt: 0x00 (Character string) FQName: JES0 T36: Attribute Value [46] Reserved: 00 00 AttVal: JES00927200 90INITIATION REGULAR (hex:) D1 C5 E2 F0 F0 F9 F2 F7 F2 F0 F0 40 40 40 40 40 40 40 F9 F0 C9 D5 C9 E3 C9 C1 E3 C9 D6 D5 40 40 40 40 40 D9 C5 C7 E4 D3 C1 D9 40 40 T40: - unknown triplet - [62] 40 40 40 40 F6 F9 F0 60 F5 F0 F1 40 40 40 F3 F9 F0 60 40 F1 F2 F7 40 40 40 40 F2 F7 F2 F0 F0 F0 F2 F1 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 T40: - unknown triplet - [62] 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 T40: - unknown triplet - [62] 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 T40: - unknown triplet - [62] 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 T80: Attribute Qualifier [8] SeqNum: 0x (0) LevNum: 0x0001 (1) 0xD3A090: TLE Tag Logical Element [340] (Offset 365) T02: Fully Qualified Name [6] FQNType:0x0B (Attribute GID) FQNFmt: 0x00 (Character string) FQName: ACC1 T36: Attribute Value [64] Reserved: 00 00 AttVal: ACC137431646900690-501EN (hex:) C1 C3 C3 F1 F3 F7 F4 F3 F1 F6 F4 F6 F9 F0 F0 F0 F0 F0 F0 40 40 40 40 F6 F9 F0 60 F5 F0 F1 40 40 40 40 C5 D5 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 T40: - unknown triplet - [62] 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 F0 F0 40 40 40 40 40 40 40 40 T40: - unknown triplet - [62] 40 40 40 40 40 40 F0 F0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 T40: - unknown triplet - [62] 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 T40: - unknown triplet - [62] 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 T80: Attribute Qualifier [8] SeqNum: 0x0001 (1) LevNum: 0x0001 (1) 0xD3A090: TLE Tag Logical Element [124] (Offset 714) T02: Fully Qualified Name [6] FQNType:0x0B (Attribute GID) FQNFmt: 0x00 (Character string) FQName: ADR1 T36: Attribute Value [104] Reserved: 00 00 AttVal: ADR1MICKEY MOUSE
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 --- Comment #7 from Harald G. Henne afput...@web.de 2009-10-19 05:00:16 UTC --- secondly i tried it with a small testcase holding 10 TLEs with increasing value length: input: afp:tag-logical-element name=name250 value= .../ afp:tag-logical-element name=name251 value= ...1/ afp:tag-logical-element name=name252 value= ...12/ afp:tag-logical-element name=name253 value= ...123/ afp:tag-logical-element name=name254 value= ...1234/ afp:tag-logical-element name=name255 value= ...12345/ afp:tag-logical-element name=name256 value= ...123456/ afp:tag-logical-element name=name257 value= ...1234567/ afp:tag-logical-element name=name258 value= ...12345678/ afp:tag-logical-element name=name259 value= ...123456789/ the first failure will be for TLE with name name253 and it just looks like a overflow. $ grep T36 testcase001.dmp T36: Attribute Value [251] T36: Attribute Value [252] T36: Attribute Value [253] T36: Attribute Value [0] T36: Attribute Value [0] T36: Attribute Value [0] T36: Attribute Value [1] T36: Attribute Value [2] T36: Attribute Value [3] T36: Attribute Value [4] in my opinion the best will be to split up such problem TLEs and write out several TLE structed fields with incremented triplet 0x80 'Sequence Number'. Unfortunately i did no java debugging for the last few years i have first to setup eclipse or IntelliJ on my computer. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 --- Comment #1 from Venkat Reddy vanukuri.ven...@googlemail.com 2009-10-07 03:18:28 PDT --- Hi Chris, Can you please attach the XSL-FO file you used for this test case? Thanks, Venkat. (In reply to comment #0) 2 of the longer TLE Values in attached XSL-FO File are truncated by AFP Renderer. Apecifically the TLEs with name JES0 and ACC1 are truncated using a recent revision of FOP trunk. I can't see any specific limit for TLE records in the MO:DCA specification. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 --- Comment #2 from Chris Bowditch bowditch_ch...@hotmail.com 2009-10-07 06:47:45 PDT --- Created an attachment (id=24355) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24355) XSL-FO to reproduce the problem -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 --- Comment #3 from Chris Bowditch bowditch_ch...@hotmail.com 2009-10-07 06:48:42 PDT --- Sorry - I seem to be having some problems with Bugzilla and attachments. I did attach the XSL-FO File when I logged the bug but Bugzilla had a problem with the content type and didn't tell me. Grmbl -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 47941] New: AFP Renderer Truncates TLE Values
https://issues.apache.org/bugzilla/show_bug.cgi?id=47941 Summary: AFP Renderer Truncates TLE Values Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: bowditch_ch...@hotmail.com 2 of the longer TLE Values in attached XSL-FO File are truncated by AFP Renderer. Apecifically the TLEs with name JES0 and ACC1 are truncated using a recent revision of FOP trunk. I can't see any specific limit for TLE records in the MO:DCA specification. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46867] [PATCH] afp:invoke-medium-map extension doesn't work in the AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=46867 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Chris Bowditch bowditch_ch...@hotmail.com 2009-03-21 01:48:37 PST --- No feedback received during the last few days so I assume patch is ok. Patch applied in revision 756894 ( https://svn.apache.org/viewcvs.cgi?view=revrev=756894 ) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46867] New: afp:invoke-medium-map extension doesn't work in the AFP Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=46867 Summary: afp:invoke-medium-map extension doesn't work in the AFP Renderer Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P1 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: bowditch_ch...@hotmail.com This bug report is related to revision 749251 ( https://svn.apache.org/viewcvs.cgi?view=revrev=749251 ). When the attached FO is first rendered to Area Tree XML and then the Area Trea parsed to generate AFP with prefer-renderer option set to true in fop.xconf the following exception occurs: SEVERE: Exception java.lang.NullPointerException at org.apache.fop.afp.modca.TagLogicalElement.writeToStream(TagLogicalEl ement.java:86) at org.apache.fop.afp.modca.AbstractResourceGroupContainer.writeObjects( AbstractResourceGroupContainer.java:150) at org.apache.fop.afp.modca.PageGroup.writeContent(PageGroup.java:91) at org.apache.fop.afp.modca.AbstractResourceGroupContainer.writeToStream (AbstractResourceGroupContainer.java:135) at org.apache.fop.afp.modca.AbstractResourceGroupContainer.writeObjects( AbstractResourceGroupContainer.java:150) at org.apache.fop.afp.modca.AbstractPageObject.writeContent(AbstractPage Object.java:320) at org.apache.fop.afp.modca.AbstractResourceEnvironmentGroupContainer.wr iteContent(AbstractResourceEnvironmentGroupContainer.java:82) at org.apache.fop.afp.modca.AbstractResourceGroupContainer.writeToStream (AbstractResourceGroupContainer.java:135) The Area Tree XML looks fine, I can see the invoke-medium-map extension element. It looks like the Renderer is treating the invoke-medium-map extension as a TLE. Hopefully I will be able to add a patch soon -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.