Cyrillic fonts not supported in variables in FM10?

Report · Sep 15, 2011

I have a whole set of files using Cyrillic (Arial CYR and Times New Roman CYR), including variables, created in FM7.2. If I try to manipulate the variables in any way in FM10 (copy/paste, import into another file, etc.), they no longer display correctly, although the font setting has not changed. The same happens for pretty much any extended font set (Chinese, Korean, Polish, etc.). Is this a bug in FM10?

Report · Sep 15, 2011

This could be a result of crossing the Unicode boundary (at FM8), but let's rule out the historical ways of having this happen ...

Can you post a typical variable Definition?

The usual problems are:

using a local override to apply the font to the var, which makes it easy for any instance of it to lose the font, or
using a Character Format to apply the font inside the var, but the ChFmt doesn't exist in the document into which you are pasting.

Report · Sep 15, 2011

This is a user-defined variable called "Product"

?íôîðìàöèîííàÿ ñèñòåìà Xper Information Management

It displays correctly in Arial CYR when I open the FM files, and I am using it in a paragraph format called "Footer," in which the font is set to Arial CYR, 8 pt. It displayed correctly when I initially opened the file, but I had adjusted some of the paragraph formats in one of the other FM files in the book, and when I imported them into the second file, the characters no longer displayed correctly, although they still appear as Cyrillic characters in the original FM file from which I imported the formats.

This also occurs with Chinese, Korean, and Central European fonts. I've also noticed the problem with some of my cross-references and some of my other paragraph formats. It's very odd, because one format will display correctly, while immediately below, another format will be scrambled.

Report · Sep 15, 2011

?íôîðìàöèîííàÿ ñèñòåìà

Is the text supposed to have the glyphs appear as they do here?

That looks like roman extension (8th bit on) characters.

I'm guessing that even in the old manual, these were the roman postional equivalents of cyrillic characters, and only took on cyrillic glyphs when the appropriate (legacy) font was applied.

If so, this is likely a Unicode boundary problem. Our shop has not migrated production beyond 7.1 for a number of reasons, but the Uniproblem is one of them. Everything will need to be checked for unintended surprise glyphs.

There may be some back traffic on this forum, from the FM8 days, regarding how to get a good start on migrating old documents. The following Google search string gets some hits:

framemaker 8 unicode font convert OR migrate OR upgrade site:forums.adobe.com

Report · Sep 15, 2011

"I'm guessing that even in the old manual, these were the roman postional equivalents of cyrillic characters, and only took on cyrillic glyphs when the appropriate (legacy) font was applied."

Yes, that's correct. However, we've had to migrate to 10 to get Unicode support for PDF and HTML conversion for certain fonts, Cyrillic being one of those. 7.2 couldn't correctly create bookmarks for Russian, Chinese, Korean, and several other languages, and would not convert those same languages to HTML correctly. I can go into each chapter of a book and manually edit the paragraph formats without losing the fonts, but that's tedious when you have multiple books in multiple languages. I've contacted Adobe support about the problem, but so far, they haven't been able to help.

Report · Sep 16, 2011

I have a whole set of files using Cyrillic (Arial CYR and Times New Roman CYR) ...

I'm guessing that you still have these legacy codepage fonts installed. I would have expected legacy FM7- documents, when migrated to FM8+, to simply continue to render as before, as long as the fonts didn't change (both font name and code points in the fonts). If documents morph, this could be a bug.

The current plain MS Arial and TNR, of course, have cyrillic glyphs at the expected Unicode code points.

I tend to doubt that Adobe provided any tools for text conversion at FM8, because migrating legacy non-roman text might be a computationally intractable problem. What appears to be normal roman 7-bit or roman 8-bit text may well be intended to be non-roman, based on local tags in the variable, character formats where used, paragraph formats where used, and local overrides where used. And even if Frame could deduce an intended rendering, there's the question of what to do about inconsistent instances.

.... we've had to migrate to 10 to get Unicode support for PDF and HTML conversion for certain fonts, Cyrillic being one of those. 7.2 couldn't correctly create bookmarks for Russian, Chinese, Korean, and several other languages ...

I suspect the thing to do is to bite the bullet and convert all the non-roman text to Unicode. There seems to be a wide choice of tools to help with the effort, many likely free. But it probably requires a human to decide "this string of roman8 randomness is supposed to be Klingon".

Our shop's hazard, non-character symbols whose code points have moved, or whose glyphs didn't earn a spot in the Unicode pantheon, seems simple by comparison.

Report · Sep 16, 2011

lhines01000 wrote:
However, we've had to migrate to 10 to get Unicode support for PDF and HTML conversion for certain fonts, Cyrillic being one of those. 7.2 couldn't correctly create bookmarks for Russian, Chinese, Korean, and several other languages, and would not convert those same languages to HTML correctly. I can go into each chapter of a book and manually edit the paragraph formats without losing the fonts, but that's tedious when you have multiple books in multiple languages. I've contacted Adobe support about the problem, but so far, they haven't been able to help.

lhines,

Frankly speaking, you should have bought professional support to solve your issues. Even before FrameMaker 8 the PDF content was Unicode (when using virtual fonts like Arial CYR) and there were solutions available to get correct bookmarks for all languages. There have also been solutions for conversion to HTML. All those requirements exist for 10+ years and they have been solved. Not by Adobe, of course, but by the well-established FrameMaker community.

FrameMaker handles the conversion of CYR and CE fonts in the text flow quite nicely, but inside variable definitions and markers (e,.g. Index marker content) there is no font context, so the application has no stable means how to convert the text.

My recommendation to fix this: Take a PDF created from the former documents and copy and paste the variable strings from the PDF into the variable definition dialog. You will see them appear as correct Cyrillic glyphs.

- Michael