[smufl-discuss] Re: script for generating minimal metadata

[Robert Piéchaud]

Hello Abraham,

You’re welcome (and thanks to you, or whomever dit it, for making it somewhat more phython-looking - I confess my python skills are somewhat unsophisticated!)

Regarding the issue you mention, my solution has been in fact _unicode-name_ = _human-friendly-name_, so the json metadata make sense for the eye.

This doesn’t seem to be a problem at all in real situations (since we are dealing with Unicode Private Areas anyway) but this leads nonetheless to the question of glyph name length limit of 31 characters.
FontForge does complain about it (upon OK-ing the glyph info dbx) but I work around it by editing the .sfd file directly afterwards. This concerns only several characters (microtonal accidentals etc.)
No problem upon font generation.

I have always wondered whether this 31-character limit was but imaginary.

By the way, November 2.0 will offer advanced support for LilyPond as well ( 2.19+). I am following Nathan Ho’s footsteps closely…:-)

Robert

> On 18 Dec 2014, at 14:54, Abraham Lee <[hidden email]> wrote:
>
>> Hello all,
>>
>> Here is a python script for FontForge to generate the very basic metadata, as discussed earlier.
>> (@Laurent: couldn’t wait…;-)  )
>>
>> http://www.codeshare.io/KWPDG
>>
>> It must be called from the font’s directory but could be easily modified to be invoked from within FontForge.
>>
>> Robert
>
> Robert,
>
> Thanks for sharing that code! Very concise and gets the job done.
>
> There's only one problem (Daniel, if you could please chime in on
> this). The metadata glyph names end up being the _unicode_ names, not
> the _human-friendly_ names (like "noteheadBlack").
>
> Is this an issue? I can see developers of notation applications
> choosing one over the other, but, since this is about standardizing
> things, I think we need to decide which way it's going to be. I guess
> it's not important if this script isn't made publicly available.
> Otherwise, it needs addressing.
>
> I guess I'm wondering if the glyph names can be the human-friendly
> names, since they are already mapped to a unicode character within the
> font. Seems redundant to have its name referencing the same unicode
> location. Maybe it's just me. Any thoughts?
>
> I have created a small mapping script that addresses this issue. It
> converts the unicode glyph names, as found in "Bravura.otf", to the
> human-friendly names, like is found in "bravura_metadata.json". It
> uses "glyphnames.json" which is graciously provided on the SMuFL site.
> The issue here is that it requires the above script to know where it
> is located. Easy to do, but for now must be done manually.
>
> Regards,
> Abraham
>
> #############################################################
> This message is sent to you because you are subscribed to
>  the mailing list <[hidden email]>.
> To unsubscribe, E-mail to: <[hidden email]>
> To switch to the DIGEST mode, E-mail to <[hidden email]>
> To switch to the INDEX mode, E-mail to <[hidden email]>
> Send administrative queries to  <[hidden email]>
>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>

[tisimst]

Robert Piéchaud wrote

Hello Abraham,

You’re welcome (and thanks to you, or whomever dit it, for making it somewhat more phython-looking - I confess my python skills are somewhat unsophisticated!)

You're welcome, too :)

Robert Piéchaud wrote

Regarding the issue you mention, my solution has been in fact _unicode-name_ = _human-friendly-name_, so the json metadata make sense for the eye.

This doesn’t seem to be a problem at all in real situations (since we are dealing with Unicode Private Areas anyway) but this leads nonetheless to the question of glyph name length limit of 31 characters.
FontForge does complain about it (upon OK-ing the glyph info dbx) but I work around it by editing the .sfd file directly afterwards. This concerns only several characters (microtonal accidentals etc.)
No problem upon font generation.

I have always wondered whether this 31-character limit was but imaginary.

@Daniel: Any thoughts on the matter?

Robert Piéchaud wrote

By the way, November 2.0 will offer advanced support for LilyPond as well ( 2.19+). I am following Nathan Ho’s footsteps closely…:-)

Robert

Are you talking about the efforts on openlilylib? Making November work with LilyPond is easier than that. If you are interested in collaborating, I'd be happy to assist you with making November LilyPond-compatible, too! You could say that I've had a little experience doing that (see http://fonts.openlilylib.org). No pressure, but would be very cool, I think, for those who want to use it. If you are interested, let's communicate about it privately since it's off-topic to this forum.

Regards,
Abraham