I have problem to make ordinals substitution working:
sub [one one.small one.osf] s' t by s.superior
sub [one one.small one.osf] s t' by t.superior
(I have also tried
sub [one one.small one.osf] s.superior t' by t.superior
in any case I alwas get this result /one /s.superior /t
it seems to me that any substitution with the target glyph in the end of the string longer than two glyphs is not working and I cannot find the reason why. but it is working when the target glyph is in the middle.
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.
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
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.
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.
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.