Is there a way to truncate the values in the path data?


#1

In some elements the path data is:

M 0.001999999862164259 41.59880065917969 C -1.626303258728257e-18 41.3223991394043 0 41.0463981628418 0 40.77040100097656 L 0 37.60000228881836 L 0 10.40000057220456 Z

Some values are even :

C -1.626303258728257e-18

I know computers like these numbers but when exporting SVG they actually add up in size which adds up in bandwidth if transferring over a network.

If they had smaller numbers they would also be easier to read.

Use Case:
Carol is an digital artist and is working with her client to create illustrations for her STEM app. The course material has her creating 100s of illustrations for their app

She is exporting to SVG to preserve the scaling on different devices. With 100 illustrations the app size grew to 100MB over the app limit.

Carol examined the SVG and realized that much precision wasn’t needed for her app. After editing the path data she was able to reduce the page size by 1/5th.


#2

Can’t you get the path data and walk it yourself, rounding to whatever you want, and then updating?


#3

In the past I was able to do something like that when I was able to get the commands as an array. I would feel more comfortable having command objects available than writing a parser from a string but if it came down to it I can write something or find a library for it.

I mention it in case it’s a relatively easy addition. Something like:

if (Settings.pathDataPrecision!=0) {
    value = parseInt(value * 100) / 100;
}

#4

I agree with @cpryland here: It isn’t too difficult to parse the string, and it – to me – would feel like cluttering up the APIs if something that can easily be done by us as developers gets “native” helpers.

I have nothing against an external library to do something like this (obviously :wink:) , but since path strings have a clearly specified grammar (and clearly specified semantics), parsing or manipulting them should be the responsibility of the developer and not the API. Including things like this in the APIs (and I guess that XD files store the path strings, so that would really just be an imaginary abstraction layer) would only mean that the APIs get less lightweight, meaning it would get much more difficult to get into plugin development.

More to the point: I think that the closer the APIs are to the “reality” of an XD file, the better (abstraction layers are good, but don’t belong into the APIs, but as third party libraries).


Add constants for frequently used types