Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Kent Lew

About

Username
Kent Lew
Joined
Visits
1,950
Last Active
Roles
Member, Type Person
Points
585
Invited by
Admin James Puckett
Posts
542
  • Re: “French” apostrophe?

    In Slovak, that is not an apostrophe! (Despite how it may perhaps be input sometimes in some “dumb” environments.)

    It is an accented letter: Ľ.

    So, yes, it is thought of as part of a single letter.
  • Re: Special dash things: softhyphen, horizontalbar

    Nina — As I said, I only double-encode U+00AD in case there is a validation tool that needs the codepoint in order to permit indication of certain codepage coverages. I suspect, as John does, that it doesn’t actually matter what’s in the font or not.
  • Re: Special dash things: softhyphen, horizontalbar

    My preferred approach to U+00AD softhyphen is the same as U+00A0 nbspace — which is to say, I prefer to double-encode them with their default references hyphen and space.

    These two are unique characters whose distinct properties I feel should be properly handled at a higher level than the font: the discretionary character of the softhyphen and the non-breaking character of the nbspace are characteristics that should be managed at the layout level. The glyphs themselves should be the exact same as the hyphen and space in every other way. I would guess that the fact that they are encoded at all is a legacy residue.

    In practical reality, I believe most most modern apps treat them this way. If these codepoints are not present, then the renderer should use the U+002D hyphen and U+0020 space. In some apps, the renderer does so regardless. However, in some apps, the renderer uses the mapped glyph if the 00AD/00A0 codepoints are actually present. And if the glyphs differ from the 002D/0020 glyphs, then unexpected behavior can happen.

    If you double-encode then you don’t need to be concerned with .case versions of U+00AD, since the hyphen glyph will be utilized and still be a proper target for any existing relevant GSUBs.

    I wouldn’t even really bother with the codepoints in <cmap> except that I suspect there are a number of validators that would flag a font as not supporting various legacy codepages that include these codepoints (especially U+00AD) if these codepoints are not in fact present.

    I interpret that the horizontalbar U+2015 is the dash that is [supposed] to be used as an introduction to speech in those traditions that utilize this style: https://en.wikipedia.org/wiki/Quotation_mark#Quotation_dash

    As such, I generally draw it as a nominal em dash — i.e., I make it a full em wide with zero sidebearings (which is not typically how I draw my emdash U+2014 these days).

    In fact, I have a simple script that just creates the horizontalbar glyph with a width from f.info.unitsPerEm, reads the thickness and vertical position from the bounding box of my emdash, and draws the relevant rectangle. Never give it a second thought. ;-)

  • Re: Typopo, a single-click online tool to wipe out frequent typos

    Christian — I believe most English style guides would advise similarly. It should be punctuated in the same manner as would the translated phrase it abbreviates: “for example.”
  • Re: “French” apostrophe?

    Michel — You say that in your second examples “vowels get more spacing,” but in fact it appears to me that the d and c have come along for the ride with the class as well.

    I, too, prefer your second set. For both English and French — except that I’d loosen the kerning with all of those straights on the left as well (or the fitting, as the case may be).

    Perhaps the issue here is really le goût d’Adobe?! ;-)

    Something representative of my own taste:



    Here the round vowels and consonants are in the same class, English and French alike; but the quoteright-ecircumflex is an exception to the class value (+35 looser in this case).

    But tell me, would you think the c’est and l’être should have the same absolute value?

    If you say Yes, then again perhaps we have a good argument for a language-specific overall adjustment, rather than just some judicious kerning exceptions.