Re: The profanation of FrameMaker 6 support for Office 2000 documents
Hi.=================================================
It's very sad that announcement of "New support of MS Word 2000 format"
in FrameMaker 6 is a marketing profanation.
When we import multilingual or Non-Western monolingual Word 2000 document
(like Cyrillic, Baltic, Turkish, Greek, Eastern European languages) into
FrameMaker,
all Non-Western text had replaced to "_".
O.K., it is the same misbehavior as in FM 556 for Word97-98-2000 documents.
Yet FM 556 newer declared its "New MS Word 2000 support"
If we advertise "New support of MS Word 2000 [Unicode] format" in
Non-Unicode application,
it should be correct to transform all multilingual Unicode text from Word
with e.g. Arial attribute to
to Arial Cyr, Arial Greek, Arial CE etc.
The PDF document at:
http://www.adobe.com/products/framemaker/keyfeature3.html
states that:
"Adobe® FrameMaker® 6.0 and FrameMaker+SGML 6.0 feature a powerful
new set of import and export filters, including PDF import, XML export,
and Microsoft Word 2000. You can import more than 50 types of files,
and save FrameMaker documents in common word processing formats,
reducing document conversion costs and allowing access to legacy
documents."
Also, the referenced document lists the following import filter:
? Microsoft Word Windows 1.x, 2.x, 6.0, 7.0, 2000
Thus the whole question of how 6.0 handles Unicode when importing Word 2000
documents is not described, and no limitations on importing such documents
are mentioned.
Dmitri is right: This is a "marketing profanation". Adobe's failure
to fully implement Unicode in FM 6.0 will isolate Frame products from mainstream
products like Word 2000.
Since Word 2000 will almost certainly become the DTP of choice for translators
because of its Unicode capabilities, it is likely that round-tripping
of Frame documents via products such as Trados' S-Tagger to accomplish translations
in Word 2000 will become problematic at precisely the point when internationalization
of documentation is becoming a high priority. The likely result will be a narrowing of
the niche which Frame products occupy, coupled with a steepening drop-off in the
installed base, which is already beginning as a result of the abandonment in V6.0 of
all Unix flavors except Sun Solaris, and the likelihood that there will never be a
released version for Linux.
I haven't even mentioned what the effect of the failure to implement Unicode
in V6.0 will be on the continued viability of FM+SGML as an XML tool.
If Adobe has any hope of maintaining the viability of Frame products
in this rapidly changing market, it must, within a very short window of
opportunity, publicly announce its future plans for FrameMaker and
FM+SGML, particularly with respect to Unicode and the XML capabilities
to be incorporated into future versions of FM+SGML. This kind of
announcement must replace the kind of "market profanations" described
in Dmitri's post.
====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.
Previous by Author:
Re: Linux
Next by Author:
Re: Why RFEs don't work
Previous by Thread:
Re: Context-sensitive help and the printed manual?
Next by Thread:
SHED Images in RoboHelp
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads