You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Peter Hancock <pe...@gmail.com> on 2009/11/24 15:30:30 UTC
Thoughts on Bug 48237
At present FOP does not respect an image color setting of 'b+w' when
rendering svg to afp (see Bug 48237)
According to the AFP spec (
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303)
it does not seem possible to specify a grayscale color space, and so my
question is how should colour be controlled?
Since AFPGraphics2D is responsible for setting the color on the MODCA
GraphicsObject prior to calling drawing methods, would a sensible fix to
the problem be to convert the awt.Color before calling this setter?
Any thoughts would be most welcome,
Pete
Re: Thoughts on Bug 48237
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Peter,
I think that's an excellent idea. However, if ColorExt is to be moved,
then this should be coordinated with Batik. At some point, Batik will
also need to support the additional color spaces currently being
specified as part of the SVG color spec [1]. That would probably require
a little bit of clean-up in ColorExt. I'm not entirely happy with that
class at the moment.
[1] http://www.w3.org/TR/SVGColorPrimer12/
On 15.12.2009 13:30:27 Peter Hancock wrote:
> Hi Jeremias,
>
> Would such a ColorConverter interface be useful as part of xmlgraphics
> commons? I think there may be other color related classes that could be
> re-housed like ColorExt.
>
> Pete
>
> On Thu, Nov 26, 2009 at 8:20 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
>
> > Hi Peter
> >
> > On 26.11.2009 21:06:42 Peter Hancock wrote:
> > > Hi Jeremias,
> > >
> > > I think I see what you have in mind - the interface could simply expose
> > > methods like
> > > *Color convertXtoY(Color)*. Or did you have in mind the methods
> > returning
> > > output type-specific color representaions?
> >
> > Pretty much just one very simple "Color convert(Color)" method. Not sure,
> > yet, if it's too simple. ;-) But at least this wouldn't make any
> > assumption what kind of color conversion happens. The setup is done
> > elsewhere. Having a simple interface has the advantage that a converter
> > can be used in different places.
> >
> > > Should AbstractPaintingState be responsible holding the ColorConverter
> > and
> > > exposing it as a property e.g for the utility of AFPGraphics2D before
> > > calling setColor() on the GraphicsObject instance?
> >
> > I haven't really thought that far, but that sounds about right. The
> > original color should be preserved as long as possible IMO, and only be
> > changed where it makes sense. And that would most probably be at the
> > point where it is set on the AFP graphics object.
> >
> > > Cheers,
> > >
> > > Pete
> > >
> > >
> > > On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki <dev@jeremias-maerki.ch
> > >wrote:
> > >
> > > > Hi Peter
> > > >
> > > > See my question I attached to bug 48237. But of course, the ideal case
> > > > is to have the color converted properly if possible.
> > > >
> > > > On 24.11.2009 15:30:30 Peter Hancock wrote:
> > > > > At present FOP does not respect an image color setting of 'b+w' when
> > > > > rendering svg to afp (see Bug 48237)
> > > > >
> > > > > According to the AFP spec (
> > > > >
> > > >
> > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303
> > > > )
> > > > > it does not seem possible to specify a grayscale color space, and so
> > my
> > > > > question is how should colour be controlled?
> > > >
> > > > I think there are two general approached besides just using RGB:
> > > > - CMYK with only the K component (that is a clear indication that we
> > > > want a fully black color or shades of that)
> > > > - using a Highlight color space (assuming black as a highlight/spot
> > > > color)
> > > >
> > > > But I have no experience with highlight colors on AFP, so I can't tell
> > > > if it would work.
> > > >
> > > > > Since AFPGraphics2D is responsible for setting the color on the MODCA
> > > > > GraphicsObject prior to calling drawing methods, would a sensible
> > fix
> > > > to
> > > > > the problem be to convert the awt.Color before calling this setter?
> > > >
> > > > Probably. I have some tentative need to have a general color conversion
> > > > facility for FOP (not just AFP). For example, at some point we may want
> > > > to have color conversion from sRGB to CMYK. Another use case for a
> > color
> > > > converter would be a detector which would convert any grayscale color
> > (R,
> > > > G, B or C, M, Y with equal values) to a CMYK value (with only K) which
> > > > might in certain situations improve output quality because otherwise a
> > > > RIP might be inclined to mix black by mixing CMY. I can imagine that a
> > > > general interface could be defined for which there could be multiple
> > > > implementations depending on the use case and configuration. For the
> > > > present case, one implementation of that interface per color setting
> > > > could be written for AFP. Not sure, just brainstorming.
> > > >
> > > > > Any thoughts would be most welcome,
> > > > >
> > > > > Pete
> > > >
> > > >
> > > >
> > > >
> > > > Jeremias Maerki
> > > >
> > > >
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
Jeremias Maerki
Re: Thoughts on Bug 48237
Posted by Peter Hancock <pe...@gmail.com>.
Hi Jeremias,
Would such a ColorConverter interface be useful as part of xmlgraphics
commons? I think there may be other color related classes that could be
re-housed like ColorExt.
Pete
On Thu, Nov 26, 2009 at 8:20 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
> Hi Peter
>
> On 26.11.2009 21:06:42 Peter Hancock wrote:
> > Hi Jeremias,
> >
> > I think I see what you have in mind - the interface could simply expose
> > methods like
> > *Color convertXtoY(Color)*. Or did you have in mind the methods
> returning
> > output type-specific color representaions?
>
> Pretty much just one very simple "Color convert(Color)" method. Not sure,
> yet, if it's too simple. ;-) But at least this wouldn't make any
> assumption what kind of color conversion happens. The setup is done
> elsewhere. Having a simple interface has the advantage that a converter
> can be used in different places.
>
> > Should AbstractPaintingState be responsible holding the ColorConverter
> and
> > exposing it as a property e.g for the utility of AFPGraphics2D before
> > calling setColor() on the GraphicsObject instance?
>
> I haven't really thought that far, but that sounds about right. The
> original color should be preserved as long as possible IMO, and only be
> changed where it makes sense. And that would most probably be at the
> point where it is set on the AFP graphics object.
>
> > Cheers,
> >
> > Pete
> >
> >
> > On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki <dev@jeremias-maerki.ch
> >wrote:
> >
> > > Hi Peter
> > >
> > > See my question I attached to bug 48237. But of course, the ideal case
> > > is to have the color converted properly if possible.
> > >
> > > On 24.11.2009 15:30:30 Peter Hancock wrote:
> > > > At present FOP does not respect an image color setting of 'b+w' when
> > > > rendering svg to afp (see Bug 48237)
> > > >
> > > > According to the AFP spec (
> > > >
> > >
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303
> > > )
> > > > it does not seem possible to specify a grayscale color space, and so
> my
> > > > question is how should colour be controlled?
> > >
> > > I think there are two general approached besides just using RGB:
> > > - CMYK with only the K component (that is a clear indication that we
> > > want a fully black color or shades of that)
> > > - using a Highlight color space (assuming black as a highlight/spot
> > > color)
> > >
> > > But I have no experience with highlight colors on AFP, so I can't tell
> > > if it would work.
> > >
> > > > Since AFPGraphics2D is responsible for setting the color on the MODCA
> > > > GraphicsObject prior to calling drawing methods, would a sensible
> fix
> > > to
> > > > the problem be to convert the awt.Color before calling this setter?
> > >
> > > Probably. I have some tentative need to have a general color conversion
> > > facility for FOP (not just AFP). For example, at some point we may want
> > > to have color conversion from sRGB to CMYK. Another use case for a
> color
> > > converter would be a detector which would convert any grayscale color
> (R,
> > > G, B or C, M, Y with equal values) to a CMYK value (with only K) which
> > > might in certain situations improve output quality because otherwise a
> > > RIP might be inclined to mix black by mixing CMY. I can imagine that a
> > > general interface could be defined for which there could be multiple
> > > implementations depending on the use case and configuration. For the
> > > present case, one implementation of that interface per color setting
> > > could be written for AFP. Not sure, just brainstorming.
> > >
> > > > Any thoughts would be most welcome,
> > > >
> > > > Pete
> > >
> > >
> > >
> > >
> > > Jeremias Maerki
> > >
> > >
>
>
>
>
> Jeremias Maerki
>
>
Re: Thoughts on Bug 48237
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Peter
On 26.11.2009 21:06:42 Peter Hancock wrote:
> Hi Jeremias,
>
> I think I see what you have in mind - the interface could simply expose
> methods like
> *Color convertXtoY(Color)*. Or did you have in mind the methods returning
> output type-specific color representaions?
Pretty much just one very simple "Color convert(Color)" method. Not sure,
yet, if it's too simple. ;-) But at least this wouldn't make any
assumption what kind of color conversion happens. The setup is done
elsewhere. Having a simple interface has the advantage that a converter
can be used in different places.
> Should AbstractPaintingState be responsible holding the ColorConverter and
> exposing it as a property e.g for the utility of AFPGraphics2D before
> calling setColor() on the GraphicsObject instance?
I haven't really thought that far, but that sounds about right. The
original color should be preserved as long as possible IMO, and only be
changed where it makes sense. And that would most probably be at the
point where it is set on the AFP graphics object.
> Cheers,
>
> Pete
>
>
> On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
>
> > Hi Peter
> >
> > See my question I attached to bug 48237. But of course, the ideal case
> > is to have the color converted properly if possible.
> >
> > On 24.11.2009 15:30:30 Peter Hancock wrote:
> > > At present FOP does not respect an image color setting of 'b+w' when
> > > rendering svg to afp (see Bug 48237)
> > >
> > > According to the AFP spec (
> > >
> > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303
> > )
> > > it does not seem possible to specify a grayscale color space, and so my
> > > question is how should colour be controlled?
> >
> > I think there are two general approached besides just using RGB:
> > - CMYK with only the K component (that is a clear indication that we
> > want a fully black color or shades of that)
> > - using a Highlight color space (assuming black as a highlight/spot
> > color)
> >
> > But I have no experience with highlight colors on AFP, so I can't tell
> > if it would work.
> >
> > > Since AFPGraphics2D is responsible for setting the color on the MODCA
> > > GraphicsObject prior to calling drawing methods, would a sensible fix
> > to
> > > the problem be to convert the awt.Color before calling this setter?
> >
> > Probably. I have some tentative need to have a general color conversion
> > facility for FOP (not just AFP). For example, at some point we may want
> > to have color conversion from sRGB to CMYK. Another use case for a color
> > converter would be a detector which would convert any grayscale color (R,
> > G, B or C, M, Y with equal values) to a CMYK value (with only K) which
> > might in certain situations improve output quality because otherwise a
> > RIP might be inclined to mix black by mixing CMY. I can imagine that a
> > general interface could be defined for which there could be multiple
> > implementations depending on the use case and configuration. For the
> > present case, one implementation of that interface per color setting
> > could be written for AFP. Not sure, just brainstorming.
> >
> > > Any thoughts would be most welcome,
> > >
> > > Pete
> >
> >
> >
> >
> > Jeremias Maerki
> >
> >
Jeremias Maerki
Re: Thoughts on Bug 48237
Posted by Peter Hancock <pe...@gmail.com>.
Hi Jeremias,
I think I see what you have in mind - the interface could simply expose
methods like
*Color convertXtoY(Color)*. Or did you have in mind the methods returning
output type-specific color representaions?
Should AbstractPaintingState be responsible holding the ColorConverter and
exposing it as a property e.g for the utility of AFPGraphics2D before
calling setColor() on the GraphicsObject instance?
Cheers,
Pete
On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki <de...@jeremias-maerki.ch>wrote:
> Hi Peter
>
> See my question I attached to bug 48237. But of course, the ideal case
> is to have the color converted properly if possible.
>
> On 24.11.2009 15:30:30 Peter Hancock wrote:
> > At present FOP does not respect an image color setting of 'b+w' when
> > rendering svg to afp (see Bug 48237)
> >
> > According to the AFP spec (
> >
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303
> )
> > it does not seem possible to specify a grayscale color space, and so my
> > question is how should colour be controlled?
>
> I think there are two general approached besides just using RGB:
> - CMYK with only the K component (that is a clear indication that we
> want a fully black color or shades of that)
> - using a Highlight color space (assuming black as a highlight/spot
> color)
>
> But I have no experience with highlight colors on AFP, so I can't tell
> if it would work.
>
> > Since AFPGraphics2D is responsible for setting the color on the MODCA
> > GraphicsObject prior to calling drawing methods, would a sensible fix
> to
> > the problem be to convert the awt.Color before calling this setter?
>
> Probably. I have some tentative need to have a general color conversion
> facility for FOP (not just AFP). For example, at some point we may want
> to have color conversion from sRGB to CMYK. Another use case for a color
> converter would be a detector which would convert any grayscale color (R,
> G, B or C, M, Y with equal values) to a CMYK value (with only K) which
> might in certain situations improve output quality because otherwise a
> RIP might be inclined to mix black by mixing CMY. I can imagine that a
> general interface could be defined for which there could be multiple
> implementations depending on the use case and configuration. For the
> present case, one implementation of that interface per color setting
> could be written for AFP. Not sure, just brainstorming.
>
> > Any thoughts would be most welcome,
> >
> > Pete
>
>
>
>
> Jeremias Maerki
>
>
Re: Thoughts on Bug 48237
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Peter
See my question I attached to bug 48237. But of course, the ideal case
is to have the color converted properly if possible.
On 24.11.2009 15:30:30 Peter Hancock wrote:
> At present FOP does not respect an image color setting of 'b+w' when
> rendering svg to afp (see Bug 48237)
>
> According to the AFP spec (
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303)
> it does not seem possible to specify a grayscale color space, and so my
> question is how should colour be controlled?
I think there are two general approached besides just using RGB:
- CMYK with only the K component (that is a clear indication that we
want a fully black color or shades of that)
- using a Highlight color space (assuming black as a highlight/spot
color)
But I have no experience with highlight colors on AFP, so I can't tell
if it would work.
> Since AFPGraphics2D is responsible for setting the color on the MODCA
> GraphicsObject prior to calling drawing methods, would a sensible fix to
> the problem be to convert the awt.Color before calling this setter?
Probably. I have some tentative need to have a general color conversion
facility for FOP (not just AFP). For example, at some point we may want
to have color conversion from sRGB to CMYK. Another use case for a color
converter would be a detector which would convert any grayscale color (R,
G, B or C, M, Y with equal values) to a CMYK value (with only K) which
might in certain situations improve output quality because otherwise a
RIP might be inclined to mix black by mixing CMY. I can imagine that a
general interface could be defined for which there could be multiple
implementations depending on the use case and configuration. For the
present case, one implementation of that interface per color setting
could be written for AFP. Not sure, just brainstorming.
> Any thoughts would be most welcome,
>
> Pete
Jeremias Maerki
Re: Thoughts on Bug 48237
Posted by Peter Hancock <pe...@gmail.com>.
Hi Venkat,
The bug is with svg images (embedded and extrernal) - you are correct that
it works with bitmaps as demonstrated in the files attached to the bug
report. Were you able to test those?
Cheers,
Pete
On Tue, Nov 24, 2009 at 4:59 PM, Venkat Reddy <
vanukuri.venkat@googlemail.com> wrote:
> 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.
>
>
> Peter Hancock wrote:
>
>> At present FOP does not respect an image color setting of 'b+w' when
>> rendering svg to afp (see Bug 48237)
>>
>> According to the AFP spec (
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303<
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303>)
>> it does not seem possible to specify a grayscale color space, and so my
>> question is how should colour be controlled?
>>
>>
>> Since AFPGraphics2D is responsible for setting the color on the MODCA
>> GraphicsObject prior to calling drawing methods, would a sensible fix to
>> the problem be to convert the awt.Color before calling this setter?
>>
>> Any thoughts would be most welcome,
>>
>> Pete
>>
>
>
Re: Thoughts on Bug 48237
Posted by Venkat Reddy <va...@googlemail.com>.
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.
Peter Hancock wrote:
> At present FOP does not respect an image color setting of 'b+w' when
> rendering svg to afp (see Bug 48237)
>
> According to the AFP spec
> (http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303
> <http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303>)
> it does not seem possible to specify a grayscale color space, and so
> my question is how should colour be controlled?
>
> Since AFPGraphics2D is responsible for setting the color on the MODCA
> GraphicsObject prior to calling drawing methods, would a sensible
> fix to the problem be to convert the awt.Color before calling this setter?
>
> Any thoughts would be most welcome,
>
> Pete