This article Windows Glyph Processing - Part Two: Glyph Processing in Detail (scroll a few pages to subheading Scripts and Language Systems) may explain more clearly how the script language selection works. It is still far from perfect, but more readable than technical specs.

George, besides the Adobe Font Feature Format and the MS documents you sent, do you know of any sources that detail the logic of 'dflt' and DFLT{'dflt'} ?  Because those sources are very poor.

Here is my summary:

The "dflt" language behaves as a wildcard, but only for those
which aren't listed anywhere among any of the tables of the current font.
Likewise, "DFLT{dflt}" behaves as a wildcard for script-language, but only for those which aren't listed anywhere among any of the tables of the font.

'dflt' example
==============
        table A to activate on: latn{'dflt'}
        table B to activate on: latn{'dflt', 'ESP '}

Then table A will not be activated for Spanish text, although it would have been without the presence of the specification for B.

DFLT{'dflt'} example
===================
        table A to activate on: DFLT{'dflt'}
        table B to activate on: grek{'dflt'}

Then table A will not be activated for Greek text, although it would have been without the presence of the specification for B.

Hi Georg,

You'll see that I made a commit of FreeSerif* based on our discussion here, and the output of that script.

I'm still unconvinced of the CSS cases, they are different in some ways, but given my confusion over the role of 'dflt', I'm not so sure.

I'll consider your new suggestions.  The first one however refers to the creation of new tables, when the biggest headache here is maintenance of existing tables.

As I said this is really terrible: a case where local changes have surprising global effects.  I may be able to patch it up to some degree with scripts.

I've been in denial about this for a long time: of course I couldn't have accomplished what I did with Devanagari, for example, without having sort of understood how 'dflt' worked.  I remember thinking: I should formulate that clearly, and write it down -- but I never did.  Thanks for making me look at it hard again!

Toward a more permanent resolution of the sorts of problems leading to the issue with ligatures, I wrote a script to find cases of 'dflt'-language tables which might be "shadowed" by an explicit language specified in another table.

tools/test/checkTableLangs.py

It's pretty rough, and takes no account of whether or not the font designer intends to disable a table.

The bigger problem here is to address the need of a font technician, to specify that this table should be activated for any language except these.  The TT/OT table specification do not lend themselves to this at all: innocent-looking modifications of one table can unintentionally disable another table.  No complaint will be raised in FontForge.  Ideally, a font editing user interface would spare the technician from this messy implementation detail.

Georg,

I've spent some hours on this, done lots of tests, yet I can't claim to understand everything.  Some of what you say I really don't understand, but part of it is simply wrong (as best as I can understand it.)

Both of the documents you listed are familiar to me.  They are both very long and complex.  Again: which exact passage do you think has been violated?  You only specified a whole (page-long) section of one of them.

However, in particular, http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#4.b, it states, referring to DFLT{dflt}
    "It is used if a program cannot find a match in the
     font to the current writing script and language."
But that would support my understanding, as well as the behaviour that I see everywhere (except in the experimental Mozilla CSS properties).

Freefont works quite well in the FontForge metrics window.  I don't see the connection between the logic of that application window (which makes sense for its users) and how a font renderer should activate features.

I'm not "bothered" by German ligature rules.  I only meant that they can't be properly implemented by font features alone.  I know in the past I tried, and at some point I also thought about disabling tham explicitly (although they aren't now...) However, it is interesting that you suggested that I try Dutch -- you might also have suggested Turkish or Spanish or Catalan. 
-- Because--
Harbuzz (and I think Windows too) specifically disables default ligatures for these few particular languages, but *not* for any other Latin-based languages I could find. 
(See attached modification of the test)
(I see the reasoning, but, frankly I hadn't realized it (maybe it's only in the new renderers.)
Again: default ligatures are activated by latn{dflt} except for German, Dutch, Spanish, Catalan, and Turkish, which are specifically disabled by the font renderer.
So, the example of the default ligatures supports my contention.

I must not understand your contention.

Let me ask, what do you think is the function of the feature activation languagesystem

    latn{dflt}

How do you think that makes ligatures work in English?  How is it that this makes it work for French and Romanian and Irish Gaelic?

I made a distinction between the experimental Mozilla OpenType features, and OpenType features that have previously been activated by language or CSS.  My point was, that your test mixes them all up.  If you separate the two, it is pretty clear that the experimental OpenType features follow a different logic regarding selection by language, than we have seen before.

With that all said, your last paragraph seems to be a moot point.  But there is another issue here, that somehow wasn't conveyed:  FreeFont supports hundreds of languages using Latin script, dozens using Cyrillic, Arabic, and Devanagari.  It would be a maintenance nightmare to list all of these languages for each feature that should be activated for all of them.
Fortunately, that's what defaults like

   latn{dflt}

accomplish.  (Except of course for the experimental Mozilla features, which seem to ignore them.)

I'm willing to keep working on this.  But so far, it looks to me that the font is correct.

(file #27990)

Thanks, Georg,

I have to admit, Uniscribe does something different than I remember happening before.  I'll write more about this later.

You made pronouncements about how table activation is supposed to work.  Again, please:

• if you're referring to a published standard, please

    indicate which one.

• also indicate the passage in that standard

    that supports your claim.

Your test file confuses the new test properties of Mozilla with established properties with which the fonts have been tested extensively.  I attach a simpler subset, with just HTML and standard CSS. It doesn't show much, but:

• positioning (kerning and mark placement) working in both

     German and English

• ligatures working in French and English, not working in German

(the standard CSS small-caps feature is still unfortunately implemented by scaling, so it doesn't show anything about the font.)

Ligatures in German are problematic.  In words such as Tiefflug, the f's must not be ligated.  I do not know how to do ligation programmatically in German.  (See the Wikipedia article on ligatures for further discussion.)

I would like you to at least entertain the possiblility that some problems you are seeing reflect recent changes in rendering software, and that some of these might be regarded as bugs in that software.

I should also say: previously I had only seen 'onum' working in XeLaTeX.  I kept a PDF to prove it.  But today, with the new XeLaTeX which uses Harfbuzz, the 'onum' feature in the same file no longer works.
The XeLaTeX people have been complaining that recent changes have broken a lot of previously-functioning documents, and I know efforts are on to remedy that.

You know, FreeSerif supports hundreds of Latin-based languages, and has been to some degree tested in each of them.  If I read correctly your claim about script{dflt}, we must now explicitly list all those languages in each of the font's many features.  This was never the case in the past -- if it is the case now it should be fixed in software.

Clearly you and I have different points of view.  Let's continue work together and share information, respecting one another's expertise.

(file #27933)