rb@acsu.buffalo.edu (rick bidlack) (09/15/90)
Rick Bidlack rb@acsu.buffalo.edu
n67786@lehtori.tut.fi (Nieminen Tero) (12/18/90)
Yes, it should be possible to build a program that is able to parse EPS files, provided they do not contain any fancy stuff, but are in principle like the ones produced by Adobe Illustrator. They sure enough do not contain any fancy Post Script pogramming tricks. Those primitives could be interpreted so that the program could display the picture in a way that makes editing easy (like the handles in Illustrator). Anyway, most of the time (at least in the Macintosh world), the PS files begin with a dictionairy that redescribes most of the used drawing primitives in one letter "short hand form". This editor program must be capable of interpreting these dictionaries too. After that the Post Script should be fairly standard so that different elements of the pictures could be displayed graphically on the screen. Text elements could be interpreted like Illustrator does it and so forth. All you have to know is the different primitives there are in the files you are supposed to edit. Also the programs might use some sort of grouping command (of which I'm not quite sure--that might be contained in the comments where they do not disturb). Actually this all would end up beeing something I have been longing after for so long; actually since after the Post Script standard emerged. It would be immensely useful utility. Often it's not very major changes that you need to make to pictures from other sources, more like just slight modifications. And so far nobody has had the courageous to do such an program. Maybe cause it would effectively defeat the purpose of bying just those particular commercial programs to edit the pictures in the first hand (ie. be less profitable for the big companies). Also I'm not completely sure of what sort of pitt falls there might be lurking around. Anyway, for a knowledgeable programmer with a decent set of tools such an project should not prove to be too difficult (if not the lack of documentation on the format turned out to be too big an obstacle--they're more or less proprietary). -- Tero Nieminen Tampere University of Technology n67786@cc.tut.fi Tampere, Finland, Europe
aberno@questor.wimsey.bc.ca (Anthony Berno) (12/19/90)
Thank you to everyone who responded to my message about EPS non-editability. However, I still think there is hope. So PostScript is like a full language, with routines and data structures and such. Well, the thing is, when you print an EPS file, you *generally* get a single, fixed, result, right? There are some exceptions - like those silly new "random" fonts, but generally, you get the same output if you do it twice in a row. As such, that output should be made up out of primitives, like squares, polygons, bitmaps, Bezier curves, etc. Well, suppose you wrote a program that simulated an EPS file printing out, but didn't send the results to the printer. Instead, it intercepted them, and converted the print calls into things like polygons or letters or bezier curves in some common, sensible format. Unless you simply CAN'T get at the output of the EPS file until it has been converted all the way to a bitmap, just about anything should be interpretable as a small set of graphics primitives. Any comments here? I don't know hoot about PostScript, but I would be most interested in learning it and doing just this when I get my NeXT.
mwu@teri.bio.uci.edu (Matt Wu) (12/19/90)
In article <c4sDu1w163w@questor.wimsey.bc.ca> aberno@questor.wimsey.bc.ca (Anthony Berno) writes: > Well, suppose you wrote a program that simulated an EPS file > printing out, but didn't send the results to the printer. > Instead, it intercepted them, and converted the print calls > into things like polygons or letters or bezier curves in some > common, sensible format. I suppose it's possible ... however, I think the result would be an application similar to Adobe Streamline, albeit one that creates images with greater fidelity. Since it is difficult to tell (without guessing) what lines you want grouped together (like eyes, nose, mouth as part of a face), the files that such a program would generate would probably not be as easily editable as you might want. This would not be an ideal solution, but it'd certainly be better than starting all over again. The easiest way to go about this would be to go through and try to figure out what all the full paths are and make them groups. Unfortunately, if an application you use produces highly inefficient or convoluted input (drawing colorless lines instead of starting a new rectangle) you might end up with kind of weird paths. Also, programs that are computation intensive (like doing lots of calculations to find out the placement of objects, especially text) could cause highly undesirable results. For example, the characters of a sentence that fits a curved line might appear as individual objects. I don't know. It sounds kind of inefficient. Does anybody know why the industry standard for page description is a computer language (based on Forth of all things to choose from)? I still think it would be much easier to represent everything as objects, especially where interchange is concerned. From my experience with postscript files, the language aspects just get in the way; I think it'd be much easier to describe a rectangle fifty times than it would be to have a loop that drew the same rectantle fifty times, especially if, in my draw program, I decide to move a few of them around, delete a few of them or transform a few of them. Anyway, compress it and the space efficiency might be similar. Fortunately (for me), though, the only stuff I tend to reuse is in Illustrator format, which should not be a problem when Illustrator for the NeXT comes out. Matt Wu mwu@teri.bio.uci.edu
gillies@m.cs.uiuc.edu (12/19/90)
Someone has written a small piece of postscript called "distillPS".
This code rebinds the low-level postscript primitives (like moveto and
line) on the printer to stub primitives which just output the
primitive itself (back to the downloading program). Thus, all the
loops, variables, re-bindings, transforms, etc. are eliminated when
you download your program to print, and "DistillPS" in turn uploads a
simple static postscript program suitable for display on the most
stupid and memory-limited of postscript printers.
It would not be hard to translate the result into any other picture
language (i.e. PICT or Impress or whatever) since this program
distills out all the junk ("stripped" does not accurately describe the
process).
You need is a printer with REAL postscript to run the distill program,
however, the NeXT seems to qualify.robertw@informix.com (Rob Weinberg) (12/21/90)
In article <c4sDu1w163w@questor.wimsey.bc.ca> aberno@questor.wimsey.bc.ca (Anthony Berno) writes: >Thank you to everyone who responded to my message about EPS non-editability. >However, I still think there is hope. > >So PostScript is like a full language, with routines and data structures >and such. Well, the thing is, when you print an EPS file, you *generally* >get a single, fixed, result, right? There are some exceptions - like those >silly new "random" fonts, but generally, you get the same output if >you do it twice in a row. > >As such, that output should be made up out of primitives, like squares, >polygons, bitmaps, Bezier curves, etc. Well, suppose you wrote a program >that simulated an EPS file printing out, but didn't send the results to >the printer. Instead, it intercepted them, and converted the print calls >into things like polygons or letters or bezier curves in some common, >sensible format. I think you could extend your exploration of PostScript by getting hold of a file created by Adobe Illustrator, and opening it from any word processor. After all, such a file is just a long text file, a PostScript program. What you WON'T find in the Illustrator file are many PostScript primitives. At the start of the file, you will find a long header. PostScript encourages the programmer to create definitions from the primitives, and to build on these to create other definitions, etc. Then, by the time a program such as Illustrator gets to the point where it needs to translate your mouse clickings and sketchings into code, it can call on these definitions to quickly generate compact code. Anyway, I know little more about PostScript then you do; but you might enjoy dissecting an Illustrator file, and get some idea of why it is not so easy to take any PostScript file and "reduce" it to editable primitives. And, an EPS file can consist of big, inscrutible bitmaps whose only "primitives" are definitions of points on a page. Also, the primitives which describe the shapes of letterforms of the fonts used by a PostScript file are contained in the fonts themselves, which reside in the printer's ROM or in seperate printer font files, not in the PostScript graphic file itself which is sent to the printer. Just take whatever PostScript files you can find lying around and poke into them a bit, and you will see some interesting things.