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 Cameron McCormack <ca...@mcc.id.au> on 2007/02/05 03:41:30 UTC
Test failures
Hi everyone.
After fixing the memory leak tests (made a couple of object references
WeakReferences in the test classes—although it seems now that running
those tests from the command line is fine, but in the whole regard test
run I still get JFrame objects not cleared), I ran regard on my Linux
(1.6.0-b105), Windows (1.5.0_10-b03) and Mac (1.5.0_06-64) machines.
There are a number of problems on the Mac, which I would prefer to be
fixed before the release if possible. The problems fall in to a few
different categories:
▪ Text layout
http://mcc.id.au/temp/t/show?mac,fontChoice
http://mcc.id.au/temp/t/show?mac,smallFonts
http://mcc.id.au/temp/t/show?mac,textFeatures
Incorrect horizontal text placement of italic text.
http://mcc.id.au/temp/t/show?mac,longTextOnPath
http://mcc.id.au/temp/t/show?mac,textAnchor2
http://mcc.id.au/temp/t/show?mac,textAnchor3
http://mcc.id.au/temp/t/show?mac,textLayout2
http://mcc.id.au/temp/t/show?mac,text
http://mcc.id.au/temp/t/show?mac,text_children2
http://mcc.id.au/temp/t/show?mac,text_dylist1
http://mcc.id.au/temp/t/show?mac,text_dylist2
http://mcc.id.au/temp/t/show?mac,text-alignment-BE-11
Incorrect vertical text placement.
http://mcc.id.au/temp/t/show?mac,textLayout
http://mcc.id.au/temp/t/show?mac,textLength
lengthAdjust="spacingAndGlyphs" not computed properly.
http://mcc.id.au/temp/t/show?mac,verticalText
http://mcc.id.au/temp/t/show?mac,verticalTextOnPath
Vertical text aligned horizontally instead.
http://mcc.id.au/temp/t/show?mac,textGlyphOrientationHorizontal
glyph-orientation-horizontal rotated text goes in the wrong
direction.
▪ Flow text layout
http://mcc.id.au/temp/t/show?mac,flowBidi
http://mcc.id.au/temp/t/show?mac,flowText
http://mcc.id.au/temp/t/show?mac,flowText2
http://mcc.id.au/temp/t/show?mac,flowText3
http://mcc.id.au/temp/t/show?mac,flowText4
http://mcc.id.au/temp/t/show?mac,flowRegionBreak
http://mcc.id.au/temp/t/show?mac,lineHeightFontShorthand
Text is all over the place.
▪ Flow text extension layout
http://mcc.id.au/temp/t/show?mac,flowText,1,3
▪ Gradients
http://mcc.id.au/temp/t/show?mac,feTile
http://mcc.id.au/temp/t/show?mac,feTileTarget
http://mcc.id.au/temp/t/show?mac,markersShapes
http://mcc.id.au/temp/t/show?mac,linearGradientRepeat
Colours slightly off.
http://mcc.id.au/temp/t/show?mac,gradientLimit
Top right gradient wrong.
http://mcc.id.au/temp/t/show?mac,gradientPoint
Gradients wrong. Got this ouptut on the console, so it may be a VM
bug:
fox:~/work/svn/batik/trunk $ java -jar batik-1.6/batik.jar samples/tests/spec/paints/gradientPoint.svg
java(10415,0x1867800) malloc: *** vm_allocate(size=3200004096) failed (error code=3)
java(10415,0x1867800) malloc: *** error: can't allocate region
java(10415,0x1867800) malloc: *** set a breakpoint in szone_error to debug
java(10415,0x1867800) malloc: *** vm_allocate(size=3200004096) failed (error code=3)
java(10415,0x1867800) malloc: *** error: can't allocate region
java(10415,0x1867800) malloc: *** set a breakpoint in szone_error to debug
java(10415,0x1867800) malloc: *** vm_allocate(size=3200004096) failed (error code=3)
java(10415,0x1867800) malloc: *** error: can't allocate region
java(10415,0x1867800) malloc: *** set a breakpoint in szone_error to debug
java(10415,0x1867800) malloc: *** vm_allocate(size=3200004096) failed (error code=3)
java(10415,0x1867800) malloc: *** error: can't allocate region
java(10415,0x1867800) malloc: *** set a breakpoint in szone_error to debug
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
http://mcc.id.au/temp/t/show?mac,masking-mask-BE-05
http://mcc.id.au/temp/t/show?mac,masking-mask-BE-06
Mask gradient wrong.
▪ Non pixel aligning
http://mcc.id.au/temp/t/show?mac,markersMisc
The squares on the bottom right test are not pixel aligned.
http://mcc.id.au/temp/t/show?mac,patternRegions
Squares around each pattern are not pixel aligned. (Also slightly
off gradient colours on the last pattern.)
http://mcc.id.au/temp/t/show?mac,enclosureList2
Coloured squares are not pixel aligned.
▪ Opacity
http://mcc.id.au/temp/t/show?mac,polygon_points2
http://mcc.id.au/temp/t/show?mac,paintOpacity
http://mcc.id.au/temp/t/show?mac,enableBackground
http://mcc.id.au/temp/t/show?mac,svgEnableBackground
Semi-opaque paints are slightly different from the reference image.
▪ Miscellaneous
http://mcc.id.au/temp/t/show?mac,batik70
The vertical stripe background renders incorrectly. The aqua stripe
seems to be pink. Also, the path forming the bottom part of the ‘i’
glyph isn’t closed.
http://mcc.id.au/temp/t/show?mac,moonPhases
The lat/long lines on the earths don’t show unless zoomed right in.
http://mcc.id.au/temp/t/show?mac,histogramNormalization
Image normalisation not done.
http://mcc.id.au/temp/t/show?mac,feConvolveMatrix
Bottom right case doesn’t have black in the right places.
http://mcc.id.au/temp/t/show?mac,maskRegions
Masking is not anti-aliased. (Maybe that’s just the Mac Java2D
implementation that defaults to non-anti-aliasing.)
http://mcc.id.au/temp/t/show?mac,fontOnPath
Text selection highlight looks a bit strange (white border is not
right on the edge of the highlight).
These on Windows:
▪ Opacity
http://mcc.id.au/temp/t/show?win,enableBackground,1,3
http://mcc.id.au/temp/t/show?win,svgEnableBackground,1,3
http://mcc.id.au/temp/t/show?win,paintOpacity,1,3
http://mcc.id.au/temp/t/show?win,polygon_points2,1,3
Semi-opaque paints are slightly different from the reference image.
▪ Gradients
http://mcc.id.au/temp/t/show?win,feTile,1,3
Colours slightly off.
These on Linux:
▪ Opacity
http://mcc.id.au/temp/t/show?linux,enableBackground,1,3
http://mcc.id.au/temp/t/show?linux,svgEnableBackground,1,3
http://mcc.id.au/temp/t/show?linux,paintOpacity,1,3
http://mcc.id.au/temp/t/show?linux,polygon_points2,1,3
Semi-opaque paints are slightly different from the reference image.
▪ Gradients
http://mcc.id.au/temp/t/show?linux,feTile,1,3
Colours slightly off.
▪ ICC colour
http://mcc.id.au/temp/t/show?linux,paintType,1,3
http://mcc.id.au/temp/t/show?linux,color-colorProf-BE-03,1,3
ICC colours render slightly differently from the reference image.
Some of these may be just due to different JRE versions doing
compositing a bit differently; whether they’re incorrect I’m not sure.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Cameron McCormack <ca...@mcc.id.au>.
Thomas DeWeese:
> > > > The text ones all give correct rendering with a small rotation.
> > >
> > > I suppose it would be an option to add a small rotation to
> > > 'complex' texts (anything that adjusts individual glyph positions),
> > > on Mac OS X. However since this is fixed in Java 6 I'd rather just
> > > recommend people upgrade the JVM...
> >
> > Maybe we could set the rendering hint that corresponds to
> > text-rendering="geometricPrecision" when rendering certain (or all)
> > text.
>
> This fixes it? It would be a simpler fix, but I'm not sure how
> it would impact general performance.
It does fix it. The only two cases I’ve noticed where the positioning
is incorrect is when there is italic text or a dy on the text. We could
set it to geometricPrecision for just these cases, but then such text
will look slightly different from other text elements. If you think
this isn’t a problem, I’ll go ahead and do this.
> > I’m not really sure where to look though for this and the other
> > alpha related problems.
>
> Neither am I really. This code is fairly complex as it tries
> to avoid Legacy problems and maintain good performance.
>
> I'll try and reproduce it on Windows by making the destination
> ARGB_PRE. If that causes the same problem then it's probably in
> our code and it will give me a better idea where to look.
Ok.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by The Web Maestro <th...@gmail.com>.
On 3/25/07, Vincent Hennebert <vi...@anyware-tech.com> wrote:
> Hehe, I stumbled upon the same questions when releasing XML Graphics
> Commons. I guess simply agreeing on the mailing list that it is time for
> a new release is enough. A formal vote then on the release files will be
> fine.
> IIC you'll have to launch the vote on xmlgraphics-general@, with a list
> of links to the files which will be distributed (binary, source, etc.),
> and with md5 sums of those files in the mail, so that people know what
> they will vote for.
>
> Jeremias, correct me if I'm wrong ;-)
>
> Vincent
Actually, that's general@xmlgraphics.apache.org. And I think we have
to Cc private@xmlgraphics.apache.org. It may also make sense to Cc
batik-dev@xmlgraphics.apache.org...
Web Maestro Clay
--
Regards,
The Web Maestro
--
<th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Cameron McCormack a écrit :
> Cameron McCormack:
>> If there are no further objections then, I will go through the motions
>> for making a release over the next week. After looking at
>> http://www.apache.org/dev/release.html, it sounds more appropriate to
>> call the release 1.7beta1 rather than 1.7rc1. Once I’m done I’ll send
>> a link to the distribution to the pmc for a vote.
>
> Actually, I should make sure I’m right on the procedural stuff. Do I
> need to call for a vote before making the candidate release and getting
> a vote on that? Or is the one vote sufficient? Also, which lists
> should I be sending the vote to?
Hehe, I stumbled upon the same questions when releasing XML Graphics
Commons. I guess simply agreeing on the mailing list that it is time for
a new release is enough. A formal vote then on the release files will be
fine.
IIC you'll have to launch the vote on xmlgraphics-general@, with a list
of links to the files which will be distributed (binary, source, etc.),
and with md5 sums of those files in the mail, so that people know what
they will vote for.
Jeremias, correct me if I'm wrong ;-)
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Cameron McCormack <ca...@mcc.id.au>.
Cameron McCormack:
> If there are no further objections then, I will go through the motions
> for making a release over the next week. After looking at
> http://www.apache.org/dev/release.html, it sounds more appropriate to
> call the release 1.7beta1 rather than 1.7rc1. Once I’m done I’ll send
> a link to the distribution to the pmc for a vote.
Actually, I should make sure I’m right on the procedural stuff. Do I
need to call for a vote before making the candidate release and getting
a vote on that? Or is the one vote sufficient? Also, which lists
should I be sending the vote to?
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Cameron McCormack <ca...@mcc.id.au>.
Hi guys.
Cameron McCormack:
> > All of the rendering issues under OS X also existed with Batik 1.6.
> > Since they’re not regressions, I suggest we leave them for now and forge
> > ahead with the 1.7 release.
Thomas DeWeese:
> I tend to agree.
Ok great.
Thomas DeWeese:
> > I wasn't sure we could do that. I thought when we used code outside
> > the project it had to be 'released' code. Am I wrong on this?
> > Maybe I'm making stuff up, Jeremias any comment?
Jeremias Märki:
> This rule is mostly about ASF-controlled software. The board wants that a
> certain amount of oversight is in place. For software developed outside
> the ASF, other rules may apply but it is still better to rely on
> formally released software in order to avoid potential legal problems.
> Imagine someone changing something that later turns out that the code
> was stolen somewhere (or whatever), i.e. they find a legal problem only
> after you already released with this code. Depending on released
> software decreases the likelihood that you run into any possible
> problems. If a committee has to nod a release through there's a good
> chance most problems are caught.
>
> In the case of a release candidate plus a patch you have full control
> over, you should be fairly safe. I wouldn't veto such a release. What's
> not a good idea is to take a snapshot from a code repo and put that in a
> ASF-controlled release. HTH
That sounds all right then. The patch is pretty short (just replacing
one line with nine lines). I’ll include a link to the Bugzilla entry
that contains the patch in the README.js.txt file.
If there are no further objections then, I will go through the motions
for making a release over the next week. After looking at
http://www.apache.org/dev/release.html, it sounds more appropriate to
call the release 1.7beta1 rather than 1.7rc1. Once I’m done I’ll send
a link to the distribution to the pmc for a vote.
I haven’t been involved in the mechanics of previous releases, but if
it’s not more than following http://www.apache.org/dev/release.html and
the instructions in the MAINTAIN file (modulo intfrastructure changes
since the least release), then I should be able to manage.
Cameron
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 23.03.2007 13:09:59 thomas.deweese wrote:
> Hi Cameron,
>
> Cameron McCormack <ca...@mcc.id.au> wrote on 03/22/2007 10:41:09 PM:
>
> > Cameron McCormack:
> > > Cool. It does fix the batik70.svg rendering under OS X. Unfortunately
> > > it didn?t seem to help the other rendering issues.
> >
> > All of the rendering issues under OS X also existed with Batik 1.6.
> > Since they?re not regressions, I suggest we leave them for now and forge
> > ahead with the 1.7 release.
>
> I tend to agree.
>
> > Still waiting on Rhino to have a new release (I believe Atilla is
> > working on better security policy work in general, rather than applying
> > the workaround I supplied). What does everyone think of making the
> > release candidate with Rhino 1.6R5 + a patch to make the debugger work,
> > and then making the final 1.7 release once Rhino?s next distribution is
> > out?
>
> I wasn't sure we could do that. I thought when we used code outside
> the project it had to be 'released' code. Am I wrong on this?
> Maybe I'm making stuff up, Jeremias any comment?
This rule is mostly about ASF-controlled software. The board wants that a
certain amount of oversight is in place. For software developed outside
the ASF, other rules may apply but it is still better to rely on
formally released software in order to avoid potential legal problems.
Imagine someone changing something that later turns out that the code
was stolen somewhere (or whatever), i.e. they find a legal problem only
after you already released with this code. Depending on released
software decreases the likelihood that you run into any possible
problems. If a committee has to nod a release through there's a good
chance most problems are caught.
In the case of a release candidate plus a patch you have full control
over, you should be fairly safe. I wouldn't veto such a release. What's
not a good idea is to take a snapshot from a code repo and put that in a
ASF-controlled release. HTH
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures | 1.7 release
Posted by Cameron McCormack <ca...@mcc.id.au>.
Daniel Meyer:
> I think it would be wise to wait 'till the security
> issues in Rhino are fixed and then release a new Batik package.
Just to be clear, it’s not a security issue that would be a
vulnerability. It’s just the way Rhino interacts with the Java security
classes which prevents it starting the debugger properly.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures | 1.7 release
Posted by Daniel Meyer <da...@pt.lu>.
Hi Cameron
Cameron McCormack wrote:
> Getting back on to this…
>
> Cameron McCormack:
>
>> Cool. It does fix the batik70.svg rendering under OS X. Unfortunately
>> it didn’t seem to help the other rendering issues.
>>
>
> All of the rendering issues under OS X also existed with Batik 1.6.
> Since they’re not regressions, I suggest we leave them for now and forge
> ahead with the 1.7 release.
>
> Still waiting on Rhino to have a new release (I believe Atilla is
> working on better security policy work in general, rather than applying
> the workaround I supplied). What does everyone think of making the
> release candidate with Rhino 1.6R5 + a patch to make the debugger work,
> and then making the final 1.7 release once Rhino’s next distribution is
> out?
>
Sounds good to me. I use the svn version for the moment,
as I need some new features added since 1.6.
I think it would be wise to wait 'till the security
issues in Rhino are fixed and then release a new Batik package.
You can then say, ok people use 1.7, it has all the new features and
it doesn't have any *major* bugs/security issues. If you release 1.7
without fixed Rhino, you'll need to do a 1.75 or 1.8 shortly after,
and that's not what you want.
Greetings from Luxembourg,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by th...@kodak.com.
Hi Cameron,
Cameron McCormack <ca...@mcc.id.au> wrote on 03/22/2007 10:41:09 PM:
> Cameron McCormack:
> > Cool. It does fix the batik70.svg rendering under OS X. Unfortunately
> > it didn?t seem to help the other rendering issues.
>
> All of the rendering issues under OS X also existed with Batik 1.6.
> Since they?re not regressions, I suggest we leave them for now and forge
> ahead with the 1.7 release.
I tend to agree.
> Still waiting on Rhino to have a new release (I believe Atilla is
> working on better security policy work in general, rather than applying
> the workaround I supplied). What does everyone think of making the
> release candidate with Rhino 1.6R5 + a patch to make the debugger work,
> and then making the final 1.7 release once Rhino?s next distribution is
> out?
I wasn't sure we could do that. I thought when we used code outside
the project it had to be 'released' code. Am I wrong on this?
Maybe I'm making stuff up, Jeremias any comment?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Cameron McCormack <ca...@mcc.id.au>.
Getting back on to this…
Cameron McCormack:
> Cool. It does fix the batik70.svg rendering under OS X. Unfortunately
> it didn’t seem to help the other rendering issues.
All of the rendering issues under OS X also existed with Batik 1.6.
Since they’re not regressions, I suggest we leave them for now and forge
ahead with the 1.7 release.
Still waiting on Rhino to have a new release (I believe Atilla is
working on better security policy work in general, rather than applying
the workaround I supplied). What does everyone think of making the
release candidate with Rhino 1.6R5 + a patch to make the debugger work,
and then making the final 1.7 release once Rhino’s next distribution is
out?
Cameron
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Cameron McCormack <ca...@mcc.id.au>.
Cameron McCormack:
> > Ok so it seems to be something to do with the going to a buffer for
> > the pattern. Here’s a reduced test case:
Thomas DeWeese:
> I think I've fixed at least this bug, it may fix more of them.
Cool. It does fix the batik70.svg rendering under OS X. Unfortunately
it didn’t seem to help the other rendering issues.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by th...@kodak.com.
Hi Cameron,
> > Ok so it seems to be something to do with the going to a buffer for
the
> > pattern. Here?s a reduced test case:
I think I've fixed at least this bug, it may fix more of them.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by th...@kodak.com.
Hi Cameron,
Cameron McCormack <ca...@mcc.id.au> wrote on 02/09/2007 08:40:35 AM:
> Cameron McCormack:
> > > ? flowBidi, which generates a StackOverflowException in some
> > > java.awt.font and sun.font methods
>
> Thomas DeWeese:
> > Since the other flow tests work, can you sort out what
> > method is causing the problem?
>
> It looks to be a bug in the 1.6 beta JRE. The call from Batik?s code
> is BidiAttributedCharacterIterator:121, where it creates a
> java.awt.font.TextLayout object. The AttributedString that?s passed to
> it is "Some (embedded bidi) of text.", where the text run in the
> parentheses has a BIDI_EMBEDDING attributed on it. I?ve filed a bug on
> Apple?s JRE.
Ok, sounds like it isn't a common enough case to warrant
too much digging around for a workaround (especially since it
may be fixed by the time it is released).
> > > ? batik70 (sample problem)
> > Second remove the use of the pattern and try
> > putting a few copies of the pattern directly
> > over the circles (to avoid rendering to a pattern
> > buffer that is then composited).
>
> Ok so it seems to be something to do with the going to a buffer for the
> pattern. Here?s a reduced test case:
>
> I tried to trace through the code to determine what
> ColorModel/WritableRaster/SampleModel are used so I could reproduce the
> rendering in a small test case. In the end I couldn?t, though. Do you
> have a Mac to test with?
I have a Mac but not Mac OS 10.4.
> > > ? masking-mask-BE-0[56] (same problem)
> > > ? histogramNormalization (same problem)
> > > ? feConvolveMatrix (same problem)
> >
> > So there is something funny going on with
> > alpha handling.
>
> I found the main BufferedImage that the whole document is rendered to is
> TYPE_INT_ARGB_PRE, and the pattern BufferedImage is TYPE_INT_ARGB. In
> my standalone test I tried painting a semi-opaque TYPE_INT_ARGB
> BufferedImage to a TYPE_INT_ARGB_PRE one, but it worked properly.
I would guess that this is related. IIRC we switched to ARGB_PRE
on Mac since it was much faster. I may try and see if ARGB_PRE on
Windows has the same issues.
> > > The text ones all give correct rendering with a small rotation.
> >
> > I suppose it would be an option to add a small rotation to
> > 'complex' texts (anything that adjusts individual glyph positions),
> > on Mac OS X. However since this is fixed in Java 6 I'd rather just
> > recommend people upgrade the JVM...
>
> Maybe we could set the rendering hint that corresponds to
> text-rendering="geometricPrecision" when rendering certain (or all)
> text.
This fixes it? It would be a simpler fix, but I'm not sure how
it would impact general performance.
> The 1.6 JRE isn?t released yet for OS X though, it?s just a beta (which
> can only be downloaded by signing up for Apple?s Developer Centre
> thingo).
Ok, still it shouldn't be that long before it get's rolled out
I would guess.
>
> > > > > http://mcc.id.au/temp/t/show?mac,linearGradientRepeat
> > > >
> > > > This looks to me like it's rendering the gradient at
> > > > lower resolution than the reference.
> > > >
> > > > > http://mcc.id.au/temp/t/show?mac,gradientLimit
> > > > > Top right gradient wrong.
> > > >
> > > > Once again I wonder if it's rendering at lower resolution...
> > >
> > > Anything that could be done about these?
> >
> > I don't know, someone must be scaling the buffer we give
> > them for display. I don't know where that would be happening.
>
> Is it enough of a corner case to ignore?
I think so.
> > > > Hmm, looks like the gradient opacity is being interpreted
> > > > 'backwards'.
> > >
> > > Strange that it?s got opacity 1 on the top scan line.
> >
> > Well it's not uncommon to have a special case for opacity==1
> > since you don't need to do compositing just copy. But that
> > would indicate that there was something a little wonky inside
> > their own code.
>
> Could be part of the same compositing problem I guess.
I would guess so.
> I?m not really sure where to look though for this and the other
> alpha related problems.
Neither am I really. This code is fairly complex as it tries
to avoid Legacy problems and maintain good performance.
I'll try and reproduce it on Windows by making the destination
ARGB_PRE. If that causes the same problem then it's probably in
our code and it will give me a better idea where to look.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Cameron McCormack <ca...@mcc.id.au>.
Hi Thomas.
Cameron McCormack:
> > ▪ flowBidi, which generates a StackOverflowException in some
> > java.awt.font and sun.font methods
Thomas DeWeese:
> Since the other flow tests work, can you sort out what
> method is causing the problem?
It looks to be a bug in the 1.6 beta JRE. The call from Batik’s code
is BidiAttributedCharacterIterator:121, where it creates a
java.awt.font.TextLayout object. The AttributedString that’s passed to
it is "Some (embedded bidi) of text.", where the text run in the
parentheses has a BIDI_EMBEDDING attributed on it. I’ve filed a bug on
Apple’s JRE.
> > ▪ batik70 (sample problem)
>
> I think the stroking problem on the 'i' is just
> a flaw in the Mac OS X stroker. I can't think of
> anything we can do. I checked to make sure that
> we add a 'close_path' in this case.
>
> For the background pattern I would try two things
> to try and sort things out. First remove the
> innerShadow filter on the ellipses. See if the
> color of the pattern goes back to normal.
>
> Second remove the use of the pattern and try
> putting a few copies of the pattern directly
> over the circles (to avoid rendering to a pattern
> buffer that is then composited).
Ok so it seems to be something to do with the going to a buffer for the
pattern. Here’s a reduced test case:
<svg xmlns="http://www.w3.org/2000/svg" width="400" height="200">
<rect width="400" height="200" fill="rgb(13, 97, 160)"/>
<g fill="rgb(110, 200, 255)">
<rect x="50" y="50" width="50" height="50"/>
<rect x="100" y="50" width="50" height="50" fill-opacity="0.8"/>
<rect x="100" y="100" width="50" height="50" fill-opacity="0.6"/>
<rect x="50" y="100" width="50" height="50" fill-opacity="0.4"/>
</g>
<pattern id="p" patternUnits="userSpaceOnUse" width="200" height="200"
fill="rgb(110, 200, 255)">
<rect x="50" y="50" width="50" height="50"/>
<rect x="100" y="50" width="50" height="50" fill-opacity="0.8"/>
<rect x="100" y="100" width="50" height="50" fill-opacity="0.6"/>
<rect x="50" y="100" width="50" height="50" fill-opacity="0.4"/>
</pattern>
<rect x="200" width="200" height="200" fill="url(#p)"/>
</svg>
This is how it renders:
http://mcc.id.au/temp/2007/composite.png
I tried to trace through the code to determine what
ColorModel/WritableRaster/SampleModel are used so I could reproduce the
rendering in a small test case. In the end I couldn’t, though. Do you
have a Mac to test with?
> > ▪ masking-mask-BE-0[56] (same problem)
> > ▪ histogramNormalization (same problem)
> > ▪ feConvolveMatrix (same problem)
>
> So there is something funny going on with
> alpha handling. I wonder if we aren't falling
> into our optimized code for MultiplyAlphaRed.
> The other possibility is that we might be
> getting the alpha pre-multipled state wrong
> (or the mac jvm doesn't handle one of the
> pre-multiplied states correctly).
I found the main BufferedImage that the whole document is rendered to is
TYPE_INT_ARGB_PRE, and the pattern BufferedImage is TYPE_INT_ARGB. In
my standalone test I tried painting a semi-opaque TYPE_INT_ARGB
BufferedImage to a TYPE_INT_ARGB_PRE one, but it worked properly.
> > The text ones all give correct rendering with a small rotation.
>
> I suppose it would be an option to add a small rotation to
> 'complex' texts (anything that adjusts individual glyph positions),
> on Mac OS X. However since this is fixed in Java 6 I'd rather just
> recommend people upgrade the JVM...
Maybe we could set the rendering hint that corresponds to
text-rendering="geometricPrecision" when rendering certain (or all)
text.
The 1.6 JRE isn’t released yet for OS X though, it’s just a beta (which
can only be downloaded by signing up for Apple’s Developer Centre
thingo).
> > > > http://mcc.id.au/temp/t/show?mac,linearGradientRepeat
> > >
> > > This looks to me like it's rendering the gradient at
> > > lower resolution than the reference.
> > >
> > > > http://mcc.id.au/temp/t/show?mac,gradientLimit
> > > > Top right gradient wrong.
> > >
> > > Once again I wonder if it's rendering at lower resolution...
> >
> > Anything that could be done about these?
>
> I don't know, someone must be scaling the buffer we give
> them for display. I don't know where that would be happening.
Is it enough of a corner case to ignore?
> > > > http://mcc.id.au/temp/t/show?mac,gradientPoint
> > > > Gradients wrong. Got this ouptut on the console, so it may be a
> VM
> > > > bug:
> > >
> > > It looks that way, perhaps it's requesting a _huge_ gradient
> > > bitmap (I noticed Mac OS X requests the entire gradient block at
> > > once instead of in small tiles).
> > >
> > > > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-05
> > > > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-06
> > > > Mask gradient wrong.
> > >
> > > Hmm, looks like the gradient opacity is being interpreted
> > > 'backwards'.
> >
> > Strange that it?s got opacity 1 on the top scan line.
>
> Well it's not uncommon to have a special case for opacity==1
> since you don't need to do compositing just copy. But that
> would indicate that there was something a little wonky inside
> their own code. But I'm actually leaning towards the problem
> being when the alpha is or isn't premultiplied (although I
> must admit that I'm having a hard time understanding how
> you get the result we see from that).
Could be part of the same compositing problem I guess. I’m not really
sure where to look though for this and the other alpha related problems.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by th...@kodak.com.
Hi Cameron,
Cameron McCormack <ca...@mcc.id.au> wrote on 02/06/2007 08:39:39 PM:
> Thomas DeWeese:
> > With the possible exception of italic text it looks to me
> > like these are all just cases of the Mac OS X glyph vector
> > class being hopelessly broken. Can you try adding a small
> > amount of rotation and seeing if that fixes most of these,
> > like it does for the 'flow text' stuff?
> >
> > Also are all these still broken in Java 6?
>
> I tried these all again on the 1.6 beta JRE on OS X. Everything now
> renders properly except:
Ok, this is very good news.
> ? flowBidi, which generates a StackOverflowException in some
> java.awt.font and sun.font methods
Since the other flow tests work, can you sort out what
method is causing the problem?
> ? batik70 (sample problem)
I think the stroking problem on the 'i' is just
a flaw in the Mac OS X stroker. I can't think of
anything we can do. I checked to make sure that
we add a 'close_path' in this case.
For the background pattern I would try two things
to try and sort things out. First remove the
innerShadow filter on the ellipses. See if the
color of the pattern goes back to normal.
Second remove the use of the pattern and try
putting a few copies of the pattern directly
over the circles (to avoid rendering to a pattern
buffer that is then composited).
> ? masking-mask-BE-0[56] (same problem)
> ? histogramNormalization (same problem)
> ? feConvolveMatrix (same problem)
So there is something funny going on with
alpha handling. I wonder if we aren't falling
into our optimized code for MultiplyAlphaRed.
The other possibility is that we might be
getting the alpha pre-multipled state wrong
(or the mac jvm doesn't handle one of the
pre-multiplied states correctly).
> The text ones all give correct rendering with a small rotation.
I suppose it would be an option to add a small rotation to
'complex' texts (anything that adjusts individual glyph positions),
on Mac OS X. However since this is fixed in Java 6 I'd rather just
recommend people upgrade the JVM...
> > > http://mcc.id.au/temp/t/show?mac,linearGradientRepeat
> >
> > This looks to me like it's rendering the gradient at
> > lower resolution than the reference.
> >
> > > http://mcc.id.au/temp/t/show?mac,gradientLimit
> > > Top right gradient wrong.
> >
> > Once again I wonder if it's rendering at lower resolution...
>
> Anything that could be done about these?
I don't know, someone must be scaling the buffer we give
them for display. I don't know where that would be happening.
> > > http://mcc.id.au/temp/t/show?mac,gradientPoint
> > > Gradients wrong. Got this ouptut on the console, so it may be a
VM
> > > bug:
> >
> > It looks that way, perhaps it's requesting a _huge_ gradient
> > bitmap (I noticed Mac OS X requests the entire gradient block at
> > once instead of in small tiles).
> >
> > > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-05
> > > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-06
> > > Mask gradient wrong.
> >
> > Hmm, looks like the gradient opacity is being interpreted
> > 'backwards'.
>
> Strange that it?s got opacity 1 on the top scan line.
Well it's not uncommon to have a special case for opacity==1
since you don't need to do compositing just copy. But that
would indicate that there was something a little wonky inside
their own code. But I'm actually leaning towards the problem
being when the alpha is or isn't premultiplied (although I
must admit that I'm having a hard time understanding how
you get the result we see from that).
> > > ? Non pixel aligning
> >
> > I don't know is this really important? I suspect
> > that it might be related to the fact that the Sun JVM
> > likes to snap end points to pixels, so it's possible
> > that the Mac OS rendering is the more 'correct' one.
> > We turn off the pixel snap when you set shape-rendering
> > to "geometricPrecision". You might see if they
> > render the same under that setting if so I would
> > write this off as unimportant (it can be controlled
> > through content).
>
> Yeah, adding shape-rendering="crispEdges" draws the lines
> exactly on the pixels.
>
> > > ? Opacity
> >
> > For the most part these are subtle. The 'paintOpacity'
> > test starts to get bad. I wonder if they aren't
> > just compositing in a different color space (linear for
> > example).
>
> Possibly. How can the colour space for compositing be controlled on the
> Graphics2D?
I think it should always use the destinations color space.
I wonder if they aren't moving bitmaps over to the graphics card
to do the compositing in HW? Still don't have any idea how we
might work around that though...
> > > ? Miscellaneous
> > Well, we do the masking implementation so I'm not sure how they
> > could make it aliased. Perhaps when we draw into the mask buffer
> > we don't turn on anti-aliasing.
>
> Hmm, that?s done in gvt.filter.MaskRable8Bit.createRendering yes? It
> looks to use the same method of painting to a buffer that other things
> use (getGraphicsNodeRable) so I dunno why it would not anti-alias.
Once again I'm willing to blame a fundamental problem in the
handling of transparent regions, with special case handling for
fully opaque (so just like mask-BE-05 once the alpha is slightly
less than 1 it goes essentially fully transparent).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Cameron McCormack <ca...@mcc.id.au>.
Thomas DeWeese:
> With the possible exception of italic text it looks to me
> like these are all just cases of the Mac OS X glyph vector
> class being hopelessly broken. Can you try adding a small
> amount of rotation and seeing if that fixes most of these,
> like it does for the 'flow text' stuff?
>
> Also are all these still broken in Java 6?
I tried these all again on the 1.6 beta JRE on OS X. Everything now
renders properly except:
▪ flowBidi, which generates a StackOverflowException in some
java.awt.font and sun.font methods
▪ masking-mask-BE-0[56] (same problem)
▪ batik70 (sample problem)
▪ histogramNormalization (same problem)
▪ feConvolveMatrix (same problem)
and the ones that aren’t really problems:
▪ maskRegions (same aliasing)
▪ fontOnPath (same strange text highlighting)
The text ones all give correct rendering with a small rotation.
> > http://mcc.id.au/temp/t/show?mac,linearGradientRepeat
>
> This looks to me like it's rendering the gradient at
> lower resolution than the reference.
>
> > http://mcc.id.au/temp/t/show?mac,gradientLimit
> > Top right gradient wrong.
>
> Once again I wonder if it's rendering at lower resolution...
Anything that could be done about these?
> > http://mcc.id.au/temp/t/show?mac,gradientPoint
> > Gradients wrong. Got this ouptut on the console, so it may be a VM
> > bug:
>
> It looks that way, perhaps it's requesting a _huge_ gradient
> bitmap (I noticed Mac OS X requests the entire gradient block at
> once instead of in small tiles).
>
> > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-05
> > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-06
> > Mask gradient wrong.
>
> Hmm, looks like the gradient opacity is being interpreted
> 'backwards'.
Strange that it’s got opacity 1 on the top scan line.
> > ? Non pixel aligning
>
> I don't know is this really important? I suspect
> that it might be related to the fact that the Sun JVM
> likes to snap end points to pixels, so it's possible
> that the Mac OS rendering is the more 'correct' one.
> We turn off the pixel snap when you set shape-rendering
> to "geometricPrecision". You might see if they
> render the same under that setting if so I would
> write this off as unimportant (it can be controlled
> through content).
Yeah, adding shape-rendering="crispEdges" draws the lines exactly on the
pixels.
> > ? Opacity
>
> For the most part these are subtle. The 'paintOpacity'
> test starts to get bad. I wonder if they aren't
> just compositing in a different color space (linear for
> example).
Possibly. How can the colour space for compositing be controlled on the
Graphics2D?
> > ? Miscellaneous
> >
> > http://mcc.id.au/temp/t/show?mac,batik70
> > The vertical stripe background renders incorrectly. The aqua stripe
> > seems to be pink. Also, the path forming the bottom part of the ?i?
> > glyph isn?t closed.
> >
> > http://mcc.id.au/temp/t/show?mac,moonPhases
> > The lat/long lines on the earths don?t show unless zoomed right in.
> >
> > http://mcc.id.au/temp/t/show?mac,histogramNormalization
> > Image normalisation not done.
> >
> > http://mcc.id.au/temp/t/show?mac,feConvolveMatrix
> > Bottom right case doesn?t have black in the right places.
>
> > http://mcc.id.au/temp/t/show?mac,maskRegions
> > Masking is not anti-aliased. (Maybe that?s just the Mac Java2D
> > implementation that defaults to non-anti-aliasing.)
>
> Well, we do the masking implementation so I'm not sure how they
> could make it aliased. Perhaps when we draw into the mask buffer
> we don't turn on anti-aliasing.
Hmm, that’s done in gvt.filter.MaskRable8Bit.createRendering yes? It
looks to use the same method of painting to a buffer that other things
use (getGraphicsNodeRable) so I dunno why it would not anti-alias.
> > http://mcc.id.au/temp/t/show?mac,fontOnPath
> > Text selection highlight looks a bit strange (white border is not
> > right on the edge of the highlight).
>
> There are some differences between how mac os X centers stroke
> on the fill.
>
> > These on Windows:
>
> I don't have any of these on my windows machine. What
> JVM are you running?
I was using 1.5.0_10-b03 on Windows. Maybe it’s the colour space stuff
that Dieter mentioned.
> Yah, I'm not too concerned with anything I see in the last set...
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Dieter von Holten <in...@dvholten.de>.
Hello,
seems you are running the tests with java6 ??
they changed the color-models to fix some bug.
so, anything dealing with colors may be slightly different.
this is what i got after i filed a bug-report:
>The reason why the file sRGB.pf was updated in fixing 6279846. You can read
that report for >details but it was correcting some colour conversion
problems and so perhaps these deviations >are just not what you expected.
We'd need a test case to do any further investigation.
file sRGB.pf sits in $JRE/lib/cmm.
When i saw this the first time, i scratched my head and thought 'were did
the reference images come from and what was the color model used to make
them?' .
of course, that doesnt help with the font-layout problems.
hth
dieter
----- Original Message -----
From: "Cameron McCormack" <ca...@mcc.id.au>
To: <ba...@xmlgraphics.apache.org>
Sent: Monday, February 05, 2007 3:45 AM
Subject: Re: Test failures
> Cameron McCormack:
> > http://mcc.id.au/temp/t/show?mac,gradientPoint
> > Gradients wrong. Got this ouptut on the console, so it may be a VM
> > bug:
> >
> > fox:~/work/svn/batik/trunk $ java -jar batik-1.6/batik.jar
samples/tests/spec/paints/gradientPoint.svg
>
> This one works and gives the correct rendering under the Apple
> 1.6.0-dp-b88 developer preview, incidentally.
>
> --
> Cameron McCormack, http://mcc.id.au/
> xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by Cameron McCormack <ca...@mcc.id.au>.
Cameron McCormack:
> http://mcc.id.au/temp/t/show?mac,gradientPoint
> Gradients wrong. Got this ouptut on the console, so it may be a VM
> bug:
>
> fox:~/work/svn/batik/trunk $ java -jar batik-1.6/batik.jar samples/tests/spec/paints/gradientPoint.svg
This one works and gives the correct rendering under the Apple
1.6.0-dp-b88 developer preview, incidentally.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Test failures
Posted by th...@kodak.com.
Hi Cameron,
Cameron McCormack <ca...@mcc.id.au> wrote on 02/04/2007 09:41:30 PM:
> After fixing the memory leak tests (made a couple of object references
> WeakReferences in the test classes?although it seems now that running
> those tests from the command line is fine, but in the whole regard test
> run I still get JFrame objects not cleared), I ran regard on my Linux
> (1.6.0-b105), Windows (1.5.0_10-b03) and Mac (1.5.0_06-64) machines.
I wouldn't worry about this, probably the object get's stuck
in a generation that isn't collected. If it runs fine by it's self
it is doubtful that there is a real problem.
> There are a number of problems on the Mac, which I would prefer to be
> fixed before the release if possible. The problems fall in to a few
> different categories:
>
> ? Text layout
With the possible exception of italic text it looks to me
like these are all just cases of the Mac OS X glyph vector
class being hopelessly broken. Can you try adding a small
amount of rotation and seeing if that fixes most of these,
like it does for the 'flow text' stuff?
Also are all these still broken in Java 6?
> Incorrect horizontal text placement of italic text.
> Incorrect vertical text placement.
> lengthAdjust="spacingAndGlyphs" not computed properly.
> Vertical text aligned horizontally instead.
> glyph-orientation-horizontal rotated text goes in the wrong
> direction.
> ? Flow text layout
> Text is all over the place.
> ? Flow text extension layout
>
> ? Gradients
Most of these look fairly ok.
> http://mcc.id.au/temp/t/show?mac,linearGradientRepeat
This looks to me like it's rendering the gradient at
lower resolution than the reference.
> http://mcc.id.au/temp/t/show?mac,gradientLimit
> Top right gradient wrong.
Once again I wonder if it's rendering at lower resolution...
> http://mcc.id.au/temp/t/show?mac,gradientPoint
> Gradients wrong. Got this ouptut on the console, so it may be a VM
> bug:
It looks that way, perhaps it's requesting a _huge_ gradient
bitmap (I noticed Mac OS X requests the entire gradient block at
once instead of in small tiles).
> http://mcc.id.au/temp/t/show?mac,masking-mask-BE-05
> http://mcc.id.au/temp/t/show?mac,masking-mask-BE-06
> Mask gradient wrong.
Hmm, looks like the gradient opacity is being interpreted
'backwards'.
> ? Non pixel aligning
I don't know is this really important? I suspect
that it might be related to the fact that the Sun JVM
likes to snap end points to pixels, so it's possible
that the Mac OS rendering is the more 'correct' one.
We turn off the pixel snap when you set shape-rendering
to "geometricPrecision". You might see if they
render the same under that setting if so I would
write this off as unimportant (it can be controlled
through content).
> ? Opacity
For the most part these are subtle. The 'paintOpacity'
test starts to get bad. I wonder if they aren't
just compositing in a different color space (linear for
example).
> ? Miscellaneous
>
> http://mcc.id.au/temp/t/show?mac,batik70
> The vertical stripe background renders incorrectly. The aqua stripe
> seems to be pink. Also, the path forming the bottom part of the ?i?
> glyph isn?t closed.
>
> http://mcc.id.au/temp/t/show?mac,moonPhases
> The lat/long lines on the earths don?t show unless zoomed right in.
>
> http://mcc.id.au/temp/t/show?mac,histogramNormalization
> Image normalisation not done.
>
> http://mcc.id.au/temp/t/show?mac,feConvolveMatrix
> Bottom right case doesn?t have black in the right places.
> http://mcc.id.au/temp/t/show?mac,maskRegions
> Masking is not anti-aliased. (Maybe that?s just the Mac Java2D
> implementation that defaults to non-anti-aliasing.)
Well, we do the masking implementation so I'm not sure how they
could make it aliased. Perhaps when we draw into the mask buffer
we don't turn on anti-aliasing.
> http://mcc.id.au/temp/t/show?mac,fontOnPath
> Text selection highlight looks a bit strange (white border is not
> right on the edge of the highlight).
There are some differences between how mac os X centers stroke
on the fill.
> These on Windows:
I don't have any of these on my windows machine. What
JVM are you running?
>
> ? Opacity
>
> http://mcc.id.au/temp/t/show?win,enableBackground,1,3
> http://mcc.id.au/temp/t/show?win,svgEnableBackground,1,3
> http://mcc.id.au/temp/t/show?win,paintOpacity,1,3
> http://mcc.id.au/temp/t/show?win,polygon_points2,1,3
> Semi-opaque paints are slightly different from the reference image.
>
> ? Gradients
>
> http://mcc.id.au/temp/t/show?win,feTile,1,3
> Colours slightly off.
> These on Linux:
Probably have the same root cause as above...
> ? Opacity
>
> http://mcc.id.au/temp/t/show?linux,enableBackground,1,3
> http://mcc.id.au/temp/t/show?linux,svgEnableBackground,1,3
> http://mcc.id.au/temp/t/show?linux,paintOpacity,1,3
> http://mcc.id.au/temp/t/show?linux,polygon_points2,1,3
> Semi-opaque paints are slightly different from the reference image.
>
> ? Gradients
>
> http://mcc.id.au/temp/t/show?linux,feTile,1,3
> Colours slightly off.
>
> ? ICC colour
>
> http://mcc.id.au/temp/t/show?linux,paintType,1,3
> http://mcc.id.au/temp/t/show?linux,color-colorProf-BE-03,1,3
> ICC colours render slightly differently from the reference image.
>
> Some of these may be just due to different JRE versions doing
> compositing a bit differently; whether they?re incorrect I?m not sure.
Yah, I'm not too concerned with anything I see in the last set...
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org