Re: SUMMARY - Error on importing Word file to Frame+SGML

["Jeremy H. Griffith" <jeremy@xxxxxxxxx>]

On Sat, 16 Feb 2002 18:22:53 +0100, m.oritz_b.erger@t-online.de 
(Moritz Berger) wrote:

>I'm with you on many accounts. I feel, however, that it's slightly
>misleading to blame 3rd parties for what Adobe has done to Frame. FYI:
>I've been using Frame since version 2, so I didn't part ways with that
>tool voluntarily.
>
>> -----Original Message-----
>> [mailto:owner-framers@omsys.com] On Behalf Of Jeremy H. Griffith
>> Sent: Saturday, February 16, 2002 5:05 PM
>> Subject: Re: SUMMARY - Error on importing Word file to Frame+SGML
>
>> That said, this import filter problem is *not* evidence of
>> malfeasance by FrameMaker engineering, for which I have the 
>> highest regard. 
>
>So where's Unicode support, to begin with?

Retrofitting a non-Unicode program to support it is a very 
major programming task.  I won't go into the details of why,
and I'd certainly like to see it too.  When the Asian language
support went in was a good time to do it, and I regret the
choice not to; IIRC, this was a Frame Technology choice too.
This is part of why Mif2Go lacks even Japanese support; we're
hoping to be able to go directly to Unicode when/if Frame does.

>I consider it somewhat embarassing that Frame 5.5.6 crashed when a font
>happened to have "too many" kerning pairs (as it is the case e.g. with
>Adobe's own OT Warnock Pro family).

<sigh>  Yes, many programming choices that were made in the 
days when every byte of memory saved counted now look bad.
For example, when storing a set of items that varies in count,
like kern pairs, it's best to use a "linked list".  But that
is more expensive in memory than an "array", and if you are
sure that you'll never have more than a small count, then a
fixed array is cheaper than a dynamic one (sized at runtime).
Of course, if the count exceeds your expectation, you have
a mess; bounds-checking code was *also* expensive then.  This
is probably the biggest source of program bugs that exists.

>Frame has many issues with EPS files (see this mailing list,
>occasionally Dov Isaacs steps in with helpful workarounds, but in
>general, InDesign just is a far superior choice if you happen to have to
>deal with vector illustrations).

Could very well be, I haven't used it myself.  But for simple
tech illustrations, or for adding callouts to an image, it's
hard to beat the simplicity of Frame's drawing tools.  Try
comparing them to Word's, which only recently improved to
be at all comparable.

>> Now Adobe, *not* known for irresponsible engineering, had a
>> problem.  They couldn't just drop the filters again, there
>> was a reason Frame needed them.  They weren't fixable, as
>> it would be cheaper to start over.  But the cost of doing
>> it right would be enormous,
>
>My solid guess is that for $100.000 you could get a near perfect Word 97
>import filter, considering that the format is very well documented by
>Microsoft (and has been ever since 1997).

You're *way* low.  Our estimate, a good deal more than a guess,
is that we'd have to spend at least $300K for a first-cut RTF
import filter, which is why we don't offer one to go with our
excellent RTF output filter.  And then spend another $100K per
year to keep up with new Word bugs, er, usage, and improve it.
As to the quality of the MS documentation, surely you jest.  ;-)

>But, Adobe didn't care. From a product marketing point of view, that's
>almost understandable. Having "working Word import filters" on your
>feature list sounds boring in comparison with having "HTML export
>capabilities" (even if they turn out to be another broken 3rd pary
>product, namely WWP 6 Standard edition).

Well, my view is the exact opposite.  Word import filters are
an aid in migrating customers *to* your product, and should be
real high on Marketing's wish list.  But Word's .doc format is
not as stable as RTF, which is the MS equivalent to MIF and is
effectively lossless.  So they probably consider this problem
solved by the Japanese RTF import filter.  They could even be
right, if only they didn't hide that filter so well... :-(

OTOH, the HTML export requirement was being handled by numerous 
third parties (some now gone), and Adobe has been good about not 
squashing its third-party vendors by adding features in which 
those vendors have invested large amounts of time and money. (Not 
so MS, which crushes them regularly, counting on monopolistic 
market share to induce new ones to spring up.  But I digress.)

As to WWP Standard, it *had* to be somewhat bro^H^H^H limited
so that people would get hooked into spending the substantial
amount to "upgrade" (heh) to Pro.  IMHO, it's little better, if
at all, than Frame's built-in HTML export, which is still there
too.  (Disclosure: we are creators and vendors of a competing
HTML/XML/etc. plug-in, Mif2Go, so we may be a tad biased.  ;-)

>> and had to be weighed against
>> other improvements the core product badly needed (many of which have 
>> indeed been made).
>
>And many of which have not been made, a state of affairs which I'm not
>willing to endure for the next 5 years (yes, it's been that long since
>Adobe got that horrendous start with Frame 5.bug.x).

You have a point there.  We will see how Frame 7 does, Real Soon Now.

>(European) tech support doesn't even know that the Jap filters are
>there. At least they didn't give me that important piece of information
>when I ran into a brick wall with the standard RTF filters (the Word
>.DOC filters would just crash with files originating from Word 2002).

Very bad.  I'd flag this to the top of Adobe's tech support group.
 
>FYI: InDesign 2 now has tables, indices as well as XML tags (and XML
>import/export capabilities). PLUS adequate HTML and SVG output (also
>direct PDF 1.4 support). Wish I had some of that stuff in Frame!

Maybe you will in, oh, four months or so.  (I'm *not* under NDA.
Nor has anyone who is talked to me.  Amazon.com, however, makes
interesting advance announcements of new books... ;-)

>Taken together with a judicious use of MS Word for story editing (that's
>where cross-references, numbering formats and some other neat things
>come from) plus an intermediate script to transform layout tags from
>Word into InDesign equivalents, I'm almost where I want to be.

*Numbering* from *Word*?  You *do* like to live dangerously!  <bg>

>At long last I wouldn't have to endure Frame's ugly paragraph
>composition engine any longer but get beautiful typographic quality,
>including ligatures, old style figures etc. etc. etc.

Yes, this is InDesign's best feature: beautiful typography.  As
good as you could get with TeX, no small accomplishment!

>> "Nobody gets out of here alive."  <bg>  But in the
>> meantime, even with its infirmities, old FrameMaker 
>> still gets a Gold from me.
>
>I used to be a die hard frame user for about 10 years of my life. I
>certainly know what you're talking about! But I've lost my faith in
>Adobe, despite their noisy protests after Cringely stated Frame's demise
>about a year ago ("unfounded rumours", that's how they put it).

They were correct.  Cringely, well, he sells magazines...  ;-)

>Basically, I guess that InDesign will get most of the long document
>stuff before too many of the sub-standard features of Frame get fixed.
>This will make Frame even more of an endangered species than it is now.

Maybe, maybe not.  That's hard to say.  They *are* distinct
development groups, with different market foci, even if they
are both under Adobe's roof.  Even PageMaker, which I'd expect
to be the first casualty, is still being enhanced.

>FrameMaker certainly isn't dead today. It's more like a Zombie (if you
>like that metaphor, Adobe could be a vampire, feeding on the remaining
>substance of the product until it falls apart to ashes).

Yikes!  Let me offer a slightly different image.  Frame is
the aging UNIX hacker, sitting at his beloved Sun 3/50 and
coding in K&R C, which still works fine in a C++ world.  And
Adobe brings him his milk and cookies to keep him going, but
hesitates to drag him out to march in the big parade led by 
the spiffy InDesign synchronized skating team.  It's just
as well... ;-)

-- Jeremy H. Griffith, at Omni Systems Inc.
  (jeremy@omsys.com)  http://www.omsys.com/

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