home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / postscri / 5660 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  3.4 KB

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