• Small-caps (of course)
• Different figure sets (oldstyle, capital etc.)
• Contextual ligatures
• Discretionary ligatures

I use OpenOffice on a regular basis, for those times when typographic detail is not my top concern.

/Måns

Kerning (kern)
Standard ligatures (liga)
Small caps (smcp & c2sc)
Fractions (frac)
Superscripts (sups)
Subscripts (subs)
Ordinals (ordn)
Figure styles (onum, lnum, tnum, pnum)
Stylistic Sets (ss01-ss20)
Contextual Alternates (calt)

Features that should be applied by default to simple scripts (Latin, Cyrillic, Greek etc.), even if there are no UI controls for advanced typographic features: kern, mark, mkmk, mset, ccmp, rlig, liga, clig, calt. If the application offers the ability to specify the language of a certain text run, also locl.

If there are UI controls, the following should be on by default and have no UI controls to turn off: kern, mark, mkmk, mset, ccmp, rlig, locl.

The following should be on by default but have UI controls to turn off: liga, clig, calt.

At least the following should be off by default but should have UI controls to turn on: smcp, smcp+c2sc, sups, subs, sinf, onum, lnum, tnum, pnum, salt.

It would be also great if the following had UI controls, off by the default, frac, numr, dnom, ordn, ss01-ss20, swsh+cswh, titl, case+cpsp, dlig, hist+hlig, pcap, pcap+c2pc, unic, zero, ornm as well as “positional forms” which would apply isol, init, medi, fina at the appropriate positions within words.

Adam

Bearing in mind that while many font developers understand what these OpenType abbreviations mean, that cannot be assumed of the general end-user population; therefore a brief description or expansion of the feature abbreviation should be displayed in the user interface where applicable.

I want it all!

Mikey :-)

[..] mark, mkmk [..]

— that would put InDesign CS3 to shame :o)

Pango uses FreeType 2.0 for drawing, doesn’t it? I was a bit disappointed by the lack of OTF support for FreeType, although that gets a fairly reasonable explanation in their documentation.

A robust OTF engine should have no problem with RTL languages, although — as with some more OTF features — that overlaps with User Interface, physically drawing strings, way of data storage, etc..

[..]what these OpenType abbreviations mean [..]

I wouldn’t have no problem with selecting the correct abbreviation per feature (not being part of the “general end-user population”), but I’m pretty sure Adam didn’t mean quite that.

Best would be a single general programming library that does all of the above!

Thanks for your opinions! Adam, I’m particularly grateful for your careful suggestions.

Theunis, regarding the single library: HarfBuzz implements a lot of the OpenType layout features missing from FreeType. The software is an unglamorous bit of code shared between Pango and Qt4, with little documentation or development at the moment, but it does its job; and the developers of the two libraries (and myself, if I can be proficient enough) want to make it the standard way of doing OpenType magic across all FLOSS, even on non-FLOSS operating systems.

Pango currently has almost everything sitting on the cusp of implementation. It seems the current developers haven’t seen much demand for these features, or at least have (quite justifiably) been focusing on getting basic support for all languages before concentrating on advanced features for Latin scripts. Currently, I’m working on finding the best way to alter the Pango API to enable access to the OpenType features; I’ve got a couple good ideas, but since Pango is used by thousands of applications, there’s probably going to be some back-and-forth before an API is settled on. In any case, this API will allow access to and inspection of any OpenType feature listed in the OpenType specs, and will also include some short aliases in order to let non-typographically-inclined developers use “small-caps” to get real small caps.

Implementing this in Pango-based applications should be relatively straightforward from that point. The biggest challenge has nothing to do with typography, actually: the file formats will most likely have to be changed to accommodate the additional information, and that always involves a lot of testing to ensure no corruption (and backwards-compatibility, if possible). In any case, I’ll start with Inkscape (I use it myself frequently) and move on from there.

Of course, many excellent applications aren’t Pango-based (notably Scribus, OpenOffice.org, and the KOffice suite). I’ll tackle these after working on Inkscape, along with Win32 and OSX support if it is necessary.

Pango 1.17 and newer support the locl tag. Vesion 1.x of freetype used to do this, but in version 2 the authors decided that glyph substitution and the like are better hadled a layer above. So, Pango now implements support for OpenType features itself! See brief demo.