[jira] [Updated] (FOP-3058) AFP-Renderer does not honour fill-rule 'nonzero' of SVG path.

2022-03-07 Thread JYR (Jira)


 [ 
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.

2022-03-07 Thread JYR (Jira)


 [ 
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.

2022-03-07 Thread JYR (Jira)


 [ 
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.

2022-03-07 Thread JYR (Jira)
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

2017-02-22 Thread simon steiner (JIRA)

 [ 
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

2015-11-26 Thread Chris Bowditch


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

2015-11-25 Thread Chris Bowditch

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

2015-11-25 Thread sdridi
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
>




[Bug 45822] [PATCH] AFP Renderer: Minor border Painting Inconsistencies

2012-10-30 Thread bugzilla
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

2012-07-12 Thread Imad Bougataya
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

2012-05-16 Thread bugzilla
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

2012-05-16 Thread bugzilla
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

2012-04-23 Thread bugzilla
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

2012-04-11 Thread bugzilla
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

2012-04-11 Thread bugzilla
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

2012-04-10 Thread bugzilla
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

2012-04-10 Thread bugzilla
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

2012-04-10 Thread bugzilla
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

2012-04-10 Thread bugzilla
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

2012-04-09 Thread bugzilla
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

2012-04-09 Thread bugzilla
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

2012-04-09 Thread bugzilla
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

2012-04-09 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-06 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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.

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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;

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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 )

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-04-01 Thread bugzilla
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

2012-03-28 Thread bugzilla
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

2010-12-16 Thread bugzilla
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

2010-10-25 Thread bugzilla
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

2010-10-15 Thread bugzilla
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

2010-10-14 Thread bugzilla
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

2010-10-14 Thread bugzilla
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

2010-04-08 Thread bugzilla
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

2010-04-07 Thread bugzilla
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

2010-04-07 Thread bugzilla
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

2010-04-07 Thread bugzilla
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.

2010-01-22 Thread bugzilla
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.

2010-01-21 Thread bugzilla
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.

2010-01-21 Thread bugzilla
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.

2010-01-21 Thread bugzilla
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.

2010-01-21 Thread bugzilla
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.

2010-01-20 Thread bugzilla
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.

2010-01-20 Thread bugzilla
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.

2010-01-19 Thread bugzilla
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.

2010-01-18 Thread bugzilla
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.

2010-01-18 Thread bugzilla
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

2009-12-30 Thread bugzilla
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

2009-12-29 Thread bugzilla
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

2009-12-29 Thread bugzilla
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

2009-12-29 Thread bugzilla
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

2009-12-17 Thread bugzilla
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

2009-11-26 Thread bugzilla
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

2009-11-26 Thread bugzilla
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

2009-11-26 Thread bugzilla
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

2009-11-26 Thread bugzilla
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 )

2009-11-25 Thread bugzilla
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

2009-11-25 Thread bugzilla
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

2009-11-25 Thread bugzilla
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

2009-11-24 Thread bugzilla
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

2009-11-24 Thread bugzilla
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

2009-11-19 Thread bugzilla
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

2009-11-12 Thread bugzilla
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

2009-11-12 Thread bugzilla
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

2009-11-12 Thread bugzilla
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 )

2009-10-24 Thread bugzilla
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

2009-10-22 Thread bugzilla
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

2009-10-22 Thread bugzilla
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

2009-10-20 Thread bugzilla
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

2009-10-19 Thread bugzilla
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

2009-10-19 Thread bugzilla
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

2009-10-07 Thread bugzilla
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

2009-10-07 Thread bugzilla
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

2009-10-07 Thread bugzilla
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

2009-10-06 Thread bugzilla
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

2009-03-21 Thread bugzilla
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

2009-03-17 Thread bugzilla
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.


  1   2   >