Bug 48237 - [PATCH] afp renderer does not respect image color settings for svg
Summary: [PATCH] afp renderer does not respect image color settings for svg
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: 0.95
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: fop-dev
Depends on: 48405
  Show dependency tree
Reported: 2009-11-19 06:31 UTC by Peter Hancock
Modified: 2012-04-01 07:04 UTC (History)
0 users

sample fo and afp (2.46 KB, application/zip)
2009-11-19 06:31 UTC, Peter Hancock
Input FO file (661 bytes, text/plain)
2009-11-24 08:59 UTC, Venkat Reddy
patch of proposed fix (20.57 KB, patch)
2009-12-17 06:08 UTC, Peter Hancock
Details | Diff
patch of proposed fix (24.89 KB, patch)
2009-12-30 02:35 UTC, Peter Hancock
Details | Diff
patch of proposed fix (32.34 KB, patch)
2010-01-08 02:34 UTC, Peter Hancock
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Hancock 2009-11-19 06:31:18 UTC
Created attachment 24564 [details]
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"/>

The attached includes sample xsl-fo and afp output to demonstrate.
Comment 1 Venkat Reddy 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...

Comment 2 Venkat Reddy 2009-11-24 08:59:36 UTC
Created attachment 24606 [details]
Input FO file
Comment 3 Venkat Reddy 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....
Comment 4 Jeremias Maerki 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.
Comment 5 Chris Bowditch 2009-11-26 00:24:13 UTC

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.


Comment 6 Peter Hancock 2009-12-17 06:08:15 UTC
Created attachment 24725 [details]
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.

This patch will depend upon an update to xmlgraphics-commons that includes the patch defined in Attachment #24724 [details]  of bug 48405
Comment 7 Peter Hancock 2009-12-30 02:35:55 UTC
Created attachment 24779 [details]
patch of proposed fix
Comment 8 Peter Hancock 2010-01-08 02:34:14 UTC
Created attachment 24818 [details]
patch of proposed fix

Updated patch.

Moved some files to xmlgraphics commons
Comment 9 Chris Bowditch 2010-01-08 06:53:36 UTC
Thanks for the patch Peter. Committed to SVN in revision 897221
Comment 10 Glenn Adams 2012-04-01 07:04:07 UTC
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed