NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/fonts/3802

Internet Message Format | 1992-12-29 | 9.5 KB

Xref: sparky comp.fonts:3802 gnu.misc.discuss:4118
Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.fonts,gnu.misc.discuss
Subject: Re: "Hinting" using antialiasing? A GNUish alternative...
Message-ID: <[e-mail]>
Date: 29 Dec 92 15:41:25 GMT
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (USENET news service)
Reply-To: [e-mail] (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth
Lines: 170
In-Reply-To: [e-mail]'s message of 27 Dec 92 22: 53:47 GMT
Nntp-Posting-Host: decb.aber.ac.uk

On 27 Dec 92 22:53:47 GMT, [e-mail] (John D. Mitchell) said:

johnm> You might want to take a look at the documentation for GeoWorks'
johnm> GEOS platform.

Can you give some more info? I seem to remember it is kind-of a DOS GUI,
only cheaper/faster/simpler than Windows 3.1 (not that it's difficult :->).

pcg> [ ... bitmap scaling vs. outline filling ... ] Not better looking,
pcg> on looks I would think it would be equivalent or nearly so; but
pcg> better in speed and non proprietariness.

johnm> Non-proprietariness I'll buy.  Speed is another issue entirely.

johnm> In any kind of regular use [ ... a few glyphs get used over and
johnm> over again, and caching them is quite effective ... ]

Yes, but this holds true for both technologies; so if one has less space
for caching, then a faster technique is preferable. For example I don't
like the few seconds of latency that existing renderers make me wait
while the rasterize the fonts contained in an imported document. Maybe I
am spoilt for speed, or maybe I cannot afford the latest Quadra or
DX2-66.

However, given that in most common day use one uses only two sets of
fonts, one for the screen and one for printer, I am particularly
thinking of keeping around printer resolution bitmaps, which are the
ones that after all matter most, and then scaling them on the fly to the
screen resolution. I am even thinking that it would make sense putting a
font server *into the printer*, which, for networked printers, is the
right thing to do. And non networked printers can be turned into
networked ones for a few hundred dollars by way of a PC as gateway.

  Yes, I am thinking of reversing the current situation in which fonts
  are downloaded from workstation to printer; I would rather do the
  opposite.

johnm> Also, I don't see how applying some number of algorithmic scaling
johnm> filters would be any faster.  I believe (totally my own
johnm> imagination :-) that only filters that worked on very local
johnm> information would be fast.  But [ ... you would need context
johnm> sensitive filters for better quality ... ]

I think too one would need context sensitive filtering; but I think this
would still be a win. It is often non obvious how to implement
Bezier/quadratic splines using integer only arithmetic, while all sorts
of bitmap filtering I can envision use only integer arithmetic and
pretty simple as well, and very predictable memory access patterns. This
can be an advantage.

  Both outlining and scaling require much the same type of effort for
  diagonal lettering (yes, you can rotate bitmaps too -- HP have
  contributed a nifty set of mods to the X11R5 font engine for this), but
  that's a fairly rare thing.

johnm> I'm not sure that I'm understanding what you mean by "an
johnm> unconscious filtering algorithm".

johnm> My understanding of the typeface design business is that the
johnm> designer generates 'perfect' character designs for some very
johnm> large em square.

Well, things actually vary a bit, as far as I know. If an existing
typeface is to be digitalized, it's as you say. A largish character
shape gets scanned in, and then a countour for it is generated
automatically by something like illustrator. Then the designer adjusts
the countour. The case of entirely new typefaces designed for digital is
rarer; just about the only two examples I know are Lucida and the Knuth
fonts. There the designer has the options of either hand drawing the
characters on paper, or starting directly with the outlines. I think
Knuth uses the latter method.

johnm> The designers then specifies the hints and their relative
johnm> importance to the overall character (such that the more
johnm> superfluous are left out sooner as the generated font size is
johnm> reduced.

The designer looks at the output bitmap produced by outline+hints, and
tweaks the hints (and the outline) until the bitmap looks "right". In
other words the designer is actually designing the *bitmaps*, and just
uses outline+hints as a way to specify the bitmap he fancies.

Maybe another way fo expressing my concept is that high resolution
bitmaps are a better (in the sense of more general, faster -- subject to
dispute -- and non-proprietary) thing to use a matrix/encoding of the
various resolution bitmaps of a glyph than an outline.

johnm> How is that 'unconscious'?

In that the adjustment process terminates when he/she "knows" that the
bitmap poduced is the "right" lower resolution bitmap. The "knowledge"
can only come from some kind of "appropriateness algorithm" the designer
has got, more or less consciously, based on the peculiarities of human
vision. Type design theory is very much about studying this
"appropriateness algorithm" humans have built in, and designing type
around it, whether lead or bitmap.

johnm> I'll grant that my understanding is incomplete and generalized.

Mine too -- I am mostly an OS guy, not a typeface guy.

pcg> I think it would be more general because I guess it could be
pcg> patterned after the rather universal properties of human vision;

johnm> The same argument as above.  Any typeface designer worth anything
johnm> must take into account the biases and pecularities of human
johnm> vision.

As agreed above, but they do so *manually* (and "unconsciously": they
basically assume that what looks right to them looks right to
everybody). I think instead that it can be done, with tolerably
satisfying results, algorithmically. Moreover the situation for hints in
existing font specification languages is less than satisfying:

pcg> instead some hinting systems are patterned after the features of
pcg> latin glyphs, and do not adapt well to other styles of writing.

I was referring to Type 1 here. TrueType hints are instead relatively
nasty to use but allow specifying any sort of correction to the output
bitmap; at times I think they are just a thinly disguised veil for
things like manual patches, bit by bit, to the bitmap.

The fact that of the typical 50-70KB of a well tuned TrueType font half
is devoted to hinting seems to indicate this.  I think that the same
space would be taken up by a master high resolution bitmap and then a
series of bit-by-bit patches that correct the scaled output.

  Or even a set of lower resolution bitmaps, which usually take up very
  little space (a 10pt .pk font at 120 DPI takes about 3k; that means
  that in 30KB one could store quite a selection of sizes, even if one
  could actually only store the differences between the scaled bitmap
  and the ideal one). So for example a font could be first produced as a
  high resolution bitmap, then this would be scaled at various point
  sizes, these would be presented to the designer, and he would apply
  corrections, that would be recorded as diffs alongside the original
  bitmap. I would rather substitute the designer with a filtering
  algorithm, either on the fly or not. Actually I would envisage a three
  stage process; high resolution font, filtering algorithm used to
  produced "decent" scalings, the designer asked to approve (the
  default, if the filtering algorithm is OK) or to record manual
  corrections (yes, hints even for scaled fonts, if you really want
  them), that are recorded as bit level diffs. I can even imagine that
  one migh have more than one scaling algorithm, each version perhaps
  more suited to certain glyph styles, and the designer chooses the best
  algorithm first, and the choice is attached to the bitmap; if the end
  user scaling engine has that algorithm, so much the better, if it does
  not, it can substitute another, perhaps generic scaling algorithm.

In practice designing a well tuned TrueType font is exactly identical to
designing the bitmaps at the various low resolutions that must be
supported, and then just encoding this as a fairly inefficient
programmatic outline and a series of fairly inefficient programmatic
(even if I seem to remember that one can actually specify bit-by-bit)
patches to it.

I like more what is done in METAFONT; there adaptation to the resolution
and quirks of the intended output device is done by adjusting various
parameters, like the shape of the "nib". This is virtually equivalent to
choosing a different filtering algorithm (the "nib" is a filter!).

Also I am not at all contrary to using outlines as a *design* tool, a la
METAFONT; algorithmic expression of typeface contours helps, perhaps a
bit too much, to express regularities in the typeface and ensure
consistency, like METAFONT does, between different fonts in the same
outline (again, like METAFONT does, and has been "discovered" only now
by the public with Adobe's so called multiple masters spec).
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <[e-mail]>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta