feature locl { # Localized Forms
language CAT;
sub L' periodcentered' L by L_periodcentered;
} locl;
and in another font
feature calt { # Contextual Alternates
sub L periodcentered' L by periodcentered.CAT;
} calt;
but neither of these tests would trigger the Acrobat PDF Maker into getting L + periodcentered as “text”.
(With different results for ttf/cff.) Bummer.
I would like to suggest to leave out CAT altogether, so that Catalan words will also look good when embedded in Spanish text, a likely scenario.
Unfortunately none of the tested features work just like that in MS Word, even for locl to work you first need to switch kerning on or so it seems.
Or edit the normal style in a new document like this: format some text, right-click, click styles, right-click Normal and select “Update Normal to Match Selection”. Then save this file as a macro enabled template, to replace C:\Users\MyName\AppData\Roaming\Microsoft\Templates\Normal.dotm
and then all newly created documents will be fine, with kerning and preferred number style, even stylistic sets can be switched on by default.
It is normal for corporate design implementations to roll out such “dot” files, so that every new document in a company automatically follows design specifications. Template producers normally must be instructed to switch on typographic options.
Text reconstruction from PDFs depends on the implementation, and as far as I can oversee it (there was a recent discussion on Twitter), almost all of the methods are flawed one way or another.
One implementation goes like this: The Unicodes of the text entry are not changed of course, rather not saved at all in a generated PDF. What gets saved instead are the glyph names. A PDF reader can try to reconstruct the characters from the glyph names embedded. Which is a pretty faulty implementation, to say the least, because it has to do a lot of guesses, and things like line breaks, se-pa-ra-ted words, paragraphs, empty lines, or multi-column typesetting will likely confuse the reverse-engineering of the text. This is also an issue for double encodings, and described in the All-Caps tutorial. By employing certain glyph names, a font can make this hack a little less unsuccessful, but also no more than that.
There is a method to properly store the original text alongside the glyphs inside the PDF, but it is not in widespread use, because IIRC it has some other flaws. I don’t remember which though.
I stopped worrying about text reconstruction from PDFs, because it is so broken from the start, and therefore I don’t believe that we can fix it from inside a font. There have been tools that did nothing but clean up and guess paragraphs from text in PDFs.
If no one minds, I will move the last couple of posts into a new thread, because here it is off topic, and therefore hard to find for later forum generations.