From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.fonts,gnu.misc.discuss
Subject: "Hinting" using antialiasing? A GNUish alternative...
Date: 13 Dec 92 19:51:05 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth


I have been very impressed with the excellent apparent resolution that
antialiasing (gray levels) gives using xdvi to preview TeX output on an
X server. I also know that antialiased fonts are used also in the Acorn
OS, to much good effect.

I have been wandering if, via antialiasing, one can achieve the same
effect as "hinting" in a different way, and secondly, if the high
desirability of antiliased bitmaps means that Type 1 is a more
appropriate than TrueType for outlining.

  The latter point can be argued as follows: given that Type 1 assumes
  that the hinting is done by the renderer, antialiased font pixmaps are
  likely to be easier to derive from Type 1 outlines than from TrueType
  programs, whose hinting algorithms are simply not designed for
  grayscaling. On the other hand, now that I think of it, antialiasing
  on the average 16-256 graylevels/colors display gives such an apparent
  increase of resolution that hinting probably is not important at all.


			THE MAIN ARGUMENT

Put very simplistically, when one uses an outline to generate a
character bitmap at some low resolution, hinting either deforms the
outline or patches up the bitmap so that its optical characteristics
look better to the human eye.

In a sense antialiasing does exactly the same; then it would be possible
maybe to generate a "perfect" bitmaps, saay at 600 DPI, antialias it to
the desired resolution, say 100 DPI, and then apply a filter to the
antialiased version to turn it into a B&W bitmap with similar optical
properties (naturally one could just filter the 600 DPI bitmap
directly). I guess that then "hinting" then reduces to designing the
appropriate filters to compress high resolution (say 600 DPI) bitmaps
into lower resolution ones.

The advantage to using filters on bitmaps is that one need not start
with an outline at all; it would be possible to have as starting point
not outlines but those high resolution bitmaps, drawn once and for all,
and then reduce them to the appropriate resolutions. This has some
advantages:

* Font bitmaps are, in some important countries at least, public domain,
  whereas font outlines, being "programs", can be copyrighted.

* From a single set of bitmaps once can derive all sort of lower
  resolution ones, I think much quicker than using outlining, as,
  for example, there would be no need to do curve fitting, i.e. to use
  FP arithmetic (curves _can_ be drawn without FP, but it's harder to
  program). There is admittedly some difficulty if the original and
  target lattices are not a convenient integral multiple of each other,
  but then that's "just" a harder filtering problem.

* Writing a good filtering/compressing renderer would be particularly
  much easier than a Speedo/Type 1/TrueType renderer. Indeed most of the
  relevant code are already in xdvi and in the bitmap type scaler in
  X11R5. Also, there is that interesting HP contribution to X11 R5 that
  adds typeface deformation abilities.

* It is particularly easy to derive low resolution grayscaled anti
  aliased pixmap fonts, and they, given the current preponderance of
  color and grayscale displays on workstations/pcs, should become the
  norm, rather than the exception, as they are now.


			POSSIBLE OBJECTION

Just about the major defect I can imagine in my innocence (I am sure to
be put right by all the people in comp.fonts which know more than me on
font technology) is that arguably 600 DPI (arguably the best resolution
for this -- but one could well use 2400 DPI ones) font bitmaps would
take quite a bit more space than outlines; to this I would counter that
heavily hinted fonts are fairly huge. Let's see...  Uhmm, this is a
list of plain cmr fonts for TeX and their sizes in bytes:

		compressed			uncompressed

	bytes	fontPoints.DPIpk	bytes	fontPoints.DPIgf

	5488	cmr10.300pk		16916	cmr10.406gf	
	5904	cmr10.329pk		18212	cmr10.445gf	
	7812	cmr10.432pk		23464	cmr10.585gf	
	11496	cmr10.622pk		32860	cmr10.842gf	
	13908	cmr10.746pk		19740	cmr12.406gf	
	6432	cmr12.300pk		27384	cmr17.406gf	
	9088	cmr17.300pk		9368	cmr5.406gf	
	12580	cmr17.406pk		11028	cmr6.406gf	
	3424	cmr5.300pk		12448	cmr7.406gf	
	3780	cmr6.300pk		23540	cmr7.842gf	
	4256	cmr7.300pk		14036	cmr8.406gf	
	8092	cmr7.622pk		15660	cmr9.406gf	
	4624	cmr8.300pk
	4932	cmr9.300pk

Even the larger sizes at the larger point sizes don't look threatening,
even uncompressed. Some/most hinted TrueType fonts are 50-60KB. Indeed,
let's check: a set of compressed cmr bitmaps at 300 DPI for point sizes
5,6,7,8,9,10,12,17 is 42KB; 300 DPI should be sufficient for both
printing and displaying on most current PCs and workstations.

Going to 600 DPI bitmaps is less easy for me now to calculate, because
the only two I can see above are the 7 and 10 point sizes, which are
twice as large (not four times -- compression counteracts that, as going
to higher resolution mostly lengthens the runs of black and white dots)
as the 300 DPI ones. Taking this ratio as good then cmr at 600 DPI would
be a total of 84KB, which does not look bad at all, considering that one
gets purpose built bitmaps for the smaller and more critical point
sizes.

			SUMMING UP

So, if I am not entirely wrong on the following points:

* Filtering high resolution bitmap fonts into lower resolution
  grayscale pixmaps is easy, very quick, and gives excellent apparent
  resolution, better than outlining + hinting, even with naive
  algorithms.

* Most current PCs/Workstations have color/grayscale displays and
  300 DPI (or at most, now, 600 DPI) printers, and thus it would
  be possible to just keep around relatively small printer resolution
  bitmaps and then compress them to display form, usually grayuscale,
  for previewing.

* Filtering high resolution bitmap fonts into lower resolution
  bitmaps (possibly passing thru the intermediate step of producing
  pixmaps at that resolution first) can be made to give goodf quality
  results,  probably similar to outlining + hinting, given relatively
  easy but not entirely naive filtering algorithms.

* The storage needed for high resolution bitmaps is not significantly
  larger than that needed for hinted outlines.

* Freeware code already exists to do BW->AA reduction (in xdvi), and
  naive, improvable code exists to do BW->BW reduction (in xdvi again,
  and in the MIT sample X server code), and it would hopefully not be
  difficult to actually improve on it.

* Suitable (families, maybe, of) filtering algorithms for the BW->BW
  reduction case can be easier to code and quicker to run than a
  proper outliner + hinter.


			"CONSPIRACY" SECTION

Well, if it is all as simple as I say (just store high resolution
bitmaps, and filter them on the fly to the appropriate lower resolution
bitmap/pixmap, instead of storing a curvaceous outline and then
rendering it to bitmap to be corrected by hints if necessary), why
Adobe, Apple, Microsoft and their friends don't do this?

The most bizarre point is that, except for Acorn, nobody seems to use
grayscale fonts (which are essentially indeed filtered high resolution
bitmaps), and it is so bizarre considering:

* Virtually all current Apple machines, and virtually all machines that
  run MS Windows can display grayscale or color (and have had this
  ability for years).

* Antialiased fonts greatly improve the apparent resolution of text,
  much more so than hinted bitmaps from outlines (and at very little
  cost in storage, and probably to an advantage in time).

Now, let's see:

* Outlines can be copyrighted, bitmaps cannot, an outliner/hinter can be
  patented, probably a filtering algorithm cannot, as filtering has
  a lot of prior art (To say the least :->).

* Now that X11R5 has a standard font server implementation, one can have
  a single copy of all the font bitmaps one wants and the font servers
  could ship pix/bitmaps for the fonts to any PC/Apple/Workstation on
  the network, without licensing problems.

* If one used high resolution bitmaps filtered on the fly or not to
  lower resolution pixmaps (or even suitably filtered bitmaps), there
  would be no need to improve the appearance of screen fonts using the
  likes of Adobe Type Manager.

Uhmmmmm. I doubt that the GNU Font project has the same interests as
Adobe, Apple or Microsoft :-).





--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta