SVG paths have 15 decimal points of precision #1152
Comments
|
Wow, that d3 issue has been open for nearly five years. Truncating to 3 decimal points of precision should be more than sufficient. As noted in the d3 issue, we should go with a custom rounding function rather than Something like: // Round to a maximum of 3 decimal places
function round3(x: number): string {
return (Math.round(x*1000)/1000).toString();
}
for (const x of [Math.PI, 1.0, 0.5555, 1.5555]) {
console.log(round3(-x), round3(x));
}
// Output:
-3.142 3.142
-1 1
-0.555 0.556
-1.555 1.556 |
|
Actually, I had to zoom right in to the pixels to spot a difference with only single decimal point of precision, so we could probably get away with only 2 digits of precision. 3 digits is definitely enough. Full precision: Single digit precision (the difference is most noticeable on the inside curve of the top half of the 3 in the time signature): Single digit precision diff: 2 digit precision: 2 digit precision diff: 3 digit precision: 3 digit precision diff: Treble clef path at full precision: Treble clef path at 2 digit precision: Treble clef path at 3 digit precision: |
|
It just occurred to me that I should have said "3 decimal places" not "3 digit precision". Sorry, I was working on a different kind of quantization all day today :) |
|
Cool. Thanks for looking into this! Can we get away with no rounding at all? I'd have to investigate, but I have a branch that is exploring 1) updating the Bravura / Petaluma font files, 2) getting rid of the NOGLYPH glyphs, and 3) trying to do as little transformation of the SVG path strings as possible. (Ideally the SVG path that we extract from the OTF is shoved directly into our final SVG output.) So far, I've extracted the updated fonts, and now use C for curves, instead of B. Looks OK so far. Baby steps! The gClef path looks like this at the moment: A couple things:
Assuming that the glyphs within a single font (e.g., Bravura) are all correctly sized relative to each other, can we stick these raw SVG paths into the same SVG group, and then apply a single transform to scale them all down? Of course, we'd have to handle things like grace notes where the glyphs are smaller, or superscript/subscript text, etc. Anyways, in an ideal world I think I'd like our rendered SVG to have as many integers as possible. I have no idea how much performance impact there will be if we scale groups of paths. I know you tested out We talked about this a few weeks ago: #1127 (comment) It might be time for me to finally investigate! I'll report back if I make any good progress. |
While looking at #1150, I noticed that our SVG outputs 15 decimal points of precision!
For a simple VexFlow demo like this:
The output SVG looks like this:
The PNG is 3KB and the SVG is 8KB of text. And indeed, when modifying our visual diffs to output SVG paths & files instead of PNG files, I noticed the tests ran slower and the output folder took up much more disk space. That's probably mostly due to PNG compression vs uncompressed SVG text.... but it would certainly make for smaller SVG files if we rounded.
For SVG path diffing, we might consider rounding down to 3 or 4 decimal points of precision.
I found this educational thread over at the d3 project:
d3/d3-path#10 (comment)
d3/d3-path#10 (comment)
d3/d3-path#10
The discussion (from a while ago) suggests that maybe the Chrome debugging experience suffers with excessively long SVG path strings.
In any case, SVG file sizes would be a bit smaller :-). Maybe we can round for the purposes of doing SVG diffing, since some of the comments suggest that different architectures might have tiny floating point differences that affect string diffing:
"The snapshot was generated on Mac but the unit tests were ran on Linux systems, and the floating point error makes the entire snapshot testing fail."
Originally posted in #1150 (comment)
The text was updated successfully, but these errors were encountered: