Xref: utzoo comp.fonts:379 comp.lang.postscript:1098
Path: utzoo!dciem!trigraph!john
From: john@trigraph.UUCP (John Chew)
Newsgroups: comp.fonts,comp.lang.postscript
Subject: Re: METAFONT & PostScript
Message-ID: <423@trigraph.UUCP>
Date: 1 Nov 88 16:52:47 GMT
Article-I.D.: trigraph.423
References: <902@cps3xx.UUCP> <10417@s.ms.uky.edu> <422@trigraph.UUCP> <3455@pt.cs.cmu.edu>
Reply-To: poslfit@gpu.utcs.utoronto.ca
Organization: Trigraph Inc., Toronto, Canada
Lines: 87

In article <3455@pt.cs.cmu.edu> tgl@zog.cs.cmu.edu (Tom Lane) writes:
...
>To which john@trigraph.UUCP (John Chew) replies in article <422@trigraph.UUCP>:
...
>>If however you design a proper algorithmic PostScript font (one 
>>which makes rasterization decisions based on the current font size),
>> then the result will be every bit as good as, and quite possibly
>>identical to that of METAFONT.
>
>I disagree.  Chew seems to believe that Metafont's only virtue is that it
>allows for nonlinear scaling of font dimensions.  This is true, but is only
>part of the story.  Metafont also uses extremely careful (= costly)
>algorithms for digitization: i.e., deciding exactly which pixels to blacken
>to represent the infinitely-precise character outline.  At low resolution
>(meaning less than 1000dpi), good digitization makes a lot of difference in
>the appearance of a character.  Metafont also allows the font designer to
>specify character dimensions in pixel-dependent units, to assist in
>selecting the best possible digitization.

I had intended the phrase `rasterization decisions' to include both
the nonlinear scaling of font dimensions and the actual pixel by pixel
fine tuning.

I envisage a good PostScript font (one that has gone to the expensive
end of the time-quality tradeoff) working as follows.  At reasonable
font sizes, the font is represented as an outline with non-linear
scaling of various dimensions.  At extremely small font sizes (w.r.t.
device resolution), the font becomes a pre-computed bitmap to ensure
that not one pixel is painted that shouldn't be.

I will readily admit that I have not designed such a font, nor would
I look forward to doing so, except by writing a METAFONT-PostScript
translator, but it is well within PostScript's abilities to execute
such a font.

I also believe that the quality possible with such a font would be
very difficult to imitate in METAFONT, though this may just be a
PostScript programmer's bias.  Can one easily make `this pixel stays
on, but that one should be turned off' decisions in METAFONT?

>While a PostScript printer with a very large font cache could perhaps afford
>to use similarly expensive digitization algorithms, I doubt that any
>currently available implementations do so.  

Actually, the size of the font cache has little to do with it.  The
PostScript font cache is used to avoid having to re-rasterize particular
scalings of fonts.  When a given font is executed at a given size, if
font caching is enabled, the resulting rasterizations are saved so that
the font code doesn't need to be re-executed until the scaling changes.
Font cache space usage is governed by the actual bitmap size of the
font currently being used and not by the complexity of the algorithm
used to create the bitmap.

The expense comes in two forms: execution time (moderate, considering
that no matter how complicated the font gets, it will always look like
a large conditional expression choosing between several relatively
simple font definitions) and program size (a consideration if the font
is not locallly resident but needs to be downloaded over a slow link).

>                                            In any case, a PostScript font
>designer has no means of specifying resolution-dependent --- as opposed to
>size-dependent --- adjustment of character outlines.  (Correct?  I thought
>that PostScript carefully hides the printer resolution...)

While PostScript does make things easy for the casual user to
ignore device resolution, the transform and dtransform operators
are defined explicitly to allow access to device resolution for
those who need it.  You *can* make decisions based on both the
font size and the device resolution.

>While we are on the subject, it's not clear to me that PostScript truly
>allows for nonlinear font scaling.  In particular, the AFM file format seems
>to dictate linear scaling of all major character dimensions, including
>x-height.  Hence there is not really much room for altering character shapes
>depending on actual size.

I don't have my AFM specs handy, but I suspect you are correct here.
A font carefully designed as described above might point out inadequacies
in the AFM format and might require custom enhancements to the font
metric routines of one's typesetting package.

John Chew

-- 
john j. chew, iii   		  phone: +1 416 363 8841     AppleLink: CDA0329
trigraph, inc., toronto, canada   {uunet!utai!utcsri,utgpu,utzoo}!trigraph!john
dept. of math., u. of toronto     poslfit@{utorgpu.bitnet,gpu.utcs.utoronto.ca}