germandbls monowidth small cap

Nick Shinn
Nick Shinn Posts: 2,195
edited April 3 in Technique and Theory

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

Comments

  • Thomas Phinney
    Thomas Phinney Posts: 2,859
    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
    Nick Shinn Posts: 2,195
    edited April 4
    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
    John Hudson Posts: 3,149
    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
    Nick Shinn Posts: 2,195
    One-character to two-character substitution isn’t possible, AFAIK.
    (The intent is to make every glyph in the font monowidth.)
  • 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 :smile:

    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
    Christian Thalmann Posts: 1,967
    edited April 4
    Historical, schmistorical. Go for the small ẞ!
    And offer a double-width SS as a stylistic alternate.
  • 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. :|
  • @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
    Nick Shinn Posts: 2,195
    edited April 5
    @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
    Thomas Phinney Posts: 2,859
    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
    Ray Larabie Posts: 1,427
    @Thomas Phinney What happens to combining diacritical marks with zero width when the Panose is set to monospaced?
  • Thomas Phinney
    Thomas Phinney Posts: 2,859
    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
    John Hudson Posts: 3,149
    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
    Peter Baker Posts: 188
    edited April 5
    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
    Nick Shinn Posts: 2,195
    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
    John Hudson Posts: 3,149
    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, 

  • 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 →).
  • 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
    Nick Shinn Posts: 2,195
    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
    John Hudson Posts: 3,149
    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.

  • Or he could just offer a stylistic alternate for that.
  • Pick the one that makes the most sense to you. If enough users complain, then do the other one.
  • JLA
    JLA Posts: 8
    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
    Jens Kutilek Posts: 359
    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:

  • 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.