smithda@cpsvax.cps.msu.edu (Daniel Smith) (10/20/88)
As I was working on installing a new DVI driver to handle resident
PostScript font, I began to think about the relationship between
METAFONT and PostScript. It occured to me that the two do about the
same thing, its just that they do it at different times. METAFONT
translates source code describing fonts into bit maps, and so
does PostScript. The difference is that PostScript does it when the
document is printed, and METAFONT does it when the font itself is
created.
I began to wonder if anyone has tried to make METAFONT spit out
PostScipt outline fonts? Such a scheme would seem to combine the best
of both worlds. METAFONT is a real programming language, written by
a computer scientist. This makes is "easy" to describe
fonts accurately and formally. PostScript on the otherhand
is not very easy to read. While it is possible to make sense out
of PostScript code, it is not as good as METAFONT.
Here is a list of pros and cons for such a scheme:
METAFONT doing just what it does now:
* The fonts produced will work on just about ANY printer. One
does not need a PostScript printer to use TeX/METAFONT.
* However, these fonts take up A LOT of disk space, espically
when compared to PostScript fonts. For example, a PostScript
outline for for say Times-Roman is basically one file. That is
one file for ALL sizes of Times-Roman, for ALL device resolutions.
Since the PostScript software in each printer has "lots of smarts"
this method works.
* DVI drivers are non-trivial pieces of software. Each driver must
deal with the bitmaps in the GF/PK/PXL files and convert those
to a scheme for the current printer.
METAFONT producing PostScript
* A LARGE savings in disk space can be realized, because very few
files are required for a font.
* Of course, the output is only of use to those who have PostScript
printers.
* PostScript is fast becoming a standard for desktop-publishing.
* Writing a DVI driver is quite simple. One no longer needs to
deal with bitmaps of fonts. The DVI file and TFM files for the
fonts are all that are needed. In some cases, the TFM may not
even be necessary.
* TeX fonts (Computer Modern) behave just like any other
PostScript font.
=========================================================================
J. Daniel Smith smithda@cpsvax.cps.msu.edu
Michigan State University
"An average English word is four letters and a half. By hard, honest
labor I've dug all the large words out of my vocabulary and shaved it
down till the average is three and a half..."
Mark Twain
=========================================================================sean@ms.uky.edu (Sean Casey) (10/23/88)
In article <902@cps3xx.UUCP> smithda@cpsvax.cps.msu.edu (Daniel Smith) writes:
[A good article comparing METAFONT and Postscript]
I'm no great fan of either, but I have to point out that METAFONT does a lot
more to generate fonts of a certain size than Postscript does. You can always
send font outlines to Postscript for scaling, but the results aren't going to
look as good as if you let METAFONT do it.
I'd like to see the functionality of both combined, but I'm not sure how it
could be done. I don't like the idea of storing bitmaps on the host system
because (1) it uses a lot of disk space and (2) someone always seems to want
something in a size that isn't there.
If you generate stuff on the fly, you either do it really slow and good with
METAFONT, or fast but not quite so good with Postscript.
Perhaps this will all be a moot point in the future, when output device
resolution will be so high that finicky differences in rasterization won't
be visible.
Sean
--
*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
*** The Hacker from Spaaaaaaaaace. {backbone|rutgers|uunet}!ukma!sean
*** U of K, Lexington Kentucky, USA ..where Christian movies are censored.
*** ``The World... she's a flat! She's a round! Flat! Round! Flat! Round!''hess@iuvax.cs.indiana.edu (Caleb Hess) (10/24/88)
In article <902@cps3xx.UUCP> smithda@cpsvax.cps.msu.edu (Daniel Smith) writes: >... I began to think about the relationship between >METAFONT and PostScript. It occured to me that the two do about the >same thing, its just that they do it at different times. METAFONT >translates source code describing fonts into bit maps, and so >does PostScript. One very important difference is that METAFONT makes no attempt to be scalable. While it might be possible to make METAFONT produce PostScript code, the resulting fonts would not behave like normal METAFONT fonts, which are designed for one point size, or like Adobe's fonts, which contain coded-in scaling hints.
mrd@sun.soe.clarkson.edu (Michael DeCorte) (10/26/88)
smithda@cpsvax.cps.msu.edu (Daniel Smith) writes: >METAFONT translates source code describing fonts into bit maps, and so >does PostScript. The difference is that PostScript does it when the >document is printed, and METAFONT does it when the font itself is >created. I began to wonder if anyone has tried to make METAFONT spit >out PostScript outline fonts? [lots of other useful observations] I have been thinking of how to do this for quite some time now. There are a few things that have to be first examined: (I am calling these things .psf for PostScript fonts) 1) As I understand it, under postscript, when you scale a font you are doing the equivalent of magstep under TeX. This is unacceptable for TeX. Therefore it won't be possible to have cmr.psf but there is nothing to stop you from having cmr10.psf. There are several advantages to this: a) it is portable between different PS printers of different resolutions b) it should be portable between write-white and write-black engines c) the .psf file may be smaller than the cmr10.pk but I am only guessing d) the cmr10.psf file will DEFINITELY be smaller than the cmr10.pk @ magstep 0,0.5,2..5. (I really like this) e) it may be faster to download as you don't have to download multiple mag of the same font and it may even be possible to make the cmr10.psf very small by having a set of ps libraries that you download before any fonts 2) if we ever get a PostScript previewer on our Sun, I won't have to have fonts at every size and dots/inch know to mankind 3) this could be generalized for vector output devices in general. Wouldn't it be nice to be able to use that 4105 to preview? I suppose you could get plotters going also. 4) internal PostScript fonts will be easier to handle I assume, as they will be handled the same as external fonts. 5) it will be necessary to use the .tfm files or duplicate them in the .psf file. I think it is better to just use the .tfm file 6) this is probably portable but... Donald Knuth spent a lot of time figuring out how to make a { look like a }. Did Adobe? Rounding leads havoc on low res fonts. 7) we will have to redo LaTeX's definition of fonts. With all of these fonts that we now have available, it will be necessary to have a font defined in three parts: family, style, size. Eg. right now we have Computer Modern, Italic, 12. We will have Helvetica, Bold, 10. This means that you would to choose a font you would do something like \rm\it\large or \hv\bf\normalsize. If you only want to change the style of the font from bold to italic but nothing else you would only do \it. Likewise, to change the family but not the size or style you would only do \rm. One minor problem is that \rm stands for Computer Modern not Roman. 9) If the .psf fonts are defined correctly, it will be possible to use fonts from TeX in non TeX stuff. -- Michael DeCorte // (315)268-2292 // P.O. Box 652, Potsdam, NY 13676 Internet mrd@sun.soe.clarkson.edu // Bitnet mrd@clutx.bitnet ------------------------------------------------------------ Clarkson Archive Server archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ------------------------------------------------------------
john@trigraph.UUCP (John Chew) (10/28/88)
In article <10417@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >I'm no great fan of either, but I have to point out that METAFONT does a lot >more to generate fonts of a certain size than Postscript does. You can always >send font outlines to Postscript for scaling, but the results aren't going to >look as good as if you let METAFONT do it. ... >If you generate stuff on the fly, you either do it really slow and good with >METAFONT, or fast but not quite so good with Postscript. The criticism of PostScript is misleading. Certainly if you create a pure bitmap or pure outline PostScript font, it will be scaled as a bitmap or an outline: poorly. 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. The automatic translation of METAFONT source to PostScript source would not be an impossible task. My guess is it would be about as difficult as and remarkably similar to writing a Pascal to Forth translator. John Chew -- john j. chew, iii trigraph, inc., toronto, canada {uunet!utai!utcsri,utgpu,utzoo}!trigraph!john dept. of math., u. of toronto poslfit@{utorgpu.bitnet,gpu.utcs.utoronto.ca} Opinions? All mine. My company never yawns openly.
mrd@sun.soe.clarkson.edu (Michael DeCorte) (10/29/88)
In article <422@trigraph.UUCP> john@trigraph.UUCP (John Chew) writes:
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 thought of that, for about 10 seconds and rejected it. Metafont is
SLOW. On a 68020 @ 25 Mhz running sun os it takes about 2 minutes to
generate ONE font. I would hate to imagine it on a 68000 @ 8 Mhz.
--
Michael DeCorte // (315)268-2292 // P.O. Box 652, Potsdam, NY 13676
Internet mrd@sun.soe.clarkson.edu // Bitnet mrd@clutx.bitnet
------------------------------------------------------------
Clarkson Archive Server
archive-server@sun.soe.clarkson.edu
archive-server%sun.soe.clarkson.edu@omnigate.bitnet
dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server
------------------------------------------------------------tgl@zog.cs.cmu.edu (Tom Lane) (10/31/88)
In article <10417@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >I'm no great fan of either, but I have to point out that METAFONT does a lot >more to generate fonts of a certain size than Postscript does. You can always >send font outlines to Postscript for scaling, but the results aren't going to >look as good as if you let METAFONT do it. To which john@trigraph.UUCP (John Chew) replies in article <422@trigraph.UUCP>: >The criticism of PostScript is misleading. Certainly if you create >a pure bitmap or pure outline PostScript font, it will be scaled as >a bitmap or an outline: poorly. > >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. 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. 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 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'm no expert on PostScript, so I'd welcome hearing contrary opinions. For one thing, how standard is AFM format? For another, can you discover the actual resolution of your device? -- tom lane Internet: tgl@zog.bcs.cmu.edu UUCP: <your favorite internet/arpanet gateway>!zog.cs.cmu.edu!tgl BITNET: tgl%zog.cs.cmu.edu@cmuccvma
lee@uhccux.uhcc.hawaii.edu (Greg Lee) (10/31/88)
From article <3455@pt.cs.cmu.edu>, by tgl@zog.cs.cmu.edu (Tom Lane): " ... " 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 More costly work doesn't mean better results. While Metafont-generated characters at 300dpi look very nice, at 78dpi they look awful. Or at least they did in my one experiment -- maybe I could have tuned the parameters ... " ... " While we are on the subject, it's not clear to me that PostScript truly " allows for nonlinear font scaling. Nor to me. If somebody has done this, how about posting at least a sample of a font, to show us how it's done? I wish, also, that a ps-guru would post an example of adding character shapes to a built-in font. Greg, lee@uhccux.uhcc.hawaii.edu
john@trigraph.UUCP (John Chew) (11/02/88)
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}
mar@athena.mit.edu (Mark A. Rosenstein) (11/02/88)
In article <3455@pt.cs.cmu.edu> tgl@zog.cs.cmu.edu (Tom Lane) writes: > 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...) No, it is possible to adjust a postscript path based on the actual device pixels. The code fragment transform round exch round exch itransform will take a x,y coordinate in user space and move it to the nearest pixel in device space. One could use this to make sure that critical points in a character outline line up in a reasonable manner on pixels. -Mark
greid@ondine.COM (Glenn Reid) (11/04/88)
> 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. This is exactly what Adobe fonts are for Display PostScript, where "extremely small font sizes (w.r.t. device resolution)" is an everyday occurrence at normal text sizes. We have built in the capability to use "prebuilt" fonts at appropriate sizes and orientations, if those fonts are available on the system. We believe that this will provide the best hybrid between readability, generality (outlines), and accuracy. The system will also be smart enough to recognize the various permutations of resolution, point size, magnification, etc. The font outlines, however, do not really accomplish non-linear scaling. To some extent, the font designs themselves cover this: "book" and "text" faces are designed to look good at 10 point, but are rarely used for "display" by anybody who is likely to notice non-linear scaling anyway. The display faces are designed to look better at 24 point or whatever size (not that I am a typographer, but I think that is generally true). Glenn Reid Adobe Systems
barry@reed.UUCP (Barry Smith) (11/07/88)
In article <423@trigraph.UUCP> you write: >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? John, pardon me for being so short, but you really don't know what you're talking about here. Why don't you take a look at the Metafont book? Keep in mind the experience and credentials of the author, too. "In extremis", of course, you're correct: it's possible, although not practical, to run Metafont IN PostScript. In more practical terms, one might pose the question thusly: "At 300 dpi, does PostScript rasterize outlines (of, say, Times Roman) as well as Metafont rasterizes, say, Computer Modern 10 point?" And the answer, quite simply, is that it's no contest. It's actually quite an interesting comparison, and an education to the untrained eye; what previously appeared to be clear, crisp Times Roman characters suddenly become muddy and coarse. (Here I'm speaking solely of rendering, not esthetics; personally, I can think of several fonts I might prefer to Computer Modern for my uses.) Another respondent referred to the poor quality of 78 dpi fonts rendered by Metafont. I agree wholeheartedly (as, I believe, does Knuth); it may be perfectly correct to say that automatic rendering of low-resolution fonts from outlines is beyond the state of the art. Barry Smith Blue Sky Research
john@trigraph.UUCP (John Chew) (11/12/88)
In article <10936@reed.UUCP> barry@reed.UUCP (Barry Smith) writes: >In article <423@trigraph.UUCP> you write: --- (I volunteer myself as the unattributed author of the following :-) >>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? > > >John, pardon me for being so short, but you really don't know what you're >talking about here. Why don't you take a look at the Metafont book? >Keep in mind the experience and credentials of the author, too. Hmm. Pardon me for taking offense at your shortness, but although I don't have a copy of the METAFONT book in front of me, I have read it from cover to cover. I am also aware of Knuth's credentials, as a mathematician, a computer scientist and as a type designer, but prefer to discuss matters such as a comparison of features of METAFONT and PostScript in terms of the documented capabilities of each without resort to argument by reference to authority or to ad hominem attacks. >In more practical terms, one might pose the question thusly: "At 300 dpi, >does PostScript rasterize outlines (of, say, Times Roman) as well as >Metafont rasterizes, say, Computer Modern 10 point?" And the answer, >quite simply, is that it's no contest. ... or at least not a fair contest. It has been pointed out that both PostScript and METAFONT are capable of pixel-level adjustments to individual fonts, though I have yet to hear arguments opposing my suggestion that this is easier in a language such as PostScript which inherently supports both bitmap and algorithmic fonts, rather than in METAFONT where the adjustments if any are best made to individual rasterizations using a bitmap editor. Thus in principle, there is no reason why both languages cannot generate identical bitmaps for a given font. For example, you could take rasterizations of CMR at a large number of point sizes and write a PostScript font that would merely interpolate between them. This would not be elegant, but the final product would be pixel-wise identical. So to take a PostScript font and a METAFONT font, representing two completely different faces and judge the languages solely on that basis is ridiculous. The most one can infer from such a comparison is a subjective opinion concerning the relative skills of the type designers who designed each font, and the degree to which each were familiar with the languages with which they dealt. >It's actually quite an interesting comparison, and an education to the >untrained eye; what previously appeared to be clear, crisp Times Roman >characters suddenly become muddy and coarse. I'm sure if the person who ported Times Roman to PostScript had had fewer constraints on his/her time and the font's own parameters, Times Roman would have more low-resolution special-casing code. >(Here I'm speaking solely of rendering, not esthetics; personally, I >can think of several fonts I might prefer to Computer Modern for my uses.) Are you ... "keep[ing] in mind the experience and credentials of the author" when you say that :-)? Not that I disagree... it's hard for me to decide which strikes me as more of an esthetic crime: Computer Modern at any size or Times Roman at 10 pt on a 300 dpi device. >Another respondent referred to the poor quality of 78 dpi fonts rendered >by Metafont. I agree wholeheartedly (as, I believe, does Knuth); it may be >perfectly correct to say that automatic rendering of low-resolution fonts >from outlines is beyond the state of the art. To re-iterate: one thing that is nice about PostScript is that after you have hand-tuned low-resolution rasterizations, you can incorporate them easily enough into a font and not rely on automatic processes. 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}