Am 09.08.2013 15:58, schrieb Carl Peterson:
On Fri, Aug 9, 2013 at 9:21 AM, Urs Liska <u...@openlilylib.org
<mailto:u...@openlilylib.org>> 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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
