dotlessi.sc in fonts, in Minion for example

Arno Enslin's picture

Why does Minion contain a dotlessi.sc? Is there any good reason – any advantage – to put a dotlessi.sc into a font, that contains small caps? I mean, Minion does not contain a Dotlessi. It would be only consequent to double not the i.sc only, but also the I.

Arno Enslin's picture

Arno Pro also contains a dotlessi.sc (with the Unicode as name and an extension). When I searched Typophile for dotlessi, I found a comment by Adam Twardoch, that the dotlessi should be replaced by the i.sc in the small caps feature. Did I misunderstood him, that the dotlessi.sc is useless, if an i.sc is present?

Michel Boyer's picture

I mean, Minion does not contain a Dotlessi.

I am not sure I understand what you are saying. Here is from Minion Pro version 002.000

Minion does contain a dotlessi...

Michel

Michel Boyer's picture

And here is from http://www.unicode.org/Public/UNIDATA/NamesList.txt (concerning the capital)


0131 LATIN SMALL LETTER DOTLESS I
* Turkish, Azerbaijani
* uppercase is 0049
x (latin small letter i - 0069)

Michel

Arno Enslin's picture

@ Michel

Okay. Imagine a font, that contains I, i.sc and i. It also contains Idotaccent, idotaccent.sc and idotaccent. But why should it contain additionally Dotlessi and dotlessi.sc? (The yellow marked letter is a small dotlessi. I mean the capital and small capital versions of that letter. Not letter, but character. I am talking about characters.)

I found Adam’s comment:
http://typophile.com/node/29469/168548

He says: "Of course "dotlessi" should be replaced by "I.smcp" as well."

I.smcp is i.sc in my example, because that’s the way I name small capitals.

Michel Boyer's picture

@ Arno

Ok, I see. The glyphs dotlessi.sc and i.sc should indeed look the same. Now, if an otf file (or a bunch of otf files) is generated by a script (and I think that's the way people from Adobe work), maybe it is less trouble to handle the .sc feature in a systematic way and have two characters with the same glyph. Just a guess...

Arno Enslin's picture

Yes, but then a font, that contains an additional (to the i.sc/I.smcp) dotlessi.sc, should also contain an additional (to the I) Dotlessi, shouldn’t it? I mean, the scenario could be, that someone types in an i.sc from the glyph panel. In Indesign this automatically activates the sc feature, as far as I know. And when the user manually deactivates the sc feature, the application replaces i.sc by i, but not dotlessi. But the same problem would appear, when the user types in the capital I. The I is replaced by the i, but not by the dotlessi, when the user converts capital letters to small ones. So, either a font should contain both, dotlessi.sc and Dotlessi or none of them. At least this sounds consequent and logical to me.

And if a font contains I, Dotlessi, i.sc and dotlessi.sc, there is the danger, that the user messes both up, if he selects one of the characters from the glyph panel.

Yesterday I removed the dotlessi.sc from a font and now I don’t know, if I shall undo that step.

Arno Enslin's picture

http://www.adobe.com/type/browser/html/readmes/PalatinoStdReadMe.html

Looks like Adobe began to add the dotlessi.sc lately to the fonts. I found that also in other readmes.

Don’t know, what I shall do know. Maybe I undo my step and add the character (!) Dotlessi (which is even more than Adobe does). But first I would like to here more opinions.

dezcom's picture

What does the substitution code look like in {smcp}? or better, the pertinent classes.

Arno Enslin's picture

@ Chris

Minion substitutes dotlessi by dotlessi.sc (class "smcp3" by "smcp4") in the smcp feature, but dotlessi.sc is not present in the c2sc feature. It neither is present in any class substituted in the c2sc feature nor it is directly listed in a substitution rule of the c2sc feature. This is what I had expected, because it would not make sense to substitute I by dotlessi.sc, maybe except from Turkish.

And I just see (in the Minion feature file, that Adobe provides along with the AFDKO), that Minion contains two different sc classes, a small letter sc class and a capital letter sc class, but a.sc is the same as A.sc for example. I don’t understand that. Isn’t that totally overdone?

twardoch's picture

Arno,

1. Minion Pro has been revised several times. It's best to look at more recent versions, e.g. Minion Pro version 2.0.

2. We at Fontlab Ltd. also think that it's a good idea to duplicate the small cap glyphs, though we recommend naming the glyphs "A.c2sc" and "a.smcp", which makes clear what their purpose is. Since PDF applications often need to parsing glyphnames to recreate the original text string (when searching or copy-pasting), keeping separate glyphname prefixes for glyphs that semantically represent uppercase or lowercase letters allows better text accessibility.

3. Currently, the recommended way to deal with Turkish letters is to duplicate "i" as "i.TRK" and place the substitution into the "locl" feature:
feature locl {
language TRK;
sub i by i.TRK;
} locl;

Then you have five glyphs for Unicode characters: I, Idotaccent, i, i.TRK, dotlessi. And you have five smallcap glyphs: I.c2sc, i.smcp and dotlessi.smcp (all identical, without a dot), as well as Idotaccent.c2sc and i.TRK.smcp (identical, with a dot).

In "c2sc", you use the substitutions:
feature c2sc {
sub I by I.c2sc;
sub Idotaccent by Idotaccent.smcp;
} c2sc;

In "smcp", you have the substitutions:
feature smcp {
sub i by i.smcp;
sub i.TRK by i.TRK.smcp;
sub dotlessi by dotlessi.smcp;
} smcp;

Adam

Arno Enslin's picture

@ Adam

Thanks!

But seriously, with regard to the suffix I totally loose the overview, if dotted letters "i" are called i (no suffix), Idotaccent (suffix: dotaccent) and i.TRK (suffix: .TRK).

And while I can understand, that it is necessarily to have an additional dotted i in the font, I don’t understand, why there are Idotaccent.smcp and (!) i.TRK.smcp. Where is the disadvantage in the following code?:

feature locl {
language TRK;
sub i by idotaccent;
} locl;

feature c2sc {
sub I by i.smcp;
sub Idotaccent by idotaccent.smcp;
sub Dotlessi by dotlessi.smcp; #*****Additional line (and additional character)!*****
} c2sc;

feature smcp {
sub i by i.smcp;
sub idotaccent by idotaccent.smcp;
sub dotlessi by dotlessi.smcp;
} smcp;

Or alternatively this, without dotlessi.smcp and Dotlessi:

feature locl {
language TRK;
sub i by idotaccent;
} locl;

feature c2sc {
sub I by i.smcp;
sub Idotaccent by idotaccent.smcp;
} c2sc;

feature smcp {
sub i by i.smcp;
sub idotaccent by idotaccent.smcp;
sub dotlessi by i.smcp
} smcp;

I mean, isn’t Adobe’s actual way a half baked thing with regard to the symmetry of dotlessi?

And why is there a need for doubling the whole alphabet ([a.smcp-z.smcp] and {!} [A.c2sc-Z.c2sc]), if the glyphs are the same?

twardoch's picture

Arno,

glyphnames are not there to be "symmetrical". I've explained it here:
http://typophile.com/node/29469#comment-404691

Adam

Stephen Rapp's picture

It would make sense to add it just for cases where text is being copied elsewhere to change fonts and you would want everything to fall into place.

Syndicate content Syndicate content