glyph-path-regexp in SVG output is overly strict

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

glyph-path-regexp in SVG output is overly strict

Simon Tatham
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:
https://www.w3.org/TR/2011/REC-SVG11-20110816/paths.html#PathDataBNF

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

Cheers,
Simon

--
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)])) # <[hidden email]>

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond

0001-SVG-Permit-e-to-appear-in-SVG-font-glyph-paths.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

pkx166h-4
Hello Simon,

On 20/02/2020 18:33, Simon Tatham wrote:

> 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:
> https://www.w3.org/TR/2011/REC-SVG11-20110816/paths.html#PathDataBNF
>
> Applying the attached patch against output-svg.scm also solved the
> problem for me, and I think it's a better fix.
>
> Cheers,
> Simon

Thanks I'll shepherd the patch through our normal patch review process -
I'll cc you on the review in case the 'real' LilyPond developers have
any concerns/questions/comments (I am not really a developer, I just
help with testing and submitting 'drive-by' patches).

Thanks again.

James


_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

James Lowe-7
In reply to this post by Simon Tatham
@bug

On 20/02/2020 18:33, Simon Tatham wrote:

> 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:
> https://www.w3.org/TR/2011/REC-SVG11-20110816/paths.html#PathDataBNF
>
> Applying the attached patch against output-svg.scm also solved the
> problem for me, and I think it's a better fix.
>
> Cheers,
> Simon

I created https://sourceforge.net/p/testlilyissues/issues/5779/ for this
issue.

James


_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

Bugs mailing list
In reply to this post by pkx166h-4
Hi Simon,

Am Freitag, den 21.02.2020, 09:29 +0000 schrieb [hidden email]:

> Hello Simon,
>
> On 20/02/2020 18:33, Simon Tatham wrote:
> > 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:
> > https://www.w3.org/TR/2011/REC-SVG11-20110816/paths.html#PathDataBNF
> >
> >
> > Applying the attached patch against output-svg.scm also solved the
> > problem for me, and I think it's a better fix.
> >
> > Cheers,
> > Simon
>
> Thanks I'll shepherd the patch through our normal patch review process -
> I'll cc you on the review in case the 'real' LilyPond developers have
> any concerns/questions/comments (I am not really a developer, I just
> help with testing and submitting 'drive-by' patches).
looking at https://sourceforge.net/p/testlilyissues/issues/5779/ and
the grammar you linked, I think the regular expression is also missing
'+Aa,'. Does it make sense to fuse attached patch?

Jonas

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond

0002-Also-allow-Aa-in-SVG-path-descriptions.patch (1K) Download Attachment
signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

Simon Tatham
Jonas Hahnfeld <[hidden email]> wrote:
> looking at https://sourceforge.net/p/testlilyissues/issues/5779/ and
> the grammar you linked, I think the regular expression is also missing
> '+Aa,'. Does it make sense to fuse attached patch?

The idea looks sensible to me, but I think you've made a mistake in the
regular expression syntax. The character '-' has to appear immediately
after the open bracket, otherwise it's taken to be the punctuation in a
range such as "A-Z". So the character class
[+-MmZzLlHhVvCcSsQqTtAa0-9,.Ee\n ] will match (at least) any character
between '+' and 'M'.

If you start the brackets with [-+Mm...] instead of [+-Mm...] then I
think it does what you intended.

Cheers,
Simon

--
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)])) # <[hidden email]>

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

pkx166h-4
Jonas

On 21/02/2020 11:33, Simon Tatham wrote:

> Jonas Hahnfeld <[hidden email]> wrote:
>> looking at https://sourceforge.net/p/testlilyissues/issues/5779/ and
>> the grammar you linked, I think the regular expression is also missing
>> '+Aa,'. Does it make sense to fuse attached patch?
> The idea looks sensible to me, but I think you've made a mistake in the
> regular expression syntax. The character '-' has to appear immediately
> after the open bracket, otherwise it's taken to be the punctuation in a
> range such as "A-Z". So the character class
> [+-MmZzLlHhVvCcSsQqTtAa0-9,.Ee\n ] will match (at least) any character
> between '+' and 'M'.
>
> If you start the brackets with [-+Mm...] instead of [+-Mm...] then I
> think it does what you intended.
>
> Cheers,
> Simon

I am not sure if this will update the tracker as Simon would have to
have the correct rights (he only contributes occasionally like this so
probably won't be interested in general LP development) the point is
that I may have to cut/paste his reply into the tracker if this is the
case so others can follow.

James




_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

Bugs mailing list
Am Freitag, den 21.02.2020, 11:50 +0000 schrieb pkx166h:

> Jonas
>
> On 21/02/2020 11:33, Simon Tatham wrote:
> > Jonas Hahnfeld <
> > [hidden email]
> > > wrote:
> > > looking at
> > > https://sourceforge.net/p/testlilyissues/issues/5779/
> > >  and
> > > the grammar you linked, I think the regular expression is also missing
> > > '+Aa,'. Does it make sense to fuse attached patch?
> >
> > The idea looks sensible to me, but I think you've made a mistake in the
> > regular expression syntax. The character '-' has to appear immediately
> > after the open bracket, otherwise it's taken to be the punctuation in a
> > range such as "A-Z". So the character class
> > [+-MmZzLlHhVvCcSsQqTtAa0-9,.Ee\n ] will match (at least) any character
> > between '+' and 'M'.
> >
> > If you start the brackets with [-+Mm...] instead of [+-Mm...] then I
> > think it does what you intended.
> >
> > Cheers,
> > Simon
>
> I am not sure if this will update the tracker as Simon would have to
> have the correct rights (he only contributes occasionally like this so
> probably won't be interested in general LP development) the point is
> that I may have to cut/paste his reply into the tracker if this is the
> case so others can follow.
It probably won't... If you don't mind, I'll carry the two commits over
to Rietveld so we can go through the review cycle and copy Simon's
reply (which is fully correct!) to SF. Ok?

Jonas

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

Bugs mailing list
In reply to this post by Simon Tatham
Am Freitag, den 21.02.2020, 11:33 +0000 schrieb Simon Tatham:

> Jonas Hahnfeld <
> [hidden email]
> > wrote:
> > looking at
> > https://sourceforge.net/p/testlilyissues/issues/5779/
> >  and
> > the grammar you linked, I think the regular expression is also missing
> > '+Aa,'. Does it make sense to fuse attached patch?
>
> The idea looks sensible to me, but I think you've made a mistake in the
> regular expression syntax. The character '-' has to appear immediately
> after the open bracket, otherwise it's taken to be the punctuation in a
> range such as "A-Z". So the character class
> [+-MmZzLlHhVvCcSsQqTtAa0-9,.Ee\n ] will match (at least) any character
> between '+' and 'M'.
>
> If you start the brackets with [-+Mm...] instead of [+-Mm...] then I
> think it does what you intended.
Absolutely correct, good spot. Luckily (for my testing) '-' is between
'+' and 'M', but that's actually too broad. Will fix the patch.

Thanks
Jonas

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

pkx166h-4
In reply to this post by Bugs mailing list
Jonas,

On 21/02/2020 11:54, Jonas Hahnfeld wrote:

> Am Freitag, den 21.02.2020, 11:50 +0000 schrieb pkx166h:
>> Jonas
>>
>> On 21/02/2020 11:33, Simon Tatham wrote:
>>> Jonas Hahnfeld <
>>> [hidden email]
>>>> wrote:
>>>> looking at
>>>> https://sourceforge.net/p/testlilyissues/issues/5779/
>>>>   and
>>>> the grammar you linked, I think the regular expression is also missing
>>>> '+Aa,'. Does it make sense to fuse attached patch?
>>> The idea looks sensible to me, but I think you've made a mistake in the
>>> regular expression syntax. The character '-' has to appear immediately
>>> after the open bracket, otherwise it's taken to be the punctuation in a
>>> range such as "A-Z". So the character class
>>> [+-MmZzLlHhVvCcSsQqTtAa0-9,.Ee\n ] will match (at least) any character
>>> between '+' and 'M'.
>>>
>>> If you start the brackets with [-+Mm...] instead of [+-Mm...] then I
>>> think it does what you intended.
>>>
>>> Cheers,
>>> Simon
>> I am not sure if this will update the tracker as Simon would have to
>> have the correct rights (he only contributes occasionally like this so
>> probably won't be interested in general LP development) the point is
>> that I may have to cut/paste his reply into the tracker if this is the
>> case so others can follow.
> It probably won't... If you don't mind, I'll carry the two commits over
> to Rietveld so we can go through the review cycle and copy Simon's
> reply (which is fully correct!) to SF. Ok?

Be my guest.

It'd take some load off of me and you can talk to Simon in a language he
will understand.

I did a quick test with Simon's patch (I didn't configure my work
machine to upload using git-cl so I have no rietveld only the tracker)
and it did pass all tests.

James



_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: glyph-path-regexp in SVG output is overly strict

Bugs mailing list
In reply to this post by Bugs mailing list
Am Freitag, den 21.02.2020, 12:58 +0100 schrieb Jonas Hahnfeld via bug-
lilypond:

> Am Freitag, den 21.02.2020, 11:33 +0000 schrieb Simon Tatham:
> > Jonas Hahnfeld <
> > [hidden email]
> >
> > > wrote:
> > > looking at
> > > https://sourceforge.net/p/testlilyissues/issues/5779/
> > >
> > >  and
> > > the grammar you linked, I think the regular expression is also missing
> > > '+Aa,'. Does it make sense to fuse attached patch?
> >
> > The idea looks sensible to me, but I think you've made a mistake in the
> > regular expression syntax. The character '-' has to appear immediately
> > after the open bracket, otherwise it's taken to be the punctuation in a
> > range such as "A-Z". So the character class
> > [+-MmZzLlHhVvCcSsQqTtAa0-9,.Ee\n ] will match (at least) any character
> > between '+' and 'M'.
> >
> > If you start the brackets with [-+Mm...] instead of [+-Mm...] then I
> > think it does what you intended.
>
> Absolutely correct, good spot. Luckily (for my testing) '-' is between
> '+' and 'M', but that's actually too broad. Will fix the patch.
Hi Simon,

the patches are now in master (actually since Tuesday). Additionally
David has applied them to stable/2.20 and they will be part of the
imminent stable release 2.20!
Thanks again for your contribution and the concise descriptions.

Regards,
Jonas

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond

signature.asc (499 bytes) Download Attachment