germandbls monowidth small cap

Nick Shinn

It’s not pretty, especially in the Bold weight, but just to confirm: this is the only correct option, isn’t it?

Thomas Phinney

You could use the cap eszett form. But should you?

I would love to hear from native German designers about this option. On the one hand, I think it will look a zillion times better. On the other hand, to the extent that monospace typefaces are supposed to look like old typewriter fonts... of course the cap eszett form is very much ahistorical.

Nick Shinn

I have published the typeface with the cap eszett form in both <c2sc> and <smcp>, but it recently occurred to me that the latter is a mistake, so I am considering the above change, for the upcoming Variable version of the typeface, at least.

John Hudson

Map the single lowercase ß to two smallcap S glyphs. There is no reason why the smallcap should be represented by a single SS glyph in all-caps or smallcaps. The standard German spelling rule—if the uppercase ẞ is not used—is that lowercase ß case maps to two uppercase S letters; that should be reflected at the glyph level for smallcaps.

Nick Shinn

One-character to two-character substitution isn’t possible, AFAIK.
(The intent is to make every glyph in the font monowidth.)

Johannes Neumeier

Nick Shinn said:

One-character to two-character substitution isn’t possible, AFAIK.
(The intent is to make every glyph in the font monowidth.)

Create a double width glyph with two smallcap S inside, and whazzaaah, one to one substitution

I agree with John's premise, if you were to type it as two S you'd use two individual letters, the monowidth SS is a "retro-fitted logic". Personally I embrace the ẞ, there could be a stylistic set to toggle between the two behaviors.

Christian Thalmann

Historical, schmistorical. Go for the small ẞ!

And offer a double-width SS as a stylistic alternate.

Denis Moyogo Jacquerye

One-character to two-character substitution isn’t possible, AFAIK.

It is possible and is very common. See https://learn.microsoft.com/en-us/typography/opentype/spec/gsub#lookuptype-2-multiple-substitution-subtable or https://adobe-type-tools.github.io/afdko/OpenTypeFeatureFileSpecification.html#5.b.

Johannes Neumeier

Denis Moyogo Jacquerye said:

One-character to two-character substitution isn’t possible, AFAIK.

It is possible and is very common. See https://learn.microsoft.com/en-us/typography/opentype/spec/gsub#lookuptype-2-multiple-substitution-subtable or https://adobe-type-tools.github.io/afdko/OpenTypeFeatureFileSpecification.html#5.b.

One to Many does not work in the default Adobe CC text engine; users need to use the Middle eastern text engine to get to enjoy the benefits of font features implemented with Adobe's own feature syntax.

Denis Moyogo Jacquerye

@Johannes Neumeier How could I forget... of course.  Someone once mentioned a work-around with glyphnames or otherwise unreachable glyphs, but I can’t recall what it is nor have I tried it.

Nick Shinn

@John Hudson
@Johannes Neumeier

Create a double width glyph with two smallcap S inside, and whazzaaah, one to one substitution

I’ve done that before (in Panoptica, an experimental monowidth+unicase design), for the fi and fl ligature characters, but the problem is that the font then ceases to be monowidth. 

My concern is that there should be some truthful data in Font Info that identifies it as Monowidth, so that when people search for that quality, or it is classified by, say, Adobe InDesign in font menus, it shows up in the appropriate category. I anticipate there may be a problem if I check the “monowidth” designation, but one glyph is double width, that it will not appear in “monowidth” searches.

Thomas Phinney

Note that there is a Panose setting for monospaced. You should only use it if your font is truly monospaced all the time, though!

MS Word at least used to apply a single advance width to all glyphs, if Panose claimed monospace. Regardless of the rest of the font data!

Ray Larabie

@Thomas Phinney What happens to combining diacritical marks with zero width when the Panose is set to monospaced?

Thomas Phinney

I imagine Word still treats them as zero width, because they are combining diacritics. But I haven’t tested it. (Indeed, I have not tested the original Word issue in many years now.)

John Hudson

What happens to combining diacritical marks with zero width when the Panose is set to monospaced?

When we worked on monospace fonts for Microsoft, we were instructed to give the combining marks the standard mono width, and then to collapse that width to zero in GPOS. Some shaping engines will automatically collapse the width of glyphs that are classified as marks in the GDEF table, but my preference is to control widths myself in GPOS.

Peter Baker

When we worked on monospace fonts for Microsoft, we were instructed to give the combining marks the standard mono width, and then to collapse that width to zero in GPOS.

Could one do the same thing in reverse? Make the double s like this:

and clean up in GPOS? (Might be confusing for users, I guess.)

Nick Shinn

I have decided to use the cramped “double-s” character, and designate the font as “Monospace” in the Panose font info.

In the first place, it won’t be the only gnarly character in the alphabet.

Secondly, if typographers find it noticeably annoying, that will probably be in a headline, in which circumstance they can easily change it by typing two lower case s’s instead of ß—without recourse to OpenType sub-menus.

Thirdly, sufficient information hasn’t emerged, in this thread, about the acceptability of small-cap eszett in <smcp>, from native German speakers (but thanks to Christian, nonetheless!)

Fourthly, sufficient information hasn’t emerged, in this thread, about whether double-width characters would compromise the status of a monowidth-labelled font, in layout apps and search engines.

Fifthly, although there is some promise in workarounds, that would require more work than the problem warrants.

John Hudson

The <smcp> feature is a bit of an oddity. It was registered in recognition of styles of typography in which lowercase characters are set as smallcaps while uppercase letters remain ‘bigcaps’. But as Adobe themselves quickly demonstrated, it isn’t actually necessary to have a distinct feature to perform those substitutions, because applications could selectively apply case mapping plus <c2sc> to lowercase characters. If those applications also applied Unicode special casing rules, they could also avoid ever having to deal with the sort of substitution Nick is querying, because those casing rules would map ß -> SS and the result from <c2sc> would be two smallcap S glyphs (all while also avoiding Adobe’s sometime allergy to type 2 GSUB).

I generally don’t provide any smallcap mapping for lowercase ß.

Thirdly, sufficient information hasn’t emerged, in this thread, about the acceptability of small-cap eszett in <smcp>, from native German speakers.

I’m not a native German speaker, but knowing what I know about Duden rules for ß, SS, and ẞ, I would say no. The uppercase ẞ is still only an accepted exception to the general casing rule. That may change in future if its use becomes widespread and the ß/ss distinction becomes standardised across both cases, but for now I think forcing a smallcap ẞ for ß would not be generally acceptable, 

Florian Pircher

Peter Baker said:

When we worked on monospace fonts for Microsoft, we were instructed to give the combining marks the standard mono width, and then to collapse that width to zero in GPOS.

Could one do the same thing in reverse? Make the double s like this:

and clean up in GPOS? (Might be confusing for users, I guess.)

I believe that is the technique that most monospaced fonts with coding ligatures do (where, for example, -> turns into a double-width →).

Florian Pircher

I consider capitalizing ß as SS to be a hack. Text reads worse when a word is suddenly one character longer just because it’s capitalized. In signs/posters/slides/… made by non-typographers it’s common to find the lowercase ß among capital letters instead of SS. (The height of the lowercase glyph helps in this regard.) That tells me that many people feel a similar uneasiness about the substitution to the point where they prefer mixing cases. The SS replacement is well-suited for old systems that cannot handle ẞ. Otherwise, ẞ is the way to go. Small caps are just that, small capital letters, so the same applies there, too.

Here is a screenshot from the area near me in the Maps app, where the word Straße (road) appears predictably often:

The ẞ works, whether someone even knows that a capital ß exists or not. No need to complicate things by replacing a glyph by two different glyphs.

Christian Thalmann

Whatever you think about the viability of a SC eszett as default, offering one as a stylistic alternate can't possibly be wrong. If a typographer activates the alternate, they presumably know what they're doing, and you're not forcing it on them.

Nick Shinn

Well then, as Florian and Christian are both in favour of small-cap eszett, that’s what I’ll do!

In defence of this rule-breaking, I should point out that it won’t alter the underlying text, as there will be two separate “small eszett” glyphs in the fonts:

germandbls.smcp
uni1E9E.c2sc

John Hudson

I should point out that it won’t alter the underlying text

But it will force users to alter the underlying text if they want smallcap SS instead of the ẞ form.

Christian Thalmann

Or he could just offer a stylistic alternate for that.

James Hultquist-Todd

Pick the one that makes the most sense to you. If enough users complain, then do the other one.

JLA

Christian Thalmann said:

Historical, schmistorical. Go for the small ẞ!

And offer a double-width SS as a stylistic alternate.

That sounds like the optimum solution to me.

Jens Kutilek

I checked my typewriter specimens, and though I found one appearance of a double S inside a single width, it was listed not under letters but under symbols of, ahem, "political organisations".

From Ransmayer & Rodrian, 1942:

Kalapi Gajjar-Bordawekar

Adding this for posterity:

I would be careful about depending on OT layout to solve design/letterform issues, especially if the fonts are intended to be used in an IDE or in the shell/terminal where OT functionality is ignored.

BraveType

https://www.lucasfonts.com/learn/1E9E