Replace ß by smallcap eszett or smallcap ss?

Andreas Stötzner

I circumvent this cumbersome glyph-substitution business, still, with regard to small caps. I do the small caps as a seperate font (yes the old-school way) because I like to keep things simple and straightforward. In the sc font, the position of lowercase ß gets a small cap ẞ glyph. That’s logical and no one complains.

Kent Lew

Seems to me the whole reason this is an issue is because the small-cap mechanism in the OpenType Layout framework was conceived to operate outside of any text-level casing mechanisms, and so the type designer or font engineer is left with the task of deciding these casing rules, one way or another.

This is why we have to worry about idiosyncrasies like Turkish dotted i and eszett in our {smcp} features.

And that makes these small-cap casing choices font-specific, which is a bad place for them (as John has argued).

If only a font had just the responsibility for mapping encoded uppercase forms to their corresponding small-cap variant, and any lowercase-uppercase case mapping were left to the text-processing engine to handle — according to localization or user-specifiable standards or whatever — then fluid situations like the eszett could be addressed in a much more responsive way.

A {smcp} lookup is really a bad projectile for trying to hit a moving target like this, unfortunately.

Nick Shinn

If someone decides to use the cap eszett, they will be replacing two glyphs in their text string by one glyph, which is what the Ligatures features do, so it does seem practical and logical for this behaviour to be available in the Discretionary Ligatures feature—even though eszetts are single characters according to Unicode, and no other Ligatures outcomes produce single characters, AFAIK.

And, as the basic text string remains two characters, it doesn’t break the golden rule of OpenType substitution.

Also, using cap eszett is not really a stylistic decision, it has grammatical significance, rather like a ‘long s’ feature—and the only reason that goes in a Stylistic Set is because the correct Historical feature is not supported by layout applications.

Therefore I agree with you Jasper, Discretionary Ligatures does seem to be the best practice.

Nick Shinn

But how would that work, would the glyph have to be named SS.dlig, rather than uni1E9E?

Christian Thalmann

DLIG is full of weird stuff that people only want to use in very specific cases. I wouldn't want to switch that on just to get a proper ß.

Nick Shinn

For this purpose <dlig> would be applied “manually” to selected text, i.e. just two letters SS.

If it were “turned on” for an entire document via a style sheet, it would transform every instance of SS, and enact every other substitution in the feature as well, if there are any.

Jasper de Waard

It does seem more practical to make the cap ß the standard, and create a stylistic set that makes it possible to replace all cap ß instances by SS. That way, a user wouldn't have to manually select each instance.

But, and this is the downside, I have a feeling there are more oponents of the cap ß then of the replacement by SS. So there is a risk of losing some customers there.

Christian Thalmann

It can't be that bad if the Duden as been using it on its cover...

The only reason I can think of not to use the cap ß is if it's badly designed (e.g., not instantly readable or disharmonious with the other letters), which is unfortunately rather often the case. Luckily, this is a problem that type designers can freely address by themselves. 

Johannes Neumeier

Sorry to be reviving this topic, with a technical twist.

Does anybody have experience with small caps behavior in Adobe apps. More precisely I am seeing that smcp feature code substituting a cap /ẞ/ with my small cap /ß/ does get ignored, and I always end up with two small cap /s/ no matter what. Is this some hard coded behavior on Adobe's part?

The feature code works as intended in e.g. Harfbuzz.

Craig Eliason

This brief recent discussion on the Glyphs forum might be of use. 

Nick Shinn

The <smcp> feature is for lower case to small caps.
The <c2sc> feature is for caps to lower case.

The peculiarity of 'cap ẞ' is that 'lower case ß' should not be changed to 'small cap ẞ' in the <smcp> feature, as that is grammatically incorrect.

John Hudson

Does anybody have experience with small caps behavior in Adobe apps. 

Adobe performs a buffered case conversion, lower-to-uppercase and then applies the c2sc feature; they only apply the smcp feature to glyphs that are not affected by the case conversion. The case conversion employs Unicode special casing rule ß -> SS, so when you get is two smallcap S glyphs output from c2sc.

U+1E9E ẞ is a stand-alone uppercase letter with no standard case mapping. The smallcap form of this character should be mapped in the c2sc feature from the ẞ glyph.

Johannes Neumeier

Thanks Nick and John, that makes sense, but also it doesn't.

Never knew about the buffered case conversion! Unsurprisingly it even says so in the spec and I also found the unicode casing rule saying ß should case to SS. Also, it seems to me this encodes as standard what used to be a best practice, not an orthographical rule (FUSS, FUß or in olden times even FUSZ, and of course now FUẞ) - in fact the whole reason for the ẞ seems to be about the issue that using SS for ß capitalization is imprecise, particularly with names, so enforcing it now that there is a ẞ seems... wrong.

Not sure what to make of this. First of all, this buffered lc to UC to c2sc is somewhat unintuitive from the stance of expecting a layout feature to execute the lookups defined in it, not do or maybe do or maybe not do some other voodoo. Secondly, rendering engines seem to handle this differently, which makes the same font behave differently in different environments. And thirdly, if I'd like to make available—not even enforce—ß capitalization to ẞ and small cap ẞ there is no way to do so in Adobe's renderer, is there?

John Hudson

in fact the whole reason for the ẞ seems to be about the issue that using SS for ß capitalization is imprecise, particularly with names, so enforcing it now that there is a ẞ seems... wrong.

But that is still the primary orthographic norm, and until the German national standards body asks Unicode to change the case mapping of ß—which could, in any case, be a problem for cross-standards stability agreements—it will remain this way. Encoding of the uppercase ẞ enables custom and tailored case mapping arrangements, though: you just need software that enables you to define or apply them.

Unicode provides a standard behaviour—think of it like a default, fallback behaviour—to which software can provide exceptions. So, e.g. there is a default ordering of characters, but individual languages may have tailored ordering. Likewise, there is default case mapping, but specific software—e.g. databases of German names—may have tailored casing.

John Savard

Jasper de Waard said:

The question is this: if a type user just typed fußball and makes that word smallcaps, would he/she probably want the ß to be converted to the smallcap eszett, or to (I think more conventional) smallcap ss. And if the latter is the case, how would I make the smallcap eszett accesible?

While the small capital ss is more conventional, that is a consequence of the fact that a capital eszet has not been available until very recently. I would think the obvious advice is to convert a lower-case eszet to a capital eszet, or a small capital eszet, whenever possible.

Whether it should be converted to ss, or just left where it is, with the user having to type the ss in, for the sake of Unicode purism is another matter.

Nick Shinn

One thing I note from this discussion is that the Dresden style, as used in the Typedrawers font, looks too much like the lower case ß. 

When I first started adding this character to my typefaces, at its introduction over 10 years ago, I used the Dresden style, but soon gravitated to the Frankfurt style, with the flat top and the very sharp corner at top right.

However, I do still opt for the Dresden very occasionally, if it seems to suit the typeface better.

Christian Thalmann

The forum font's Dresden isn't particularly well-drawn (too closed on the bottom, too deeply incised, overall disharmonious shape). A proper Dresden is very distinct from the lowercase version and feels thoroughly «cappy».

I'm generally disinclined toward the Frankfurt style, but not as much as I used to. There are certainly fonts where it makes sense.

Oliver Weiss (Walden Font Co.)

In 2017, the Council for German Orthographyofficially adopted a capital, ⟨ẞ⟩, into German orthography, ending a long orthographic debate.

Following this, I believe automatic case mapping should be implemented, if it hasn't already. It's not something that should be done at the font level, IMHO.

John Hudson

In 2017, the Council for German Orthography officially adopted a capital, ⟨ẞ⟩, into German orthography

As an option. So now there are two acceptable ways to capitalise ß.

Johannes Neumeier

Thanks for the insightful answers. Apparently Adobe's renderer does this case caching outside/prior of the GSUB processing. I was trying to get a stylistic set working which would enable a /ß/ to /ß.scmp/ substitution, but no way around it from within the font with doing some intermediary glyph substitutions etc. ... which makes sense.

I wonder how unicode casing will eventually address an "optional captialization" rule. From my use case this seems like a limitation rather than a standard.

John Hudson

I wonder how unicode casing will eventually address an "optional captialization" rule. From my use case this seems like a limitation rather than a standard.

There has to be a default behaviour, which is what Unicode specifies. Unicode explicitly recognises the possibility—and sometimes need—for tailored behaviour in specific situations or software, i.e. it is outside of Unicode’s domain. What I can imagine is the German national standards body—or the intergovernmental orthography council—defining parallel standards for German text processing that would have different casing rules for ß, such that software makers would have a standard way to present the options to users. At the moment, it seems quite vague: there is a permitted option to do this non-default thing, but no standardisation of how or when it should be done.

Nick Shinn

I like the idea of options, but it’s unlikely I will be providing optional Dresden/Frankfurt ß glyphs in a stylistic set any time soon.

Johannes Neumeier

Nick Shinn said:

I like the idea of options, but it’s unlikely I will be providing optional Dresden/Frankfurt ß glyphs in a stylistic set any time soon.

The stylistic alternate would not be for what type of /ẞ/, but for what type of /ß.smcp/, "SS" or "ẞ" shaped. One could argue such a casing/orthography switch should be set in the text editor or on application level instead, sure. Meanwhile, in the real world…

Christian Thalmann

John Hudson said:

As an option. So now there are two acceptable ways to capitalise ß.

It's not an option if the text editor forces the decision on you.

(On an unrelated note, I do provide Frankfurt alternates for my Dresdens if I feel like it...)

John Hudson

It's not an option if the text editor forces the decision on you.

On the contrary, that is the level at which the option is implemented: in software support. The orthographic council has sanctioned the option, but has not decreed that it must be made available, nor even defined a specific standard within which the ß -> ẞ mapping would be the default. So software makers could provide a mechanism to apply that case mapping as a preference, but they don’t have to. That is the option.

I am not saying that I think this vague situation is a good thing. I think some kind of formal standard including the ß -> ẞ behaviour would be a good idea, because then there would be something definite for software makers to implement, and for customers to point to as a request.

Nick Shinn

Let’s not forget the ‘Zehlendorf’, somewhere between Dresden and Frankfurt.

Andreas Stötzner

Nick, that is the Dresden form.

Nick Shinn

Yes, I was wrong, it’s not the Zehlendorf.
But I do think it’s quite distinct from the Dresden; so I will call it the “Orangeville” (where I have my studio).

Christian Thalmann

But I do think it’s quite distinct from the Dresden; so I will call it the “Orangeville” (where I have my studio).

The Dresden is a large parameter space that encompasses your design. So if anything, your design is a subform of the Dresden, just like my Zürich. (Though unlike the Zürich, «Orangeville» has been in widespread use since the earliest beginnings.)

Oliver Weiss (Walden Font Co.)

I just love how this is a somewhat ambiguous space. I had a lot of fun with these