You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The metadata for Petaluma does not contain any sets. This is potentially problematic:
If I would like to use the small flag for eight notes, there is currently no reliable way to find it:
It is named flag8thUpShort, consistent with Bravura. However, this name is just a convention between those two fonts and not specified in SMuFL
flag8thUpShort show up under flag8thUpin glyphsWithAlternates in Petaluma. However, there is no way to tell the type of the alternative, it's just listed as one alternative out of three.
In Bravura, given the information in sets, these pieces of information can be put together, but sets is missing from Petaluma.
IMO, this is a flaw in SMuFL itself rather than in the fonts themselves: as SMuFL defines the type flagsShort, why isn't it possible to flag a certain alternate with "type": "flagsShort" instead of taking the long way through sets, inviting to situations like in Petaluma. Or, even better IMO, define fixed codepoints for the alternate glyphs in SMuFL! That would decrease the amount of work needed to find the correct codepoint for an alternative glyph.
The text was updated successfully, but these errors were encountered:
The metadata for Petaluma does not contain any sets. This is potentially problematic:
If I would like to use the small flag for eight notes, there is currently no reliable way to find it:
flag8thUpShort
, consistent with Bravura. However, this name is just a convention between those two fonts and not specified in SMuFLflag8thUpShort
show up underflag8thUp
inglyphsWithAlternates
in Petaluma. However, there is no way to tell the type of the alternative, it's just listed as one alternative out of three.In Bravura, given the information in
sets
, these pieces of information can be put together, butsets
is missing from Petaluma.IMO, this is a flaw in SMuFL itself rather than in the fonts themselves: as SMuFL defines the type
flagsShort
, why isn't it possible to flag a certainalternate
with"type": "flagsShort"
instead of taking the long way throughsets
, inviting to situations like in Petaluma. Or, even better IMO, define fixed codepoints for the alternate glyphs in SMuFL! That would decrease the amount of work needed to find the correct codepoint for an alternative glyph.The text was updated successfully, but these errors were encountered: