Skip to main content
4everJang
Legend
November 30, 2009
質問

Import from FM 7: index markers - Unicode problem?

  • November 30, 2009
  • 返信数 2.
  • 2600 ビュー

Hello all,

I am converting a bunch of manuals from FM7 to FM8 and I suspect there is a Unicode-related problem in the non-Latin language versions. I have imported a Greek language manual and everything seems to be OK, except the index appears as total gibberish. I do have a PDF that was created with the original FM7 files and it shows me what it should look like. The index markers have the gibberish in them already. Does anyone know the details about the way FM7 handled the non-Latin character sets and how I can make FM8 import the markers in the correct way?

Here is an example:

Ενδεχόμενοι Κίνδυνοι  - this is the correct marker, copied from the PDF file

ÁóöÜëåéá: ÐñïëçðôéêÜ ìÝôñá  - I don't think my customers are going to be pleased with this version...

Thanks in advance

Jang

    このトピックへの返信は締め切られました。

    返信数 2

    Participant
    December 15, 2011

    Jang . . .

     

    I'm wondering if you ever found a solution for this index issue.  We currently work with over 20 languages and our Author's are finding that index codes for CS, HU, EL, RO, TR, ZH, PL languages are not correct when brought into FrameMaker 9 from FrameMaker 7.

    Participating Frequently
    December 16, 2011

    You might want to try Index Tools Professional to see if it would help. Full-disclosure: I wrote the plug-in many years ago for FrameMaker 5.5.

    The Frame 7 version of the Index Tools Pro plug-in uses regular Frame encoding for special characters. Those are the characters that have issues when they are converted to Unicode on Frame 8, 9, or 10. There is a "Unicode" version of Index Tools Pro that supports those special characters in the index entries.

    You would need to do the following:

    1) In Frame 7, you would need to use Index Tools Pro to "expand" the existing Index markers.

    2) In Frame 10, you would need to use the "Unicode" version of Index Tools Pro. Then you would need to perform the "Insert All Markers" command to create new Index markers, based on the index marker text.

    All of these operations are discussed in the Index Tools Pro documentation.

    I can't guarantee that it will work for your issue, but I think it might. I know it's been successfully done for Chinese and Arabic documents that had similar issues.

    You can get Index Tools Pro here:

    http://www.siliconprairiesoftware.com

    Just go to the Downloads link on the left. Be sure to get the documentation as well.

    Steve

    Participant
    December 16, 2011

    Thank you Steve – I’ll pass this to our Authors.

    Mike

    Inspiring
    November 30, 2009

    Jang,

    The correct translation of non-Western font symbols depends on FrameMaker’s knowledge which font is used. Within markers, there is no font, so FrameMaker 8/9 assumes the characters are from the systems default codepage.

    The best way would be to use one of those marker editing plug-ins that change the Index markers into paragraphs for editing. Then open in FrameMaker 8 or 9 and use the plug-in again to change the paragraphs back to markers.

    HTH,

    - Michael

    Bob_Niland
    Community Expert
    Community Expert
    December 15, 2011

    MMH: The correct translation of non-Western font symbols depends on FrameMaker’s knowledge which font is used. Within markers, there is no font, so FrameMaker 8/9 assumes the characters are from the systems default codepage.

    Not having needed to experience this migration yet, what you've said implies that if I set my Windows locale to match the old document, and open it in FM8 or later, each Marker Text character is assumed to be codepage-mapped in the default localization, and is converted to the Unicode code point for that glyph. Can you confirm?

    Did Adobe ever write up a summary of how legacy document text and metadata is handled when opened in FM8 or later? Some scenarios strike me as being risky to automate. Frame could hardly be expected to know what every glyph of every arcane 8-bit codepage font maps to in Unicode space - for example, musical notation fonts included with some older MIDI products.

    And as we know, not all legacy glyphs attained a codepoint in Unicode space. How would they be handled?

    Michael_Müller-Hillebrand
    Legend
    December 15, 2011

    Error7103,

    Unfortuinately I cannot confirm anything from personal experience. It seems that FM10 does a better job with this as I was just seeing Polish files migrated from FM7 to FM10 and the generated Index was OK.

    I am not aware of any official Adobe note on handling legacy documents.

    The described process only works, if you worked with Windows-provided virtual fonts (aka FontSubstitutes) and will never work with "fake foreign fonts", i.e. fonts with non-Western glyphs at Windows-1252 code-points. In the 90ies there were e.g. fonts with Cyrillic or CE glyphs available that were occupying the accented latin glyph positions, like ÄÂÁÀ etc..

    - Michael