jayem@quiche (Jean Marc MONTI) (06/01/90)
This request was already posted to comp.text.desktop... I guess it has already been posted in this group also so I apologize for the redundancy. Here it goes: So far we've been using FrameMaker 1.3 to make figures, storing them in postscript files, and using psfig to include them in LaTeX. Then, we run dvi2ps and we have a postscript file containing both images and text. We just received FrameMaker 2.0, and we have been unable to use the same technique and the figures don't get printed anymore. Would anybody out there know why is this ? Does v2.0 generate something that psfig can't understand ?? Where do things go wrong ?? Lastly, is there a fix ?? thanks a lot Jean-Marc jayem@calvin.cs.mcgill.ca
etan@tellab5.tellabs.com (Nate Stelton) (06/04/90)
In article <3503@calvin.cs.mcgill.ca> jayem@quiche.cs.mcgill.ca (Jean Marc MONTI) writes: >So far we've been using FrameMaker 1.3 to make figures, storing them in >postscript files, and using psfig to include them in LaTeX... >... FrameMaker 2.0, and we have been unable to use the same >technique and the figures don't get printed anymore. Would anybody out >there know why is this ? Does v2.0 generate something that psfig can't >understand ?? Where do things go wrong ?? Lastly, is there a fix ?? It does seem that Frame changed something about the way they save PostScript files. We do a similar thing with FrameMaker and Eroff, and encountered a similar problem. I assume that the problem you are having is that the PostScript file is an 8.5X11 page overlaying the parent document and "whiting" large portions of the page or printing somewhere off the page. This seems to occur on "real" PostScipt devices, but not on our UltraScript QMS printer. One thing I did as an experiment (which worked) was this: 1. In FrameMaker, pull up the print menu. 2. As usual, check the "print to .ps file" box. 3. Set the page height to .1" instead of the default 11". You may have to change the position at which psfig places the imported PostScript "page" onto the real page. I realize that this isn't much of a solution, but it may provide some insight in the problem. I seems that the proper solution (at least for Eroff applications) would be for FrameMaker to be able to save to EPS, or for the importing software to be able to crop the incoming page. I'm just a dumb customer sharing some meager observations. Does anyone from Frame or Elan, or perhaps a LaTeXpert, have any further comments or assistance? etan
mario@madarch.man.ac.uk (Mario Wolczko) (06/06/90)
In article <3503@calvin.cs.mcgill.ca>, jayem@quiche (Jean Marc MONTI) writes: > So far we've been using FrameMaker 1.3 to make figures, storing them in > postscript files, and using psfig to include them in LaTeX. Then, we run > dvi2ps and we have a postscript file containing both images and text. We > just received FrameMaker 2.0, and we have been unable to use the same > technique and the figures don't get printed anymore. Would anybody out > there know why is this ? Does v2.0 generate something that psfig can't > understand ?? Where do things go wrong ?? Lastly, is there a fix ?? We have encountered exactly the same problem. In 2.0, the folks who wrote it were kind enough to ensure that no matter what you do, the PostScript generated by Maker cannot be included in another document, because it messes with global things. It also carefully obliterates part of the page before drawing anything. When I called our support number about this, at first I couldn't get them to understand what on earth I was talking about ("Why not stop using LaTeX anyway?"), and then they said it wouldn't be fixed. If anyone from Frame is out there, *please fix this*. It's antisocial to produce PostScript that cannot be imported. Unfortunately, I can find no easy-to-apply fix. First, you have to get rid of the lines that look like this: manualfeed {true} {papersize} ifelse {manualpapersize} {false} ifelse {desperatepapersize} if (These are in /FMDOCUMENT.) Then, you have to get rid of some of the lines that are at the beginning of your diagram. These seem to vary from diagram to diagram, so you'll have to experiment. Here's an example from one of my drawings: 612 792 0 FMBEGINPAGE 0 0 612 792 C 0 0 612 792 R 7 X 0 K %V %72 746 540 756 R %V %72 32.67 540 42.67 R %V %72 72 540 720 R %V 90 450 36 18 125.57 630 G 1 H 0 Z 0 X I have commented out some of the lines. Best of luck. Mario Wolczko ______ Dept. of Computer Science Internet: mario@cs.man.ac.uk /~ ~\ The University USENET: mcsun!ukc!man.cs!mario ( __ ) Manchester M13 9PL JANET: mario@uk.ac.man.cs `-': :`-' U.K. Tel: +44-61-275 6146 (FAX: 6280) ____; ;_____________the mushroom project___________________________________
zmls04@trc.amoco.com (Martin L. Smith) (06/06/90)
In article <1307@m1.cs.man.ac.uk> mario@madarch.man.ac.uk (Mario Wolczko) writes:
..... discussion of difficulty importing FrameMaker 2.0 PS files into LaTeX
We have encountered exactly the same problem. In 2.0, the folks who
wrote it were kind enough to ensure that no matter what you do, the
PostScript generated by Maker cannot be included in another document,
because it messes with global things. It also carefully obliterates
part of the page before drawing anything. When I called our support
number about this, at first I couldn't get them to understand what on
earth I was talking about ("Why not stop using LaTeX anyway?"), and
then they said it wouldn't be fixed. If anyone from Frame is out
there, *please fix this*. It's antisocial to produce PostScript that
cannot be imported.
I think it's a lot worse than antisocial. It is at least unethical,
maybe outright dishonest. If the manufacturer is doing this on
purpose than he is deliberately sabotaging his own customers.
My own employers (for whom I do not speak) are currently looking over
Frame and some other DTP packages. If Frame's makers are deliberately
crippling their product to prevent us from using it as a generic tool
to produce PS files (and I regard unwillingness to correct such a
severe shortcoming as "deliberate"), then I think it will not be too
difficult to ensure that, whatever we end up using, it will not be
FrameMaker.
--
Martin L. Smith Amoco Research Center
P.O. Box 3385
zmls04@trc.amoco.com Tulsa, OK 74102
[zmls04@sc.msc.umn.edu] 918-660-4065tdm@frame.UUCP (Trish Mudgett) (06/13/90)
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
spqr@ecs.soton.ac.uk (Sebastian Rahtz) (06/13/90)
David Fuchs writes about Framemaker & PostScript:
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.
.
.
.
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.
I haven't really followed this debate, because I don't use Framemaker,
and do not understand why people want to put its output into LaTeX,
but I think David Fuchs isn't entirely correct in his statements:
1) There are several dvi to PS converters that generate good robust
encapsulated PostScript; I have included output from dvitops, for
instance, back into a LaTex document, and into Illustrator (and
thence back into LaTeX)
2) Pagemaker appears to me to produce pretty acceptable EPS output; I
often use it to wrap up Macdraw pictures for inclusion into LaTeX.
Mind you, I think Fuchs' conclusion (`blame the dvi to PS program
not my PS) is probably not a bad one. There are still a lot of
inadequate dvi to PS programs out there.
Sebastian Rahtz
--
Sebastian Rahtz S.Rahtz@uk.ac.soton.ecs (JANET)
Computer Science S.Rahtz@ecs.soton.ac.uk (Bitnet)
Southampton S09 5NH, UK S.Rahtz@sot-ecs.uucp (uucp)dbs@dbsmax.enet.dec.com (dan sears) (06/14/90)
The Adobe PostScript file server has a script for fixing Frame 2.0 files.
The directory has the following introduction:
fixFM.script 889 Mar 23 17:16
This is a simple UNIX shell script that uses awk to fix PostScript
language files that are produced from Frame Maker 2.0 on the Sun.
The problem is that the files generated are not page independent
and therefore fail to execute properly in some environments where
page independence is strictly enforced (such as the NeXT preview
app). This program is NOT a general purpose fix-up program. It
ONLY works for file generated from Frame Maker 2.0 on the Sun.
Try sending a mail message to ps-file-server@adobe.com with
this line: "send Programs fixFM.script".
--Danmario@madarch.man.ac.uk (Mario Wolczko) (06/15/90)
In article <3762@frame.UUCP>, David Fuchs (drf@frame.com) explained Frame Technology's position regarding the production of PostScript from FrameMaker. In summary, his position was that FrameMaker is for document compilation, and hence need not produce Encapsulated PostScript. Further, he states that Frame Technology has never advertised their product as being able to do this. First, thanks for the response. Second, I agree that FM was never advertised as doing this, and hence the strongest word I used in my posting was "antisocial". The key statement in his his response seems to be: > 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. People will always do this. If we as a site have invested in 10 FM licenses (which we have), it is because we thought we were buying a versatile and well-made product (which it is). Two aspects of that product are: - it has a pretty good graphics editor - it produces PostScript An obvious possibility then is that the graphics editor could be used to produce PostScript diagrams, subsequently to be imported into a different system (in our case LaTeX). Note that we did not *expect* this to be an absolutely smooth process, because, as David rightly says, it was not advertised as a feature. However the realities of life are such that all PostScript --- even that designed to be printed --- may have to be processed in some way. Examples I can think of are doing "n-up" printing and page re-ordering. The PostScript language and the structuring conventions were designed exactly with this in mind. There are bound to be others that I have not thought of --- nobody can anticipate all the possibilities. Hence, it would seem only sensible for a company like Frame Tech. to design its product so that it can be used in cooperation with other tools, ie for it to be in some way "open". Having your PostScript importable seems to me to be one of the smallest ways in which they can do this. Indeed, in 1.3 things *could* be imported with only minor effort (the %%BoundingBox values had to be edited). Clearly, you have already done this to some degree (eg, your pages can be reordered) ... why not go the whole way? To me this just makes sound business sense: your customers are happier, and some of them (here, mostly LaTeX users) get to use your product who otherwise wouldn't. Your position seems to be almost encouraging us to go out and buy a different package for this purpose; surely you want as many FM users as possible? Arguing that other products don't do it really doesn't wash: as Sebastian Rahtz has pointed out, some do (or get darned close). Anyhow, even if they didn't, wouldn't this give your product an edge? > Finally, I must take personal exception to remarks about "antisocial" > [...] behavior. This was not intended as a personal slight. But I still feel it's antisocial to say "we'll take anybody's (encapsulated) PostScript but we won't let anybody else take ours". It isn't that hard to make EPSF; surely one option to output a single page in that format wouldn't be too hard to provide? Then again, I may not need it now that a fix has been placed on the Adobe server... Mario Wolczko ______ Dept. of Computer Science Internet: mario@cs.man.ac.uk /~ ~\ The University USENET: mcsun!ukc!man.cs!mario ( __ ) Manchester M13 9PL JANET: mario@uk.ac.man.cs `-': :`-' U.K. Tel: +44-61-275 6146 (FAX: 6280) ____; ;_____________the mushroom project___________________________________