Unicode, FM, Locked Code Points and Other Translation Problems

[Dmitri Yunov <yudmi@xxxxxxxxxxx>]

Hi, David.

> Does FrameMaker support Unicode characters?  I suspect not, but I can't find any
> references in the archive.  I have some text-mode screenshots with boxes and
> arrows.  I can save them as unicode characters via Notepad (it has a unicode
> option in the SaveAs dialog box), but copy/paste into FrameMaker doesn't
> transfer the characters correctly.  Any ideas?
Which goal you try to solved concretely?
The import of Unicode TXT is impossible in FM.
If your lot of symbols is from  standard MS Charsets (MS Cyrillic, MS
Greek, MS CE, MS Turkish etc.) some solution
present. But you must to know from with Charsets are your symbols
really.
More details are need for me.
> 


===FM and Unicode===
David.

Leave behind the word "Unicode" or even "National Codepage's standard" if you ask about
ANY Adobe's applications.
I know only one from this list - ATM NT that support Unicode partially.

..Yet no any DTP applications now that support Unicode directly.
Neither QuarkXPress 4, nor Interleaf 6-7, nor PageMaker 6.5 nor new
InDesign 1.0 nor Corel Ventura 8 - they are not support Unicode now.

By hard rumors next Ventura 9 and QuarkXPress 5 (on beta-testing now)
will have Unicode support.


Only NT Notepad, NT CharMap, MSOffice 97 and MSOffice2000 have good
Unicode support - but
there are not DTP applications absolutely.

#############################
Hi, Dan, too.
Thanks for reply.

>These locked code points appear to the the reason that one or more glyphs in
>Times New RomanCYR and Times New RomanCE cannot be produced in FrameMaker or
>FM+SGML, affecting the capability to use Frame for translations in about 6
>Cyrillic and Central European languages. Undoubtedly, it affects fonts other
>than Times New Roman, and languages other than Cyrillic and Central European
>as well.

>Additionally, in FM+SGML the order in which Read/Write rules are listed for
>ISO PUBLIC character set entities is, according to the Developers Guide,
>supposed to determine which rule applies (i.e., the first rule that's
>encountered is supposed to determine which entity reference is used on
>export to SGML). For instance, if #include ISOlatin2 appears before
>ISOlatin1 in the main read/write rules file, code points common to both
>should translate to ISOlatin2 entity references on export. This however, is
>not the case, and it becomes necessary to comment out the conflicting entity
>declarations and read/write rules in ISOlatin1 before the correct entity
>references are produced on export.

>The problem cited by Dmitri, as well as the mistranslation of entities,
>effectively destroys Frames capabilities for handling translations in many
>languages.


International support of FrameMaker 5.5.6 keep the same as in
FrameMaker 3.0 (1992)
or in Xerox Ventura 1.1 (1988), or in IBM Interleaf 1.0 (1989)
Yes, Asian CJK support has included now to main FM version.
Any other languages must be supported with "FrameRoman" encoding only.

"FrameRoman" encoding is truncated ISO 88595-1 (Latin-1) - so Frame
deleted Icelandic support from Latin-1.

Neither Frame Tech., nor Adobe does not change even one byte in this
"FrameRoman" encoding for move to Unicode or NLS (multicodepage) standards.


===To Adobe (FrameMaker) marketing department===

My caustic remark and advice to Adobe marketing department.
Since Adobe programmers like very match the "FrameRoman" encoding
Adobe may to attach a big smart color label to FrameMaker 6, 7, 8, 2000 box.

"Wow!! The news! FrameMaker 2000 supports new languages! It is best
choice for multilingual publishing and technical documentations in the
world! We support now additional <see my list of possible languages>....!!!"

All this languages are possible in current version of FrameMaker and
"FrameRoman" encoding.

For same solution of marketing it is possible for Adobe to close own
FrameMaker's programmer department and to save a lot of money in
programming trend.

But very big lot of people (it seems, sorry, include me) will spent
their money/time to future Unicode based Corel Ventura 9 and leave behind Framemaker .. forever.

<My list of possible languages for poor and unhappy future FrameMaker
6 or 2000>
=Africa=
Swahili
Congo
Zulu (if to replace B'b'=>Bb)
Afrikaans

=artificial languages=
Interlingua
Occidental

=Europe=
Albanian

Hungarian (since FrameMaker has own pseudo symbol "hungarumlaut" -
(\xfd)" = press "Control + q }" and try to understand from wich font this symbol?

Breton
Flemish
Retoromanian (Ladino)
Occitane=Provence

=SE Asia=
Indonesian
Tagalog (it's need only to generate a big tilde over
        ligature "ng" - see my Hungarian comments)


===FM and XML===

About Frame+SGML/FrameMaker 5.5.6 and its "Save As XML".

Since XML is in general Unicode based standard
all XML files generated by FM are poor.

For justice it need to said the Japanese/Roman text converted to Unicode inside
FrameMaker's XML files correctly.
Any other possible languages (Greek, Turkish, Cyrillic, Central European,
Icelandic, Baltic, Asian Turkik, Asian Cyrillic, Thai, Lao, Khmer, Burmese etc. etc.)
will be converted with FrameMaker to the Roman range of Unicode.

It is a shame all the more since Frame+SGML 556 has at last the correct Unicode
mapping tables for main CodePages - take a look to file "F+SGML\FILTERS\ltscsd13.tlb"
.....

By my experience - only two XML generated products support Unicode 2.x well or very well:

1. Take a look at "T.I.M.E.L U X" EditTIME 3 SGML/XML Unicode Editor.
http://www.timelux.lu/EditTIME3/EditTIME.htm


2.
XML Spy  2.5 (www.xmlspy.com)
http://www.icon-is.com/e/menu_prod.html?SOFTWARE#
My congratulations to creators of XML Spy!
Even Indic/Arabic/Thai XML/Unicode files are generated correctly with this tool!
XML Spy used RichEdit 3.0 DLL from Win2000 beta 3.


Best wishes.
Dm.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **