Hi,
I would like to have an option in "simplify" that puts the control points on pixel boundaries, in order to reduce the precision of the numbers in the svg file.
Now every floating point number has 5 digits, whereas 0 or 1 digit would probably not make a visually significant change.
-- lode
lode leroy wrote:
I would like to have an option in "simplify" that puts the control points on pixel boundaries, in order to reduce the precision of the numbers in the svg file.
Now every floating point number has 5 digits, whereas 0 or 1 digit would probably not make a visually significant change.
Me Too. Sounds like an excellent idea for an extension. Throwing something together quickly will help to show 1) how this is useful (eg. retroactive snapping, file size compression, etc.) and 2) how you see it best implemented. It would probably need to be an output extension because Inkscape will convert the numbers back into floats on load. It would be cool to pursue "SVG Compression Techniques" a bit further and distill appropriate PATH segments into their shorthand counterparts (eg. L becomes H or V). If not an extension, I think the idea probably deserves an RFE.
Aaron Spike
On Jul 7, 2005, at 5:09 AM, aaron@...749... wrote:
lode leroy wrote:
I would like to have an option in "simplify" that puts the control points on pixel boundaries, in order to reduce the precision of the numbers in the svg file. Now every floating point number has 5 digits, whereas 0 or 1 digit would probably not make a visually significant change.
Me Too. Sounds like an excellent idea for an extension.
Ahhh...
But there's a problem.
What's a pixel???
Are we 90 DPI, 75 DPI, 72 DPI...?
I think there are a few things that need to get settled down in the code before pixel-level accuracy can be hit. Unfortunately that might included changes needed for "target profile" support. Fortunately, that work will probably address this and similar issues.
Of course, it's set to happen at "some point in the future", so the schedule is not fixed.
Jon A. Cruz wrote:
Ahhh...
But there's a problem.
What's a pixel???
Are we 90 DPI, 75 DPI, 72 DPI...?
I think there are a few things that need to get settled down in the code before pixel-level accuracy can be hit. Unfortunately that might included changes needed for "target profile" support. Fortunately, that work will probably address this and similar issues.
Of course, it's set to happen at "some point in the future", so the schedule is not fixed.
That's right. No rasters here. ^^
I was thinking about this. Would someone really want to put an arbitrary limit on precision? What kind of granularity is proper?
For example, this PDF highway map of California: http://gocalif.ca.gov/tourism/pdfs/Map_CAstate.pdf
Imaging this recast as SVG.
If its resolution were limited, then the macro image would be ok, but the fine detail would be illegible. One would not be able to zoom in and still have accurate lines, or font->curve conversion.
IMHO, it should not necessarily be a fixed precision, but a "best fit" for the given dynamic range of the whole image.
-Or- it might be to use a selected percentage of the dimensions of the page's viewBox.
Bob
Bob Jamison wrote:
Jon A. Cruz wrote:
But there's a problem. What's a pixel??? Are we 90 DPI, 75 DPI, 72 DPI...?
That's right. No rasters here. ^^
No, not a problem. The user decides when they make the choice to save with rounded units.
I was thinking about this. Would someone really want to put an arbitrary limit on precision? What kind of granularity is proper?
Not an arbitrary limit, a user defined limit.
For example, this PDF highway map of California: http://gocalif.ca.gov/tourism/pdfs/Map_CAstate.pdf
Imaging this recast as SVG.
If its resolution were limited, then the macro image would be ok, but the fine detail would be illegible. One would not be able to zoom in and still have accurate lines, or font->curve conversion.
I think that image is a bad example. No one would want to reduce the precision of a detailed map. At least I wouldn't want to. Beautiful artistic pieces aren't in the running either. Let me dream up a few use cases.
#1 A Patern: I want to make a toy out of cardboard for a child. I choose to draw a patern for the toy in Inkscape because its bezier is easy to use. After I rough out the basic design I decided I should have been snapping to a grid every quarter inch so that it would have been easier to transfer on to the cardboard. Instead of grid snapping every point by hand, I use the reduce precision effect and snap all my points to the nearest quarter inch. (yes internally the effect needs to figure out how to round to the SVG User Unin nearest to a quarter inch.) Lost precision helps me.
#2 Outside Inkscape: Writing a program that uses SVG paths internally to represent various shapes perhaps hundreds map symbols. Using inkscape again because it is easy. In order to make file size smaller I would like to round all paths to the nearest .05 which I have decided is plenty of precision for my application.
Sure these are rare cases. That is why it should be an extension. I don't know if either of these things are what the original poster had in mind. But use two is one of the first things I found myself doing with Inkscape using electric guitar body shapes not map symbols. Perhaps reduced precision sounds to negative. How about float rounding or lossy float compression.
Aaron Spike
On Sat, 9 Jul 2005, Bob Jamison wrote:
Date: Sat, 09 Jul 2005 03:54:21 -0500 From: Bob Jamison <rwjj@...127...> To: Jon A. Cruz <jon@...18...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Req: reduced precision
Jon A. Cruz wrote:
Ahhh...
But there's a problem.
What's a pixel???
Are we 90 DPI, 75 DPI, 72 DPI...?
I think there are a few things that need to get settled down in the code before pixel-level accuracy can be hit. Unfortunately that might included changes needed for "target profile" support. Fortunately, that work will probably address this and similar issues.
Of course, it's set to happen at "some point in the future", so the schedule is not fixed.
That's right. No rasters here. ^^
I was thinking about this. Would someone really want to put an arbitrary limit on precision? What kind of granularity is proper?
I was thinking another approach might be to have snap to grid enabled with a very small grid to help ensure most coordinates were nice rounded integer numbers and then use some crude find and replace to cleanup the markup. (Replacing .00000 with blank is about as easy as it gets, on a good day though I might get organised and put together some scripts.)
I also thought the Simplyfy command might take into account trying to use more rounded numbers, but I dont know if that is the case.
Mabye others are looking for something different but I'm looking for cleaner markup that makes it easier for me to tweak things in an external editor.
On of these days I might finally start writing my own SVG Tidy scripts.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Sat, Jul 09, 2005 at 10:26:46PM +0100, Alan Horkan wrote:
I was thinking another approach might be to have snap to grid enabled with a very small grid to help ensure most coordinates were nice rounded integer numbers and then use some crude find and replace to cleanup the markup. (Replacing .00000 with blank is about as easy as it gets, on a good day though I might get organised and put together some scripts.)
Re cleaning up the .0000000 stuff, my preferred approach is to trim zeros after decimal point from all numbers. I have a patch to do this, and will post about it with subject line `trimming trailing zeros in output'.
pjrm.
On Fri, Jul 08, 2005 at 09:00:29PM -0700, Jon A. Cruz wrote:
lode leroy wrote:
I would like to have an option in "simplify" that puts the control points on pixel boundaries, in order to reduce the precision of the numbers in the svg file. Now every floating point number has 5 digits, whereas 0 or 1 digit would probably not make a visually significant change.
Ahhh...
But there's a problem.
What's a pixel???
Are we 90 DPI, 75 DPI, 72 DPI...?
In this context, I suppose it means a user unit in the <svg> element's coordinate space.
We don't in general know how many mm a user unit is; though if the outermost <svg> element has a viewBox attribute and has width & height attributes specified in mm/in/pt/... then we at least know the default size of a user unit if the viewing program hasn't overridden our specified width/height hints.
Similarly, we don't in general know how many device pixels or even CSS px a user unit is, though the default interpretation in absence of a viewBox attribute would be for one user unit to equal one CSS px, and for a CSS px to be an integer number of device pixels.
pjrm.
participants (7)
-
unknown＠example.com -
Aaron and Sarah Spike -
Alan Horkan -
Bob Jamison -
Jon A. Cruz -
lode leroy -
Peter Moulder