[HN Gopher] SVG passthrough precision
___________________________________________________________________
SVG passthrough precision
Author : zdw
Score : 86 points
Date : 2022-04-18 16:23 UTC (6 hours ago)
(HTM) web link (bjango.com)
(TXT) w3m dump (bjango.com)
| yumindev wrote:
| interesting
| sings wrote:
| I wonder whether you could work around these precision issues
| using the viewBox attribute, but I expect most of this software
| would just strip it out.
| PaulHoule wrote:
| I was thinking that the perfect SVG editor would use arbitrary-
| precision decimal math so that you'd never run into those 0.1 +
| 0.2 != 0.3 problems that are endemic when you use those "floating
| point" numbers that are approximate to those phony "real" numbers
| Cantor warned you about.
|
| (Baudrillard would say that anybody using the word "real" is
| trying to bind you with illusion and like a wolf that craps on a
| trap to protect the pack he crapped on that word pretty bad!)
| legulere wrote:
| The question is what you try to achieve. At a certain precision
| you won't get any difference in any rasterized image anymore so
| you do not really care anymore. The SVG standard agrees there
| and states that 32 bit floating point is enough. IEEE binary
| floating point numbers are widely supported and performant.
|
| You can easily sidestep problems with errors of calculation
| (which includes already parsing decimal floats into binary
| floats, and happens here also with addition) by keeping the
| error smaller than what you care about: Read in as double
| precision float and use double for calculation, convert back to
| single precision before converting to decimal floating point.
| The error you will do in double precision will be smaller than
| what you loose converting to single precision. You can use that
| for SVG path optimization where you will run across
| 0.1+0.2!=0.3 problems.
|
| If you really want exact measurements, then you would want
| fractional numbers, so you can also cut lengths in e.g. three
| precisely.
| 3r3rni9 wrote:
| Came here to mention this, seeing those high precision decimals
| -- if you ever need to use their dimensions in any DOM
| arethmetic, be sure your process converts those to integers and
| back first (or use a lib like BigNumber, or the new JS BigInt).
| Many experienced front end devs ignore floating point issues
| unless they're doing financial math, then wonder why their
| JavaScript CSS calculations won't work out precicely.
| PaulHoule wrote:
| In the case of the SVG editor I'd really like something that
| round-trips to and from SVG that looks nice in a text editor.
|
| In a case like that it should "snap-to-grid" on the last
| decimal place of the number that's being edited, maybe the
| grid should even be displayed on the screen. That grid might
| be rotated or skewed because of coordinate transforms, and
| there ought to be some way to add another digit worth of
| fineness if not a factor of 2 or 5.
| MauranKilom wrote:
| The Save As clearly outputs single precision floats.
|
| Try putting the input values into e.g.
| https://www.h-schmidt.net/FloatConverter/IEEE754.html - the
| outputs are just the closest representable float numbers
| (converted back to a reasonable base-10 representation).
| perardi wrote:
| _"Being a large app with multiple ways to do almost everything,
| Illustrator also has multiple methods to export SVGs."_
|
| Bravo for phrasing that neutrally, because I see at least 4 ways
| to export SVGs, and I have no idea what Adobe actually _wants_
| you to use, because I increasingly think Adobe hates you.
|
| 1. Export for Screens... (which is what I generally use)
|
| 2. Export As...
|
| 3. The Asset Export panel.
|
| 4. Save As...
|
| The first 3 all use the same export engine (or at least I think
| they do), but they all expose the settings in different
| locations. And then there is Save As... which tends to mangle
| things, as described in the article, and also lets you save as
| SVGZ, which is supposedly compressed, but it's not.
| andrewmcwatters wrote:
| I wonder if they should all be exporting, if possible, up to
| DBL_DIG?
| addaon wrote:
| The general rule for serializing floating point representations
| to strings is not to output a fixed number of digits (DBL_DIG
| or otherwise), but rather to output sufficient digits that your
| inverse operation of parsing gives a bitwise identical floating
| point number.
| ResNet wrote:
| This is a nice dive. I've also came across some SVG libraries
| that end up converting SVG path coordinates from original
| floating point values into integers, and then apply a
| scale/transform to that path to get the desired final size.
| Presumably this is/was faster for complicated paths or other
| elements.
| klodolph wrote:
| There are various reasons why integers are convenient to work
| with, it's not all about performance.
| btrettel wrote:
| This is interesting as I would have assumed that formats like SVG
| are "lossless" and wouldn't suffer from generation loss [0], but
| I hadn't considered that internally software might round some
| numbers.
|
| [0] https://en.wikipedia.org/wiki/Generation_loss
| anecd0te wrote:
| What I've found working with geometric data like SVG is that
| your software will use some kind of internal representation
| that looks quite different than SVG, so you will do some kind
| of parsing into your data structure and then serializing out to
| SVG at the end. Even doing something like
| serialize(parse(number)) is not guaranteed to be lossless.
|
| The only way to avoid doing that losslessly is to track the
| original text that you parsed into your IR nodes, which is a
| bit expensive if you think about it. A double is 64 bits, most
| shape/path data is packed and dense lists of doubles.
| Interleaving strings or ids that can be used to track them can
| be really annoying to thread through your program without
| performance or memory issues.
| TobTobXX wrote:
| Inkscape is close to that. An Inkscape save file is a valid
| SVG file, but some SVG processors don't display all things
| correctly, so it also allows you to export it as "Plain SVG".
| But most browsers would read an inkscape save file just fine.
|
| (Note that if you want to serve the SVG file, you should
| still "export as SVG" it, since Inkscape embeds a lot of
| semi-sensitive informations into the SVG like file path etc.)
| YakBizzarro wrote:
| Inkscape is missing there, and it scores perfectly, no precision
| loss. The only discrepancy (apart from the XML formatting), is
| the addition of an ID to each object, if missing
| danbee wrote:
| Inkscape is great, but it's almost unusably slow on macOS,
| especially Intel based Macs.
| McKayDavis wrote:
| Often, you can considerably reduce the file size of an SVG text
| file without a noticeable reduction in perceptual quality just by
| reducing the precision of the coordinates.
|
| The awesome SVG Optimizer [1] has a filter (cleanupNumericValues)
| to process SVG files to a fixed precision.
|
| The equally awesome SVG Optimizer Missing Gui (SVGOMG) [2]
| provides a web-based GUI [3] to interactively adjust precision
| and see the resulting render (and file-size).
|
| [1] https://github.com/svg/svgo
|
| [2] https://github.com/jakearchibald/svgomg
|
| [3] https://jakearchibald.github.io/svgomg
| jjcm wrote:
| Super cool and simple test! One nitpick is the author says the
| following:
|
| > "Black is the default shape colour for SVGs, so the fill
| attribute can be omitted entirely, as per the source SVG."
|
| This isn't entirely true, as there's a specificity difference
| between having the attribute and not having it. I'm not sure
| which is the "right" approach though for a design tool. If this
| were purely a svg command line tool, I'd expect there to be no
| additional metadata, but considering this is the export from a
| design tool, I'm not sure what the right approach is. When you
| export something you often want it to look exactly as it is on
| the canvas, not to dynamically change color if there's a `fill`
| css declaration somewhere up the chain. Both Sketch and Figma*
| look like they've made the decision to go with consistency of
| visuals rather than consistency of meaning.
|
| Very impressed with Sketch here in how accurately it preserves
| the precision, but disappointed it's exporting with non-unique
| IDs. Illustrator feels like it's doing a very Adobe thing - two
| different ways of doing something in the app results in either
| the best output or the worst output. Figma I'm disappointed
| transforms the rects into paths. This feels like it's optimizing
| for the general case rather than what the best output might be.
| I'll lump XD into the same category here with their transform
| hack for positioning. Not a fan of either.
|
| * Disclaimer: I work for Figma.
___________________________________________________________________
(page generated 2022-04-18 23:00 UTC)