RE: [Inkscape-user] Cut off digits after decimal point automatically?
That's a good point you raise about throwing out zeros first because they are not significant digits.
It would be interesting to see a script that compressed the image by removing extra digits as Henning suggested, but also allowed you to determine how much loss you were willing to accept. With the range of compression options such as:
- lossless where it only throws out zeros eg. .75000000 >> .75, 143.23123576 >> 143.23123576
- lots of loss rounds all coordinates to nearest whole number, all opacity values to
two decimal digits (so the percentage is a whole number) eg. .75000000 >> .75, 143.23123576 >> 143
- somewhere in between allows a user to specify how many digits to round off eg. .750 >> .75, 143.23123576 >> 143.231
I'm sure it would be possible to further optimize the compression by doing things like changing path names to shorter values, remove whitespace, convert styles to a style sheet, etc.
- Dave
-----Original Message----- From: inkscape-user-admin@lists.sourceforge.net [mailto:inkscape-user-admin@lists.sourceforge.net] On Behalf Of mental@...32... Sent: Thursday, November 17, 2005 8:51 AM To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] Cut off digits after decimal point automatically?
Quoting Henning Pingel <henning.pingel@...26...>:
It should work like this:
Before:
<path d="M 197.50906,180.93358 C 208.42611,171.19005243.09749,175.25444 255.13174,160.93358 C 258.56906,156.84315 258.33300,147.20836 258.33300,140.93358"
style="fill:none;fill-opacity:0.75000000;fill-rule:evenodd;stroke:#00000 0;stroke-width:1.0585089px;stroke-linecap:butt;stroke-linejoin:miter;str oke-opacity:1.0000000"
id="path1310" />After:
<path d="M 197,180 C 208,171 243,175 255,160 C 258,156 258,147258,140"
style="fill:none;fill-opacity:0.75000000;fill-rule:evenodd;stroke:#00000 0;stroke-width:1.0585089px;stroke-linecap:butt;stroke-linejoin:miter;str oke-opacity:1.0000000"
id="path1310" />Thanks in advance!
It seems like the numbers like 0.75000000 would be better candidates for throwing out digits (as those zeroes are not significant).
For paths, throwing out the fractional part of all coordinates is likely to cause visible distortions.
-mental
------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id%16845&op=ick _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Dave Holmes wrote:
... It would be interesting to see a script that compressed the image by removing extra digits as Henning suggested, but also allowed you to determine how much loss you were willing to accept. With the range of compression options such as:
lossless where it only throws out zeros eg. .75000000 >> .75, 143.23123576 >> 143.23123576
lots of loss rounds all coordinates to nearest whole number, all opacity values to
two decimal digits (so the percentage is a whole number) eg. .75000000 >> .75, 143.23123576 >> 143
somewhere in between allows a user to specify how many digits to round off eg. .750 >> .75, 143.23123576 >> 143.231
...
It might be more useful to let a user specify the number of significant digits. This should give much more consistent results.
Jasper van de Gronde wrote:
It might be more useful to let a user specify the number of significant digits. This should give much more consistent results.
Might as well add my 2 cents. I would find even more useful retroactive grid snapping, ie. round all units to the nearest 1/4 inch.
Aaron Spike
aaron@...476... wrote:
Might as well add my 2 cents. I would find even more useful retroactive grid snapping, ie. round all units to the nearest 1/4 inch.
I second this. I remember going through a small drawing in Sodipodi trying to do this in the XML editor. It turned out to be a huge pain that I never want to have to do again.
- somewhere in between allows a user to specify how many digits to round off eg. .750 >> .75, 143.23123576 >> 143.231
...
It might be more useful to let a user specify the number of significant digits. This should give much more consistent results.
How about to within an error margin...
You lose alot more detail rounding 1.4444 -> 1 rather than rounding 1.9999 -> 2
Maybe what is needed is a kind of 'normalise'.
Think of a particularly bad case for rounding, say a rectangle with the left side with an X of 1.5 and the other at 3.0 Say you rounded to 0dp, then the left side moves 30%, but the right side moves 0. I wonder if you could not massage the points a bit so they both move around the same sort of amount.
Would this preserve the 'image' better?! (*shrug*)
-kt
(non-removable crud below) --
Please consider our environment before printing this email.
WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately.
It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments.
This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision.
Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency.
Westpac Banking Corporation ABN 33 007 457 141.
On Fri, Nov 18, 2005 at 10:43:48AM +1100, Kinsley Turner wrote:
- somewhere in between allows a user to specify how many digits to round off eg. .750 >> .75, 143.23123576 >> 143.231
...
It might be more useful to let a user specify the number of significant digits. This should give much more consistent results.
How about to within an error margin...
You lose alot more detail rounding 1.4444 -> 1 rather than rounding 1.9999 -> 2
Maybe what is needed is a kind of 'normalise'.
Think of a particularly bad case for rounding, say a rectangle with the left side with an X of 1.5 and the other at 3.0 Say you rounded to 0dp, then the left side moves 30%, but the right side moves 0. I wonder if you could not massage the points a bit so they both move around the same sort of amount.
Would this preserve the 'image' better?! (*shrug*)
There's some code I wrote a long time ago that does these sorts of number formatting mechanisms. It's in the 'experimental' cvs module under bryce/ftos/ if anyone would like to play with hooking it up for Inkscape.
It does the basic "drop trailing 0's" stuff, plus has options for doing sigfigs and controlled precision. Usage:
// string ftos(double val[, char mode[, int sigfig[, int precision[, int options]]]])
// sigfig - the number of significant figures. These are the digits // that are "retained". For example, the following numbers // all have four sigfigs: // 1234 12.34 0.0001234 1.234e-10 // the last digit shown will be rounded in the standard // manner (down if the next digit is less than 5, up otherwise.) // // precision - the number of digits to show to the right of the decimal. // For example, all of the following numbers have precisions // of 2: // 1234.00 12.34 0.00 1.23e-10 123.40e-12 //
(It's got some other formatting features like engineering style, or with 42x10^12 instead of 42E12, although obviously we wouldn't need those styles.)
Anyway, I think the work of hooking this up would involve adding a user preference variable somewhere for keeping track of the preferred sigfigs and then inserting this ftos() routine at the point where numbers get exported, and of course some GUI stuff for the user to type in their desired sig fig value. Maybe there's more to it beyond that... I think pjrm looked at it at one point so he'd be a good one to ask.
It'd be interesting to see how badly the rounding would affect things. I'd done some analysis to see how the rounding propagated (for an engineering program I was developing), and found that even small errors would tend to propagate pretty quickly, but if it's only used during document save, as it would be in Inkscape, then the impact may be minimal.
Personally, it was only the excessive .00000's that bugged me, and I was happy to see Peter fixed that; I don't mind so much that there are extra digits in other numbers, but certainly for numbers like 1.999999 or 0.7500001 it would be nice to see those rounded off. If anyone's bugged enough to want to fix it, feel free to play with ftos() and if it'd work ok.
Bryce
Bryce Harrington wrote:
// string ftos(double val[, char mode[, int sigfig[, int precision[, int options]]]])
I think this solution is the only one which might work. Always rounding to a fixed value inch doesn't work: Imagine, you have a small graph which is scaled up.
If we just round to a certain fraction of inches or millimeters, this graph will become a dot.
It'd be interesting to see how badly the rounding would affect things. I'd done some analysis to see how the rounding propagated (for an engineering program I was developing), and found that even small errors would tend to propagate pretty quickly, but if it's only used during document save, as it would be in Inkscape, then the impact may be minimal.
This is true but remember that the saved document will be loaded again, eventually. Many load/save cycles shouldn't deteriorate the image, either. And the setting must be something which the user (who has no idea what's going on) doesn't notice.
Otherwise, he'll save the image, open it the other day and scream.
Quoting Aaron Digulla <digulla@...310...>:
Otherwise, he'll save the image, open it the other day and scream.
By the way, this is the very reason that we don't do other often-requested destructive optimizations on save, either (e.g. vaccuum defs).
-mental
On Fri, Nov 18, 2005 at 08:23:36PM +0100, Aaron Digulla wrote:
It'd be interesting to see how badly the rounding would affect things. I'd done some analysis to see how the rounding propagated (for an engineering program I was developing), and found that even small errors would tend to propagate pretty quickly, but if it's only used during document save, as it would be in Inkscape, then the impact may be minimal.
This is true but remember that the saved document will be loaded again, eventually. Many load/save cycles shouldn't deteriorate the image, either. And the setting must be something which the user (who has no idea what's going on) doesn't notice.
Otherwise, he'll save the image, open it the other day and scream.
Well, presumably this would be an option that would be off by default, so he'd select it only if he specifically wanted it (sort of like the 'save as plan svg' option.
Bryce
On Fri, 18 Nov 2005 mental@...32... wrote:
Date: Fri, 18 Nov 2005 14:43:57 -0500 From: mental@...32... Reply-To: inkscape-user@lists.sourceforge.net To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] Cut off digits after decimal point automatically?
Quoting Aaron Digulla <digulla@...310...>:
Otherwise, he'll save the image, open it the other day and scream.
By the way, this is the very reason that we don't do other often-requested destructive optimizations on save, either (e.g. vaccuum defs).
Would be nicer though if defs, gradients, color swatches and other resources could be collected for general reuse rather than bogging down a file with with predefined objects which are *not actually being used* (and I'm fairly sure there is a request to that effect already in the tracker).
- Alan
On Fri, 2005-11-18 at 22:59 +0000, Alan Horkan wrote:
Would be nicer though if defs, gradients, color swatches and other resources could be collected for general reuse rather than bogging down a file with with predefined objects which are *not actually being used* (and I'm fairly sure there is a request to that effect already in the tracker).
Yep. Actually, I used to do that quite a lot back when I still created SVGs by hand -- created separate "library" files for common props and things.
Of course that is yet another reason not to automatically "vaccuum defs" on save. Imagine the consequences it would have if you edited and saved such a library file!
-mental
On Nov 18, 2005, at 3:53 PM, MenTaLguY wrote:
On Fri, 2005-11-18 at 22:59 +0000, Alan Horkan wrote:
Would be nicer though if defs, gradients, color swatches and other resources could be collected for general reuse rather than bogging down a file with with predefined objects which are *not actually being used* (and I'm fairly sure there is a request to that effect already in the tracker).
Yep. Actually, I used to do that quite a lot back when I still created SVGs by hand -- created separate "library" files for common props and things.
I think I need to get more into actually producing artwork with Inkscape. Once I do, the pedantic programmer in me will get me to address this.
Now that CSS support has come in, we can get more traction on actually fixing things.
participants (10)
-
unknown＠example.com -
Aaron Digulla -
Alan Horkan -
Bryce Harrington -
Dave Holmes -
Jasper van de Gronde -
Jon A. Cruz -
Kinsley Turner -
Kyle -
MenTaLguY