I'm a bit unclear on why you think you need to create duplicates of your ligatures.

You can encode (e.g.) your f_i ligature as UFB01, include a rule sub f i by f_i, and omit the duplicate fi character altogether. Note that either name (fi or f_i) is consistent with proper naming conventions (though personally I'd use the latter).

Including capital versions of the ligatures is only necessary if you want to accommodate users who employ hard-coded ligatures in their text (something which I view as a bad practice).

André

In theory, Unicode should not exist for ligatures, because they confound the distinction between character and glyph.

However, Unicode accommodates many "legacy" typographic characters that were part of exisiting encodings -- and so, because "fi" was part of, for instance, the Mac OS Roman encoding, it is given its own Unicode.

Are your fi.sc a real ligature or a mere aggregation of f.sc and i.sc, if the later is the case, then I see no point in having an fi.sc glyph at all, it is just redundant. you can instead say:

sub fi by f.sc i.sc;


and the same goes for other similar ligatures.

Is there such a thing as an uppercase long s?

sub fi by f.sc i.sc requires an application to support one to many substitutions which many currently do not.

The issue of small capital f_i, however, only arises where the user actually enters uFBO1 instead of simply entering the sequence f i. I'd hope that with the advent of opentype, few users are choosing to do this. Given a legacy text which includes hard-coded ligatures, I'd think the user would be better off doing a search-and-replace to fix so that spell-checking, hyphenation, etc. actually work properly anyway, so supporting smallcap (or all cap) versions of ligatures doesn't seem like it should be a priority when coding features.

André

@Oldnick.

Yes. You can find it at u0053.

André

Hi André, this is what M.Sousa says about duplicating ligatures:
"The only reason why there's the need for smallcap versions of fi and fl is because they are characters, i.e. they have their own Unicode codepoints. In addition, these two characters are included in the MacRoman encoding and can be easily accessed from the keyboard, so there's a high chance to find them in texts."
Thansk Nick, that's why I'm thinking about removing the encodings of my ligatures.
Khaled, good point, thanks.
Mr. Oldnick, I also would like to know about that, I think there isn't an uppercase form of long s.

Eli,

Sousa's comments provide a reason for providing a f_i.sc glyph, but not a reason for providing both f_i and fi glyphs. That's the part I'm not getting.

André

Hi Eli!

I’d say the only encoded ligatures you should include are fi and fl, because there is a fair chance that in some texts they were set as one single character:

(US keyboard)
alt shift 5 = fi
alt shift 6 = fl

(Spanish ISO keyboard)
alt shift f = fi
alt shift g = fl

Duplicate them as f_i and f_l is not mandatory, but doesn’t hurt anyway, since this way you are not depending on the Mac OS Roman encoding.

At least, that is what I did for Espinosa Nova (check out slots 386, 387, 390 and 391).

———

About the uppercase long s:
http://en.wikipedia.org/wiki/Capital_%C3%9F
(Included in Espinosa Nova as well, see slots 88 and 195.)

———

And please Eli, let me see your typeface when it is done. I am intrigued about the long s. Are you working on an oldstyle typeface?

I'm curious what applications don't support one to many substitutions? looks so 80s to me.

André, I think the problem with encoded ligatures is that when you use them and make the feature liga with them you are not changing the glyph but the character itself and I think it can cause problems with your GSUB table, but I'm not sure about that.

Cristobal thank you for your clarification, I think I'm going to do what you did with your beautiful Espinosa Nova. Correct me if I'm wrong, the eszet is a ligature between long s and s, I don't know if there is a capital form of long s alone. You may want to have a look at these links for more comments about the capital eszet: http://www.flickr.com/photos/elibaal/5039507654/ http://www.flickr.com/photos/hardwig/5087231570/
And finally, I'm currently working on a humanist sans, I'll send you a sneak preview.

I stand corrected: yes, I was talking about an uppercase ß, not an uppercase long s alone. Sorry about that. :P

Looking forward to see your sans serif long s!

My take is you grudgingly support legacy characters, you never encourage their use.

We don't sell fonts, we work them over only to set type. Maybe my views shouldn't count, then. But when I run into a font with a fi or fl character, (and a Unicode codepoint), I take them out. At some point, the fi character should be *deprecated.* Far as I'm concerned, that was as soon as we could employ a character-glyph distinction.

As for F_I ligatures, whether small or full cap, why? How many texts come to people who use type where that's been an issue? I've never seen one -- can somebody remember one, or is this just a theoretical exercise?

What to do when small or full caps are both ligatures and letterspaced, esp. just below the point where any ligatures break into component characters? They're going to look dreadful. And both are commonly letterspaced.

Etc.

I say let a text show .notdef and salmon for any fi/fl etc. characters. Fix that text then & there, and we've gotten rid of one more bum situation.

I'm not a German, but small eszet always looked like an upper letter to me, I like the one in this sign http://www.flickr.com/photos/hardwig/5087231570/ as it looks like a real small letter (and does not look like a B or small beta either).