Nick, that wasn't what I suggested using the Titling Alternates for. For removing the accents from Greek all-caps settings, I use the COntextual Alternates (calt) feature, and map directly to the corresponding unaccented glyphs. The contextual substitution is a two-stage process:

Where a tonos or oxia falls on the first vowel of a two-vowel combination that can be read as a diphthong, I change the second vowel to add a dialytika over it. Then I remove all accents except the dialytika. I do this for both all-caps and smallcaps.

By using the Contextual Alternates feature, I ensure that this behaviour is active by default -- which it should be, as it is the grammatical norm --, but allow users to turn the accents back on if they want them by turning off the feature.

>Where a tonos or oxia falls on the first vowel of a two-vowel combination that can be read as a diphthong, I change the second vowel to add a dialytika over it. Then I remove all accents except the dialytika.

I'm afraid I don't understand that. Sorry for being a bit slow on the uptake, but could you spell it out a bit more? Thanks!

Okay, you have a word like ρωμέικα. The Greek letter sequence ει is usually pronounced as a diphthong, but the presence of the tonos on the ε indicates that the two vowels are pronounced separately with the accent on the ε. The rule is that if the accent is on the whole diphthong then the tonos falls on the second vowel, so:

ει = unaccented diphthong
εί = accented diphthong
έι = non-diphthong, accent on the ε
εΐ = non-diphthong, accent on the ι

If you want to set the word in all-caps, a simple case conversion will produce ΡΩΜΈΙΚΑ, which is incorrect because the accent mark should be dropped from the Έ in an all-caps setting. So you need to contextually swap the unaccent Ε glyph for Έ when preceded by another uppercase letter. In VOLT parlance:

Epsilontonos -> Epsilon
‹uppercase group› |

However, this will result in ΡΩΜΕΙΚΑ, which is also incorrect because you have lost the indication that the E and Ι are to be separately pronounced, so before you perform the substitution of Ε for Έ you need to insert a dialytika over the Ι. For this, you used the tonos on the Έ as a context trigger:

Iota -> Iotadieresis
‹Epsilontonos› |

This results in ΡΩΜΈΪΚΑ. Now you perform your second substitution to remove the tonos from Έ when preceded by another uppercase letter, and you are left with ΡΩΜΕΪΚΑ, which is correct.

There are seven Greek diphthongs, and the above rules apply to all of them during case mapping (and also smallcaps): αι ει οι υι αυ ευ ου

So your first lookup goes like this:

Iota -> Iotadieresis
upsilon -> upsilondieresis
‹uppercase with tonos/oxia group› |

and your second one goes like this:

Alphatonos -> Alpha
Epsilontonos -> Epsilon
Etatonos -> Eta
%... etc. for all accents except dialytika
‹uppercase group› |

Perhaps someone else can express these lookups in FontLab/FDK syntax?

One of our Greek colleagues was kind enough to point out that in the orthographies of some Greek dialects ηυ and ωυ are also diphthongs and would follow the same rules in casing as those I've described. Examples she gives include Ionic νηῦς, corresponding to the Attic ναῦς, and New Ionic ὡυτός corresponding to the Attic αὐτός.

Thanks so much John, I think I should be able to figure this out in FontLab, but it will take me a few days as I haven't finished all my glyphs yet.

OK, I've studied this topic some more, and have a few questions for John, and Thomas.
I haven't actually tried any implementation, so this is still theoretical.

1. John, why handle Greek all-caps with the Contextual Alternates feature and not "Case"? Wouldn't Case perform the same function more logically? (As I understand it, the "case" feature is not activated during "shift+character" keystrokes, but only by "command-shift-k", or from a typographic menu.)

2. John, as your second substitution removes the accents on caps following another cap, what happens to the initial capital letter of an all-caps word? Surely that should lose its accent(s) too, only being accented in titlecase setting?

3. Thomas: I've been looking at the "all caps" behavior of InDesign, applied to Polytonic Greek, and there are quite a few lower-case accented characters which it has no effect upon. What's the reason for that?

1. I originally considered using 'case' for Greek all-caps, but after discussing it with Paul Nelson at MS I decided against it. The 'case' feature is intended for what are typographical niceties but optional, e.g. specially aligning punctuation. The 'case' feature is not widely implemented, and in Adobe's UI at least it is tied to a particular display function, not to the presence of strings of uppercase letters. You want the Greek capping behaviour to be on by default, and it is context specific, so 'calt' is both more desirable and more appropriate.

2. Yes. You want the context to include before and after cap context.

3. Thomas may have a more specific answer, but my guess is that polytonic Greek casing is not supported in InDesign yet. Which lowercase accented characters are not affected?

You want the Greek capping behaviour to be on by default, and it is context specific, so ‘calt’ is both more desirable and more appropriate.

Yes, I get it now.

...context to include before and after cap context.

OK, that's smart. I was originally thinking if it were being done with the "case" feature, it could just be a straight substitution: characters with accents replaced by corresponding accent-less glyphs. But with that behaviour in an always-on "calt" feature, you'd never be able to set a single accented cap for titlecase!

Which lowercase accented characters are not affected?

I haven't checked them all methodically; while InDesign (in my set-up, at least) appears to capitalize nearly all of the Polytonic characters, it seems to have gaps, for instance vowels with perispomeni.

..vowels with perispomeni.

...and no breathing. Perhaps InD doesn't capitalize these because it recognizes that accented capitals should only appear at the begining of words (although it applies capitalization indiscriminately), and such characters would always have a breathing in that position?

Just to clarify a little further, just in case anyone is confused, when I say that the context should include both preceding and following capitals, I mean two separate contexts, not a dual context. It should be obvious...

Regarding the casing issue in InDesign, I'll investigate this. Most Greek casing is fairly straightforward: the only tricky bit is the lowercase diacritics for which there are no corresponding uppercase, e.g. iota with both accent and dialytika.

Okay, I've taken a look at what InDesign is doing. The lowercase letters that it is failing to case convert to uppercase are those for which there are no standard polytonic uppercase equivalents. These are diacritics that only have lowercase forms in the orthography. That said, though, I don't think what InDesign does in case mapping is ideal: these characters should not be left as lowercase, rather, they should be converted to appropriate unaccented uppercase characters. Of course, in the case of a character-level conversion, this process cannot be reversed, but that is often the way with special casing (the German eszett is another example of non-reversible case mapping). The attached image shows which Greek lowercase letters are converted by InDesign and which are not.

...these characters should not be left as lowercase, rather, they should be converted to appropriate unaccented uppercase characters.

This can't be done as a third lookup in the "calt" feature, because the obvious context triggers (preceded by or followed by an unaccented cap) would result in unwanted capitalizations in U&lc settings, in situations where the problem character follows an unaccented initial cap, or is the last letter in a word.

Therefore, it looks like the "case" feature is the solution, so why not use it for the whole feature?

I'm not talking about glyph-level display conversions for casing, Nick. It is the application's job to look after case conversion at the character-level, whether actually affecting the backing text string or in a buffered display state. You shouldn't have to do any messing around in glyph lookups to achieve correct case mapping: this is all standard Unicode text processing stuff that applications are supposed to handle correctly. Unfortunately, a lot of applications support normal character casing, but do not support all or any of the Unicode Special Casing mappings. Greek has both conditional and unconditional special mappings, and applications need to handle these. You can review the special mappings for Greek characters in the SpecialCasing.txt file that is part of the Unicode Standard.

In the case of the lowercase alpha with perispomeni the Special Casing rule is

1FB6; 1FB6; 0391 0342; 0391 0342; # GREEK SMALL LETTER ALPHA WITH PERISPOMENI

which indicates that for uppercase and titlecase, the correct character mapping is to two characters: uppercase Alpha and the combining perispomeni character. This is actually a bit more complex a mapping than I was anticipating, and encourages me to view the Unicode polytonic encoding as a kind of compromise between the standard orthography (encoded as precomposed diacritics) and the occasional need to encode and display non-standard combinations. That is, it is not usual to have an uppercase Alpha with perispomeni since this is contrary to spelling rules according to the standardised polytonic system, therefore this diacritic is not encoded because there is little need for the typical font, text processing system, etc. to support it and to do so would be a burden. On the other hand, what should be the proper encoding and what should be the default behaviour if a user wishes to have this diacritic in a document. This is a matter of interest to me because my major polytonic clients are scholars who may be dealing with manuscript sources that pre-date the standardisation of the polytonic system or who may even have a need to encode scribal errors in ancient documents, so I need to implement robust glyph solutions for unusual things. The Unicode Standard indicates that the correct, unconditional mapping of the lowercase ᾶ is to the unaccented uppercase Α (U+0391) and the combining perispomeni character ͂ (U+0342). Presuming that the application gets this right, the question for font developers is how should this be handled at the glyph, and the options are the same as for any base + combining mark sequence. The sequence can be mapped to a precomposed glyph in the 'ccmp' feature, or it can be handled using dynamic mark positioning ('mark' feature). My general preference is mark positioning, because it is most flexible and does not require me to second-guess every possible combination that users may wish to encode and display. However, the case of Greek capitals is complicated by the fact that the mark is placed before, to the left of the letter rather than above it, and this requires not only positioning of the mark but also a lookup that contextually increases the advance width of the base letter to make room for the mark. This is doable, and still the best fallback solution for unanticipated sequences, but I think it would be a good idea to include precomposed glyphs to render uppercase diacritic sequences resulting from Unicode Special Casing rules, mapped in the 'ccmp' feature.

Now Adobe have been cruising along for many years not including combining mark characters in their fonts -- except those I've made for them :) -- and not supporting either 'ccmp' or 'mark' in the primary versions of their applications (these features are supported in the Middle East versions). I can understand the lagging application support, even though it is regretable, but it seems to me particularly ill-planned not to support combining mark characters in their fonts at least for those instances in which Unicode casing rules demand them. In general, combining mark support has not been necessary for most the script and language combinations that comprise Adobe's historical font market, but as soon as you decide to support a language that had Special Casing rules that involve combining marks, you really should be including appropriate glyphs and cmap entries in your fonts. Even if InDesign is updated to support correct Special Casing for polytonic Greek, fonts like Garamond Premier Pro will still be unable to provide even crude support due to the absence of support for U+0342 and other combining mark accents.

You shouldn’t have to do any messing around in glyph lookups to achieve correct case mapping

Think of it as an in-font "bug fix". What's the harm in that?

Even if InDesign is updated to support correct Special Casing for polytonic Greek, fonts like Garamond Premier Pro will still be unable to provide even crude support due to the absence of support for U+0342 and other combining mark accents.

What I am proposing is to fix the "non all-capping" of those problem characters, in the "Case" feature of my polytonic fonts, so that All Caps is diacritically correct in InDesign -- at least for the standard range of polytonic accented characters. Of course, it's not ideal for Adobe or Microsoft to do that kind of hacking, but it's not inappropriate for an independent foundry. It provides a font feature not presently avaialable, and when the apps are updated to do a more comprehensive All Capping, my font will still work just as well (providing I get it right in the first place!).

You want the Greek capping behaviour to be on by default

I don't think I do. That's automatic grammar-correction; it means that if a writer makes a deliberate grammatical mistake, the software will correct his/her keystroke and substitute a different character to the one typed. Sure, it can be turned off by un-checking contextual alternates, but that's the kind of default software behavior I detest. Like when MS Entourage won't let me begin a sentence with a lower-case letter.

If you configure de-accenting of an all-cap setting as part of contextual alts, you're relying on "All Caps" formatting anyway, because the only other way to get an all-cap setting is to "hard-set" it, typing letter by letter using the shift key.

The only difficulty I can think of: if capitalization of the problem characters were made a "case" feature, then all-cap text formatted in InDesign might lose such capitalization if exported into another app that didn't support the "case" feature, but would perhaps keep the rest of any all-cap formatting.

What's the harm? Well, if an application is doing what it should, your lookups will simply be ignored, since character level case conversion will happen before any glyph processing, so the input glyphs for your 'bug fix' will have disappeared. But I think you are making a mistake in relying on 'case' feature implementation because there is going to be a world of difference between how Adobe are doing this -- the whole 'All Caps' display formatting of what remains lowercase text is bizarre -- and how other major app developers are likely to implement it. Adobe have hidden access to this feature, but have linked it to a formatting function, meaning that it cannot be applied to actual all caps text unless the user, counter-intuitively, selects that all caps text and says he wants it displayed as, um, all caps. Who is going to do that if the text is already in all caps? [For once in my life, I am tempted to use an interrobang.] I don't think the Adobe implementation of the 'case' feature is a very good one, and you shouldn't expect it to be followed by other app or system developers. A better one would apply the feature heuristically whenever sequences of uppercase characters occured, in which case you are back to a feature that is on by default, just like 'calt'. As I say, I originally thought of using 'case' for de-accenting Greek, but I switched to 'calt' on Paul Nelson's recommendation; when the people who will be implementing OpenType Layout for the world's most widely used software recommend something to me, I pay attention. Sometimes I disagree with the recommendation, and do my best to get it changed, but in this case the argument for 'calt' is very sound: it is the logical choice for what is, after all, a contextual alternates substitution.

Consider: in the case of your 'bug fix' to provide upper case display for those lowercase Greek letters than require special casing, it would make sense for this to be done in the 'case' feature since the lookup is not contextual. It seems to me that if you want to do this -- and I'm not encouraging it -- you should follow the Unicode Special Casing rules for the results. So the lookup mapping for e.g. ᾶ should correspond to however you intend that a sequence of uppercase Alpha and the combining perispomeni character should be displayed. If this is as a single glyph, then this glyph should be included in the font and mapped from ᾶ in the 'case' feature lookup. Okay, so the 'case' feature is now providing special casing at the glyph level to make up for deficiencies in applications, and is producing accented capitals for corresponding lowercase diacritics: all the more reason for you to want the de-accenting of all caps to happen someplace other than in the 'case' feature, since you presumably want the presence/absence of accents to be controllable by the user independently of the apparent case conversion. This isn't possible if you are relying on the same feature for both.

Of course, it’s not ideal for Adobe or Microsoft to do that kind of hacking, but it’s not inappropriate for an independent foundry.

Considering that Special Casing rules are a part of the Unicode Standard that neither Microsoft or Adobe have managed to yet implement correctly, I'm not sure what they would consider 'ideal'. :)

Of course, it’s not ideal for Adobe or Microsoft to do that kind of hacking, but it’s not inappropriate for an independent foundry.

What I meant was that it would be better for Adobe or Microsoft to add the functionality we're discussing by improving an application or operating system, rather than doing it through a font -- which is something an independent foundry can do, as we're always rolling with the elephant anyway.

Adobe have hidden access to this feature, but have linked it to a formatting function, meaning that it cannot be applied to actual all caps text unless the user, counter-intuitively, selects that all caps text and says he wants it displayed as, um, all caps. Who is going to do that if the text is already in all caps?

That's true for the non-alphabetic typographic features of "case", but not for the issue here. Applying "All Caps" to Greek capitals is redundant in practice; if the text is all-caps to begin with, it has been "hard-keyed" with the appropriate non-accented cap characters, so "All Caps" will only be applied to U&lc text.

However, I take your general point about the lack of feature clarity. There is a similar situation in the InDesign UI concerning things like the small caps command, where there is no indication whether the result is true or faux.

I can guess why this has been done -- to shorten the menu and make things more transparent for non-OT-savvy users. That can be a good UI principle, but IMHO it would be better here to have a dedicated OpenType menu palette which lists all the features in a font by name. After all, other palettes such as color aren't dumbed down, so why expert typography?

I don’t think the Adobe implementation of the ‘case’ feature is a very good one, and you shouldn’t expect it to be followed by other app or system developers.

Even though my font development is Mac and Adobe-centric (my graphic design background), your suggestion makes sense -- I am swayed by the lack of clarity surrounding Adobe's "case" command. Having said that, I am a lapsed Quark devotee, and am eagerly anticipating the XPress OpenType UI; but even if it is impeccable, I will still keep to using InDesign as the primary "application target" for my fonts.

...If this is as a single glyph, then this glyph should be included in the font and mapped ... in the ‘case’ feature lookup.

I'll just map the problem lc accented characters directly to their non-accented cap versions, that way I won't have to create another 21 pre-composed glyphs.

***

So: I'll implement Greek all-caps as a "calt" feature, and put the "bug-fix" in the "case" feature. I'll post my FontLab code once I have it figured out.

Thanks, John.

I’ll just map the problem lc accented characters directly to their non-accented cap versions, that way I won’t have to create another 21 pre-composed glyphs.

The application is failing to correctly map some lowercase letters to uppercase letters with combining marks, as specified in the Unicode Standard Special Casing rules, so you are going to use glyph processing to map them, also incorrectly according to the standard, to unaccented uppercase glyphs and only when this bizarre lowercase-as-uppercase display function in InDesign is activated. If the user actually selects to change the text case, your lookup will have no effect.

You can't correctly support polytonic Greek without also supporting combining mark characters. If InDesign were to implement Special Casing support, Adobe's own polytonic Greek fonts would be unable to display the results (you'd get .notdef glyphs for the missing combining mark accents). So the first thing you should do is include the combining mark characters for all Greek accents and breathing marks. Then you should add those additional precomposed glyphs (unless you want to use the dynamic mark positioning approach, in which case you'll have to abandone FontLab for OTL development), and add 'ccmp' feature mappings for the base + combining mark sequences to these precomposed glyphs (to support correct Unicode special casing when it occurs). That is the only correct way to support polytonic Greek casing in all its potentialities.

That is the only correct way to support polytonic Greek casing in all its potentialities.

I would like to be able to do things correctly, but I am also practically inclined.
I have as yet sold no Greek fonts and have no OEM contracts to design such; David Lemon of Adobe and Gerry Leonidas of Reading have persuaded me that there is a demand for Polytonic Greek, and despite my appraisal of the Greek market as commercially unpromising (a mere 25 million there, same size as Canada, plus assorted Greek scholars worldwide -- Cyrillic is a much larger market with less font complexity), I have plunged in and am attempting to do the right thing. But it keeps getting deeper and deeper!

Being practically inclined, I prefer to work from a functioning model, rather than principle, which would require a greater commitment to being a programmer (VOLT, Python scripting) than I am presently comfortable with. I have based my Greek character set on Minion and Gentium.

You can’t correctly support polytonic Greek without also supporting combining mark characters.

Haven't I done that if I follow the Minion character set?

...you should add those additional precomposed glyphs

So Greek all-caps would then work correctly in non-Adobe applications that don't use the "case" feature, such as perhaps the "Lower Case to Caps" command in MS Word? Does Word for Greek correctly implement this in Polytonic? I'm assuming it will, given your involvement with the ClearType project -- and the implication is that Adobe's Polytonic Greek fonts will have a ".notdef" glyph behaviour.

But it keeps getting deeper and deeper!

Yes. [This website is an incredibly good resource for understanding Greek text encoding and display issues.]

I have based my Greek character set on Minion and Gentium.

Then you should also limit yourself to what those fonts provide, which is support for standardised polytonic text. Anything beyond that is getting into things that are very unlikely to occur in the texts that most users will be working with, the sort of things that only my scholarly clients working with ancient manuscript sources are going to care about. If I were you, I would follow what Adobe has done with Garamond Premier Pro (not Minion Pro), and don't worry about trying to circumvent limitations in application casing support for characters that are not usually uppercased.

'calt' feature support for de-accenting is a good idea, though, and something I would like to see standard in all polytonic Greek fonts.

Haven’t I done that if I follow the Minion character set?

No. None of the Adobe fonts support combining marks for Greek. This is why they will break if Adobe does Special Case conversion correctly or, indeed, if people start normalising Greek text with full decomposition, as Unicode recommends.

So Greek all-caps would then work correctly in non-Adobe applications that don’t use the “case” feature, such as perhaps the “Lower Case to Caps” command in MS Word?

Yes, if

a) the application applies Unicode Special Casing rules to map the unicameral lowercase diacritics to sequences of unaccented caps + combining marks, and

b) if the font used has glyphs mapped for those combining marks and some mechanism to display the results in an acceptable way.

At the moment, Word (2003) is not correctly casing polytonic Greek at all. I am not beta testing Office 12, so do not know if this has been corrected or whether it now includes Special Casing support. It is the sort of thing that MS should be doing, and are capable of doing within their existing text processing architecture, I believe, based on what they are doing with complex character-level operations for other scripts.

Gentium does support Greek combining mark characters (U+0300–U+0301, U+0304, U+0306, U+0313—U+0314, U+0342–U+0345), so I would recommend following Victor in this regard rather than Adobe. However, Gentium does not have 'calt' support for de-accenting, while I believe the final version of Garamond Premier Pro got this right (I don't have the release version, only an earlier beta in which this was not working correctly).

Later this month, I'll have a test version of SBL Greek ready, and can send it to you. It is pretty thorough in its polytonic coverage, including archaic letters and ancient and mediaeval editorial marks. I will break my glyph list down into different priority levels and post that information.

The MS CLearType fonts do not support polytonic, alas. There wasn't enough money in the phase one budget. I'm hoping this support will be added in a future update.

...and can send it to you

That would be much appreciated.

In the meantime I'll figure out what the Font lab feature code is (with the extra 21 composite characters) and post it later on.

Based on the above discussion, I had a look at the substitution coding required for Polytonic, and it turned out to be more complicated than I had expected, requiring quite a bit of grammatical know-how to figure out what to do in multiple-vowel sequences.

So I've decided to limit the Greek case feature to monotonic.
Even there, I suspect that the feature is somewhat redundant, given the way monotonic is generally written.

My FontLab code:

CLASSES

UCtonos: Alphatonos Epsilontonos Etatonos Iotatonos Upsilontonos Omicrontonos Omegatonos

UCnotonos: Alpha Epsilon Eta Iota Upsilon Omicron Omega

FEATURE CODE
feature case {
sub Iota by iota;
sub @UCtonos iota' by Iotadieresis;
sub iota by Iota;
sub Upsilon by upsilon;
sub @UCtonos upsilon' by Upsilondieresis;
sub upsilon by Upsilon;
sub @UCtonos by @UCnotonos;
} case;

(This omits other parts of the case feature.)

> Okay, you have a word like ρωμέικα. [...]
There are seven Greek diphthongs, and the above rules apply to all of them during case mapping (and also smallcaps): αι ει οι υι αυ ευ ου [...]
Perhaps someone else can express these lookups in FontLab/FDK syntax?

Here it goes:

feature calt {
# First substitution that transforms ΡΩΜΈΙΚΑ into ΡΩΜΈΪΚΑ
## for diphthongs αι ει οι υι
sub [Alphatonos Epsilontonos Omicrontonos Upsilontonos] Iota' by Iotadieresis;
## for diphthongs αυ ευ ου
sub [Alphatonos Epsilontonos Omicrontonos] Upsilon' by Upsilondieresis;

# Second substitution that transforms ΡΩΜΈΪΚΑ into ΡΩΜΕΪΚΑ
## for diphthongs αι ει οι υι
sub [Alphatonos Epsilontonos Omicrontonos Upsilontonos]' Iotadieresis by [Alpha Epsilon Omicron Upsilon];
## for diphthongs αυ ευ ου
sub [Alphatonos Epsilontonos Omicrontonos]' Upsilondieresis by [Alpha Epsilon Omicron];
} calt;

I just tried that in InDesign (CS1) and it didn't work.

(I should add that my bit of code above works in case, but not in calt, with the same error as yours.)

You're right Nick, that code is flawed, sorry about that.
[Note to self: double-check before posting!!]

The good news is, it can be fixed easily. We'll just have to put each pair of substitutions in a separate lookup (which makes perfect sense!!). So here's the CORRECT VERSION of the code (tried in FontLab and it works):

feature calt {

lookup ONE {
sub [Alphatonos Epsilontonos Omicrontonos Upsilontonos] Iota' by Iotadieresis;
sub [Alphatonos Epsilontonos Omicrontonos] Upsilon' by Upsilondieresis;
} ONE;

lookup TWO {
sub [Alphatonos Epsilontonos Omicrontonos Upsilontonos]' Iotadieresis by [Alpha Epsilon Omicron Upsilon];
sub [Alphatonos Epsilontonos Omicrontonos]' Upsilondieresis by [Alpha Epsilon Omicron];
} TWO;

} calt;

It ought to work in InDesign now. Let us know. Thanks!

Miguel,
Aren't you up a bit early for the west coast?
Perhaps you are up late, I should have said.

ChrisL

It ought to work in InDesign now.

Not yet.

**

There is another problematic "monotonic" character: upsilondieresistonos.

So this line of code would need to be added:

sub upsilondieresistonos by Upsilondieresis;

CLASSES
UCtonos: Alphatonos Epsilontonos Etatonos Iotatonos Upsilontonos Omicrontonos Omegatonos
UCnotonos: Alpha Epsilon Eta Iota Upsilon Omicron Omega

FEATURE CODE

feature case {
sub Iota by iota;
sub @UCtonos iota’ by Iotadieresis;
sub iota by Iota;
sub Upsilon by upsilon;
sub @UCtonos upsilon’ by Upsilondieresis;
sub upsilon by Upsilon;
sub @UCtonos by @UCnotonos;
sub upsilondieresistonos by Upsilondieresis;
} case;

Yes, it should be in the "calt" feature, but this code works in "case" in InDesign, but not in "calt". Best I can do so far.

> this code works in “case” in InDesign, but not in “calt”.

How are you ordering the features?
Do you have "Contextual Alternates" turned on? (Sorry, just a sanity check)

The only code I would put in 'case' is,

feature case {
sub iotadieresistonos by Iotadieresis;
sub upsilondieresistonos by Upsilondieresis;
} case;

as these are the 2 monotonic Greek characters that are not capitalized by InDesign, when one applies "All Caps".

Then I would order the features like this:
case
calt

BTW, your code is affecting more than the 7 diphthongs. Etatonos, Iotatonos and Omegatonos shouldn't be part of your classes, for example.

> The only code I would put in ‘case’ is,
> feature case {
> sub iotadieresistonos by Iotadieresis;
> sub upsilondieresistonos by Upsilondieresis;
> } case;
> as these are the 2 monotonic Greek characters
> that are not capitalized by InDesign, when one
> applies “All Caps”.

Miguel,

this recommendation reads like you’re suggesting that OpenType features should be devised to acommodate for peculiarities of specific versions of specific applications. I would appreciate some clarification on this.

Regards,
Adam

This seems to be working OK now.

CLASSES

@UCtonos:
Alphatonos Epsilontonos Etatonos Iotatonos Upsilontonos Omicrontonos Omegatonos

@UCnotonos:
Alpha Epsilon Eta Iota Upsilon Omicron Omega

@GrCaps:
Alpha Beta Gamma uni0394 Delta Epsilon Zeta Eta Theta Iota Kappa Lambda Mu Nu Xi Omicron Pi Rho Sigma Tau Upsilon Phi Chi Psi Omega uni2126

FEATURE CODE

feature calt {

lookup ONE {
sub [Alphatonos Epsilontonos Omicrontonos Omegatonos] Iota' by Iotadieresis;
sub [Alphatonos Epsilontonos Omicrontonos Omegatonos] Upsilon' by Upsilondieresis;
} ONE;

lookup TWO {
sub @UCtonos' @GrCaps by @UCnotonos;
sub @GrCaps @UCtonos' by @UCnotonos;
} TWO;

} calt;

I would appreciate some clarification on this.

You'd think that the way to solve it would be to put the two odd characters in "calt", not "case", like so:

sub @GrCaps iotadieresistonos' by Iotadieresis;
sub @GrCaps upsilondieresistonos' by Upsilondieresis;

That works in FontLab preview, but not in InDesign.
Must be some quirk of the casing mechanism.

So unless someone can come up with a way of making it work in "calt", the best practice is to put the two characters "ignored" by InD casing into the Case feature.

> this recommendation reads like you’re suggesting that OpenType features should be devised to acommodate for peculiarities of specific versions of specific applications. I would appreciate some clarification on this.

I'm simply trying to help Nick to achieve what he wants. It doesn't mean I recommend it.
(If you play with Arno Pro in InDesign CS2, you'll see that nothing happens when you apply "All Caps" to ΐ [U+0390] or ΰ [U+03B0])