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 Tonny Kohar <to...@kiyut.com> on 2004/06/28 11:45:49 UTC
bugzilla during comiter absence
Hi,
I would like to ask the status of Batik bug found during commiter
absence and the provided fix (is it acceptable ?).
Here is the bugzilla ID, and the provided fix by various person.
- 28679 (Fill rule bug, it is fixed by Cameron McCormack, if the fix is
not on bugzilla, contact me/him, I still got his fix on my computer)
- 28035 (Default AttributeInitilizer bug)
- 28081 (Enhancement not bug regarding SVG DOM default attribute
generator)
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: bugzilla during comiter absence
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Cameron McCormack:
> > You could easily check this by removing or replacing with an 8,
> > the character '∞'. This doesn't help much with identifying
> > the problem font though...
>
> There are a few generic sounding fonts in that package, such as a
> Helvetica; it could be the culprit. I'll try finding which one is
> the problem font tomorrow.
Found the culprit: it is the URW++ Century Schoolbook L font that comes
in the gsfonts package. I can live without it.
/me returns to running regard
--
Cameron McCormack
| Web: http://mcc.id.au/
| ICQ: 26955922
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: bugzilla during comiter absence
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Thomas DeWeese:
> I don't think it is a good idea to try and bundle variations for
> various platforms, it is hard enough to maintain one good set of
> reference images (this might actually argue towards not including
> any reference images and have each person 'generate' there own
> set of reference images from a known good copy of Batik).
>
> Anyway I would suggest downloading a clean copy of Batik 1.5.1
> run regard there with 1.4 (once we sort out the font problem) and
> then just copy to candidate-variation files to your working copy
> of Batik as 'accepted-variation' files.
Ok then.
> For the font it appears to me that they are not including
> the infinity char in the embedded symbol font. In this case
> Batik will check every font installed on they system to try
> and locate a font that is capable of displaying the character.
> This is almost certainly why it is dying.
Well spotted. :-) I take it that's not deliberate though.
> You could easily check this by removing or replacing with an 8,
> the character '∞'. This doesn't help much with identifying
> the problem font though...
There are a few generic sounding fonts in that package, such as a
Helvetica; it could be the culprit. I'll try finding which one is
the problem font tomorrow.
Thanks,
Cameron
--
Cameron McCormack
| Web: http://mcc.id.au/
| ICQ: 26955922
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: bugzilla during comiter absence
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Cameron,
I don't think it is a good idea to try and bundle variations for
various platforms, it is hard enough to maintain one good set of
reference images (this might actually argue towards not including
any reference images and have each person 'generate' there own
set of reference images from a known good copy of Batik).
Anyway I would suggest downloading a clean copy of Batik 1.5.1
run regard there with 1.4 (once we sort out the font problem) and
then just copy to candidate-variation files to your working copy
of Batik as 'accepted-variation' files.
For the font it appears to me that they are not including
the infinity char in the embedded symbol font. In this case
Batik will check every font installed on they system to try
and locate a font that is capable of displaying the character.
This is almost certainly why it is dying.
You could easily check this by removing or replacing with an 8,
the character '∞'. This doesn't help much with identifying
the problem font though...
Cameron McCormack wrote:
> Thomas DeWeese:
>
>> What JDK are you using? 1.4? If so this is likely the problem
>>here. There are some subtle differences in the rendering. I'm a
>>little reluctant to move from 1.3 to 1.4 for testing because it means
>>that quite quickly Batik will likely only support 1.4 - and right now
>>there is no pressing issue with 1.3 compatibility (1.2 compat was
>>dropped because it was getting expensive).
>
>
> Yeah I'm using 1.4. Maybe there should be 1.4 variations included (or
> make 1.4 the standard and include 1.3 variations)?
>
> I'm not even sure if I can get the right libstdc++ libraries to work
> with the JDK 1.3 that I just downloaded!
>
>
>>> Running samples/mathMetal.svg
>>> java: ../../../src/share/native/sun/awt/font/t2k/t1.c:2171:
>>> tsi_T1GetGlyphIndexFromAdobeCode: Assertion `0' failed.
>>
>> Hmm, can you view mathMetal in squiggle? This looks to me like
>>you might have a 'corrupt' font on your system. You could look at
>>what fonts mathMetal uses and try 'hiding' them to isolate what one
>>is causing the problem.
>
>
> mathMetal seems to use only embedded fonts. The error sounds like it is
> in a Type 1 font.
>
> *tests*
>
> I removed the gsfonts-x11 package and now it seems to work. Doing this
> probably will break ghostscript or xpdf though, I guess.
>
> Maybe I'll just have to run the tests in Windows in vmware, but that would
> be fairly annoying and slow!
>
> Cameron
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: bugzilla during comiter absence
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Thomas DeWeese:
> What JDK are you using? 1.4? If so this is likely the problem
> here. There are some subtle differences in the rendering. I'm a
> little reluctant to move from 1.3 to 1.4 for testing because it means
> that quite quickly Batik will likely only support 1.4 - and right now
> there is no pressing issue with 1.3 compatibility (1.2 compat was
> dropped because it was getting expensive).
Yeah I'm using 1.4. Maybe there should be 1.4 variations included (or
make 1.4 the standard and include 1.3 variations)?
I'm not even sure if I can get the right libstdc++ libraries to work
with the JDK 1.3 that I just downloaded!
> > Running samples/mathMetal.svg
> > java: ../../../src/share/native/sun/awt/font/t2k/t1.c:2171:
> > tsi_T1GetGlyphIndexFromAdobeCode: Assertion `0' failed.
>
> Hmm, can you view mathMetal in squiggle? This looks to me like
> you might have a 'corrupt' font on your system. You could look at
> what fonts mathMetal uses and try 'hiding' them to isolate what one
> is causing the problem.
mathMetal seems to use only embedded fonts. The error sounds like it is
in a Type 1 font.
*tests*
I removed the gsfonts-x11 package and now it seems to work. Doing this
probably will break ghostscript or xpdf though, I guess.
Maybe I'll just have to run the tests in Windows in vmware, but that would
be fairly annoying and slow!
Cameron
--
Cameron McCormack
| Web: http://mcc.id.au/
| ICQ: 26955922
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: bugzilla during comiter absence
Posted by Thomas DeWeese <Th...@Kodak.com>.
Cameron McCormack wrote:
> Hi Thomas.
>
> Thomas DeWeese:
>
>> Let me know if you have any other questions about the tool
>>or how to run it.
>
>
> Ok, I downloaded and unzipped the SVG test cases and I'm trying to run
> "build regard". I get this output:
>
> Could not open variation url : file:/base/cam/work/xml-batik/test-references/samples/accepted-variation/anne.png
> >>>>>>>>>>>>>>>>>>>>>> Rendering is not accurate
> Running samples/asf-logo.svg
> Could not open variation url : file:/base/cam/work/xml-batik/test-references/samples/accepted-variation/asf-logo.png
> >>>>>>>>>>>>>>>>>>>>>> Rendering is not accurate
What JDK are you using? 1.4? If so this is likely the problem
here. There are some subtle differences in the rendering. I'm a
little reluctant to move from 1.3 to 1.4 for testing because it means
that quite quickly Batik will likely only support 1.4 - and right now
there is no pressing issue with 1.3 compatibility (1.2 compat was
dropped because it was getting expensive).
> Running samples/mathMetal.svg
> java: ../../../src/share/native/sun/awt/font/t2k/t1.c:2171: tsi_T1GetGlyphIndexFromAdobeCode: Assertion `0' failed.
Hmm, can you view mathMetal in squiggle? This looks to me like
you might have a 'corrupt' font on your system. You could look at
what fonts mathMetal uses and try 'hiding' them to isolate what one
is causing the problem.
> Java Result: 129
>
> BUILD SUCCESSFUL
>
> Total time: 4 minutes 52 seconds
>
> Any idea? I did think that I would get some inaccurate renderings
> because of text, but some of the examples there (such as the Apache
> logo) don't have text. The assertion is a bit of a worry too. :/
>
> Cameron
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: bugzilla during comiter absence
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Hi Thomas.
Thomas DeWeese:
> Let me know if you have any other questions about the tool
> or how to run it.
Ok, I downloaded and unzipped the SVG test cases and I'm trying to run
"build regard". I get this output:
Could not open variation url : file:/base/cam/work/xml-batik/test-references/samples/accepted-variation/anne.png
>>>>>>>>>>>>>>>>>>>>>> Rendering is not accurate
Running samples/asf-logo.svg
Could not open variation url : file:/base/cam/work/xml-batik/test-references/samples/accepted-variation/asf-logo.png
>>>>>>>>>>>>>>>>>>>>>> Rendering is not accurate
Running samples/barChart.svg
Could not open variation url : file:/base/cam/work/xml-batik/test-references/samples/accepted-variation/barChart.png
>>>>>>>>>>>>>>>>>>>>>> Rendering is not accurate
Running samples/batik3D.svg
Could not open variation url : file:/base/cam/work/xml-batik/test-references/samples/accepted-variation/batik3D.png
>>>>>>>>>>>>>>>>>>>>>> Rendering is not accurate
[...]
Could not open variation url : file:/base/cam/work/xml-batik/test-references/samples/accepted-variation/mapSpain.png
>>>>>>>>>>>>>>>>>>>>>> Rendering is not accurate
Running samples/mapWaadt.svg
Could not open variation url : file:/base/cam/work/xml-batik/test-references/samples/accepted-variation/mapWaadt.png
>>>>>>>>>>>>>>>>>>>>>> Rendering is not accurate
Running samples/mathMetal.svg
java: ../../../src/share/native/sun/awt/font/t2k/t1.c:2171: tsi_T1GetGlyphIndexFromAdobeCode: Assertion `0' failed.
Java Result: 129
BUILD SUCCESSFUL
Total time: 4 minutes 52 seconds
Any idea? I did think that I would get some inaccurate renderings
because of text, but some of the examples there (such as the Apache
logo) don't have text. The assertion is a bit of a worry too. :/
Cameron
--
Cameron McCormack
| Web: http://mcc.id.au/
| ICQ: 26955922
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: bugzilla during comiter absence
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Cameron,
The basic criteria for checking stuff in is running
'regard' on the code. To run regard you need to have
a copy of the W3C SVG test suite (the directory should
be named 'beSuite') as a sibling of the xml-batik directory.
You should be able to get it from:
http://www.w3.org/Graphics/SVG/Test/20011026/rel-20011026.zip
Then you should be able to type:
$ build regard
This should then go off and run around a 1000 tests on Batik
and generate a summary of failures in:
xml-batik/test-reports/[date-time]
You can then look at html/regardReport.html in your web
browser to see what went wrong. You are likely to have some
differences due to fonts etc.
One nice thing is that if you decide a difference is harmless
you can copy a 'variation' file from the 'candidate-variation'
directory to the 'accepted-variation' directory (these are in
test-references in a structure that mimics the 'samples' directory
tree). From then on regard will consider the test to pass as
long is the variation stays constant
You can also give the name or part of a name to regard and it
will only run those tests. For example:
build regard text
Will run only those tests that have 'text' in their name.
This is helpful if you are debugging a failed test. In general
we try to add new tests when we fix a failure. The list of
tests to run lives in test-resources/org/apache/batik/test/regard.xml
which references other files listing tests, most of the 'samples'
tests are called out in .../batik/test/samplesRendering.xml.
Let me know if you have any other questions about the tool
or how to run it.
Cameron McCormack wrote:
> Tonny Kohar:
>
>>I would like to ask the status of Batik bug found during commiter
>>absence and the provided fix (is it acceptable ?).
>>
>>Here is the bugzilla ID, and the provided fix by various person.
>>- 28679 (Fill rule bug, it is fixed by Cameron McCormack, if the fix is
>>not on bugzilla, contact me/him, I still got his fix on my computer)
>>- 28035 (Default AttributeInitilizer bug)
>>- 28081 (Enhancement not bug regarding SVG DOM default attribute
>>generator)
>
>
> I could commit them now, but I think I need guidance from Thomas and
> Vincent: for small patches likes these do I need to check in regard
> tests as well? If not what sort of things do I need to do make tests
> for? (I've been looking through the test directories to get acquainted
> with the architecture; I don't want to start checking in willy nilly.)
> Are you keeping any separate branches for major additions to the
> codebase?
>
> Thanks,
>
> Cameron
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: bugzilla during comiter absence
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Tonny Kohar:
> I would like to ask the status of Batik bug found during commiter
> absence and the provided fix (is it acceptable ?).
>
> Here is the bugzilla ID, and the provided fix by various person.
> - 28679 (Fill rule bug, it is fixed by Cameron McCormack, if the fix is
> not on bugzilla, contact me/him, I still got his fix on my computer)
> - 28035 (Default AttributeInitilizer bug)
> - 28081 (Enhancement not bug regarding SVG DOM default attribute
> generator)
I could commit them now, but I think I need guidance from Thomas and
Vincent: for small patches likes these do I need to check in regard
tests as well? If not what sort of things do I need to do make tests
for? (I've been looking through the test directories to get acquainted
with the architecture; I don't want to start checking in willy nilly.)
Are you keeping any separate branches for major additions to the
codebase?
Thanks,
Cameron
--
Cameron McCormack
| Web: http://mcc.id.au/
| ICQ: 26955922
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org