From David Webber:
> one for normal symbols
> another for clef changes
> another for cue notes
> another for grace notes
> another for cue grace notes
> another for clef changes on cued in staves
What about encoding these abstract values as characters (i.e. characters
without graphical representation)?
Then, to have cue-sized notehead, an application could use a sequence of
two characters CUE-SIZE + BLACK_NOTEHEAD; Then the font engine would
draw the correct glyph as a ligature (and 'liga' feature, unlike
stylistic alternates, is, as to my knowledge, commonly supported,
because some languages need it for correct spelling).
Three codepoints would be needed, for these abstract values:
- clef change (as this can have different look/scaling factor than cue-size)
- cue size
- grace note
It would be very inconvenient for part-time font designers, but seems to
make sense.
That would be convenient also for one very special case: there exists a
version of transposing ottava bassa g-clef for tenors in choir music,
which is basically a treble clef with a simplified version of an
old-style C-clef placed on third space (sic!). For correct setting in
cues, it cannot be just scaled (additional C-clef part must be smaller,
but still on the third space).
Emil Wojtacki
#############################################################
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]>
Locked
