Re: SMuFL

[Urs Liska]

Am 09.08.2013 15:58, schrieb Carl Peterson:

On Fri, Aug 9, 2013 at 9:21 AM, Urs Liska <address@hidden> wrote:

Am 09.08.2013 15:11, schrieb Jan-Peter Voigt:

Of course I don't know that either, but I see a few steps:

1) Modify the mapping of glyphs to Unicode numbers
   I think that would be very simple, just a matter of remapping them in a suitable application.
   If LilyPond really accesses the glyphs by their names this wouldn't even imply any internal changes.

But then, if we intended to allow LilyPond to use other SMuFL-compliant fonts, there *would* be internal changes,

Yes, of course. What I meant is that, as a very first step, we could probably change the mapping of glyphs to codepoints without needing internal changes.

as we would have to have, at a minimum, a mapping table to convert glyph names to codepoints. The broader question for me is how many Feta glyphs *aren't* in the SMuFL standard and how many SMuFL/Unicode codepoints aren't already represented in Feta. Since they're looking for feedback, we may be able to "contribute to the community" by providing such a list of glyphs that may need to be added to the standard.

These are two different issues, I think:
Regarding glyphs defined in SMuFL that aren't present in Feta we could simply use them as inspiration what _could_ be added to Feta/LilyPond.
The standard doesn't require any specific coverage. Its point is to guarantee that _if_ a font provides e.g. the fermata sign it's guaranteed to be accessible at a specific codepoint.
The other way round is exactly as you say: making suggestions for additions to the standard is a good thing (only question: who'd volunteer comparing ...)
Maybe we should start with suggesting the CreativeCommons logo to balance the no-copying one ;-)

 

2) Adapt anchors and (perhaps) scaling
   If I understand the SMuFL specification correctly it also specifies where the anchors should be set in the glyphs.
   I don't know what this would mean in terms of development.
   Maybe it's 'just' a matter of updating the glyphs and one setting in LilyPond for each glyph.
   But it could also be that one would have to re-define the glyph positioning in LilyPond at a deeper level,
   with all kinds of possible side-effects ...

I read through/skimmed the SMuFL standard. The basic design concept/scale is a 1em high five-line staff. Pretty much anything that is positioned relative to a pitch is drawn so that the line y=0 in the glyph's coordinate system corresponds to the reference pitch. Flags have the attachment point as the origin. Generally all glyphs have x=0 at the leftmost edge. I don't know how that necessarily translates for our purposes,

I don't know either. I'm only afraid it couldn't be feasible to 'simply' modify the right parameters but that it could imply complete 'retuning' of the layout system.

Urs

Carl

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user