[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

glyph-path-regexp in SVG output is overly strict

From: Simon Tatham
Subject: glyph-path-regexp in SVG output is overly strict
Date: Thu, 20 Feb 2020 18:33:24 +0000
User-agent: Sup/git

A user of my notation font Gonville reported to me this week that they
had tried to use the Lilypond SVG backend with Gonville, and had found
that everything worked fine except that the sharp signs were
mysteriously missing from the output.

I debugged the problem and found that this happened because Fontforge
had generated the SVG path string for that glyph in a way that happened
to include the floating-point literal "9.91821e-05", written in
scientific notation, and that the 'glyph-path-regexp' definition in
output-svg.scm was failing to match the path string as a result, because
it doesn't permit the letter 'e'.

I was able to work around the issue by editing my SVG font file to
re-express that number as 0.0000991821, without the 'e'. But as far as I
can see, scientific notation of that form is legal per the SVG spec:

Applying the attached patch against output-svg.scm also solved the
problem for me, and I think it's a better fix.


for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print("".join([chr(32+3*((k>>x)&1))for x in range(79)])) # <address@hidden>

Attachment: 0001-SVG-Permit-e-to-appear-in-SVG-font-glyph-paths.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]