The following topics are a collection of hints, tips, frequently asked questions, and technical notices that might be of interest in rare cases only. Nevertheless, this information might help to solve or identify one or the other problem.

Where appropriate, other sections in this book refer to these topics. Also, several index entries guide you to these topics; note especially the index entries “hints”, “tips”, and “technical notices “.

Contents [hide] 1 About Microsoft (R) Word documents 1.1 Disk space consumption with .doc files 1.2 Problem: Word files with embedded picture data cannot be exported 1.3 Automatic font conversion for translated RTF documents 1.4 Translating TOC and index sections in Word documents 1.5 EQFRTF/EQFMSWRD markup table and third-party program limitations 2 About bidirectional language processing 2.1 Windows (R) Help/RTF – Table columns not in reverse order

About Microsoft (R) Word documents

Disk space consumption with .doc files

When OpenTM2 processes Microsoft ^(R) Word files, it temporarily needs disk space that might be a multiple of the size of the .doc file to be processed. Especially files that contain graphics require more disk space.

The reason is that OpenTM2 uses an internal conversion from .doc to .rtf format to process Microsoft ^(R) Word files.

Problem: Word files with embedded picture data cannot be exported

The export of .doc and .rtf documents might fail if they contain embedded objects in a format other than Word’s native format. To overcome this problem, convert the embedded objects into graphics before importing.

1. Open a document in Microsoft ^(R) Word and locate all pictures, one after the other.
2. Click a picture, and observe the status line.
3. If the status line shows “Double-click to edit Unknown” , this picture is not stored in native format.
4. Mark this picture and press CTRL-SHIFT-F9, which converts the embedded object into a graphic.
5. For verification, click the picture again. The “Double-click to edit Unknown” message should not appear.
6. Continue until all pictures are processed this way.

Automatic font conversion for translated RTF documents

OpenTM2 supports the automatic font conversion for translated RTF documents. You can see the conversion when postediting your translation (provided that all the required fonts are installed), or after exporting the translated document.

The specifications for the automatic font substitution are in the language-specific sections of file ..\eqf\table\eqfrtf.chr. If you want to change the specifications, you need to change the parameters following the keywords CHANGEFONT or DEFCHGFONT.

If you want to add specifications for another language, follow the layout of the already existing specifications in this file.

• CHANGEFONT specifies one or more one-to-one font substitutions.

The general structure of an entry is:

CHANGEFONT="[source font name]=RTF font spec. for target font" \
            (...)
           "[last entry]=..."

where substitutions are enclosed in double quote pairs, and separated by backslash characters.

The following example:

CHANGEFONT="[Times New Roman]={\f%1\froman\fprq2\fcharset2\fprq2 Arial;}" \
           "[Courier]={\f%1\froman\fprq2\fcharset2\fprq2 Garamond;}"

specifies font substitution from “Times New Roman” to “Arial” and from “Courier” to “Garamond”. The other characters in the RTF font spec. for target font specify special characteristics of the substitution.

• DEFCHGFONT specifies font family substitution.

The general structure of an entry is:

DEFCHGFONT="[source font family]=RTF font spec. for target font family" \
             (...)
           "[last entry]=..."

where substitutions are enclosed in double quote pairs, and separated by backslash characters.

OpenTM2 supports the following font families as RTF font spec. for target font family:

Font family	Characteristics	Examples
\froman	Roman, proportionally spaced serif fonts	Times New Roman, Palatino
\fswiss	Swiss, proportionally spaced sans serif fonts	Arial
\fmodern	Fixed-pitch serif and sans serif fonts	Courier New, Pica
\fscript	Script fonts	Cursive
\fdecor	Decorative fonts	Old English, ITC Zapf Chancery
\ftech	Technical, symbol, and mathematical fonts	Symbol
\fbidi	Arabic, Hebrew, or other bidirectional font	Miriam

 

Note: If you use both keywords in a language section, and specify identical source fonts, the one-to-one font substitution takes precedence.

Translating TOC and index sections in Word documents

When you open a Word document in OpenTM2, the table of contents section and the index section of the document are protected and cannot be translated.

To create translated table of contents and index sections, re-create both sections after the translation is completed. Open the document in Microsoft ^(R) Word, select where you want to insert the TOC, respectively index, click Index and Tables on the Insert menu, and then click the Table of Contents tab, respectively Index tab. The table of contents and index are then re-created from the (already translated) headings and index entries.

For more details see Microsoft ^(R) Word Help.

EQFRTF/EQFMSWRD markup table and third-party program limitations

If you use the markup tables EQFRTF (for Rich Text Format documents) or EQFMSWRD (for Microsoft ^(R) Word documents), note the following limitations:

• The Mac file format is currently not supported.
• Font Embedding is currently not supported.
• For bidirectional languages, note that the Visual C++ help compiler versions 4.01.0950 and 4.03.0002 (part of Visual C++ versions 5.0 and 6.0) do not support the reordering of table columns; therefore table columns are not automatically displayed in reversed order.

See also Windows Help/RTF – Table columns not in reverse order.

About bidirectional language processing

Windows (R) Help/RTF – Table columns not in reverse order

Although the RTF specification encloses special tags for bidirectional language processing of tables, the Microsoft ^(R) Help compiler does not support column reordering for bidirectional languages. Note the following excerpt from a Microsoft ^(R) technical article: “… Right-to-left tables, a standard feature of word processors such as Arabic Microsoft ^(R) Word, are not a supported feature of Help Compiler Workshop. Help Compiler Workshop will compile a right-to-left table as if it is a left-to-right table. …”.

See also EQFRTF/EQFMSWRD markup table and third-party program limitations.

As a workaround, you can edit the tables manually before importing the documents into OpenTM2. You can use the Word macro function to automate this task.