greg@brolga.cc.uq.oz (Gregory R. Lehmann) (06/26/89)
It seems to me adobe have made a mistake with their fonts. They all have an extremely annoying tendency to run together. The classic example is burn which turns into bum when printed on our 2 laser printers. Does anyone know why they have done this? I have heard comments that it is not the fonts but the software that produces the postscript. I have disproved this by writing my own postscript program to print burn. I still got bum. I can't believe adobe expect every piece of software to put extra space around every character just to make the resulting text readable. Any other theories? Greg
jaa@basser.oz (James Ashton) (06/28/89)
In article <1974@bunyip.cc.uq.OZ> greg@brolga.cc.uq.oz (Gregory R. Lehmann) writes: >It seems to me adobe have made a mistake with their fonts. They all >have an extremely annoying tendency to run together. The classic >example is burn which turns into bum ... >... Any other theories? The main reason is that PostScript does no kerning. Each character has a width and is printed using its width all the time in ignorance of the adjoining characters. Characters like `r' (and `j') are a problem with this system because they are lop sided. Obviously their widths have been slightly reduced so that in general they will look alright. When they adjoin certain other characters however, they practically touch which is a real bummer in this case (candidate worst pun of the year here). The solution is either to store a 2D array of inter character spaces or to calculate the spacing at typesetting time. These alternatives are expensive either in memory or processing time although a combination involving caching might not be too bad. The process of adjusting character separations to account for their shape and not just their width is called kerning and is particularly important for poster style art work. A final note for the pedants lurking in netland: it's not really PostScript that is at fault here, only its font dictionaries and associated machinery. It would be quite possible to implement kerning in PostScript with sufficient printer resources. James Ashton.
lee@uhccux.uhcc.hawaii.edu (Greg Lee) (06/28/89)
From article <2285@basser.oz>, by jaa@basser.oz (James Ashton):
" In article <1974@bunyip.cc.uq.OZ> greg@brolga.cc.uq.oz (Gregory R. Lehmann) writes:
" >It seems to me adobe have made a mistake with their fonts. They all
" >have an extremely annoying tendency to run together. The classic
" >example is burn which turns into bum ...
" >... Any other theories?
"
" The main reason is that PostScript does no kerning. ...
" A final note for the pedants lurking in
" netland: it's not really PostScript that is at fault here, only its
" font dictionaries and associated machinery. It would be quite possible
" to implement kerning in PostScript with sufficient printer resources.
The .afm files for Adobe fonts have kerning information which would be
made use of, for example, by TeX, by incorporating it into TeX's .tfm
files. But kerns are ordinarily negative spaces, (they are all negative
for Times-Roman.afm), and of course using negative kerns is not going to
keep the letters from running together. You could add a bunch of
positive kerns, I suppose, if you're using TeX. Or how about turning
down the darkness control on your printer?
Greg, lee@uhccux.uhcc.hawaii.edued@mtxinu.COM (Ed Gould) (06/29/89)
>>It seems to me adobe have made a mistake with their fonts. They all >>have an extremely annoying tendency to run together. >The main reason is that PostScript does no kerning. Each character has >a width and is printed using its width all the time in ignorance of >the adjoining characters. ... It would be quite possible >to implement kerning in PostScript with sufficient printer resources. Implementing kerning in PostScript is probably a lose, since essentially nobody uses PostScript to compute line breaks and the like. Whatever formatter does the page layout must know where the characters will actually land on the page; it cannot have the post-processor reposition things for any purpose. Of course, if there were a character-pair spacing matrix, formatters could use this information to good advantage. Maybe a way to load an override-spacing matrix would be a good thing. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA ed@mtxinu.COM +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
rcd@ico.ISC.COM (Dick Dunn) (06/29/89)
In article <2285@basser.oz>, jaa@basser.oz (James Ashton) writes in response to a question about why fonts look so "tight" on a PostScript printer: > The main reason is that PostScript does no kerning. Each character has > a width and is printed using its width all the time in ignorance of > the adjoining characters. Characters like `r' (and `j') are a problem > with this system because they are lop sided. Obviously their widths > have been slightly reduced so that in general they will look alright. This is true to the extent that if you print a sequence of characters with the "natural" widths, there is no adjustment based on context. This is necessary in some sense to maintain useful width properties--for example, the "stringwidth" of (a) plus the stringwidth of (bc) is the stringwidth of (abc). The font tuning is intended to give the best average appearance of characters--that is, the width of a character is set so that on average it looks reasonable. In some combinations it will look too tight; in others it will look too open. It's the best that can be done for simple programs making simple assumptions about character widths. > ...A final note for the pedants lurking in > netland: it's not really PostScript that is at fault here, only its > font dictionaries and associated machinery. It would be quite possible > to implement kerning in PostScript with sufficient printer resources. I don't see that PostScript is at fault at all. It provides a font mechanism with certain useful guaranteed properties. The property of concern here is that the width of a character (actually the escapement-- the distance the "current position" moves upon displaying the character) is independent of the context in which it is displayed. It's a very useful property. You can't expect the PostScript character output process to do the kerning for you. Think about whether "(a) show (b) show (c) show" should produce the same output as "(abc) show". Then think about what happens to the current position in between the characters in the first case. On the other hand, Adobe *does* provide the information you need to do pair kerning: The .afm files now (as of 2.0 font metrics) have a section of kerning pairs and amounts. That's as much as can be reasonably expected; the information is there and the rest is up to the program which prepares the PostScript file. _ _ _ _ _ Incidentally, one other possible reason for characters mushing together is that some write-white printers produce characters which are rather bolder than they really should be, although this doesn't alter the character widths. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...If you plant ice, you're gonna harvest wind.
prc@erbe.se (Robert Claeson) (06/30/89)
In article <2285@basser.oz> jaa@basser.oz (James Ashton) writes: >The main reason is that PostScript does no kerning. Each character has >a width and is printed using its width all the time in ignorance of >the adjoining characters. ..... >it's not really PostScript that is at fault here, only its >font dictionaries and associated machinery. It would be quite possible >to implement kerning in PostScript with sufficient printer resources. PostScript has the hooks neccesary for implementing various types of kerning. Look up the ashow, awidthshow and kshow operators in the Reference Manual. The green book ("PostScript Language Program Design") has a chapter devoted to setting text and performing things like kerning. Take a close look at chapter 7.6, titled "Kerning and Ligatures". That should be the info needed for most implementors of kerning.