You should try subscribing to the OpenType list. It's a better source of help. Send an email to the address below. And you can also open an existing font and look at the tables to see how features are implemented.

subscribe: opentype-migration-sub@indx.co.uk
unsubscribe: opentype-migration-unsub@indx.co.uk
messages: opentype-migration-list@indx.co.uk

George
I felt bad because I had no shoes, until I met a man who had no Bodoni

Not sure about 1 and 2, but 3 is not allowed as far as I know. Do this instead:

sub glyph.1.a' glyph.2.a by glyph.1.b ;
sub glyph.1.b glyph.2.a' by glyph.2.b ;


Only one substitution per statement, but easy enough to work around.

George — Thanks for the hint. I tried to subscribe to the OT List, but did not get approval so far. Rather than joining yet another list/forum, I'd like to thoroughly study the OpenType Feature Language syntax first, find out solutions by myself, so that I do not need to ask any more obvious questions. Is the documentation available for download as a printable pdf? It is hard to study and read from a screen, browsing hopelessly cluttered web pages, so I hoped there might be a nicely structured pdf OT syntax manual, somewhere…

Mark — As regards my question (3): Yes, I knew, thanks, but this workaround will likely cause problems in some cases, and sure becomes perilously tedious when one needs to substitute large sequences. Furthermore, it is my understanding that multiple-substitutions are implemented into (allowed by) the OT syntax, but are not supported by present interpreters.

Additionally, I'd like to know what be the case with one-into-many substitutions (or ligature decomposition) such as sub fi by f.buttonhook i; (which would save the i-dot in TRK in the most appropriate way, or which would correctly space punctuation, using a statement such as:
sub @word [question exclam]' by uni2007 [question exclam];
(uni2007 being the codepoint for punctuation space).) An insert command keyword would of course be even more convenient…

As for (1) and (2), this would offer lots of possibilities such as embedding features into other features, e.g. features that are not supported by user apps yet, to become available through features that do are supported already, without confusing the code by merely hacking existing features. Also, this would allow type developers to enforce certain substitutions into a feature, that generally are not included in that feature, such as pairing small caps lining figures (x-cap numerals) with small caps by default.

Ludwig,

In each OpenType font, there are two *separate* lists of visual text transformation procedures: there is a list of features and there is a list of lookups.

Features are functional procedures that do visual text transformation. They have a name and a widely accepted meaning.

Lookups are actions (substitutions or position changes) that are performed on groups of glyphs. Each font contains one list of lookups, ordered in a particular sequence. You could view lookups as being the technical implementation of some visual text transformation procedures.

The features in a font are mapped to a tree structure of writing systems (scripts) and language systems.

Each font also includes a n:m map from features to lookups. In other words, one feature can map to several lookups -- if this is the case, when the feature is activated, the lookups will be applied on the text in the sequence in that they are ordered in the font. Also, several features can map to the same lookup (for example, the "sups" and the "numr" features could both map to the same lookup that replaces regular figures with superscript figures).

This means that you have a tree structure of scripts and language systems that defines when particular functions should be applied, you have a list of features that defines what those functions actually mean, and you have a list of lookups that define the internal implementation of the functions, i.e. what exactly should happen when a particular visual text transformation is applied.

Lookups cannot contain other lookups (although theoretically, such a scheme might be useful) and features cannot contain other features (this wouldn't make sense anyway because each feature has a different meaning).

A.

The full spec is here

http://partners.adobe.com/public/developer/opentype/index_tables.html

Explanation of layout is here

http://partners.adobe.com/public/developer/opentype/index_layout.html

Feature Tags and explanations are here:

http://partners.adobe.com/public/developer/opentype/index_tag3.html

George
I felt bad because I had no shoes, until I met a man who had no Bodoni

Also, one-to-many substitutions (GSUB LookupType 2) are unfortunately not widely supported in OT Layout engines. For example, the normal international versions of InDesign, Illustrator or Photoshop do not support them (the Middle Eastern versions do).

There is no need, however, to decompose the fi ligature into anything. The currently preferred implementation of the Turkish ligature behavior is by applying a "locl" feature in the Turkish languagesystem context (latn/TRK). That feature should be mapped to a lookup that substitutes the "i" glyph with a "i.TRK" glyph which is identical in appearance. More on this in http://typophile.com/node/29469

Regards,
A.

BTW, I recommend everyone interested in the topic (Adobe support for GSUB LookupType 2 -- "one-to-many substitutions" -- in OpenType fonts) to file a product feature request at:

http://www.adobe.com/support/feature.html

The more different people submit this, the more likely a feature will be actually implemented.

Regards,
Adam

Adam — First of all, thank you for your always exhaustively and logically structured clarifications.

If I understand it correct and may complete your explanation, each (properly set-up) OpenType font includes (1) tables, (2) glyph classes, (3) languagesystems, (4) features, (5) lookups and (6) statements, and lists their names and defines them, with the exception of tables (which are constituted by the OT format as such) and of statements (which are nameless definitions by themselves.)

List Order — The five aforementioned types of OT components, must be listed in a logical order. It is not all too clear what that order ideally must be. Two different relationships of chronological hierarchy are to be taken into considerations. There is (1) the list order of those five types of components as regards each other, (2) the order of instances of these component types amongst themselves.
As for the first, I guess, the above itemisation represents a quite common, perhaps even (partly) obligatory hierarchy, with the exception that, in the example files I looked into, languagesystems are stated within features, rather than that features "are mapped to a tree structure of (…) language systems", as you say they are. As for the second, it is my understanding that the order in which the tables are listed is of no relevance (i.e. has no consequences for the behaviour of the font during its interpretation by the OT engine), apart from the fact that the head, name and base tables should go first, in that order, and that furthermore the GSUB table, for instance, doesn't have to be stated explicitly. Neither so, complies the order of glyph classes to any prescription, unless glyph classes contain other classes, in which case they must evidently be listed below those which they contain. The order in which features and lookups are listed, conversely is of crucial importance, because of changed contexts that might affect later substitutions.
However, in the .fea feature files I inspected, there seems to be no strict order for the listing of glyph classes, of features nor of lookups, apart from such a one that does not cause features and lookups to become obsolete. There is no really systematic structure. The structure I think to be able to recognise is that, first all glyph classes are defined, then the languagesystems, thereafter the naming list of features (within the aalt feature (!)), and lastly the explanation of these features, which on their turn both list and define lookups.
In short: (1) there is no list (index) for the tables (which is made redundant because of the OT specification itself), (2) there is a list of glyph class definitions, which precedes the features and lookups in which they will be used, (3) there must be a list of languagesystems, also preceding the features for which they will be needed, (4) there is a list of all features that are present in the font's feature file, namely listed within the aalt feature, which consequently is listed first and (5), contrary to what you seem to write, I find no such list for lookups. Lookups appear to be both listed and defined at the same within the features, at the moment they are needed first. To me, it seems indeed useful to define lookups only at the moment they will be called for, for the first time, but this should also apply for glyph classes. This would facilitate scripting and the reuse of code snippets into other feature files.
I do not understand what you mean by an "n:m map" — in the .fea example files I looked into (especially minionpro.fea, FontRevision 2.012), there seems to be no such thing.

Lookups — You write lookups "are actions that are performed on groups of glyphs". Does this imply there is no use for 'singleton' lookups (i.e. lookups that contain only one substitution or position change statement)? This would make sense, though, because of their extensibility and reuse in several following features. I notice however that, contrarily to what you seem to suggest, features do not contain lookup actions (mapped to languagesystems) only, but that they also define (isolated) actions that are not grouped into lookups.

Embedded features — You confirm that features cannot contain other features (and neither can lookups). As I mentioned above, there is however at least one exception, namely the aalt feature, which contains (lists) all other features in the font. May I conclude from this exception that the OT feature language syntax does allow for the embedding of features? I see at least one (to me) useful implementation, namely to have a 'default' feature (dflt), that, of course, should be applied by default by the OT engine, and which contains all the features the developer/designer of the font deems typographically necessary for his font, but which may be overruled by other features, accessed through the UI.

GSUB LookupType 2: one-to-many It's unfortunate indeed that this is not supported more widely, especially since the similar (and less useful) one-from-many (LookupType 3) is. I agree that there is no need to decompose the fi ligature for TRK, because of the workaround you mentioned. However, my proposed solution would imho not only be more elegant, it also solves the awkward collision of the overhanging f with the dotted i (for which the fi-ligature was needed in the first place), by substituting the f by an alternate buttonhooked f. But there are more useful implementations, such as the earlier mentioned insertion of hair spaces in a feasible punctuation spacing feature (sppu). An insert (substitute non-into-many) and remove (substitute many-into-none) command would alternatively offer the same flexibility.

George — Thanks for the links. Yet, I still find it hard to go through this complicated material by browsing websites and scattered information sources.

Is there really no comprehensive OT Feature Language manual, that I can print, start reading and studying at my desk, rather than staring at a screen, clicking my way through this mess of unorganised documentation? (Alas, I'm not that of a geek, yet.)

> support for GSUB LookupType 2

How does this work? Must the support for LookupTypes be implemented at the level of the OT interpreter, rather than is the case with support for features, which need to be implemented at the level of the applications and their UIs? Lack of support for features (i.e. their accessibility within an app) may be hacked by workarounds such as my proposed dflt feature, whereas the absence of support for LookupTypes is more devastating, since that truly hinders development.

I certainly support your call to Adobe to implement LookupTypes more urgently. Their Product Feature Request form, however, seems to target user applications rather than back-end interpreters.

Do you know of programs that do support GSUB LookupType 2? XeTeX perhaps?

Ludwig,

1. A lookup can apply to singleton glyphs, classes, series of singleton glyphs, or series of classes. By "groups" in my former description, I meant a generalization of those, i.e one or more glyphs.

2. Changing spacing of characters does not have to be done through inserting glyphs. The OpenType positioning statements pos glyphname <dx1 dy1 dx2 dy2>; allow you to change the position of the current and the next glyph origin. For example, pos A <200 0 400 0>;" moves the glyph origin of the "A" glyph by +200 units (therefore, effectively, increasing the LSB of "A" by 200 units) and moves the next glyph origin by +400 units (therefore, effectively, increasing the RSB of "A" by another 200 units). pos parenleft <0 100 0 0>; moves the glyph origin of parenleft (i.e. the glyph itself) by 100 units up.

3. One thing that you need to understand is that the internal structure of the OpenType GSUB and GPOS tables is different than the AFDKO source code syntax that is used to describe the OpenType Layout feature definitions in FontLab Studio and Adobe FDK for OpenType. The AFDKO syntax simplifies the creation of lookups and some features in two ways:

- For "aalt", it provides a simplified syntax; what actually gets done is that all lookups that are associated with all the features that are enumerated in the "aalt" definition also get associated with "aalt". In other words, the special AFDKO syntax for "aalt" hides some implementation specifics; in reality, there still is no "features within features".

- Lookups in the AFDKO syntax are defined within feature definitions. Lookups don't even have to be named explicitly.

The AFDKO syntax:

languagesystem latn dflt;
languagesystem latn TRK;
feature smcp {
  sub [a b c f g l u] by [A.smcp B.smcp C.smcp F.smcp G.smcp L.smcp U.smcp];
} smcp;
feature liga {
  lookup liga_i {
   sub f i by f_i;
  } liga_i;
  lookup liga_noi {
   sub f l by f_l;
  } liga_noi;
language TRK exclude_dflt;
  lookup liga_noi;
} liga;

actually compiles to something like this (this is in pseudosyntax):

# LOOKUPS

lookup L01 {
  sub [a b c f g l u] by [A.smcp B.smcp C.smcp F.smcp G.smcp L.smcp U.smcp];
} L01;

lookup L02 {
  sub f i by f_i;
} L02;

lookup L03 {
  sub f l by f_l;
} L03;

# FEATURES

script "latn";
  DefaultLangSys;
   feature "liga" {
   lookup L02;
   lookup L03;
   } liga;
   feature "smcp" {
   lookup L01;
   } smcp;
  LangSys "TRK";
   feature "liga" {
   lookup L03;
   } liga;
   feature "smcp" {
   lookup L01;
   } smcp;

While the AFDKO syntax:

languagesystem latn dflt;
languagesystem latn TRK;
feature liga {
  lookup liga_i {
   sub f i by f_i;
  } liga_i;
  lookup liga_noi {
   sub f l by f_l;
  } liga_noi;
language TRK exclude_dflt;
  lookup liga_noi;
} liga;
feature smcp {
  sub [a b c f g l u] by [A.smcp B.smcp C.smcp F.smcp G.smcp L.smcp U.smcp];
} smcp;

actually compiles to something like this:

# LOOKUPS

lookup L01 {
  sub f i by f_i;
} L01;

lookup L02 {
  sub f l by f_l;
} L02;

lookup L03 {
  sub [a b c f g l u] by [A.smcp B.smcp C.smcp F.smcp G.smcp L.smcp U.smcp];
} L03;

# FEATURES

script "latn";
  DefaultLangSys;
   feature "liga" {
   lookup L01;
   lookup L02;
   } liga;
   feature "smcp" {
   lookup L03;
   } smcp;
  LangSys "TRK";
   feature "liga" {
   lookup L02;
   } liga;
   feature "smcp" {
   lookup L03;
   } smcp;

Note that in both cases, the order of the features in the compiled format is the same. Only the order of the lookups differs, and it is inferred from the order in which the lookups are defined (implicitly or explicitly) in the AFDKO syntax. Also note that the lookups don't have any actual names, the "L##" convention I used is just an example. Internally, numbers are just used.

The problem with the second implementation is that if a user applies both "liga" and "smcp" to the word "flug", the L01 lookup replaces the glyph sequence "f l" by a glyph "f_l", and then, lookup L03 replaces the glyphs "u" with "U.smcp" and "g" with "G.smcp". You end up with the glyph sequence "f_l U.smcp G.smcp", which is surely not what you wanted.

In the first, correct, implementation, the lookup L01 replaces "f" with "F.smcp", "l" with "L.smcp", "u" with "U.smcp" and "g" with "G.smcp", and then L02 is executed but has nothing to replace. You end up with the string "F.smcp L.smcp U.smcp G.smcp", which is probably what you wanted.

This illustrates why the sequence in which you define your lookups is important. In the AFDKO syntax, it means that the sequence in which you place the feature definition blocks is important, but when the font is generated, the AFDKO compiler will extract all the (implicit and explicit) lookup definitions from the feature definition blocks, create a lookup list from them (in the order they come in), and then the compiler will build a list of features (sorted alphabetically) and will map the lookups to the appropriate features within the appropriate languagsystem contexts.

In AFDKO 2.0, it is possible to defined named lookups in the order you want outside of the feature definition blocks. This is sometimes useful if you want to, on one hand, precisely control the sequence of lookups while on the other hand, re-use lookups in different features.

A.

BTW, all the substitution and positioning rules are stored (in a compiled form) in two tables: "GSUB" and "GPOS". There are many other tables in a font, such as "glyf" or "CFF " that store the glyph outlines (for OpenType TT or OpenType PS fonts, respectively), "name" that stores all the family and style names, copyright and version strings and other textual information, "OS/2" that stores some important style-linking and character set coverage information, "cmap" that stores the Unicode-to-glyph mapping information, "post" that stores the glyphnames in OpenType TT fonts, and many many others.

I recommend taking a look at the OpenType specification at least to familiarize yourself with the purpose and the names of the tables included in the font. You can use a tool such as TTX ( http://www.font.org/software/ttx/ ) to convert a binary OpenType or TrueType font into XML and preview the internal table structure.

A.

Just to clarify, one thing that is not supported in the OpenType *format* itself is many-to-many substitutions as a single substitution. This is not a matter of text engine support, but of format support. As I understand it, this was a deliberate decision, not something overlooked.

Regards,

T

Thomas — I guess the technical, or rather logical, restriction for a many-into-many substitution is the ambiguous nature of this kind of lookup type (which from many is to be substituted into which one out of the other group of many?), as Adam wrote somewhere.

Lookup Type 2 (one-into-many), however, is in the OT specs, but hasn't been implemented yet. This should be done as soon as possible. As I said, commands such as 'insert' or 'remove' would be an alternative solution. One possible application I see is the contextual insertion of spaces (as they have Unicode codepoints). Too, editors could customise their OT fonts for all sorts of text editing specifications.

As I understand it, 'nul' or 'nought' is in the OT specs as well, but hasn't been implemented either. 'sub x by nul;' would have the same effect as 'remove'.

Ludwig M. Solzen wrote:
[...] or which would correctly space punctuation, using a statement such as:
sub @word [question exclam]' by uni2007 [question exclam];
(uni2007 being the codepoint for punctuation space)

Adam Twardoch wrote:
such as the earlier mentioned insertion of hair spaces in a feasible punctuation spacing feature (sppu)

Interesting. I haven't even recognized this punctuation space character. However, taking into account possible problems*, you should follow Adam Twardoch's recommendation to increase space before punctuation via pos commands. This could look like a second class based kern feature, and is something that I already put into fonts.

* See the OT List posts with the subject "Acrobat text restoration and unrecognised glyph names" ...

It's nice to see your enthusiasm, but just changing or adding to specs is not enough. It is applications -- i.e. the extent to which they do or don't support features or lookup types -- that impose restrictions.
But: Even if future versions of applications would support lookup type 2 -- there are current application versions which have real problems with fonts that contain lookup type 2. Since the lifetime of old versions of applications can be pretty long (people will continue to use Creative Suite 2 for some time to come, just as some still use MacOS9, XPress 4, PhotoShop 7, InDesign 2 now), it doesn't seem to be wise to include this lookup type into fonts for the next few years ...

Having said this, it seems there is some demand for a collection of feature and lookup related information: Not only which apps support which features, but also which apps support which lookup types.

Adobe's Feature File Syntax document is a pretty good introduction to writing OT features. Download it here or -- which I'd recommend -- you download the complete AFDKO here. The latter includes the Feature File Syntax plus some other important documents, and very useful Python scripts for use in FontLab Studio. For more links, you can download a PDF here.

Karsten

BTW, I recommend everyone interested in the topic (Adobe support for GSUB LookupType 2 — “one-to-many substitutions” — in OpenType fonts) to file a product feature request

if i remember correctly (which i very well may not), Thomas Phinney had announced that the next iteration of AFDKO would support all lookup types.

"this was a deliberate decision, not something overlooked."

Why is that Thomas?

ChrisL

Chris,

my guess is that it was done not overcomplicate things. Currently, what you can do (in apps that support all lookup types) is replace one glyph by one (A -> B), several glyphs be one (A B -> C) or one by several (A –> B C). There is always "one" included in each lookup type, so for a line layout engine, it’s comparably easy to track the character-to-glyph dependance and do things like "remove glyphs from the internal buffer" or "add glyphs to the internal buffer" is some subprocedures. A many-to-many lookup would introduce a situation where the internal buffer might grow or shrink or stay the same, all potentially in the same lookup. I guess it would be more difficult for layout engine developers to deal with this kind of "variability".

Also, the AFDKO support for *building* OpenType tables and the type engines' support for *running* (i.e. "consuming) OpenType tables are somewhat different things. Of course, in a perfect case, both the development tools and the layout applications should support everything.

A.

Karsten — Thank you very much for the links. I did find your pdf link list already and it’s a great help. It seems I'll have to do without a "OT for Dummies" like, printed manual.

There are several space characters in Unicode (have a quick overview here). If you put those in your fonts, you can determine yourself what should be the ideal width for e.g. hair space, instead of relying on the user app. I am not sure in how far page lay-out applications such as InDesign or Quark actually use the space's advance width information in the font: maybe it's ignored, or overruled by the program's default H&J parameters. (Likely the regular word space is accepted, but as it seems most fonts designers don't consider the space character, the user app has its own default widths. This goes for the regular inter-word breaking space, but probably even more so for thin space, hair space and the like.) Nevertheless, if the font would have all those spaces included, and if it would have an OT feature which contextually inserts these spaces, typesetting at the micro-typographical level would get much easier, better, and because of the automation it would be seen more often (font designers, being aware of the possibility, would put this feature in their fonts).

I considered to use the pos command instead of substitutions too, mainly as a workaround, because Lookup Type 2 (one-into-many) isn't supported. But position changes are much harder to implement, need more code and hence are a less elegant solution. Too, the insertion of a no-break space (uni00A0), e.g. between day and month, is not possible.

Now, some will argue that these kind of uses, which actually affect the typography of the text, are in opposition with the intended use of the OpenType format, that they belong to the task of the typesetter/typographer, or that of the editor, and they really shouldn't be a feature of the font. Hence, the page lay-out program should be responsible for them. I put forward, however, that the present generation of typesetting programs is not capable to do this yet, or at least does not offer the possibility — with the exception of TeX and its various distributions. Furthermore, one could argue that spacing depends on the design of the typeface and should hence be dictated by the type designer. If a typographer doesn't agree with the type designer's settings, he would still have the possibility to overrule them. Also, it is improbable that lay-out programs would apply spacing by default, so that users who are not aware of micro-typographical issues (i.e. most users), will never use the feature, and as a result, the vast majority of typesetting would be devoid of it. Is this a problem? Yes, to me it is, and to all who care for typography, just as the absence of ligatures in most publications that came under their eyes, was to their annoyance, before the advent of OT and InDesign's default application of them. Ligatures were possible, sure, with the tedious use of Expert Sets, but before OT, they were but seldom used.

Yes, I'm an enthusiast, and probably may seem naïve as well. Nevertheless I do am aware that as font developers we depend completely from the developers of user apps. We may invent all sorts of uses, devise even new OT features, but as long as these are not supported, because application programmers find them "crazy", it's of no use. This is exactly why I advocated that rather than adding support for features, the developers of the user apps, should concentrate on the implementation of the OT format as such, and of all its Lookup Types. This, along with the DFLT feature I proposed on the other thread, would give font developers the flexibility they need, without having to rely on the support of apps any further. (Backward compatibility is another issue.) As long as this is not the case, I'm afraid, engineers and programmers, will be imposing which is proper design and which is not — such as the discretionary oldstyle use of the ampersand. (Sorry, Adam ;-) As font designers, I think we have the duty of being enthusiasts, and as users, we have the privilege to make suggestions, even if in the eyes of engineers they seem improbable. I am not asking for unrealistic things. I am no programmer, granted, but I do have an understanding of what computer programs are capable of and how they work. After all, the implementation of Lookup Types is not that hard, and to me it is a matter of the willingness to it, rather than the technical impossibility of it.

Yes, I’m an enthusiast, and probably may seem naïve as well.

Hope you didn't read this as an insult -- because the description fits for one of my former selves too (say, the one of three to two years ago). I said farewell to PS T1 fonts three years ago and stick to OTFs, but have to face the fact that most collegues (designer, typographer) are rather afraid of OTF, and that there are people who still don't know what "this OTF thing" is.

Using positioning instead of space substitution for punctuation spacing is no disadvantage. As to feature code, it is virtually the same. If you can insert a space in certain contexts, you can increase the advance width of a glyph or glyph class as well; it is neither more nor less code.
I too try to put as much "typographic knowledge" into fonts as possible, as I indicated when saying that I already include a feature for spacing punctuation marks. (It's in a Stylistic Set feature so users can switch it off. One must not forget that spacing rules are very different in different countries.) Related to this, I am working on a contextual positioning feature which spaces uppercase letters differently in lowercase and uppercase-only context (I think that increasing advance width or sidebearings at a fixed value for all glyphs is not enough, typographically). To date, I used an additional set of uppercase glyphs that are substituted in uppercase-only context; but this blows up the glyph set unnecessarily.
Whenever you take advantage (typographically, pleasing the user, technically, pleasing yourself when producing fonts) of aspects of OpenType that are supported by a few new applications, you risk that your fonts or parts of them are incompatible with most applications. Even very tiny details can have a huge effect:
Say, you make PS-OT (CFF-OT) fonts. You can sort glyphs nicely, so the application's glyph palette shows a well ordered glyph set. But if you do this, and if you use this font in MacOS9 applications other than InDesign, then the (German keyboard) Euro-shortcut will not return the Euro sign but the currency symbol ...
Or, you could solve the kern feature subtable overflow problem with a little addition (no need to care for subtable breaks) -- but: such a kern feature will be completely ignored by most applications.
Whenever you incorporate very recent OT things you have to remember that you exclude many people from being able to use your fonts.

As to the ampersand, I use it whenever possible, but this is nothing that I would impose on others. If you consider it to be an essential part of your type design, put it into liga or calt which are on by default at least in typographically sensitive applications.

Karsten — No, be assured, I didn't take it as an insult, for I don't think it to be shameful not knowing all about something new. I am new to OT feature coding, and find the topic highly stimulating, because I realise it might solve lots of typographical issues that in the past were very hard to accomplish and practically undoable. But it does annoys me if people who are experts systematically dismiss the enthusiast's proposals as unfeasible. (This does not apply to you.) As a young, but old school typographer I seek to find a way to get the highest level of typography without the time and effort that was needed in the old days, *and* I actively look into the technical side of it, so as to find workable, not imaginary or utopian solutions. Not that I dislike the challenge of time-intensive work, but, as a pragmatist, I know most people (users of programs) do. This is why I find computer typography so motivating: taking advance of instructed default settings, it can subtly induce the ignorant to make more beautiful typography, without him even needing to be aware of it.

You may be right about positioning being a better strategy for punctuation spacing, I don't know, I will have to learn more about it. But what about the no-breaking space?

Putting the punctuation spacing in one of the Stylistic Sets, is a good thing. But you say, this way, users can switch it of. It’s the opposite: Stylistic Sets are not switched on by default, so users will actually have to turn them on. As a result, you could but hope that users will indeed and that they are aware of the availability of the feature. It is my (somewhat patronising) conviction that the default settings of user apps, and by extension, those of fonts, should yield the highest level of typographical standards, without needing the intervention of the user. Much the same way as hyphenation routines follow lexicographic rules, without having to rely on the user's knowledge of the language. If advanced users, who consequently are aware of these issues, disagree with your default settings, they still have the possibility to overrule the defaults. The same argument applies to backward compatibility. As a (font or other) developer, you should take care not to confuse the ordinary user or to disable his functionality (cfr your example of changing the character mapping). But adding extra glyphs and features to your fonts, doesn't harm if the user is not aware of their presence. If he is and he likes to use the extra's, but his software doesn't support, that's a pity for him. But if he really cares, he has to and likely will upgrade. I don't think technological progress is helped by restricting itself in giving too much consideration to users that are not willing or do not care to follow. Mind you, I am not saying the ordinary user's functionality may be hindered, but that the addition of novelties by definition only targets the most advanced and up-to-date users. It's a question of different levels.

As regards the ampersand, I'd like to stress that I am not insisting on this (turning me into a some sort of swash freak). I just imagined it might be a feasible extra, without much of work, but certainly not something to be a default setting.

Putting default settings in the LIGA or CALT, is not really a solution. This is what I called (in the other thread) hijacking of features. And as you say, these defaults would be recognised and applied by OT-savvy applications only. This is why I proposed the DFLT feature.

> a contextual positioning feature which spaces uppercase letters
> differently in lowercase and uppercase-only context

I'm curious: how do you code contextual strings of characters? I'm looking for a feature that automatically recognises strings of uppercases, so as to substitute them by small caps (so that the typesetter doesn't need to tag or format those explicitly, by applying the SMCP and C2SC features manually). Ideally one could program a minimum amount of characters, so that a string of max. 3 consecutive uppercases (as in MD, or EUR) would be substituted by intermediate caps, and those of 4 or more, by small caps.

Ludwig,

1. Inserting spacing glyphs doesn't make sense. Using OpenType postioning, this is exactly what it is intended for.

2. As for your DFLT feature "proposal", I still do not understand how this "would give font developers the flexibility they need, without having to rely on the support of apps any further". I'm sorry but I cannot make anything out of your "proposal". I replied to you: "If you want a particular glyph appear by default when a particular Unicode codepoint is keyed in, the easiest way to achieve this is to simply assign that Unicode codepoint to that glyph. No extra OpenType features need to be applied then." (In other words, if the font developer wants that the user sees small caps instead of lowercase, he should assign the lowercase Unicode codepoints to the small caps glyphs. However, I still don't understand what sense this would make.)

There is a set of OpenType features that applications should have on by default (calt, ccmp, liga, rlig, locl etc.) Some of them (ccmp, rlig, locl) should remain on all the time, while for the others, the user should have means to disable them.

I do not at all understand the need for a "DFLT" feature. Given the way the OpenType architecture is designed, it simply does not make sense.

A.

Some initial food for thought:

@UC = [A B C D E F];
@SC = [A.smcp B.smcp C.smcp D.smcp E.smcp F.smcp];
@TEXT = [a b c d e f];
feature calt {
lookup calt1 {
ignore sub @TEXT @UC';
ignore sub @UC' @TEXT;
sub @UC' @UC by @SC;
} calt1;
lookup calt2 {
ignore sub @UC @UC';
ignore sub @UC' @UC;
sub @SC @UC' by @SC;
} calt2;
} calt;

(This needs rewriting to take care of all cases properly.)

Note, however, that this sort of "smartness" in a font may backfire. Many typographers specifically know when they want to insert small caps and when not.

A.

I'm a little confused, too:

"And as you say, these defaults would be recognised and applied by OT-savvy applications only. This is why I proposed the DFLT feature."

*Any* OpenType layout feature requires the application be OpenType savvy. (The one exception being GPOS kerning in OT-CFF, and that only because some OSes go through some hoops to present a subset as legacy-style kerning data.)

Regards,

T

Adam —

> Inserting spacing glyphs doesn’t make sense (…)
Again: what about the no-break space? And what if the user changes tracking or applies Optical Kerning instead of the font's metrics? Positioning values are expressed absolutely, and not as a relative amount (percentage).

> simply assign that Unicode codepoint to that glyph
This is really no solution, since there are no Unicode codepoints for each and every glyph shape the font designer may devise — this is exactly what OpenType, the Unicode Private Area and unassigned glyphs is all about, isn't it? Assigning the lowercase Unicode codepoints to the small caps glyphs, as you propose, is certainly not what we would want to do, for we do not want to regress into the practices from the days of Expert Set fonts, do we?

Thanks for the coding, I'll give it a try. Would it be possible to define a minimum/maximum amount of glyphs in a string, so that a sequence of three uppercases would be substituted by intermediate caps, those of four or more by small caps? I realise that this "smartness may backfire". However, experienced typographers would always have the possibility to overrule/disable the feature. Also, I think most of these substitutions could and should be in accordance with generally accepted traditions of good typographic practice (Oxford Rules, Chicago Manual). As Karsten put it, I too like to have "as much typographic knowledge build into the font as possible".

Adam, Thomas — Sorry I didn't reply sooner. I have no time to explain the idea in full. The basic concept is quite simple, though. (1) A DFLT feature should be registered. (2) Implement the DFLT feature in the user application, have it checked-on by default (i.e. the application's OT engine should look for the presence of a DFLT feature in the font, and if so, should run all its functions). But allow the user to uncheck the feature. (3) Font developers associate all the usual lookups (associated with registered features) they deem essential to their font to the DFLT feature (such as some or all lookups from e.g. LIGA, CLIG, CALT, with or without language system specific exception rules and/or contextual rules), expanded with custom lookups (that do not fit into registered features and are hence not otherwise accessible). Of course they should take care the lookups are defined in the proper sequence and that they are defined thusly that for example strings of uppercases only are substituted with small caps. The DFLT feature is truly a default (generic) feature in that for more specific formatting or local exceptions the intervention of the user is required through the OT palette. Also, the font developer should not compromise the usability of his font by associating extravagant substitution lookups with the DFLT feature. (4) If this all were to be implemented, user applications (only those that already support OT, of course, i.e. are equipped with an OT engine), wouldn't have to worry about adding feature checkboxes in the UI, while the DFLT feature would take care of a font's most essential features (such as ligatures in MS Word). Font developers on the other hand, would have more flexibility in that they could add unregistered custom-made features to their fonts, having them function by associating them with the DFLT feature.

Additionally, I wonder if it were feasible if the user application could generate a dynamic menu of available features in a font, instead of presenting the user with a fix and inflexible menu, such as is the case now. The OT menu in InDesign, e.g., lists but a standard menu of features which the user can check or uncheck, putting those features that are not available in the font between square brackets, but leaving out features that are present in the font but are not supported. I think this (having the user app generate a dynamic OT menu on the fly) could be easily done. The AALT feature already lists all available features within a font, so the user app would have but to display them with checkboxes. If eventually feature tags would be expanded with name flags, for clarity the user app might list them instead of the four letter tags.

As regards the support for Lookup Types, I wonder in what way the OT format differs from or makes use of / is compatible with Regular Expressions (Wikipedia info). Would macro scripting, taking advantage of regular expression, offer an alternative to solve typesetting issues that cannot be solved with OT features?

Ludwig,

1. What's the purpose of registering one more feature that duplicates the purpose of liga, clig and calt?

2. "Font developers on the other hand, would have more flexibility in that they could add unregistered custom-made features to their fonts, having them function by associating them with the DFLT feature." -- I cannot make any sense at all of it. How is "DFLT" more flexible than what is already done with liga, clig and calt? Typically, liga, clig and calt are all enabled by default but can be disabled by the user. I don't see why adding yet another feature that does the same would add any flexibility or make anything for the user easier.

3. User applications can build their user menus any way they want. Adobe applications such as InDesign, Illustrator and Photoshop use static OpenType feature lists while Apple applications such as Keynote, Pages and TextEdit use dynamic OpenType feature lists. Both approaches have their advantages and disadvantages. There are important reasons for both Adobe and Apple why they chose one implementation over another.

4. OpenType Layout features operate on the glyph stream (the visual representation of text) while leaving the encoded character stream (the logical/semantic representation of text) intact. Search/replace operations, regular expressions and scripting typically operates on the encoded character stream. This is the principal difference.

I assumed that before suggesting extensions to the OpenType format, you have actually read the essential OpenType documentation in order to understand what the format is about. However, perhaps you may want to re-read John Hudson's Windows Glyph Processing: an OpenType Primer and Microsoft Typography's OpenType Development.

Adam —

(1) The purpose of the DFLT feature is *not* merely duplicating already existing and registered features. As I explained, its purpose is to combine the functions of both registered and unregistered features, and this according to the arrangement of the font developer, who might judge differently than application developers on which features should be defaulted. This is an essentially different thing. Associating liga, clig and calt to the dflt feature is just an example, not compulsory and certainly not exhaustive.

(2) Not all applications enable clig and the like by default or even give access to them (e.g. QuarkXPress 6, present PhotoShop releases and both present and future releases of MS Office). If they would support the DFLT feature and by preference would enable it by default, they would apply all features that are associated with DFLT at once, without having to further implement a complex OT menu (which one can expect only to be available in advanced layout applications). Also, unregistered features and/or other registered features that likely will never be implemented in even the most sophisticated of user applications would be available without having to rely on UI support, as long as they are associated with DFLT. This way, font developers would have the flexibility to devise and add as many features to their fonts, without needing to rely on their standard implementation (apart from the generic DFLT feature, obviously), what for most of these custom feature will evidently never be the case. I recur that the functions of such customised features in several cases do not fit into registered features (which is why they would be "hijacked"), including Stylistic Sets, which are never enabled by default neither generally supported, anyway.

(3) Could you state those important reasons or advantages why developers would prefer static over dynamic OpenType feature lists? If it is for consistency, applications could at any time implement both static (with standard features) and dynamic (with all other features that are in the font) OT menu palettes.

(4) I grant that probably I look for more appliances of OpenType than those for which the format was intended originally, such as automated text editing (spacing issues, contextual small caps, …). In most cases, though, the OpenType technology and its coding syntax already allows to implement these, which brings about that users (font developers) actually will, whatever the intentions or recommendations of the format owners. (They may very well have to, for custom font projects.) As I said before, OpenType moreover quite fits these purposes, precisely because it operates on the glyph stream, and does not hard-code substitutions on the character level. Your earlier suggestion to nevertheless impinge on the character coding therefore doesn't fit the purpose. However, in as far as OpenType support doesn't allow (yet) for more advanced tasks (one-into-many substitutions, operator values for sequences, language support), I considered scripting with regular expressions to be a practicable alternative.

I read through all the documentation available. I also assume I understood what I read and that by now I comprehend what be the essence of the OT format. Thus I see there are some shortcomings which I hope to help to overcome with my iterations. As a font developer and experienced typographer, evidently I look at things from the user's perspective. Nevertheless do I try to get hold of the ways in which applications are built and how programs function, and so in order to avoid proposing unrealistic or unworkable solutions for my needs as a user and those of my fellow typesetters, type designers and clients. If application developers however consider my proposals being nonsensical, then be it so. It would be a pity if they would disregard useful recommendations, but of course, it's their right to do things only the way they think is the right way. Likewise, I do my things my way and in doing so get my jobs done. I don't need extra extensions, but, sure, it would help. Thus far, your counter argumentation has not been valid, nor convincing and is at several instances contradicting itself.

Hm, I think the point Adam Twardoch makes is this:
Applications that do support OT features, do it the right way, i.e. liga or calt will be on by default -- which means that no additional feature is required. Applications that do not support OT features, will not support a DFLT feature either.

The more interesting question to me is, where to draw the line between things addressed by the application, and things addressed by the font. This is not an easy decision.
Personally, I am unhappy that there are language/script tags at all in fonts, for I think that all a font should be is a collection of glyph designs, a table to map glyphs to characters, and some OT features [a] to help the application find alternate glyph sets and [b] do some design related (contextual) substitution/positioning -- in short: provide applications with the resources with which applications can do smart things.* Following this logic, even punctuation spacing is something that, strictly speaking, should be offered by applications rather than by fonts. I encourage everyone to send a feature request to Adobe, see the link already provided here.

* An example: It is quite unhappy that things like Turkish i/dotlessi in liga and smcp, or germandbls in smcp, are dealt with on font level. InDesign CS2 is a noteworthy exception: When applying Small Caps, first it switches from lowercase to uppercase on application level and then applies s2sc feature to map to small caps. Similarly, it turns germandbls into S S, which then will become S.smallcap S.smallcap.
Then, as soon as a question like 'how to address a text string of 3 or 4 characters length?' turns up, this indicates that here is something which is better solved on application level.

Adam Twardoch's remarks are backed by his knowledge of, and experience with, font and application development and testing, unicode and related issues (his website, which is understatement rather than boasting, gives an idea of this).

Karsten — Adam Twardoch is a major expert on things font. I acknowledge that, no doubt. And I really appreciate his magnanimous sharing of know-how. This is precisely why it vexes me that he does not (will not?) make sense out of my in the mean time elaborate explanations. But no hard feelings, I started this thread as a "newbie" and still remain to be so. Still, I'm not dumb and really do not need to be told when to do over my lesson.

I follow your interpretation about non-OT supporting applications expectedly not be willing to implement even a DFLT feature ever. I guessed so myself, but this doesn't involve the rationale behind a DFLT feature, for at least applications that do support OT, but are not suited (i.e. are too basic) to implement all conceivable, more advanced features (such as Apple Keynote), could still take advantage of a DFLT feature. Too, I repeat and stress that the DFLT feature is essentially not about backing up for lack of support by applications, but far more its purpose is to supply font developers with a resort for all their ad hoc custom features and at the same time to allow them to set defaults themselves.

You're quite hitting the core of this discussion in that this all is about the strategic question of font vs application task management. (I read your article on spacing). I guess I'm on the font-side with my DFLT feature. Some reasons are:

(a) With OT (and GX/AAT) fonts have become like programs, being much more than a mapped collection of glyphs. In the old days, founts of type were supplied in cases out of which the typesetter had to choose the right sort, in early DTP the designer had to do the same, manually selecting expert sets out of simple font files, later on he could use search-and-replace, even scripts and macros, whereas today all, even inexperienced users, can benefit from intelligent fonts that automate typesetting. I think this has several advantages. For one, typographic knowledge is automatically available for all users (that have the right fonts and apps). From the commercial/legal perspective, it cannot be maintained that fonts are just a database of node positions (thus failing the legal protection as copyrighted programs), but more and more become to behave like programs. And not the least: intelligent fonts give their designers the opportunity to put in their own (to their design suitable) typographic preferences.

(b) Fonts "do some design related (contextual) substitution/positioning", as you wrote. They not only do so, but should do so, precisely because the greater part of micro-typographic formatting is design related. Therefore, rather than applications, fonts are more suited, not for some, but all design related interventions.

(c) For the success of their designs, type designers ideally do not want to depend from backward applications and/or uninformed/illiterate users. Bad use spoils the design efforts greatly. The more a font can influence the final typesetting all by itself, the greater its chances for success.

(d) Intelligent fonts may eventually turn typesetting (truly typographical correct and handsome setting of type, that is) in just "flowing text into a frame", thus greatly improving workflow efficiency and consistency.

(d) With publicly available Feature coding templates, font designers can share their knowledge, thus guaranteeing for consistent typographic formatting of text, whereas applications typically do not disclose their features. This implies that with upgrades, platform or workflow changes, users always need to port their preference settings. Fonts remain what they are, whatever the platform or workflow.

As regards language/script tags in the font's feature coding. I agree that most such issues are not design related. Some are, though. Russian vs Bulgarian glyph shapes, different diacritics in some languages…

> its purpose is to combine the functions
> of both registered and unregistered
> features

What for? What exactly behaviors are there that cannot be implemented in calt, clig and liga? Please give an example.

> Not all applications enable clig and the
> like by default or even give access to them

But the OpenType specification recommends that they should. If applications don't follow the current OpenType specification, what makes you think that these applications will follow the next OpenType specification that includes "DFLT"?

> If they would support the DFLT feature
> and by preference would enable it by default,

Right, "if". But if the applications makers take the time to implement this new feature, they will probably also take the time to implement existing features properly.

> they would apply all features that are
> associated with DFLT at once,

You cannot apply "all features associated with DFLT". DFLT is one feature. A feature cannot have many features. Your description doesn't make sense.

> without having to further implement a complex
> OT menu (which one can expect only to be
> available in advanced layout applications).

You can already do this with "calt", "liga" and "clig". They are applied by default in UI-less applications such as Notepad on Windows (if complex script processing is activated in the system).

> Also, unregistered features and/or other
> registered features that likely will
> never be implemented in even the most
> sophisticated of user applications
> would be available without having to
> rely on UI support, as long as they
> are associated with DFLT. This way,
> font developers would have the flexibility
> to devise and add as many features to their
> fonts,

Heee? By adding one feature, font developers would add "as many features as they want". What is this, Jesus Christ performing wonders? If you add one feature to your font, you just add one feature to your font, not many.

> (3) Could you state those important reasons
> or advantages why developers would prefer
> static over dynamic OpenType feature lists?

You cannot just list all features available in the font, blindly. The application can only support a certain number of registered features, for the simple reason that each feature in the font is only labeled with a four-letter tag. The application needs to present those features with human-readable captions in the UI, in a logical order, grouped into some sections (e.g. all the features that regard numerals would be listed together).

Also, many registered OpenType feature have a special purpose that is limited only to specific writing systems (e.g. Arabic, Devanagari, Japanese), is used in certain combination with other features and should be only called automatically by the layout engine in specific contexts. Listing those features in menus would only clutter them, and the ability to invoke them arbitrarily would give no benefit to the user.

If activated, some features such as "liga" or "smcp" are supposed to be applied to entire runs of text, while other features such as "fina" or "init" are supposed to be applied only to specific characters (first, last) in a word. In other words, with each registered OpenType feature, an application needs to *know* what to do with it, and what purpose this feature serves. This is an essential element of the OpenType Layout format, and it is its essential difference from AAT (Apple Advanced Typography). In OpenType, the "intelligence" is shared between the font and the application, in AAT, the "intelligence" is all in the font.

So in AAT (formerly known as TrueType GX), all the burden of implementing a complex typesetting system is placed on the font vendor, which potentially gave great flexibility but in practice resulted in very few GX/AAT fonts ever produced, most of them by or for Apple directly. Microsoft and Adobe learned from this lesson and implemented a system that is more pragmatic, and while having some limitations regarding flexibility, it *actually gets implemented*.

AAT was an attempt to build a vehicle that can swim, drive and fly, all at the same time, and all to an excellent degree. OpenType understands that you should either build a car, or a plane, or a boat, and that a Formula 1 racing car will not necessarily perform well on a desert or in the jungle.

> If it is for consistency, applications could
> at any time implement both static (with standard
> features) and dynamic (with all other features
> that are in the font) OT menu palettes.

Well, if half of the UI is static and half of it is dynamic, I don't understand how anyone could call it "consistent".

A dynamic menu has its problems as well. If the user selects a text that is set in roman type with some words set in italic, and the roman font has small caps but no swashes and the italic fonts has swashes but not small caps, what would the menu show and why?

> Your earlier suggestion to nevertheless impinge
> on the character coding therefore doesn’t fit
> the purpose.

I'm sorry, which suggestion!? I never suggested that you should do something on the character coding level.

> However, in as far as OpenType support doesn’t
> allow (yet) for more advanced tasks (one-into-many
> substitutions, operator values for sequences,
> language support), I considered scripting with
> regular expressions to be a practicable alternative.

Another alternative is of course to develop a text layout application that does just what you need, regardless of the "level".

> If application developers however consider my
> proposals being nonsensical, then be it so.

I cannot speak for typographic application developers (because I'm not one), but as a type designer, typographic engineer, typesetter, and a person involved in software creation, I do consider your proposal for the "DFLT" feature completely nonsensical.

> It would be a pity if they would disregard
> useful recommendations,

I agree that *useful* recommendations should be taken into consideration by application developers. I don’t think your "DFLT" proposal fulfils this criterion though.

> Thus far, your counter argumentation has not
> been valid, nor convincing and is at several
> instances contradicting itself.

I agree that argumenting with proposals that don't make sense is a tough challenge, but I'm trying.

You surely have an interest and a dedication, and some energy to spend. I'd recommend that you continue your studies of type and the technology, and try to really understand all the variables involved. The OpenType font format has been developed and shaped to a certain stadium for the last 10 years by a collective mind of application developers, typographic engineers, type designers and typographers. Not everybody is happy with everything, but there is a common ground on which things operate.

A "DFLT" feature certainly does not fit onto this ground -- by miles. Among others, because it by no means specifies the use and purpose of this feature. Within the domain of OpenType, people agreed that functionalities that can do "all or nothing, anything or everything" do not have a place, because it is difficult to communicate what that particular functionality is all about to other parties involved. Your case is a perfect example of this failure: you tried how many -- five times? -- to explain what you want to achieve with this, and nobody else stood up to admit that he or she understands your concept. If I were talking to a crowd explaining my concept, and nobody seemed to understand what I'm saying, for me it would be a hint that perhaps my concept has serious flaws (unless it turned out that I'm telling my story in Polish to a crowd of Hungarians).

I encourage you to work out solutions and concepts, but also to listen to experienced people in the field. In many cases, they have (mentally, conceptually) "been there, done that". Of course there always is a chance that you may discover a major omission in your predecessors' reasoning and figure out that the Earth is round rather than flat. But either way, a thorough study of the subject is required.

A.

Adam —

> What exactly [sic] behaviors are there that cannot be
> implemented in calt, clig and liga? Please give an example.

What about spacing of punctuation, at least one example that has been given here repeatedly?

> what makes you think that these applications will follow
> the next OpenType specification that includes “DFLT”?

I don't, as you would have known if you had actually read what I wrote instead of looking for opportunities to debunk: "I follow your interpretation about non-OT supporting applications expectedly not be willing to implement even a DFLT feature ever. I guessed so myself, *but* [etc]"

> You cannot apply “all features associated with DFLT”.
> DFLT is one feature. A feature cannot have many features.
> Your description doesn’t make sense.

You should remember I started this thread exactly with this question: "Is it allowed that a feature contains another feature?" So, apparently it isn't, that became clear early enough. No big deal, since features may contain lookups that are defined in other features. This is virtually the same as features being associated with other features. Just for the sake of proper wording: "Other features may be associated with the DFLT feature." = "The DFLT feature includes lookups that are defined in other features and excludes lookups from features it needs to overrule."

> You can already do this with “calt”, “liga” and “clig”.
Again, yes, but not with anything else. Even less so with unregistered features.

> What is this, Jesus Christ performing wonders? If you add
> one feature to your font, you just add one feature to your font, not many.

No need for miracles, just plain efficient use of resources. If you rearrange the words from a given text, you create a new text; if you do it well, you create one that makes sense. Likewise, if you add a container for lookups from other features, that arranges its content in a specific new way, then you add a new feature; if the arrangement is done well, the new feature will make sense. If you add lookups to that very same container from features that are not otherwise accessible, you extend its functionality and hence practically add as many new features to your font.

> You cannot just list all features available in the font, blindly.
Tss— your FontLab's OT Preview Panel does exactly this.

> The application needs to present those features
> with human-readable captions in the UI.

This is why I wrote: "If eventually feature tags would be expanded with name flags, for clarity the user app might list them instead of the four letter tags."

> Well, if half of the UI is static and half of it is dynamic, I don’t
> understand how anyone could call it “consistent”.

The static menu is for consistency (and benchmarking), the dynamic one offers additional functionality for advanced users, in exchange for less (anyhow logically impossible) consistency. This approach is in itself consistent.

> A dynamic menu has its problems as well. If the user selects [etc]
This is also the case with a static menu (e.g. InDesign's).

> […] special purpose that is limited only to specific writing systems
> […] Listing those features in menus would only clutter them
Not if you group them by language system.

> I’m sorry, which suggestion!? I never suggested that you
> should do something on the character coding level.

In spite of my repeated arguments, you did that twice: "I replied to you: 'If you want a particular glyph appear by default when a particular Unicode codepoint is keyed in, the easiest way to achieve this is to simply assign that Unicode codepoint to that glyph. No extra OpenType features need to be applied then.'"

> Another alternative is of course to develop a text layout
> application that does just what you need, regardless of the “level”.

No need. Since this is being done already by accomplished people (Harfbuzz, Graphite, XeTeX, ConTeXt, Scribus) who welcome ideas for extra functionality, do bother to conceive them, are unbiased about feature requests and usually don't need more than but a few days/weeks to implement them *and* release the upgrade — without all the bloating.

> I agree that argumenting [sic] with proposals that don’t make sense
> is a tough challenge, but I’m trying. (…) you tried how many
> — five times? — to explain what you want to achieve with this,
> and nobody else stood up to admit that he or she understands your concept.

I'll make no further attempts here to teach the dumb to speak, so that you won't feel urged to spill your energy on a sixth refutation.

> unless it turned out that I’m telling my story
> in Polish to a crowd of Hungarians

This may very well be the case. No offence to the Polish, though, for the blame may be on the Hungarians, notwithstanding that they are experienced and esteemed usurpators of Polish territory.

> What about spacing of punctuation, at least one
> example that has been given here repeatedly?

Why can't you use the "calt" feature for that?

> > A dynamic menu has its problems as well.
> > If the user selects [etc]
> This is also the case with a static menu (e.g. InDesign’s).

Heh? Have you ever tried it? In TextEdit or Keynote, you cannot turn on or off ANY features if you have selected a text run that involves different fonts. In InDesign, sure you can -- the features will be turned on and off appropriately.

> > […] special purpose that is limited only to
> > specific writing systems
> […] Listing those features in menus would
> > only clutter them
> Not if you group them by language system.

No, because the whole point is that an application is not supposed to list them in the UI *at all*. RTFM.

> Tss— your FontLab’s OT Preview Panel does exactly this.

Exactly -- this is why it wouldn't make sense in an end-user application, though it works in a development tool.

> This is why I wrote: “If eventually feature tags would
> be expanded with name flags, for clarity the user app
> might list them instead of the four letter tags.”

This is up for the consideration only for the ssXX features, nothing else.

> (Harfbuzz, Graphite, XeTeX, ConTeXt, Scribus)

Harfbuzz is nothing else than an OpenType Layout engine, I very much doubt that it will implement behaviors that contradict the OpenType specification. Graphite uses a completely different layout system -- you're free to add tables for Graphite into your font, just like you are free to add AAT tables, but this has nothing to do with OpenType Layout. XeTeX implements AAT (on Mac OS X) and OpenType Layout (on all systems), and I doubt that Jonathan Kew will bend over backwards to do anything that breaks the spec, though AFAIK, he is also working on adding Graphite support to XeTeX. The creators of pdfTeX/ConTeXt have very ambitious plans for a complete TeX rewrite. I wish them well but I doubt it will happen in forseeable time. As for Scribus, I don't know much about it.

Again -- you're free to develop a layout system on your own, or extend one of the existing ones, so that one particular application works the way you want it to work. There is nothing wrong with that. But it's a completely different goal than trying to expand an international ISO standard (which OpenType is: ISO/IEC 14496-22 "Open Font Format Specification") that is supposed to be used across various operating systems and applications. OpenType is not everybody's playground. Yes, there are things that you cannot do with OpenType, and this is so *by design*. Simple things gets adopted and implemented, complex things have a far lesser chance for that to be done.

If you think that this is bias, then go kick the wall somewhere and chill down. Once your "DFLT" feature gets implemented in Harfbuzz, Graphite, XeTeX, ConTeXt or Scribus, please let me know!

A.

Generally, I would suggest shopping your proposal on the OpenType mailing list first, and getting feedback. That can give you a pretty good idea of the likelihood of your proposal getting adopted. Not all the key players hang out on Typophile.

Personally, I am a bit skeptical of the need for a DFLT feature. The main dividing line out there is not between applications supporting a couple of features and applications supporting many, it's between applications supporting features versus those not supporting any features. If you're talking features that would all be on by default and have no UI, supporting a single OpenType layout feature that can use many lookup types is not particularly easier than supporting a whole bunch of OpenType layout features. The problem is getting into OpenType at all, really.

Cheers,

T

I believe the biggest problem of the DFLT feature is that its purpose is underspecified. All other OpenType Layout features have a clearly devised function, purpose. As far as I understand, the idea behind "DLFT" is to have some sort of "wildcard" feature. But my understanding of the OpenType specification is that its makers specifically did not want to allow this kind of arbitrary, wildcard behavior.

A.