home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / fonts / 3831 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  3.9 KB
  1. Xref: sparky comp.fonts:3831 gnu.misc.discuss:4125
  2. Newsgroups: comp.fonts,gnu.misc.discuss
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!pasteur!cory.Berkeley.EDU!johnm
  4. From: johnm@cory.Berkeley.EDU (John D. Mitchell)
  5. Subject: Re: "Hinting" using antialiasing? A GNUish alternative...
  6. Message-ID: <1993Jan1.074250.21177@pasteur.Berkeley.EDU>
  7. Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster)
  8. Nntp-Posting-Host: cory.berkeley.edu
  9. Organization: University of California, at Berkeley
  10. References: <PCG.92Dec29154125@decb.aber.ac.uk> <1992Dec29.193853.17902@pasteur.Berkeley.EDU> <PCG.92Dec31122838@decb.aber.ac.uk>
  11. Date: Fri, 1 Jan 1993 07:42:50 GMT
  12. Lines: 81
  13.  
  14. In article <PCG.92Dec31122838@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo
  15. Grandi) writes:
  16. >On 29 Dec 92 19:38:53 GMT, johnm@cory.Berkeley.EDU (John D. Mitchell) said:
  17.  
  18. [...Re: Summary posting notice...]
  19. Fine by me.
  20.  
  21. [...]
  22. >Some info about Nimbus? Some details about the rasterizer? :-)
  23.  
  24. Nimbus... As in URW Nimbus typefaces/fonts.  It's got a fairly
  25. straightforward layout and the GEOS version of the file format has been
  26. tweaked for speed.  The GEOS version of the driver works with the tweaked
  27. files and is completely written is heavily optimized 8086 assembly
  28. language.
  29.  
  30. [...Rasterizer speed shme...]
  31. >Neither, because it is easy to see a small pause as a previously unseen
  32. >character is rasterized in each of the first few paragraphs; after the
  33. >first few paragraphs virtually all the letters are done, so it's quick.
  34.  
  35. Okay, so it really is the fault of slow rasterizers. :-)  Could be an
  36. inherently poorly designed format and/or poorly implemented rasterizer for
  37. that particular platform.  I assume it's obvious that I don't believe that
  38. this has to be true for a well designed format and quality implementation.
  39. :-) 
  40.  
  41. >johnm> Fixed point arithmetic, when intelligently applied, is a great
  42. >johnm> thing. :-? :-)
  43. >Quite so, but not so easy; I imagine from your smileys that you have had
  44. >your little time with it.
  45.  
  46. Naw, somebody had already done all of the nasty work. :-)
  47.  
  48. [...Non-local context needed?...]
  49. >Bah, I can only hope some sucker (maybe myself :->) sees to it that non
  50. >local information filtering be not that slow. For example, instead of
  51. >averaging a 4x4 cell to 1x1, one could do with 8x8 to 2x2; or indeed one
  52. >could go for the really expensive and do 8x8 to 1x1. But it may be still
  53. >be fast enough: I still think that simple bitmap sweeps might be more
  54. >suited to current hardware than drawing a curve and then filling.
  55.  
  56. Hmm... I'm also thinking of problems that involve very non-local
  57. information such as symmetry.  Though now that I think about it, it's
  58. probably not something that needs to be worried about.
  59.  
  60. [...Vision expertise necessitates AI?...]
  61. >Not really; I think more straight image processing; there is an amazing
  62. >wealth of work that has been done on bitmap/pixmap filtering.
  63.  
  64. Probably a good indication that I don't know squat about this side of
  65. things. :-)
  66.  
  67. [...]
  68. >The only evidence I can offer are that automatically applied hints, as
  69. >in FontoGrapher, are often 'good enough'; also METAFONT, see below.
  70. >
  71. >johnm> As they say, knowing when to break rules is at least as important
  72. >johnm> as the rules themselves.
  73. >
  74. >Ah, but then this amounts to adjusting by hand the output bitmap for the
  75. >very most elegant output; and for this I think that just doing that and
  76. >recording the differences from the scaled one would do.
  77.  
  78. Okay, so you have your 'hints' for the filters too.  I'll buy that.
  79.  
  80. [...METAFONT information...]
  81.  
  82. Very interesting.  I'll have to go study up.  :-)
  83.  
  84. [...Filter 'programs' == less 'freedom' for implementors?...]
  85. >Ah yes, but virtually all the image processing techniques around are
  86. >well known art, and thus free. Not that this has stopped anybody ever;
  87. >as the comp.compression FAQ reports, RLE encoding has been patented in
  88. >1986...
  89.  
  90. They are either free or somebody has already patented them.  Sigh.
  91.  
  92. Happy New Year,
  93.     John
  94.     johnm@cory.Berkeley.EDU
  95.