Appended is a patch to trim trailing zeros after the decimal point, so that `10.000000' becomes `10', and `1.500000' becomes `1.5'.
(A couple of people have complained about our trailing zeros.)
Given that we're so near to release, I didn't want to commit without discussing here first, i.e. whether to wait until after 0.42.
This affects both SVG and eps/ps output, and possibly other formats.
Are there any situations where e.g. `4' would have a different meaning from `4.0' or `4.0000000' ? E.g. in C `4.0 / 3' means something different from `4 / 3'; are there any similar cases in postscript or something ?
Testing done so far:
Inkscape compiles, and passes its test suite (make check).
HEAD-inkscape --export-plain-svg=a0.svg share/examples/art-nouveau-P3.svg trim-inkscape --export-plain-svg=at.svg share/examples/art-nouveau-P3.svg diff -du a[0t].svg | less (manual checking for bad differences)
# Compare eps output from the trimmed and HEAD versions of inkscape, # in an attempt to pick up differences in meaning of the two SVG # files. HEAD-inkscape --export-eps=a0-0.eps a0.svg HEAD-inkscape --export-eps=at-0.eps at.svg diff a[0t]-0.eps # produces no output
trim-inkscape --export-eps=a0-t.eps a0.svg trim-inkscape --export-eps=at-t.eps at.svg diff a[0t]-t.eps # produces no output
diff -du a0-[0t].eps | less (manual checking for bad differences; though I'm not very familiar with postscript)
# Generalize the gives-same-eps test. for i in share/examples/*.{svg,svgz}; do HEAD-inkscape --export-plain-svg=$HOME/tmp/a0.svg $i if trim-inkscape --export-plain-svg=$HOME/tmp/at.svg $i; then :; else echo "$i to plain failed" fi for f in 0 t; do HEAD-inkscape --export-eps=$HOME/tmp/a$f-0.eps ~/tmp/a$f.svg done diff -u ~/tmp/a[0t]-0.eps|head|grep -q . && echo "$i has diffs" done
At the time of writing, I haven't actually run inkscape in its gui mode: I've done the change remotely. Of course I'll do that too before committing.
Another thing I'll do before committing (but haven't yet done) is to create a new unit test.
What are people's comments about whether to include this in 0.42 or not? What further testing would be needed if it were to be in 0.42 ?
pjrm.
On Wednesday 13 July 2005 11:08, Peter Moulder wrote:
Appended is a patch to trim trailing zeros after the decimal point, so that `10.000000' becomes `10', and `1.500000' becomes `1.5'.
(A couple of people have complained about our trailing zeros.)
Given that we're so near to release, I didn't want to commit without discussing here first, i.e. whether to wait until after 0.42.
This affects both SVG and eps/ps output, and possibly other formats.
Are there any situations where e.g. `4' would have a different meaning from `4.0' or `4.0000000' ? E.g. in C `4.0 / 3' means something different from `4 / 3'; are there any similar cases in postscript or something ?
Testing done so far:
Inkscape compiles, and passes its test suite (make check).
HEAD-inkscape --export-plain-svg=a0.svg share/examples/art-nouveau-P3.svg trim-inkscape --export-plain-svg=at.svg share/examples/art-nouveau-P3.svg diff -du a[0t].svg | less (manual checking for bad differences)
# Compare eps output from the trimmed and HEAD versions of inkscape, # in an attempt to pick up differences in meaning of the two SVG # files. HEAD-inkscape --export-eps=a0-0.eps a0.svg HEAD-inkscape --export-eps=at-0.eps at.svg diff a[0t]-0.eps # produces no output
trim-inkscape --export-eps=a0-t.eps a0.svg trim-inkscape --export-eps=at-t.eps at.svg diff a[0t]-t.eps # produces no output
diff -du a0-[0t].eps | less (manual checking for bad differences; though I'm not very familiar with postscript)
# Generalize the gives-same-eps test. for i in share/examples/*.{svg,svgz}; do HEAD-inkscape --export-plain-svg=$HOME/tmp/a0.svg $i if trim-inkscape --export-plain-svg=$HOME/tmp/at.svg $i; then :; else echo "$i to plain failed" fi for f in 0 t; do HEAD-inkscape --export-eps=$HOME/tmp/a$f-0.eps ~/tmp/a$f.svg done diff -u ~/tmp/a[0t]-0.eps|head|grep -q . && echo "$i has diffs" done
At the time of writing, I haven't actually run inkscape in its gui mode: I've done the change remotely. Of course I'll do that too before committing.
Another thing I'll do before committing (but haven't yet done) is to create a new unit test.
What are people's comments about whether to include this in 0.42 or not? What further testing would be needed if it were to be in 0.42 ?
pjrm.
Don't know if anyone has mailed you off list but no replies here so far. Simply trimming doubles or floats like 10.000000 to 4.0 to 10 or 4 may (probably? will) cause loss of accuracy if every instance is not checked. Converting 10.000000 to 10.0 is safer.
While I'm not on the Inkscape team, reading where things are at in the 0.42 process, I'd be checking and rechecking the result of the script and checking into 0.43cvs after 0.42 is released.
Craig
On Wed, Jul 13, 2005 at 07:08:22PM +1000, Peter Moulder wrote:
Appended is a patch to trim trailing zeros after the decimal point, so that `10.000000' becomes `10', and `1.500000' becomes `1.5'.
What are people's comments about whether to include this in 0.42 or not? What further testing would be needed if it were to be in 0.42 ?
pjrm.
Perhaps since the amount of time we have to test pre-release is limited, you could include a commandline option to allow users to switch to the old behavior. This would also be useful in testing, since people would be able to try it both ways and see if it produces different results. The option would then be removed for 0.43.
I'm glad to see this implemented; this had been somewhere down on my todo list too. :-)
Bryce
Judging from Craig & Bryce's comments, it sounds like this is for after 0.42.
Re command-line switch: someone sufficiently interested to use a command-line switch might also be sufficiently interested to use CVS, so I'll keep things simple.
pjrm.
participants (3)
-
Bryce Harrington -
Craig Bradney -
Peter Moulder