You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2010/07/07 16:13:41 UTC
SVG Color 1.2: proof of concept done
Those who monitor general@xmlgraphics.apache.org will have seen that I'm
working (among other things) on ICC named color support for FOP and
Batik. I have now a first version that supports cielab() and
icc-named-color() functions from the SVG Color 1.2 Working Draft:
http://www.w3.org/TR/SVGColor12
The code relies on changes in XML Graphics Commons which are currently
placed in a dev branch and which are also used by a dev branch for FOP:
https://svn.apache.org/repos/asf/xmlgraphics/commons/branches/Temp_Color
https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color
So adding this to Batik will finally add that dependency on XML Graphics
Commons which we have talked about long ago.
Adding support for the remaining methods from SVG Color 1.2 won't be all
that hard. There's cielch() that requires a formula to convert the
values to CIE Lab. And finally, the device-specific colors which also
be fairly easy with a little additional work in XML Graphics Commons.
The question is now, if it were ok, if I created a similar branch for
Batik and upload my changes there for everyone to review. I'm not
technically a Batik committer although I theoretically have write access
to the Batik repo since I'm a PMC member. That's why I'm asking what the
best course of action is. I can also post a patch if that's preferred.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVG Color 1.2: proof of concept done
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
So, the branch is now created:
https://svn.apache.org/repos/asf/xmlgraphics/batik/branches/svgcolor12
For those who want to give the new functionality a try: I'm fighting a
bit with the whole Class-Path manifest and runtime policy thing. The
easiest thing for me (for the moment) was to do this:
- Compile XML Graphics Commons: http://svn.apache.org/repos/asf/xmlgraphics/commons/branches/Temp_Color
- Compile Batik (Target all-jar)
- Copy xmlgraphics-commons.jar (see build directory) to FOP's lib
directory.
- Copy batik-all.jar to FOP's lib directory.
- Compile FOP: http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color
- Instead of running Batik's rasterizer, use:
fop.cmd/fop.sh -imagein mysvg.svg -pdf out.pdf
...to convert an SVG to a PDF file. That doesn't require complicated
manifest and policy manipulations. And it allows to test through all of
FOP's supported formats whereas in Batik only PDF is currently available
besides bitmap formats.
I've added a couple of simple test files in samples/tests/spec12/paints/.
On 09.07.2010 16:44:24 Jeremias Maerki wrote:
> On 08.07.2010 11:44:45 thomas.deweese wrote:
> > Hi Jeremias,
> >
> > Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 07/07/2010 10:13:41 AM:
> >
> > > Those who monitor general@xmlgraphics.apache.org will have seen that I'm
> > > working (among other things) on ICC named color support for FOP and
> > > Batik. I have now a first version that supports cielab() and
> > > icc-named-color() functions from the SVG Color 1.2 Working Draft:
> > > http://www.w3.org/TR/SVGColor12
> >
> > Great work!
>
> Thanks. :-)
>
> > > The question is now, if it were ok, if I created a similar branch for
> > > Batik and upload my changes there for everyone to review.
> >
> > It is OK with me.
>
> Great, thanks for your confidence. I'll create the branch on Monday if
> there's no veto until then.
>
>
> Jeremias Maerki
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVG Color 1.2: proof of concept done
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 08.07.2010 11:44:45 thomas.deweese wrote:
> Hi Jeremias,
>
> Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 07/07/2010 10:13:41 AM:
>
> > Those who monitor general@xmlgraphics.apache.org will have seen that I'm
> > working (among other things) on ICC named color support for FOP and
> > Batik. I have now a first version that supports cielab() and
> > icc-named-color() functions from the SVG Color 1.2 Working Draft:
> > http://www.w3.org/TR/SVGColor12
>
> Great work!
Thanks. :-)
> > The question is now, if it were ok, if I created a similar branch for
> > Batik and upload my changes there for everyone to review.
>
> It is OK with me.
Great, thanks for your confidence. I'll create the branch on Monday if
there's no veto until then.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVG Color 1.2: proof of concept done
Posted by th...@kodak.com.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 07/07/2010 10:13:41 AM:
> Those who monitor general@xmlgraphics.apache.org will have seen that I'm
> working (among other things) on ICC named color support for FOP and
> Batik. I have now a first version that supports cielab() and
> icc-named-color() functions from the SVG Color 1.2 Working Draft:
> http://www.w3.org/TR/SVGColor12
Great work!
> The question is now, if it were ok, if I created a similar branch for
> Batik and upload my changes there for everyone to review.
It is OK with me.
Re: SVG Color 1.2: proof of concept done
Posted by Chris Lilley <ch...@w3.org>.
On Friday, July 9, 2010, 4:43:53 PM, Jeremias wrote:
JM> Hi Chris
JM> On 07.07.2010 17:43:31 Chris Lilley wrote:
>> JM> Adding support for the remaining methods from SVG Color 1.2 won't be all
>> JM> that hard. There's cielch() that requires a formula to convert the
>> JM> values to CIE Lab.
>> Yes. That's pretty trivial, L is the same and c,h are the polar form of a,b.
JM> Right, I've seen that formula somewhere. Should be easy. Some cos() &
JM> sin() something.
a = C cos(H)
b = C sin(H)
H is in degrees, by the way and normalised to 0 <= H < 360
and for the other way
C = sqrt(a*a + b*b)
H = atan2 (b, a)
because a can be zero.
>> JM> And finally, the device-specific colors which also
>> JM> be fairly easy with a little additional work in XML Graphics Commons.
>> They are easy to parse, but device-specific colours introduce a
>> complication in that they are just a recipe for an output device, not a
>> colour. So they can't be easily combined with other colours (e.g. used
>> in a gradient, combined using opacity, etc). The sRGB fallback colour
>> needs to be retained, used if a device-specific colour is mixed with
>> another colour.
JM> I have that mapped already. I just hope XSL-FO 2.0 will do that the same
JM> way. http://wiki.apache.org/xmlgraphics/ColorHandling
I was just reading that page today.
Yes, the intention is that XSL FO and SVG do colour management the same way (and CSS too, when it gets around to it). SVG WG and the FO subgroup of XSL WG coordinate to ensure that this happens.
--
Chris Lilley mailto:chris@w3.org
Technical Director, Interaction Domain
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVG Color 1.2: proof of concept done
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Chris
On 07.07.2010 17:43:31 Chris Lilley wrote:
> On Wednesday, July 7, 2010, 4:13:41 PM, Jeremias wrote:
>
> JM> Those who monitor general@xmlgraphics.apache.org will have seen that I'm
> JM> working (among other things) on ICC named color support for FOP and
> JM> Batik. I have now a first version that supports cielab() and
> JM> icc-named-color() functions from the SVG Color 1.2 Working Draft:
> JM> http://www.w3.org/TR/SVGColor12
>
> Woohoo, this is great news. Looking forward to playing with that. Also,
> its much easier to write test cases when there is a working
> implementation to sanity-check them with.
:-) Right, the test cases is also something on my list. Right now, I'm
just working off a single A4 page written in XSL-FO that plays through
all possibilities in FO and SVG.
>
> JM> The code relies on changes in XML Graphics Commons which are currently
> JM> placed in a dev branch and which are also used by a dev branch for FOP:
> JM> https://svn.apache.org/repos/asf/xmlgraphics/commons/branches/Temp_Color
> JM> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color
> JM> So adding this to Batik will finally add that dependency on XML Graphics
> JM> Commons which we have talked about long ago.
>
> JM> Adding support for the remaining methods from SVG Color 1.2 won't be all
> JM> that hard. There's cielch() that requires a formula to convert the
> JM> values to CIE Lab.
>
> Yes. That's pretty trivial, L is the same and c,h are the polar form of a,b.
Right, I've seen that formula somewhere. Should be easy. Some cos() &
sin() something.
> JM> And finally, the device-specific colors which also
> JM> be fairly easy with a little additional work in XML Graphics Commons.
>
> They are easy to parse, but device-specific colours introduce a
> complication in that they are just a recipe for an output device, not a
> colour. So they can't be easily combined with other colours (e.g. used
> in a gradient, combined using opacity, etc). The sRGB fallback colour
> needs to be retained, used if a device-specific colour is mixed with
> another colour.
I have that mapped already. I just hope XSL-FO 2.0 will do that the same
way. http://wiki.apache.org/xmlgraphics/ColorHandling
> JM> The question is now, if it were ok, if I created a similar branch for
> JM> Batik and upload my changes there for everyone to review. I'm not
> JM> technically a Batik committer although I theoretically have write access
> JM> to the Batik repo since I'm a PMC member. That's why I'm asking what the
> JM> best course of action is. I can also post a patch if that's preferred.
>
> Personally I would find it easier to check out a branch than to check out a trunk and then apply a patch each time.
>
>
> --
> Chris Lilley mailto:chris@w3.org
> Technical Director, Interaction Domain
> W3C Graphics Activity Lead
> Co-Chair, W3C Hypertext CG
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVG Color 1.2: proof of concept done
Posted by Chris Lilley <ch...@w3.org>.
On Wednesday, July 7, 2010, 4:13:41 PM, Jeremias wrote:
JM> Those who monitor general@xmlgraphics.apache.org will have seen that I'm
JM> working (among other things) on ICC named color support for FOP and
JM> Batik. I have now a first version that supports cielab() and
JM> icc-named-color() functions from the SVG Color 1.2 Working Draft:
JM> http://www.w3.org/TR/SVGColor12
Woohoo, this is great news. Looking forward to playing with that. Also, its much easier to write test cases when there is a working implementation to sanity-check them with.
JM> The code relies on changes in XML Graphics Commons which are currently
JM> placed in a dev branch and which are also used by a dev branch for FOP:
JM> https://svn.apache.org/repos/asf/xmlgraphics/commons/branches/Temp_Color
JM> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color
JM> So adding this to Batik will finally add that dependency on XML Graphics
JM> Commons which we have talked about long ago.
JM> Adding support for the remaining methods from SVG Color 1.2 won't be all
JM> that hard. There's cielch() that requires a formula to convert the
JM> values to CIE Lab.
Yes. That's pretty trivial, L is the same and c,h are the polar form of a,b.
JM> And finally, the device-specific colors which also
JM> be fairly easy with a little additional work in XML Graphics Commons.
They are easy to parse, but device-specific colours introduce a complication in that they are just a recipe for an output device, not a colour. So they can't be easily combined with other colours (e.g. used in a gradient, combined using opacity, etc). The sRGB fallback colour needs to be retained, used if a device-specific colour is mixed with another colour.
JM> The question is now, if it were ok, if I created a similar branch for
JM> Batik and upload my changes there for everyone to review. I'm not
JM> technically a Batik committer although I theoretically have write access
JM> to the Batik repo since I'm a PMC member. That's why I'm asking what the
JM> best course of action is. I can also post a patch if that's preferred.
Personally I would find it easier to check out a branch than to check out a trunk and then apply a patch each time.
--
Chris Lilley mailto:chris@w3.org
Technical Director, Interaction Domain
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org