On 25-Nov-2014 03:46, Tavmjong Bah wrote:
- % values on root 'width' and 'height'
I saw something on IRC about % values on the root SVG 'width' and 'height'. This is actually a very common use case for web designers where the SVG is to automatically fill a space. Inkscape treats % values on the 'width' and 'height' by using the values from the 'viewBox' (or if there is no 'viewBox' it assumes all values are in pixels).
If you would like to weigh in, there is an open bug concerning that second case here:
https://bugs.launchpad.net/inkscape/+bug/1245989
where at least in some versions (I have not checked lately) it was opening these files as an unusable 1x1 px image.
- Precision
We allow the user to set the numerical precision to up to 16 digits. This makes little sense given that floats are good to only 6 or 7.
IEEE 754 specifies 6-9 digit text representations, see page 4
http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
The meaning of that range is specifically that for a conforming implementation, when numbers are converted textA -> internal 32bit float -> textB, then textA must be identical to textB.
Is the numerical precision you are referring to just for the GUI or does it also include values written to the SVG file? Is it total displayed digits or just digits after the decimal point?
In any case, MAX_PRECISION (or whatever it is called in Inkscape) needs to be set by the underlying float type. Going to double precision for internal calculations is fine but if the SVG specifies that values must be 32 bit floats then the corresponding fields in the objects should be as well. So maybe 9, but definitely not 16. Otherwise we will run into situations where a file will look one way in Inkscape, then save, reopen, will look slightly different, due to the loss of precision on conversion for the save. It might be a tiny difference, but it still shouldn't happen. One reason to insist on perfect "round trip" performance is that it greatly simplifies testing - just use "diff" on the input and output and if they are the same the test is passed. If tiny changes in precision are allowed then determining "pass" in such a test often becomes incredibly messy.
- Converting between 90/96 dpi
I think our focus here is to do the minimum possible to convert an SVG file between 90 and 96 dpi. Trying to scale everything inside the file is rarely going to work satisfactory for a file of any complexity.
As in it currently fails with clipping, patterns, and anything that refers to something stored in <defs>. There are several related bugs about this, here is one:
https://bugs.launchpad.net/inkscape/+bug/1348417
a. Add a 'viewBox'
If a file has been created to a specific size using only user units, say A4 at 90dpi, using on user-units then one can set the SVG root to be:
<svg width="210mm" height="297mm" viewBox="0 0 744.09448819 1052.3622047" ...>
Sounds like the simplest solution.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech