Re: SMuFL

[Shane Brandes]

SMuFL has nothing much to do with preserving the Unicode standard. If
you can get the Unicode consortium to participate in outlining SMuFL
stuffs in its standard than it would be good, but an abstracted
standard used by one or two applications is a bad idea especially for
one text based like ours. It reduces the odds of universal support
that the Unicode consortium is trying to create. We don't need such an
extra layer of confusion. We just need to apply pressure to the
consortium to get the things that are missing encoded. That is my
stance.

Shane

On Fri, Aug 9, 2013 at 10:24 AM, Urs Liska <address@hidden> wrote:
> 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
>
>
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>