sxm@bebop (Sandeep Mehta) (02/21/90)
In article <1990Feb20.235243.21897@Neon.Stanford.EDU>, rokicki@Neon (Tomas G. Rokicki) writes: >It is becoming increasingly obvious that the future of graphics with TeX >(and virtually anything else for that matter) is in PostScript graphics. couldn't agree more. >All that lacks is the appropriate connection between TeX and PostScript. >All TeX previewers and printer drivers should be retrofitted with some >sort of communication to a PostScript interpreter so that included >graphics can be rendered automatically, easily. i would think NeWS would be an appropriate platform for this. assuming that the included PostScript code downloaded through the connection to the NeWS server can be rendered (i.e., the server doesn't choke on some operators etc.). doing it under X or something assumes that a full fledged PostScript interpreter can efficiently reside between the display server and the client TeX tool. >output can be easily integrated. (And Apple and Microsoft should hire >some competent people to revise their awful prologs.) > so far i (and some others) have been satisfied with Trevor Darrell's psfig macro package (and dvi2ps/dvips). it works with most WYSIWYG drawing editors and other pd tools (actually it is broken with FrameMaker 2.0 :-(). the best one can hope for in a previewer, at present, is displaying reserved space. since the graphic has been edited WYSIWYG this is just about liveable. i think that something more robust and standard is on order. else, i wonder how TeX/LaTeX will fare under the onslaught of niftier WYSIWYG systems. sandeep -- sxm@philabs.philips.com ...to be or not to bop ?
beck@hermod.cs.cornell.edu (Micah Beck) (02/21/90)
In article <1990Feb20.235243.21897@Neon.Stanford.EDU> rokicki@Neon.Stanford.EDU (Tomas G. Rokicki) writes: >It is becoming increasingly obvious that the future of graphics with TeX >(and virtually anything else for that matter) is in PostScript graphics. Well, you're half right. PostScript is half of a solution - the back end. However, a document described in PostScript cannot necessarily be manipulated in any way except to be printed. For instance, it is not in general possible to edit a PostScript file in a structured way (ala MacDraw, Fig, etc..) The worst case: text which has been written in TeX, translated to PS, and included as part of a figure cannot be edited in LaTeX, or even roughly translated back to TeX. Same for structured graphics objects. What's needed is a standard application-level representation for graphics, and a good standard translation from this to PostScript. Representing all graphics in PostScript is like writing all programs in assembly language! /micah
alberto@konark.cs.umd.edu (Jose Alberto Fernandez R) (02/22/90)
<<
What's needed is a standard application-level representation for graphics,
and a good standard translation from this to PostScript. Representing
all graphics in PostScript is like writing all programs in assembly language!
>>
I have been using Fig to create my graphics and the transfig package
to translate it to diferent outputs. I have used PiCTeX, EPic and
EEPic, there are also output to PostScript and directly to LaTex if
your figure is simple.
The advantage of this is that my DVI files are not printer dependent
if I don't want it to be. This means that I can generate the same
document using only DVI primitives (resulting in a bigger file) and
being able to reproduce it everywhere or generate a PS version only
for my local printer.
Are there any other tools that have this flexibility? The problem I
have is that the XFIG program version 1.4.3 to create the output has
lots of bugs.
Jose Alberto.
--
:/ \ Jose Alberto Fernandez R | INTERNET: alberto@cs.umd.edu
:| o o | Dept. of Computer Sc. | BITNET: alberto@cs.umd.edu
:| ^ | University of Maryland | UUCP: {...}!mimsy!alberto
:\ \_/ / College Park, MD 20742 | dhosek@jarthur.Claremont.EDU (dhosek) (02/22/90)
Just as an informational point, there is a committee established
by TUG, of which I am the chair, which is dealing with DVI driver
standardisation. The issue of graphics inclusion has been discussed
in the past (and it's a far more complicated issue than it appears
on the surface) and I plan to instigate further discussion towards
establishing a preliminary standard on this issue for the TUG
conference in July. I will be posting a follow-up note on the committee
itself later this week.
If you're not already a TUG member, you should join, btw. For more
information:
TeX Users Group
P.O. Box 9506
Providence, RI 02940-9506 USA
401-751-7760
tug@math.ams.com
-dh
--
"Odi et amo, quare id faciam, fortasse requiris?
nescio, sed fieri sentio et excrucior" -Catullus
D.A. Hosek. UUCP: uunet!jarthur!dhosek
Internet: dhosek@hmcvax.claremont.edu