home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / fonts / 3822 < prev    next >
Encoding:
Text File  |  1992-12-31  |  6.5 KB  |  145 lines
  1. Xref: sparky comp.fonts:3822 gnu.misc.discuss:4124
  2. Path: sparky!uunet!pipex!warwick!uknet!gdt!aber!fronta.aber.ac.uk!pcg
  3. From: pcg@aber.ac.uk (Piercarlo Grandi)
  4. Newsgroups: comp.fonts,gnu.misc.discuss
  5. Subject: Re: "Hinting" using antialiasing? A GNUish alternative...
  6. Message-ID: <PCG.92Dec31122838@decb.aber.ac.uk>
  7. Date: 31 Dec 92 12:28:38 GMT
  8. References: <PCG.92Dec27213908@decb.aber.ac.uk>
  9.     <1992Dec27.225347.28173@pasteur.Berkeley.EDU>
  10.     <PCG.92Dec29154125@decb.aber.ac.uk>
  11.     <1992Dec29.193853.17902@pasteur.Berkeley.EDU>
  12. Sender: news@aber.ac.uk (USENET news service)
  13. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  14. Organization: Prifysgol Cymru, Aberystwyth
  15. Lines: 126
  16. In-Reply-To: johnm@cory.Berkeley.EDU's message of 29 Dec 92 19: 38:53 GMT
  17. Nntp-Posting-Host: decb.aber.ac.uk
  18.  
  19.  
  20. A point of order: I will eventually post a summary of the e-mail
  21. suggestions I have received. If any of my correspondents objects, please
  22. let me know; after all I did not say explicitly that I might do a
  23. summary. Thanks!
  24.  
  25. On 29 Dec 92 19:38:53 GMT, johnm@cory.Berkeley.EDU (John D. Mitchell) said:
  26.  
  27. johnm> The Nimbus font driver for GEOS is the fastest rasterizer
  28. johnm> implementation I've ever heard of, seen, and/or used for that
  29. johnm> class of hardware.
  30.  
  31. Some info about Nimbus? Some details about the rasterizer? :-)
  32.  
  33. pcg> For example I don't like the few seconds of latency that existing
  34. pcg> renderers make me wait while the rasterize the fonts contained in an
  35. pcg> imported document.
  36.  
  37. johnm> I'd say that it's most likely a matter of poor
  38. johnm> design/implementation of the ImpEx code rather than (just) a
  39. johnm> problem of the rasterizing of a bunch of fonts/characters.
  40.  
  41. No, because the delay does not appear when prebuilt bitmap fonts are
  42. used...
  43.  
  44. johnm> Perhaps the systems that you're using are doing something silly
  45. johnm> like building out all of the characters in each font that's used?
  46.  
  47. Neither, because it is easy to see a small pause as a previously unseen
  48. character is rasterized in each of the first few paragraphs; after the
  49. first few paragraphs virtually all the letters are done, so it's quick.
  50.  
  51. johnm> Fixed point arithmetic, when intelligently applied, is a great
  52. johnm> thing. :-? :-)
  53.  
  54. Quite so, but not so easy; I imagine from your smileys that you have had
  55. your little time with it.
  56.  
  57. johnm> Seriously though, I don't see any way of producing the kind of
  58. johnm> quality output that you desire without non-local contextual
  59. johnm> information and that must dramatically increase you resource
  60. johnm> needs.
  61.  
  62. Bah, I can only hope some sucker (maybe myself :->) sees to it that non
  63. local information filtering be not that slow. For example, instead of
  64. averaging a 4x4 cell to 1x1, one could do with 8x8 to 2x2; or indeed one
  65. could go for the really expensive and do 8x8 to 1x1. But it may be still
  66. be fast enough: I still think that simple bitmap sweeps might be more
  67. suited to current hardware than drawing a curve and then filling.
  68.  
  69. pcg> I think it would be more general because I guess it could be
  70. pcg> patterned after the rather universal properties of human vision;
  71.  
  72. johnm> The same argument as above.  Any typeface designer worth anything
  73. johnm> must take into account the biases and pecularities of human
  74. johnm> vision.
  75.  
  76. pcg> As agreed above, but they do so *manually* (and "unconsciously":
  77. pcg> they basically assume that what looks right to them looks right to
  78. pcg> everybody). I think instead that it can be done, with tolerably
  79. pcg> satisfying results, algorithmically.
  80.  
  81. johnm> I think this moves off into discussions about expert sytems and
  82. johnm> other AI shme.
  83.  
  84. Not really; I think more straight image processing; there is an amazing
  85. wealth of work that has been done on bitmap/pixmap filtering.
  86.  
  87. johnm> I do believe that many of the 'standard' tricks and rules of the
  88. johnm> human vision trade can be codified into algorithmic 'filters' but
  89. johnm> I don't see how that will be 'good enough'.
  90.  
  91. The only evidence I can offer are that automatically applied hints, as
  92. in FontoGrapher, are often 'good enough'; also METAFONT, see below.
  93.  
  94. johnm> As they say, knowing when to break rules is at least as important
  95. johnm> as the rules themselves.
  96.  
  97. Ah, but then this amounts to adjusting by hand the output bitmap for the
  98. very most elegant output; and for this I think that just doing that and
  99. recording the differences from the scaled one would do.
  100.  
  101. pcg> I like more what is done in METAFONT; there adaptation to the
  102. pcg> resolution and quirks of the intended output device is done by
  103. pcg> adjusting various parameters, like the shape of the "nib". This is
  104. pcg> virtually equivalent to choosing a different filtering algorithm
  105. pcg> (the "nib" is a filter!).
  106.  
  107. johnm> Hmm... Sounds interesting.  So instead of a single 'virtual' pen
  108. johnm> you can have a multitude of drawing tools?
  109.  
  110. Indeed; when the countour of the outline is drawn, this is done with a
  111. shaped "nib", and the size and characteristics of the nib can be
  112. adjusted; for example METAFONT will rasterize to different bitmaps
  113. depending on whether the output device is a write white or write black
  114. laser (something no outline rasterizer that I know can be parameterized
  115. about, except at times those embedded in the printer itself, that get
  116. hand-tuned and hardwired, but not always, to its characteristics -- even
  117. with Adobe, two printers with different technologies are more liable to
  118. give different results with Type 1 fonts than with METAFONT ones). An
  119. e-mail correspondent (Brian Bartolemew) observed:
  120.  
  121. Brian> I've long suspected metafont knows more about low resolution (~90
  122. Brian> dpi) than it lets on - witness the comments-in-passing about
  123. Brian> using diamond- shaped nibs instead of elliptical ones because
  124. Brian> they produce fewer artifacts at lower resolutions.
  125.  
  126. Indeed even CM fonts, which have fairly fine details, come out quite
  127. well at screen resolutions, without any hints whatsoever.
  128.  
  129. johnm> P.S.    I'm certainly for more/better 'free' scalable font
  130. johnm> technology and building this stuff on top of filters may or may
  131. johnm> not prove to be a good thing.  As an issue more relevant to the
  132. johnm> gnu side of this discussion, I worry that the 'filters' being
  133. johnm> 'programs' would thus be much easier to control (in the
  134. johnm> copyright/patent sense).
  135.  
  136. Ah yes, but virtually all the image processing techniques around are
  137. well known art, and thus free. Not that this has stopped anybody ever;
  138. as the comp.compression FAQ reports, RLE encoding has been patented in
  139. 1986...
  140.  
  141. --
  142. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  143.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  144.   alle orecchie del suo divino protettore, il dio della barzelletta
  145.