Opentype case & eszett



  • So if one were designing a titling face SS would be put in place of ß
    […] do you actually add an SS glyph?
    Yes, see e.g. the ß in Adobe’s Trajan. Yes, in theory this is problematic when tracking is applied.

    ẞ can be included simply by encoding it as U+1E9E. Additionally providing it as a stylistic alternate is OK.

    See also this older thread on the same subject.

  • Thanks Florian… interesting… I guess if there was a way around the tracking issue Adobe would've done it differently.
  • Florian HardwigFlorian Hardwig Posts: 138
    edited October 2015
    I have yet to encounter an example of tracked caps with a noticeably atomic ß as SS. It’s probably a rare scenario to start with. Also, users might use all-caps (InDesign then inserts two separate S’s). Finally, if this actually happens, the user will simply replace the ß with two s’s.

  • John HudsonJohn Hudson Posts: 1,378
    Isn't better to keep fonts responsible to define the smcp/c2sc transformations and so ensure greater standardization over results? I thought the OT features system were exactly to let the fonts embed everything needed to correct results, while the host application just reads that.

    That's more the AAT/Graphite approach, in which the font really is responsible for everything and the state engine is an essentially dumb (but very powerful) consumer of the font. The OpenType model generally favours locating standard behaviour at the layout engine level, so that the font — and hence the font maker — doesn't need to be responsible for all aspects of text shaping. Of course, like most other things in OpenType, the model isn't always adhered to strictly. Smallcaps are something of an edge case, but insofar as they are related to case transforms, a good argument can be made as standard case folding is handled via software, at the character level, rather than in font lookups, it makes sense for the same to apply during conversion of lowercase to small(er) caps. This is, in fact, a much better guarantee of standard results than leaving it up to the font makers to agree on a method, as I think this thread demonstrates.

    Of course, what we have now are different layout engines doing different things as well as different fonts doing different things.
  • Nick ShinnNick Shinn Posts: 1,273
    There is a lot of discrepancy of figure style behaviour in the small cap features, as determined by various font makers. But this is appropriate, as there is no consensus as to what are the appropriate default styles for figures—in all caps, mixed case, smcp and c2sc—and it can vary with typeface genre, at the discretion of the type designer.

    The same is also true for punctuation; I’d hate to see layout engines automatically raising certain punctuation marks when All Caps is selected.
  • Now that a year has passed, what's the current best practice for 00DF (the standard ß location) in ALL CAPS typefaces? How's everyone handling this?

    1E9E: ẞ
    00DF: SS or ẞ

  • Nick ShinnNick Shinn Posts: 1,273

  • Since a few weeks/month ago, the official rules allow the ẞ but SS is still default. 
  • John HudsonJohn Hudson Posts: 1,378
    edited January 2017
    what's the current best practice for 00DF (the standard ß location) in ALL CAPS typefaces?

    My inclination would be to make an SS glyph mapped to U+00DF, but also include a <ccmp> feature decomposition to two S glyphs, so that tracking can be applied to text without the SS staying stuck in a fixed relationship.

    In an all-caps font, I think it would also be reasonable to provide the ẞ form as a stylistic variant of ß, so that users do not need to re-encode text in order to obtain that form.
  • I would default to the cap form and provide "SS" as an alternate.
  • John HudsonJohn Hudson Posts: 1,378
    I would default to the cap form and provide "SS" as an alternate.
    Thereby producing unpredictable and different outcomes depending on what kind of text processing functions a user applies. So, for instance, the same all-caps font will display text differently depending on whether it is encoded as lowercase or has undergone a text case conversion to uppercase. I think it is generally best practice to have default behaviour correspond to standard encoding and case mapping, and have stylistic variants reserved for variant behaviour.
  • I wasn't talking about an all-caps font. What I'm saying is that a capitalized ß should default to "ẞ" and not "SS".
  • >  the only way to do this is to use a custom casing method

    I'm glad there's a way.
Sign In or Register to comment.