[smufl-discuss] Re: Private use area?

[Emil B. Wojtacki]

Daniel wrote:

> Emil wrote:
>
>> Additionally, in some output conditions, there is sometimes an issue
>> with scaled objects, which appear too thin. For instance, at some staff
>> sizes and resolutions, the width of the hair stroke of a treble clef is
>> rendered with two pixels line, whereas a scaled clef (at clef change,
>> 75%) has its hair stroke rendered with just one pixel line (way too
>> thin). This should be avoided, and including the glyphs for changing
>> clef is the most elegant solution.
> I certainly don't dispute that it is important to be *able* to use
> alternate glyphs for clef changes. However, I still don't believe that
> clef changes are intrinsically any different than any other glyphs that
> are identical in form but required at a different size relative to the
> staff, such as accidentals, articulations, noteheads, flags, etc., which
> amounts to hundreds of different glyphs.
>
> The same argument about strokes becoming too thin when glyphs are drawn at
> a smaller size surely applies to all of these other cases too (the
> vertical stem on a flat, the angled lines of an accent, etc. etc.). Are we
> also going to include all of these glyphs at multiple sizes at recommended
> code points? Surely not -- but why not, given the rationale stated above?

You are right, this could apply to grace and cue notes as well. But I
would compare them to different type cases (in the old typographical
meaning -- boxes for types, "Setzkasten" in German). So grace notes with
their accidentals and articulations belong to "case with graces", and
cue notes with their decorations -- to "case with cues".

If there arises a problem with too thin strokes in sharps in cue notes,
then it is not such a big issue (I like David's comparison to footnotes)
-- cues are simply a different case, so a difference in relative
blackness is acceptable (exactly as with footnotes). The same could
apply to graces.

But clef changes belong to to the basic case. There are no accompanying
accents, accidentals, ornaments in "clef change" size -- they are set
between noteheads, accents and flags of the regular size. Additionaly,
cues have sometimes their own clef changes (maintaining them in smaller
size helps to point out the actual entry of the instrument).


> A number of different solutions are possible without arbitrarily assigning
> clef changes special status, as I have outlined already: the one I favour
> for Bravura is defining a stylistic set containing optical variants for
> the common glyphs (not only clefs, but also noteheads, accidentals,
> articulations, dynamics, time signature digits, and so on); Dave has
> talked about inserting his three required glyphs into the "private use
> area"; and there are probably others, too.

I would not call it "special status", it is just a status of a basic
symbol. The number of solutions *is* a problem. It equals the loose in
compatibility: font designers will address needs of different apps --
let me quote --  "in an uncoordinated and haphazard fashion, leading to
significant inconsistencies"...

By the way: the problem of stylistic alternates is more complex. Should
they be designed so, that:
   (1) the intended appearance is achieved at the same font size, or rather
   (2) that they have proper size after scaling down to, say, 72%?
The second solution is counter-intuitive, as the glyph, which is
intended to appear as smaller,  will be thicker than the base glyph in
the font (due to optical corrections). However, it is much safer for the
case, when there are no alternates in the font-- apps can always perform
scaling, without checking the presence of a special glyph/set).

>> My suggestion is to encode:
>> - changing G-clef
>> - changing C-clef
>> - changing F-clef
>> - control character 'changing clef' (this is to avoid duplicating all
>> the clefs, while enabling to use dedicated glyphs e.g. for clefs with
>> ottava bassa, as sometimes seen in double bass parts).
>>
>> This is a reasonable suggestion,
Thank you.

> in as much as it is pragmatic. However,
> the use of a control character to perform glyph substitution means that
> it's no more simple to support for a scoring application than using a
> stylistic set, which remains my current recommendation.
An app may draw string changingClef + gClef8vb without need of changing
font attributes or invoking explicit glyph from PUA (provided the font
and rendering device support ligatures, and font attributes are properly
set). A ligature with control character is the easiest OpenType glyph
substitution to implement. Other OpenType features (like stylistic sets)
are just a bit harder (as there arise a problem of compatibility, e.g.
with browsers); the most difficult is access via 'aalt' (since it would
need a profound redesign of the interface in many apps; Generally:
many-to-one substitutions work well; one-to-one ones usually do;
one-to-many substitutions are likely to cause problems.).

It is about just four codepoints. Please reconsider them. Just to avoid
building fonts "in an uncoordinated and haphazard fashion, leading to
significant inconsistencies".

Emil





#############################################################
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]>