🚀 go-pugleaf

Arnis - That's odd, because when I try to use unicode characters in Frame 8 with the old "synthetically derived" fonts (dummy 256-character fonts derived from the unicode Arial font), they work for me. The FM 8 document text actually contains unicode characters, and FM 8 rather cleverly backmaps the characters to display the glyphs from the old synthetic font correctly. Not only that, but when I open a Russian FM 5.5 document in FM 8 it even remaps from 1251 to unicode on the fly - the converted document looks the same and uses the same old synthetic font but the document is now unicode in FM 8 and I can then change to a different a unicode font to see the same proper Russian characters in a proper unicode font. (!)

Carlo - But your original question was about FM 7. It is possible that the two machines in question have different entries for the "NonTextFamilies" listing in their maker.ini files. This listing is under the heading of "Frame font families that will not be spell-checked" but the setting actually does more than this. It controls one aspect of font mapping. If a font is included in this list then it is used "as is", without remapping, and all character slots are available . If the font is not in this list then it is processed by the famous (or infamous) ANSI-to-Frame remapping system, and some slots are unavailable. It's possible that the other author had to add Arial Baltic to their NonTextFamilies list in order to use characters slots that would be unavailable otherwise.
So... either add Arial Baltic to the list, or (if it's already there) remove it, then try opening the document again.

One more note - it is possible that the automatic remapping mentioned above (when reading, say, a FM 7 document into FM 8 ) will only work on text which uses a font which is NOT in the NonTextFamilies list.

Dave