NonText Families - central european

[_thomas_bro_]

When entering this in the Maker.ini:

NonTextFamilies=Arial CE, Times New Roman CE, Courier New CE, ...

I get different views in FrameMaker for CE fonts. They are as a fact correct.

But if the original setting is used (NonTextFamilies=ZapfDingbats, Symbol...) they are incorrect.

According to the description the NONTEXT is only for spell check (or lack of).

The files in questions are being translated in Cz and just received for PDF'ing.

Why is it influencing the FM look. PDF's are produced accordingly correct/incorrect.

Saved MIF files from the two instances are however identical.

keep smiling
thomas

[Arnis Gubins]

Thomas,

I think that this setting forces FM to also interpret different ANSI
values for the hexcodes. Consequently, the glyph called in the font on
output varies. If you look at the FM character sets table, the
Standard Character set uses the FrameRoman encoding (hex and ANSI
don't always match), while the Symbol and Dingbats Character set uses
sequential values (hex and ANSI match). This only differs in the high
ANSI range above 127, where the accented CE characters are found.

None of this is documented anywhere that I've found.

[AxialInfo]

Thomas,

I have no idea whether this might be useful for your specific problem, but just in case, here's a CE languages FM plug-in notice that I came across recently: http://www.kontentsu.com/products_k-fm.html

SHeila

[_thomas_bro_]

Arnis, Sheila

Thanks for the inputs. I'll look into the Kontentsu.

I did have the feeling that this entry in the maker.ini for not well (=not) documented, and that it did exactly what you describe Arnis.

For your information the entire problem arose because the original UK file was being translated into CZ and POL in two different rounds using TRADOS. In the first round Word 2000 was used for saving the RTF file and the second Word 2003 was used. Since Microsoft has changed their RTF format (they apparently do that every time the change versions). This caused the problems in FrameMaker. I'm not totally blaming Word, since the behaviour in Frame is somewhat curious (=how can a spell check setting influence the choice of fonts!).

Another funny part in this is that is I swop the settings in the INI file back to the original the older files become correct and the new one incorrect. A vice versa situation.

The real problem, I think, is really that the hexcode in the MIF file is identical whatever is being done in the INI file.

So what can one do but hope for a UNICODE version of FrameMaker.

keep smiling
thomas

[Helge Blischke]

I cannot add much to the Windows issue, but from my experience with UNIX FrameMaker (since Version 1.3 by the way) the following holds:

(1) Up to and including 5.56, this setting (NonText fonts) in fact denoted fonts that are treated as sort of "symbolic" fonts. In the UNIX versions, these fonts did not undergo any re-encoding on the PostScript level; it was assumed that - whatever platform you used - the mapping from character codes to glyphs is the same.

(2) Beginning with version 6.0, this obvously did change (the non-text flag is no longer passed to the PostScript generator).

I suspect that this issue has been induced by handling of unicode-compliant trueType fonts on Windows (these need not know of glyph names at all).

Moreover, the joint M$/Adobe created PostScript driver on W2K and
above does not properly process those "non-text" Type1 fonts (any glyphs are substituted by the bullet, which usually isn't even present in these fonts).

For the UNIX version, we have written our own PostScript generator which still permits to handle these non-text fonts, and, at least for printing to whatever, we are switching from Windows and Mac to UNIX.

[Helge Blischke]

Just an addendum: on the Win boxes (W2K and XP) we use the old kernel mode NT4 PostScript generator for any GDI printing. Though it has is's own drawbacks, at least all glyphs come out.

[_Dieter_Gust_]

NonText Families - Central European languages and FrameMaker

Adding fonts to the entry "NonTextFamilies" may be used as one of three or four tricks to get the two "famous" characters tcaron (Slovak and Czech language) and Zacute (Polish language) displayed by FrameMaker.

Beside the documented purpose (Customizing_Frame_Products.pdf), characters will not be re-encoded by the Frame internal (Hex) codepoint representation if they are formatted with a font listed in the NonTextFamilies line.
The other way round: normal text formatted with (text-)fonts not mentioned in the NonTextFamilies line will be re-encoded according to the Macintosh Codepage (not exactly, but that's what stands behind the re-encoding).
"Search and Replace", for example, only works with "normal text"; that is, the corresponding font must not be listed in the NonTextFamily section. Why is this? For cross platform reasons and because FrameMaker is not a Unicode enabled program.

From an Adobe point of view, FrameMaker just supports ISO Latin 1 8859-1 (UNIX) or respectively Windows 1252 (Western languages) respectively the think different Macintosh codepage besides the supported double byte codepages for CJK languages.
http://www.adobe.com/support/techdocs/322964.html

As no FrameMaker user wants to throw FrameMaker away or wait until Unicode-FrameMaker arrives, I think every FrameMaker user in the world - except Adobe itself - now uses FrameMaker for publishing in almost every world language.

In order to publish languages beyond the Western ones the trick is to use the FM codepoints and to let these codepoints be interpreted by different codepages. This can be simply achieved by using fonts supporting the required codepages. In order to activate a special codepage in FrameMaker, Microsoft has implemented the so called virtual font or "FontSubtitutes" feature. For some excellent details see: http://wgl.typ.pl/help/enintro.htm. This points to a Polish website - guess why.

You may use also Type 1 CE fonts in FrameMaker but you will have to take into account the antiquated Type 1 concept for supporting codepages.

The "font trick" for foreign languages works with every single byte codepage and every OpenType/TrueType font containing the necessary characters. The "font trick" has initially nothing to do with entries in the NonTextFamilies line.

When using fonts covering Eastern languages you will have to take into account the following problems:
FrameMaker has "blind spots" at the codepoints (0129, 0143, 0144, 0157.
But caution: only the FM internal mappings of these codepoints are addressed!

Among all Eastern European languages the FrameMaker blindspots affect Slovak (tcaron) and Polish (Zacute) most of all:
- tcaron: Windows 1250 codepage, codepoint dec 0157/hex 0165. FM internally maps tcaron to dec 253/hex FD.
Inside the file "framemaker.exe" this codepoint is hard-encoded to the "seconds" character (or? "double acute accent") presented by the Symbol font
- Zacute: Windows 1250 Codepage, codepoint dec 0143/hex 0179. FM ignores the codepoint: you get nothing (no character at all, and therefore no codepoint).

In order to get FrameMaker to display any characters positioned at these "blind spot" codepoints in any of the Windows single byte codepages you have one of the three following possibilities:

1. You add the used text font (containing the necessary characters) in the NonTextFamilies line:
As a result FM does not re-encode the characters of that "NonTextFont": the codepoint 0157 is not
remapped to 0253, it is left where it is. And FrameMaker is able to display the character for the codepoint
0157. And like a miracle tcaron will be displayed. But be aware of the side effects when exchanging documents on different PCs.

2. You may patch the framemaker.exe file, but it's not magic. This has been done by www.amsoft.cz and http://framemaker.narod.ru and a German FrameMaker expert (no English information available yet)

3. You may use a so called OWP Codepage Patch delivered by my company itl as a goody of the so called One World Publishing Workshop for FrameMaker. An abridged version will be held as a Webinar by STC in the mid of 2005.
And you may directly meet us at the next STC conference (ITL - Insitute for Technical Literature). http://www.stc.org/52ndConf/Exhibitors/exhibitors.asp.

4. RTF 1.8 (Word 2003)and RTF 1.7 (Word 2002) introduced an new control word for Unicode characters (codepoints) which might be the reason for th RTF problems. A Workaround is to save the RTF with Word 2000 (= RTF 1.6) which uses only codepoints for the corresponding single byte codepages.

If the "NonTextFamilies" trick is chosen with Trados you must activate the corresponding checkbox "Symbolfont" in S-Tagger

To sum it up:
Adding fonts in the NonTextFamilies line stops the Frame internal re-encoding of characters. This "trick" may be used for displayiing the two special characters tcaron and Zacute
It is easy to use this trick but it is difficult to control the side effects when FM-documents shall be exchanged. The best solution would be a Unicode FrameMaker...

The biggest challenge is to understand the technical background in combination with the whole document production and translation workflow ...

Now I'm exhausted
Dieter

[Arnis Gubins]

Dieter,

Thank you for the detailed explanation of this topic. I'll mark this
as a permanent topic so that it stays in the archive.

Arnis

[_Dieter_Gust_]

Additional information with supplemental links concerning the same issue may be found in another thread: "Convert FrameMaker to InDesign".

The discussed reason for this "dangerous" intention FM2InDesign has been the Unicode based architecture of InDesign, but as the thread shows: InDesign is not at all an alternative to FrameMaker even with regard to Unicode.

Dieter Gust "Convert FrameMaker to InDesign" 2/2/05 8:32am

Regards Dieter
http://www.itl.de/default_nf_en.html

[_thomas_bro_]

Dieter

As with Arnis I've marked, printer, PDFfed both threads.

AND foremost I found the reason for all the problems: Word versions and Trados.

Thanks a billion

keep smiling (I am!)
thomas