home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / postscri / 6091 < prev    next >
Encoding:
Text File  |  1992-12-23  |  3.1 KB  |  72 lines
  1. Newsgroups: comp.lang.postscript
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!sugar!ficc!peter
  3. From: peter@ferranti.com (peter da silva)
  4. Subject: Re: Justifying strings, how??
  5. Message-ID: <id.SM2W.B2K@ferranti.com>
  6. Organization: Xenix Support, FICC
  7. References: <zisk-181292180203@macne003.boston.us.adobe.com> <id.4D0W.BNH@ferranti.com> <1992Dec23.082549@eklektix.com>
  8. Date: Wed, 23 Dec 1992 20:09:12 GMT
  9. Lines: 61
  10.  
  11. In article <1992Dec23.082549@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
  12. > That is, it may appear that stringwidth is cheap under normal circumstances,
  13. > but if you didn't do corresponding show's afterward, it might look more
  14. > expensive.
  15.  
  16. Agreed, but we're doing this anyway.
  17.  
  18. > It's easy for the simple case, hard for the semi-sophisticated case, and
  19. > damned-near-impossible for the general case.
  20.  
  21. I'll buy that, but some meatball AI (clever choice of algorithms) on the
  22. host side can reduce these to cases where the tradeoffs are clearer.
  23.  
  24. > Is the cost of parsing and managing it separated from the cost of trans-
  25. > mitting it?
  26.  
  27. Should it be? If the file is physically larger if the host does the
  28. details of the spacing, and this slows things down, does it matter whether
  29. it's the parsing or the transmission?
  30.  
  31. > >Personally, I would prefer it if programs made decisions like this as late
  32. > >as possible, so I can print a document with a different font (say, my printer
  33. > >doesn't handle Palatino and the company is too cheap to buy a softfont)
  34. > >without screwing things up too badly.
  35.  
  36. > This would be nice, and it works for simple documents, but how far can you
  37. > carry it?
  38.  
  39. Pretty far... certainly typical technical documentation is going to be
  40. better off.
  41.  
  42. > My experience is that it works for *very* simple stuff, but you
  43. > hit the wall before you get all you want.  Here's where it goes:  If you
  44. > chnage the font, you change the line breaking, which requires hyphenation
  45. > on the printer side.
  46.  
  47. Typically I'm switching between Palatino and Times or New Century Schoolbook,
  48. which are fairly close... close enough that it's only mildly annoying when
  49. I print man pages. I wouldn't want to do it to Courier or title fonts, but I
  50. wouldn't want to set running text in them anyway. Currently, I get soething
  51. like:
  52.  
  53.     The frobnitz command generates      a five sided    polygon
  54.     in the  interior of the    circle,  if you are using the
  55.     deep mode...
  56.  
  57. I can get better output from nroff! Just proportionally spacing the words in
  58. the line without any further modification would make the difference between
  59. soething I can use and soething that gives me headaches.
  60.  
  61. (ideally, the docs should be raw text but that seems to have fallen out of
  62.  favor)
  63.  
  64. It's like the difference between a program that uses hardcoded paths and one
  65. that uses environment variables. Sure, it takes a little longer to look up
  66. environment variables, but the result is a higher quality program.
  67. -- 
  68. Peter da Silva                                            `-_-'
  69. Ferranti International Controls Corporation                'U` 
  70. Sugar Land, TX  77487-5012 USA
  71. +1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
  72.