This content has been marked as final. Show 12 replies
This is because the logic for processing substitution rules says:<br />1) for each substitution lookup in the font:<br /> 2) for each rule in the current lookup<br /> 3) check the current glyph position to see if rule match string matches here. If so, then apply the rule, advance the current glyph position by the length of the substitution target string, and start over at 2)<br /><br />Your first rule matches in in the string "/one /s /t" when the current glyph '/s'. The rule is applied. The string then is "one /s.superior /t", and the current glyph is "/t". the second rule will never match, because it does not contain "/s.superior" in the match context. To work, this should be:<br /><br />sub [one one.small one.osf] s' t by s.superior <br />sub [one one.small one.osf] s.superior t' by t.superior<br /><br />The way you wrote the first rule guarantees that "/s" will have been changed to "/s.superior" by the time the rule processor gets to the second rule.<br /><br />Gratuitous complications:<br />The bit about "advance the current glyph position by the length of the substitution target string" means that if rule looked like:<br /><br />sub [one one.small one.osf] s' t' by s_t.superior;<br /><br />then current position woudl have been advanced by two glyphs, not jsut one, as the lenght of the strign that was substituted is two glyphs.<br /><br />An oddity that is useful for avoiding overly complex match contexts is the 'ignore sub' rule. If you say:<br />'ignore sub <some match string>;<br /> then the rule processing logic will match at that rule, but do nothing. This can be used to shelter subsequent rules from a particular context.. For example, you could say:<br />ignore sub [ @ALL_NUMBERS ] s t [ @ALL_NON_SPACE_GLYPHS ];<br />to avoid matching a context where the 'st' was followed by something other than whitespace.
Thanks for your explanation, but as I have written my problem is that I also tested
sub [one one.small one.osf] s.superior t' by t.superior
but it did not work neither.
Even if I use any similar substitution - I mean the target glyph is in the end of the context matching string - it does not work at all.
In short, any substitution
sub a b c' by c.alt
is not working. I would like to avoid defining @classALL_NON_SPACE_CHARS, as the font has more than thousand glyphs.
I looked into Minion Pro which ordn feature works fine in IND but it uses the same type of substitution as I intended to use! So I am completely confused now.
Then we are missing some information. As a general statement, rules of the form:
sub a b c' by c.alt;
are correctly built in the font, and do work. If your experience is that they do not, I can think of only one possiblity: you are running into an bug in conextual substitution in MakeOTF, and older FontLabs. Through InDesign 2.0 and FontLab 4.5, and MakeOTF FDK1.5, these tools interpreted the order of glyphs before the substitution in an order opposite that of the MS tools and programs. (These tools all worked together happily, however. ) The symptom is that rules with more than one glyph in the back-track sequence match in the reverse order. Hence the first rule will match in the context expected, as there is only one glyph in the backtrack sequence; the second rule won't because there are two glyphs. You can quickly test this by building the rule with the order being:
b a 'c by c.alt;
if works in the context "a b c", this is the problem.
For details on this issue, please see the message on this forum, in the archives directory:
"New release of the Adobe Font Development Kit for OpenType"
Read Roberts - 10:45pm Mar 10, 2003 Pacific
I am currently trying to use FontLab 4.6.0 (instead of FDK 1.6) and this is probably the cause of my problem.
As you have said,
sub a b' c by b.alt; works just fine.
Thank you very much once more.
You can use FontLab 4.x; you just need to make sure that the name table Version string contains one of the strings of text that will identify your font as having the InDesign2-compatible format,. MakeOTF in the FDK1.6 still builds contextual susbtitutions in the old format by default; you hve to select an option avodi this.
I did not have a clue that version string (do you really mean 5.x.x in Name table?) affects the interpretation of OTF features in InDesign. I do not know which string identifies OTF as IND2-compatible format. Could you please point me to the document where it is decribed? I have gone through OTF specification and FDK documents but I could not find it.
Thanks a lot.
The contents of the name table Name ID 5 do affect how InDesign 3 (and other Adobe programs) process contextual substitutions. An ugly hack, but the best we could think of. Certainly is better than making a whole group of fonts not work.
The necessary documentation notes are in the file: "FDKReleaseNotes.txt" at the top level of the FDK directory tree.
Thanks for your support.
Version string "mystery" is now solved and clear to me. :-)
Meanwhile I found out (thanks to FontLab support staff) that the main problem is that there must be reversed order of the glyphs in contextual substitution:
sub [one one.small one.osf] s' t by s.superior
sub s.superior [one one.small one.osf] t' by t.superior
Now, this substitution works as expected and returns:
/one /s /t >>>> /one /s.superior /t.superior
(the trick I was not able to find in OTF Features Syntax ver. 1.4)
Your solution does work for newer programs, but will fail in InDesign 2.0.
I suggest that it would be better to use the correct syntax in the feature file, and add the necessary text in your name table name ID 5 Version string. That way, both InDesign 2 and InDesign 3 and later will process the rules correctly. Furthermore, when you rebuild your font with FontLab 5, where the underlying tools error ought to be fixed, you will need to change only the Version string, instead of fixing all the affected contextual substitution rules.
Oh yes, Read. I have found it out.
I will have to use FontLab 4.52 because FL4.60 is simply not able to compile universally working OTF.
Thanks a lot for your support.
Wouldn't it be cleaner to have an "s_t.superior" ligature?
Then it's just
sub [one one.small one.osf] s' t' by s_t.superior
The other consideration is that this is very anglo-centric. What about ordinals for other languages?
Adobe started going down that path, and that's why we decided to stop doing our ordinals as contextual. It was just crazy to try to anticipate every relevant language, and there's no reason users should be hobbled to only use the languages we think about.