🚀 go-pugleaf

As the Technical Support Manager at Frame Technology, a few postings
were forwarded to my attention regarding FrameMaker 2.0 and LaTeX.
A representative of our engineering department offers the following
in answer to this issue.

-------------------

Concerning recent messages about folks using FrameMaker-generated PostScript
in LaTeX:  Please remember that FrameMaker is a document compilation system.
Just as with Interleaf, Ventura, PageMaker, Quark, and every other document
compiler (including troff, TeX, and LaTeX), our PostScript is, of necessity,
designed to be printed.   Adobe has specified "Document Structuring
Conventions" to help provide standards in this regard, so that post-processing
can be done to reverse-print, or make folio plates, or automatically download
fonts on demand, etc. We attempt to comply with these standards so that we can
be "good citizens" in the printing world.

On the other hand, programs that create graphics images intended for inclusion
in other documents (everything from MacDraw and MacPaint on up) have a
different set of requirements.  In the PostScript world, it's best for these
applications to follow Adobe's "Encapsulated PostScript" specification, so
that they can be readily imported into documents managed by document compilers
such as FrameMaker, and be easily scaled, rotated, and (especially) printed on
a PostScript printer without any worry about interference between the image's
PostScript code and that of the document compiler's.  Again, we try hard to
make sure that FrameMaker is able to properly import Encapsulated PostScript
files.

What we don't do (and to the best of my knowledge, what Interleaf, Ventura,
PageMaker, Quark, troff, and certainly TeX/LaTeX also don't do) is to somehow
make our fully-paginated, printer-oriented PostScript output also behave as if
it were proper Encapsulated PS.  FrameMaker's output wasn't designed with this
goal in mind, nor does it appear on any "feature list" for our product, nor
has FrameMaker ever been advertised or otherwise officially represented as
being able to accomplish this difficult task. What we'd probably need to do
would be to add a feature whereby a single page of a FrameMaker document could
be output in Encapsulated PS format. Even if we had the resources to spec and
implement and test and support it, there are many other features that our
customers have asked for much more frequently that are higher priority to 
implement.

This is not to say that there aren't some customers who have made use of
FrameMaker's PostScript output in ways we hadn't planned for.  Due to the
design of the PostScript language, it's not too surprising that it is in fact
possible to extract sections of our output and be able to splice them into
other PostScript files.  It's quite doable with FrameMaker 1.3, and likewise
for FrameMaker 2.0.  No doubt there's a bit of hand-work to be done in both
cases, and some familiarity with the PostScript language is probably necessary
to figure it out the first time.  It's also undoubtedly going to be a different
procedure with FM 2.0's vs. FM 1.3's PostScript, since no attempt was made to
keep it the same.  On the other hand, the differences shouldn't be much, since
FM 2.0's PostScript is only different than FM 1.3's with regards to features
that were added to our 2.0 FrameMaker product that need improved printing
support (Bezier curves, rounded rectangles, unlimited font sizes, thumbnail
printing, registration marks, user-defined arrows, rotation, mixed page
orientation, full-color raster printing, spot color support, better paper size
support, etc.)  In the process of adding these features, it's not at all
surprising if we might affect some attribute of our PostScript output that we
don't test, don't support, and don't even consider.

On the other hand, if anyone points out a specific bug in our PostScript
output, we'd be very happy to hear about it and fix it as soon as possible.
And if anyone can provide us with specifications for how we can improve our
PostScript output so that it can be more useful in broader applications than
it was designed to handle while still fulfilling all our requirements for the
current uses and users that we have strong commitment to, then we'd be glad to
hear it.  Simply saying "It doesn't work with LaTeX" isn't sufficient for us
to do anything, since it's not a matter of LaTeX, it's a matter of which
DVI->PostScript interpreter is being used and what its requirements are in the
way of non-EPS PostScript inclusion.  There were a number of such programs
floating around last time I looked, each with different sorts of conventions,
and different sets of bugs, which certainly makes the problem even more
difficult.

Finally, I must take personal exception to remarks about "antisocial",
"unethical" and, "outright dishonest" behavior.  I'm personally responsible
for FrameMaker's PostScript output.  We have some of the highest-quality
PostScript output in the industry; it's compact, efficient, portable, and
fast.  Adobe's Green Book, the new Red Book, the Type 1 Fonts book, the
Illustrator '88 and other new Adobe product documentation are FrameMaker
PostScript files.  As it happens, my previous position was Manager of the
TeX Project at Stanford.  I spent eight years working for Prof. Donald Knuth,
helping to implement, debug, tune, distribute, and support TeX.  The very fact
that it's as easy as it is to get PostScript output out of TeX and LaTeX is
due in great part to the DVI output format I designed.  The notion that I
would somehow sabotage FrameMaker's PostScript so as to interfere with TeX
brings into question my professional conduct here at Frame, as well as my
loyalty to all my old friends in the TeX community.  A truly low blow.


David Fuchs
Frame Technology
drf@frame.com 

-------------

We continue to welcome your feedback about our FrameMaker product. If
you would like to send your comments to us directly, please feel free
to use the "comments@frame.com" address. This alias is monitored by
the Technical Support staff of Frame Technology.

Trish Dailey Mudgett
Frame Technology
tdm@frame.com