Superiors problems

Hello,

I am preparing a set of superiors letters and came into such problems:

  1. When I try to use recipes (like it was described in a blog post) it just creates empty glyph: esuperior+gravesuperior=egravesuperior

  2. In left panel under the CATEGORIES>Letter>Superscript not all letters are visible eg. lsuperior, ssuperior, xsuperior aren’t.

  3. There could be some kind of kerning inheritance… I have kerned all lowercase letters so why do I have to kern superiors? Or if I could just do it like with sidebearnings: eg. esuperior has sidebearing =e*.7
    That would be nice feature when creating small caps.

The superior letters have quite strange categories in Unicode,
e.g. lsuperior is a accent.

I try to tweak that from time to be more logical for a designer. So in my version the lsuperior shows up in my list, but if someone needs it to be a accent it will not work any more.

About the kerning. You should not use to much time for it. It is very uncommon to have more then one or two superiors next to each other…
But you are right. A method for copying kerning to small cap would be great. MetricsMachine does that quite nicely.

Perhaps it’s a better choice to use the .sups extension?
e.sups+grave.sups=egrave.sups

@Georg:
Copying kerning from caps to smallcaps: http://pastebin.com/7dMf7Ac2

You are right. But in French: Yes I know but there is no trial version and I am not sure if it is worth buying, or rather do I really need it working in Glyphs. Thanks, it works.

What you mention should be in the ordn feature, and the letters should be grouped in one single glyph, e.g. e_r.ordn

And the ordn feature could be extended by:
sub one e’ r’ by e_r.ordn;
sub one egrave’ r’ e’ by egrave_r_e.ordn;
sub [one two three four five six seven eight nine zero] m’ e’ by m_e.ordn;
Etc.

Ok. I will include them in ordn feature also. I saw in some fonts that superscipts letters are available through ordn and sups.

This script http://pastebin.com/7dMf7Ac2 makes all kerning class names lowercase. So I have @a.sc etc while glyphs naming convenction is A.sc.

Why is that?

P.S.
I have removed lower() function

There is no consensus about the lowercase or uppercase small caps. Personally I consider small caps to be lowercase that happen to look like uppercase. There are two OT feature that use them. The smcp and the c2sc. The smcp feature is there to switch lower case to small caps (e.g. to mark a name in a text) and the later is there to witch uppercase to small caps (e.g. to make an abbreviation not stand out so much in a text).

So the question is what is the more important use case for you? In Germany it is quite common to use small caps for names and as a typographic style and not so often used for abbreviations, thats why I consider them to be small caps. Thous I use a.sc.

So if it is a matter of style I’ll stick to uppercase convention.

Thank You guys for valuable tips.

mekkablue


Doing this you should know all the abbreviations used in all languages your font is supposed to be used. Why don’t just create an ordinal version of each lowercase and let people compose their text?
This is only done in a few languages. German, for instance, uses a period after the number. Plus, there are different conventions, e.g. underlined or dotted letters. And what do you do if you want to have the letters go diagonal as it is done in many script typefaces?

The method you mention, i.e. indiscriminately raising all selected letters, is what sups is for.

Ok right:
sups > all lowercase + basic punctation
ordn > specific language combos. Do you know if there is any list of all this kind of numerals please?

The point of ordn is not necessarily to move glyphs up, but rather to provide a contextual variation for ordinal numbers.

As for a list, well, people once tried something on Typophile, but it quickly proved to be too complicated for a simple list. See for yourself: http://typophile.com/node/42577

Keep in mind that, like in English, it is sometimes disputed whether ordinal suffixes should be raised at all.

What you could do, however, is make a chaining contextual substitution like in frac:

sub [@figures period] @letters’ by @raisedletters;
sub @raisedletters @letters’ by @raisedletters;

…which raises all letters until the first non-letter. As a user, I’d be reluctant to make use of this feature because I’d be afraid that it could raise more letters than necessary. In that case, I’d use a GREP style with sups. But I imagine there are uses where this could still be a good idea.

this is nice, but assumes there is a “period”. I’ll think about what to do, no precise idea by now. Thanks!

Either a period or a figure. In Spanish, a period is used between numbers and suffixes. You could refine it to this:

sub @figures @letters’ by @raisedletters;
sub @figures period @letters’ by @raisedletters;
sub @raisedletters @letters’ by @raisedletters;

I wonder why one would need egravesuperior. From discussions on the ATypI mailing list I remember that its inclusion in Unicode was a mistake. Today I asked our colleague type designer Jean-Francois Porchez. He told me that the only superiors in use in french are: 1er, 1re, 2e, 3e, 4e… 52e, Mme, M., Mlle, as well Mgr, Cie, may be others. At text level, it is always better to use the full word: Première, Deuxième …

Furthermore he said: Sadly on iphone [etc] now they correct language for you (oh nice!)… and suggest the mistake 2ième and so on. Terrible! In reality, the e following a number is mostly used for titles like 43e Anniversaire.

I would suggest not to fill a questionable funny slot just because it’s there …

While JFP is correct in terms of current French prescriptive orthography, he is wrong about descriptive orthography. There have been enough cases of ‘1ère’ historically, and even a simple Google search brings up 70 million hits for ‘1ère’. Like it or not, it is in use, and may be very well included in the next orthography reform. The point being it is not the font’s job to judge a user’s orthography, which may also be a conscious decision, not just a spelling mistake.

I am not aware of raised è having a Unicode value though. AFAIK, it is purely accessed through OT features.

Dear Rainer, of course you are right, ègravesuperior does not have a Unicode. The discussion was about wether ist should be in a font or not. The person in question more or less regretted that he incuded the character in one or more typefaces he designed for one of the Bigger Players. Another reason for thinking this over is that I have occupied myself with legibility, accessibility and things such as plain language. Superior letters are an issue here and as accents are even smaller, they tend to make things worse. I must admit that I can not quote studies on this, but I think that writing the lowercase part of Nième in superior letters as suggested here is not what we would think of as a service to the reader.