Small-cap Eszett impossible to input in InDesign?

Rob Mientjes's picture

I've been working on the specimen booklet for my graduation typeface (part digitisation of Manuscript Antikva, part stylistic extrapolation), and have run into the curious situation of not being able to use one of my designed characters.

As Adam Twardoch mentions here, uppercase ß will still map to SS. Oddly, however, InDesign CS5 allows me to input the capital Eszett just fine. However, the small-caps variant is seemingly impossible (I've attached a screenshot of the usual situation upon insertion—small-caps SS). I can only think of placing it in the Private Use Area, but I'd rather not. So, in short, how can I access the actual glyph at codespace uni00DF.sc without InDesign telling me what it's supposed to be?

AttachmentSize
Eszett becomes SS69.63 KB
riccard0's picture

Shouldn’t the small-cap ß be placed by the app as a variant of the regular one?

twardoch's picture

The glyph should be accessible through the "smcp" feature of the font:

feature smcp {
sub a by a.smcp;
sub b by b.smcp;
...
sub germandbls by germandbls.smcp;
...
} smcp;

(As should all the other small-cap letters).

In InDesign, it would be accessible through the "Small caps" option in the Character palette. I'm not aware of any situations where InDesign would perform some behind-the-scenes additional operations when applying small caps.

In addition, you'll probably want to have the "c2sc" feature in your font which maps uppercase letters to the small-cap variants. You can choose to create an additional set of small cap glyphs for those (identical in shape but with different glyph names, so a small-cap "A" would exist in the font as "a.smcp" and as "A.c2sc") or you could just use the same set (named whatever you wish).

If you go with the separate sets, then the small-cap ß would exist as "germandbls.smcp" and as "uni1E9E.c2sc", and the code for "c2sc" would be then:

feature c2sc {
sub A by A.c2sc;
sub B by B.c2sc;
...
sub uni1E9E by uni1E9E.c2sc;
...
} c2sc;

Cheers,
Adam

andreas's picture

sub uni1E9E by uni1E9E.sc; will work

germandbls to SS is hard coded and InDesign programmers don't get it.
BTW: In InDesign (pre CS versions) 1 to 2.0 it will work.

Nick Shinn's picture

I differ from Adam on this.

I've put this character in my fonts since it was introduced in Unicode, but only make it available through c2sc, not smcp.

In the smcp feature, ß maps to a special double-s glyph.
This is so that "caps with small caps"—which is what, in implementation, smcp really is — is a true bicameral setting, corresponding with the way that ß is capitalized by layout engines.

However, if the special Eszett character exists as text in a cap setting (never as titlecase, of course!), that makes it OK to have it in the c2sc feature—which is, in implementation, "all small caps".

twardoch's picture

I'm not really advocating any particular design solution, I'm just suggesting a coding solution.

The decision what kind of shape to put as a small-cap ß which is intended to work in "smcp" is up to the designer. I mean, whether your "germandbls.smcp" looks like a small-cap version of the uppercase "ß" or if it's a smallcap "ss" is a design decision. But the code I've given will work either way.

Rob Mientjes's picture

Thanks for all the replies! I'm pretty sure Andreas is actually outlining what I'm saying: InDesign has it hardcoded, and that makes it impossible to input. To check up on my sanity, here is the OpenType in place:


@LC_ALPHA = [a-z germandbls];
@UC_ALPHA = [A-Z uni1E9E];
@UC_SMCP = [A.sc-Z.sc uni1E9E.sc];

feature c2sc {
sub @UC_ALPHA by @UC_SMCP;
sub @LC_ALPHA by @UC_SMCP;
sub @LC_PUNCT by @SMCP_PUNCT;
sub @PNUMS by @SCNUMS;
sub @ONUMS by @SCNUMS;
} c2sc;

(I realise I'm conflating c2sc and smcp; that's laziness, and will be resolved as soon as I get to the final designs.)

Nick Shinn's picture

This line is not necessary in c2sc:

sub @LC_ALPHA by @UC_SMCP;

Also, for @LC_SMCP, make sure that germandbls is substituted by "germandbls.smcp", which is two small cap "s"s.

**

This is what should happen:

The fact that "mixed case to small caps/all small caps" loses the distinction between Gross and Groß follows on from the way that layout engines convert "mixed case to all caps", losing the distinction there (although it is maintained in the underlying text). This is because traditionally there was no cap eszett accessible in most fonts or via keyboards, and this behaviour has been grandfathered.

Rob Mientjes's picture

Hey Nick,

Thanks for clarifying. Changed germandbls.smcp to two smcp-'s's. I finally understand the point about the SS-conversion. I've changed my OpenType code, but am not sure about its functionality. In FontLab, c2sc just swaps the caps? And InDesign combines c2sc and smcp when selecting All Small Caps? I am not sure. Here's my OpenType code.

feature smcp {
sub @LC_ALPHA by @LC_SMCP;
} smcp;

feature c2sc {
sub @UC_ALPHA by @UC_C2SC;
sub @LC_PUNCT by @SMCP_PUNCT;
sub @PNUMS by @SCNUMS;
sub @ONUMS by @SCNUMS;
} c2sc;

[update]
All of this worked! InDesign allows me to input small cap uni1E9E when cap uni1E9E is used, and otherwise inserts 'ss'. Thanks a lot for all the help.

twardoch's picture

Yes, in InDesign, "all small caps" invokes both "smcp" and "c2sc".

Also, I tested the substitution:

feature smcp {
sub germandbls by germandbls.smcp;
} smcp;

in InDesign CS5 Middle East on Mac OS X, and it I found that when using the "Paragraph Composer", then "ß" is indeed converted to "ss" before "smcp" is applied, while when using the "World-Ready Paragraph Composer", germandbls is indeed being substituted directly.

My guess is that when using "Paragraph Composer", when the "Small Caps" is applied, InDesign converts all lowercase text in the string to uppercase, and then to lowercase again, using the Unicode case mapping rules, and the "smcp" feature is applied after that. When using the "World-Ready Paragraph Composer" is used, the "smcp" feature is applies without any preprocessing.

Nick Shinn's picture

And what does it do when "all caps" is applied?
Does it turn ß into cap eszett?

(Sorry, I don't have the latest version of CS.)

John Hudson's picture

Nick: Does it turn ß into cap eszett?

It certainly shouldn't. Bear in mind that the cap eszett character is a minority display preference: the formal case mapping of lowercase ß to uppercase is still SS, according to both German standard spelling and Unicode case mapping.

Nick Shinn's picture

John: …the formal case mapping of lowercase ß to uppercase is still SS…

Is this likely to change, as more and more fonts incorporate the new Unicode character?

Are German typographers exercising the "minority display preference"?

It's been three years since the new character was formalized in Unicode.

Is it part of any standard encodings?

How many new fonts include it?

How many foundries include it in all new fonts as a matter of course?

dan_reynolds's picture

The German standard spelling regarding ß to SS is not likely to change based on font character set support. I suspect that, like most bodies that add words to language and regulate spelling, changes to German orthography will be made based on a combination of history and current use of how the language is spoken and written. German recently had a big spelling reform; whether another top-down reform could come in the near future … I have no idea.

One should not judge what practicing German typographers are doing based on glyph design discussions of a certain number of type designers alone. The pros and cons of the cap eszett are still quite active topics of discussion among German typographers. No particular feeling toward the new form is universal yet. I certainly know plenty of type designers, book designers, and typography professors who are not in favor of cap eszett use.

>How many foundries include it in all new fonts as a matter of course?

Well, I work at the largest foundry in the country, and we do not include these new glyphs in all new fonts as a matter of course. In fact, we include them in hardly any new fonts. There are a few fonts with them now, but only because the type designers behind the fonts wanted to include them. Otherwise (in the majority of cases, in fact), they are not part of the character set. Some of the type designers that I work with are actually relieved about this, because they are not in favor of the cap eszett yet either, and do not want to have to draw them just for the sake of character set completion.

k.l.'s picture

You cited the wrong part of John's post. :)
Coming up with some character, unicoding it and adding it to fonts is one thing. But unless there will be yet another spelling reform ...

[Replying to Nick.]

dan_reynolds's picture

Thank you, Karsten, for saying in so few words what I could not get across with so many!

k.l.'s picture

Unfortunately I saw your comment only after posting mine which reloaded the page ...
Good to know about the largest foundry's praxis as to this character!
Isn't it largest foundry in Europe by now? :)

dan_reynolds's picture

Well, in terms of library size, as well as the number of fonts and the number of staff working on those fonts, I guess that ITC-Linotype-Monotype could be called the largest foundry at the moment; in Europe and elsewhere.

Nick Shinn's picture

Thanks for the candid response, Dan.
It's good to know that MegaFont GmbH isn't totally behind this new gizmo—gives me the edge!
I quite enjoy drawing the character. More fun than Aringacute or Greenlandic k.

hrant's picture

Nothing is more fun than Armenian. :-)
Small character set, the familiarity of left-to-right non-joining forms in two cases,
and half a dozen characters at least as challenging as the Latin lc binocular "g".

hhp

ralf h.'s picture

The German standard spelling regarding ß to SS is not likely to change based on font character set support.

Well, of course the change of the standard spelling requires a sufficient support of the character in typical operating systems first. Everything else would be madness.
And the common dictionary publishers like DUDEN will follow whatever the users make their standard.

And actually, I am surprised how many users actually use it even today—especially on the internet. Even though there are no easy input methods yet and even though many readers will still see a NOT DEF sign instead. It is spreading—whether the conservative typographers like it or not.

But apart from that I fully agree, the standard is still ß to SS in uppercase and small caps and fonts, design applications and browsers should implement it that way. (Maybe leaving additional options for using the cap Eszett instead in stylistic sets and the like.)

dezcom's picture

I guess there will always be disagreement between German speakers about the use of that glyph--some even quite passionate about it. I usually include it but not for any philosophical reason. I just put it in there for those who need it. I don't care to get involved in the pro and con positions opposing sides site. Those who want it can use it and those who don't can just ignore it. I put there just like the florin, AE Ring acute, etc. and let the user have the option if so desired. I include it in the c2sc code and as a stylistic alternate to the S_S.sc glyph.

My understanding is that the majority of uses involve proper names mostly of towns and cities.

John Hudson's picture

The strongest argument I have heard in favour of the new Unicode character, from a German, is that it enables reliable one-to-one round-trip case mapping, which is desirable in data management for things like e.g. passport control. There are apparently some German names in which a distinction between ß and ss is critical, and different government agencies store names in all uppercase or in mixed case.

Of course, this has nothing to do with the design of the glyph, but only with the existence of the distinct codepoint for an uppercase eszett, which might ostensibly be displayed as /SS/.

John Hudson's picture

Ralf: And the common dictionary publishers like DUDEN will follow whatever the users make their standard.

My impression of Duden is that it tends to favour a top-down approach to spelling, reflecting official decision making rather than popular usage. Duden seemed to be key in disseminating the recent spelling reform.

John Hudson's picture

On the subject of Duden, it is worth noting that the 1957 East German Duden (Lepizig) provides one of the notable instances of an uppercase eszett.

ralf h.'s picture

I guess there will always be disagreement between German speakers about the use of that glyph

I predict it will be a transition over one or two generations. Same thing happened for the Umlauts. They started out as a lowercase ligature and when their use was common, the uppercase versions slowly appeared and are now standard too. We are used to them now, so no one is questioning the existence of those characters, even though—ironically—their formal development from a lowercase letter is something that some experts now use as an argument against the cap Eszett.

the strongest argument I have heard in favour of the new Unicode character, from a German, is that it enables reliable one-to-one round-trip case mapping

Well, of course. This is how every Western alphabet works. See also http://opentype.info/blog/2011/01/24/capital-sharp-s/
And that's why I always get a little mad, when typographers(!) call the cap Eszett a “silly” idea. It is silly not to have a lowercase AND uppercase version of any character in any Western alphabet. Its the most basic principle.

My impression of Duden is that it tends to favour a top-down approach to spelling, reflecting official decision making rather than popular usage.

They do both. Of course they follow the spelling reform, because this is now the new standard. But when new words or new spellings become widely used, they list these also, even though they are not in the official German orthography.

twardoch's picture

I agree with Ralf. There is also a strong linguistic reason for having an “uppercase ß” (U+1E9E, ẞ) adopted widely:

In the pre-1996 German spelling, the basic principle for writing consonants after a vowel was:
— if the vowel is long, write a single consonant (in “Bote”, the “o” is long)
— if the vowel is short, write a doubled consonant (in “Gott”, the “o” is short)

This was a very reliable rule, that also applied to “s” and “ss”, e.g. in “Mus”, the “u” was long, and in “Masse”, the “a” was short. The only exception was “ß” where the behavior was “undefined”. If “ß” followed a vowel, you never knew whether the preceding vowel was long (as in “groß”) or short (as in “muß” or “daß”). The reader needed to “memorize” the pronunciation. So “ß” was viewed as an ambiguous letter that was either “single” or “doubled” depending on the context. This was correct historically, because “ß” was originally a doubled letter, and then a ligature.

But in the 1996 spelling reform a rule was introduced, which has been kept up in the 2006 “reform of the reform” that “ß” is a single letter. So all situations where the preceding vowel was long kept the “ß” (“groß” is the new spelling) while in all the situations where the vowel was short, the “ß” was replaced by “ss” (“muss”, “dass” is the new spelling).

So now, German is written very logically, and the single-or-doubled consonant rule is reliable. But this has repercussions.

All the readers who grow up with the new spelling, or adopted it quickly (such as myself) rely on the rule blindly. In the words “Rußpartikel” or “Großenkel”, it is absolutely obvious that the vowels preceding “ß” are long. It’s automatic, there is no doubt about it.

So, “ß” is a single letter.

But hang on... Not when the word is written in uppercase! When I convert the word to uppercase using the currently valid rules, I get “RUSSPARTIKEL” or “GROSSENKEL”, and then the acquired reading automatism forces me to think that the “U” vowel in the first word or the “O” vowel in the second word is short. So I mispronounce the words.

This of course is most problematic for personal names, where you don’t really know a “memorized” pronunciation. “Frank Mussmann”: “u” is short, of course. “Frank Mußmann”: “u” is long, of course. But “FRANK MUSSMANN”? “Well of course, the U is short”, says my reading automatism. But I may be wrong!

If “ß” is a single letter now, why is its uppercase representation a doubled letter? That’s now (after the 1996-2006 reforms) less logical than it was before. It’s now completely counter-intuitive.

So I strongly presume that the reason why the case conversion rules were not changed in 1996 or 2006 was purely technical. I.e., there was no technical means to represent a “more logical conversion”, because the uppercase “ß” character was not codified or even “invented”.

Andreas Stötzner’s Unicode proposal has resolved this barrier. The Windows 7 versions of the Microsoft core fonts (Arial, Times New Roman etc.) have been revised to include the U+1E9E character (ẞ), and more and more fonts are coming out that include it. A search at MyFonts reveals 106 families that include the uppercase ß character. Not many, but I’m sure more are coming.

So we’re in a technical transitional period now. Just like with the Euro currency character, the technical support needs to be there first (fonts and keyboard layouts), but at some point people will be adopting ẞ more and more widely — because it’s the only logical thing to do.

Arguments against it are based purely on tradition and history. Arguments for it are based on linguistics, pragmaticism, logic and practicality. Go figure who will “win” in the longer term :)

twardoch's picture

UPDATE: In 2010, the German Federal Agency for Cartography and Geodesy (“Bundesamt für Kartographie und Geodäsie”) published the 5th revised edition of the document “Toponymic guidelines for map and other editors for international use Federal Republic of Germany”.

Section 1.1.3 of this document says:

1.1.3 Special letter ẞ ß
The special letter ß (“strong s”) existed hitherto only as small letter (minuscule). In 2007 DIN and ISO accepted the capital letter ẞ which is rendered on position 1E9E of the Unicode character tables. In official spelling it must not be substituted by any other letter combination, as e.g. SS, ss. In the alphabetical order ẞ, ß is treated like SS, ss. Since a typographical implementation of the upper case letter ẞ in the various character fonts will take some time, it may be temporarily substituted by SS, ss.
NEW: Due to the new regulation of German spelling the letter ß is after a short (stressed) vowel now replaced by ss. The letter ß remains after a long vowel or a diphthong.

Examples for names of geographical regions:
— now: Hassberge (short and stressed vowel a), until now: Haßberge
— will continue: Meißner (diphthong preceding ß), MEIẞNER
— will continue: Großer Feldberg (long vowel o preceding ß), GROẞER FELDBERG

Example for an officially approved name of a municipality
— will continue: Haßfurt, HAẞFURT (though a short and stressed vowel a is preceding ß)

This is, to my knowledge, the first official German government body that not only approves but actually prescribes the use of uppercase ß (U+1E9E, ẞ), and only accepts the use of SS “temporarily” (“since a typographical implementation of the upper case letter ẞ in the various character fonts will take some time”).

Regards,
Adam

Nick Shinn's picture

Unfortunately, we pioneers of the inevitable are creating fonts with OpenType encoding that will become obsolete once the change is made official.

Presently, our coding in 'smcp' and 'c2sc' maps ß to a glyph that looks like two small cap s's.

Perhaps in future smart layout applications could, when 'germandbls.smcp' is called for, search for 'uni1E9E.smcp', and, if it exists in a font, use it instead.

Or is that what the "world-ready paragraph composer" is already doing?

Adam, what is the OpenType coding in that Trump sample that you showed above?

twardoch's picture

Nick,

as I've pointed out in my post, it's:

feature smcp {
...
sub germandbls by germandbls.smcp;
...
} smcp;

A.

Nick Shinn's picture

Sorry, not paying attention.

Your explanation of what happens is more complex than the single character substitution I suggested.
What would happen if you changed the name of your small cap eszett to something quite different than uni1E9E.smcp?

Syndicate content Syndicate content