home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!torn!nott!cunews!revcan!ecicrl!clewis
- From: clewis@ferret.ocunix.on.ca (Chris Lewis)
- Newsgroups: comp.lang.postscript
- Subject: Re: Text formatters turn PostScript upside down -- why?
- Message-ID: <4023@ecicrl.ocunix.on.ca>
- Date: 23 Nov 92 02:06:30 GMT
- References: <4438@vidiot.UUCP> <4010@ecicrl.ocunix.on.ca> <4460@vidiot.UUCP>
- Organization: Elegant Communications Inc., Ottawa, Canada
- Lines: 56
-
- In article <4460@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes:
- >In article <4010@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
- ><
- ><This is really simply a matter of the guy writing the driver deciding
- ><which set of coordinates that he wants to think in. As a counter example,
- ><the PostScript that Psroff generates is right-side-up w.r.t. PostScript
- ><with no rotates, scales or translates of any kind. Then I didn't have
- ><to think about font transform matrices, and it only costs a subtraction
- ><in the driver. There is no real penalty, because psroff has to cope
- ><with multiple frame resolutions/orientations anyways.
-
- >Interesting point. Obviously it is easier to just change the spot on the paper
- >right before it is printed, than it is to flip everything over.
-
- I'm not sure whether it's easier or not. But when you already gotta
- mung coordinate systems to fit HP Laserjets, what's a little PostScript? ;-)
-
- >But here is an interesting thought. When I was supporting both Adobe
- >TranScript's psroff and groff, I kept the origin in the upper-left corner
- >when I included my own EPS files. If I would have used your Psroff, wouldn't
- >the default location be the lower-left corner? If so, that would mean my code
- >to position EPS file would be really different that what I used for psroff.
-
- But you aren't including EPSs. You're doing absolute PostScript positioning -
- no bounding box processing etc.
-
- >I have to admit that there was separate code to include PostScript files into
- >my final output because psroff and groff do it differently. But, the math to
- >position the output was the same.
-
- If the files you were including were EPS, and you were using groff's
- (or psfig's/DWB/Transcript) full blown EPS mechanism, you wouldn't need separate
- code no matter what coordinate system they were using...
-
- In fact, I include EXACTLY the same EPSs with my psroff and tpscript or
- psdit (each of which have different coordinate systems), pound thru psfig
- and the result is EXACTLY the same.
-
- That's what that bit of PostScript prolog that comes with psfig is for.
- It has to be tuned to the driver you have, then inserted into the
- driver's prolog. Then you have *complete* driver independence with
- your EPS inclusions. (the prolog is supposed to prepare an "environment"
- for the EPS, such that the EPS is all by itself, but translates and scales
- have been done to put it in the right place).
-
- >This isn't to say that your leaving the origin in the lower-left corner is
- >wrong, quite the contrary. My leaving the origin in the upper-left corner
- >isn't exactly right. It has actually come to haunt me a little bit.
-
- The origin in psroff's output is irrelevant. EPS are supposed to be independent
- of that. Your use of an origin of the upper left hand corner isn't "wrong"
- either. Your problem is that you're not using EPSs properly.
- --
- Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
- Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
- Ferret list: ferret-request@ferret.ocunix.on.ca
-