avi@dgp.toronto.edu (Avi Naiman) (11/08/88)
In article <19809@apple.Apple.COM> jp@Apple.COM (John Peterson) writes: >> David Casseres >> In spite of the enthusiasm of its supporters, the question of the >> *readability* of anti-aliased text remains open. I would tend to agree with David's assessment of the situation: the question of the *utility* of grayscale text remains open. Depending on the task at hand, 'utility' might mean discriminability, legibility, readability, aesthetics, or some combination of these qualities. Several research projects have started *preliminary* work into investigating the issues involved [Bender 87, Farrell 88, Gould 84, Gould87a, Gould 87b, Naiman 88]. However, it is premature to draw generally applicable conclusions from any of the published research (at least, that which I have seen). Furthermore, in having spoken with at least one author of each of the papers I reference (and many other researchers in the field), I believe they all agree that we still have much to do before anything close to an 'all-encompassing' grayscale font production system is available. Other than pragmatic-type problems (e.g., how fast can the fonts be produced), some of the issues which need addressing include: -- algorithmic processes for generating grayscale fonts -- appropriate filters -- tradeoffs between number of grayscale levels and resolution -- the visual system's response to grayscale edges -- the relationship between flicker and grayscale -- fatigue of the visual system -- sub-pixel positioning -- 'difference' metrics for multiple versions of a character -- display device modeling >John Peterson > Not really, some studies have been done. I have in front of me a paper > titled "CRT Typeface Design and Evaluation" that was prepared by some people > at MIT and IBM. In their study they found that people can read a display > with anti-aliased fonts -faster- than the equivalent hardcopy text. This > compares quite well to traditional CRT text, which was found consistantly > slower than hardcopy. >From my experience, I find it hard to believe that one can today compare a screen font (regardless of whether or not there is grayscale) with an *equivalent* hardcopy sample. Aside from the fact that the illumination levels of the two media are quite different (one being steady and reflective, the other refreshed and emissive), the point spread functions will likely be quite different. Hence, the character shapes will be distorted by the two media in different ways. While we can try to minimize these differences, until we have established metrics by which to measure the 'differences' between two versions of the same character (in terms of the performance of the human visual system in some task domain), we will not even know what 'nominally equivalent' means. On the bright side, there have been certain controlled, focused -- and limited -- experiments which have demonstrated that, under suitable conditions and for given tasks, subjects can use a 'particular' grayscale font to better advantage than a 'particular' hardcopy font. Since John brought up the [Bender 87] paper, let me illustrate my remarks (both the limitations of completed research and the need for much more) with some quotes from, and remarks on, the article [note that the authors do not make exactly the same claim John describes]: -- "To *begin* to understand this question" ['*' are mine] -- "... we have designed a new [sic] anti-aliased typeface which can be viewed on an analog color display." How are things affected when monochromatic grayscale monitors are used? How is "color" accounted for? -- "[video display] technology presents advantages and limitations never considered in the design of typefaces for printed communication." This implies -- correctly -- that there is much we do not yet understand about "digital typography", let alone grayscale fonts. -- "Most CRT typefaces attempt to imitate printed typefaces, and their design is not optimized for CRT's. It was our intention to design this new typeface on the media for which it was ultimately intended." Three possibilities exist: the grayscale font is an implementation of the hard-copy font, the hard-copy font is an implementation of the grayscale font, the grayscale font is similar to, but not the same as, the hard-copy font. By their own admission, the grayscale font used in the experiment was derived from a hard-copy font, but was re-designed for the video terminal. Hence, the media is not the only thing that was different between the font samples. -- "In our experiment, we had a graphic designer hand-tune the algorithmically generated grayscale characters." How would the grayscale font have fared without hand-tuning? Is hand-tuning feasible for large-scale font production? -- "It is important to find a common ground between acuity and positionability. ... His experienced eye was used to find a balance between the acuity and shape of each character." How can we incorporate the designer's aesthetic sensibility into an automated process? In what ways is the 'solution' task-dependent? -- "In addition, he designed a typeface which was well-suited for CRT display; the smallest elements of the characters ... were on the scale of a pixel." How well will more traditional typeface designs transfer to the grayscale media? Will this prove more successful than black and white versions in capturing subtle design details? -- "It is our guess that the application [of] typographic skills to our character design, as opposed to simply the application of filters, however well-tuned, is the factor which has significantly improved the readability of our anti-aliased characters over previously reported results. [Gould 1984]" Note that the authors themselves are questioning exactly what role the grayscale media played in 'improving' the quality of the CRT font. Furthermore, the "control for this study was hardcopy printed on the IBM 5218 Printwheel Printer with a Prestige-Elite Printwheel II". Ideally, one would like hand-tuned and untuned versions of black & white as well as grayscale fonts, in order to separately evaluate the issues of grayscale, typographic skills, and media. Furthermore, since their grayscale font was Century Schoolbook-like [private communication], how justified are the results? I do not contest that the particular grayscale, hand-tuned, CS-like, CRT-displayed font out-performed the hard-copy, Prestige-Elite one; but what conclusions are fair to draw from this fact? In fact, they make essentially the same (implied) observation: "Future work will include a direct comparison of algorithmically generated fonts with hand-tuned fonts, as well as a comparison between the same typeface, hand-edited bi-level and grayscale." -- "The data suggests that proofreading with the new anti-aliased [sic] typeface on an analog color display is faster than from a hardcopy". For the particular sample fonts and task used! Would it have been faster than high-quality typeset hard-copy fonts? -- "Only six out of eighteen [preferred] the printed copy. ... Although not significant, this result does suggest a trend that deserves further investigation." Indeed it does! I hope no one construes this posting as an attack on the [Bender 87] work. I am merely trying to illustrate some of the complexities involved in using grayscale on a widespread basis. I'm all for it; I just don't know how to do it consistently *well* yet (nor, do I believe, does anyone else). Avi Naiman Dynamic Graphics Project Department of Computer Science University of Toronto avi@dgp.toronto.edu Bender 87 Bender, W., R. A. Crespo, P. J. Kennedy, and R. Oakley, ``CRT Typeface Design and Evaluation,'' Proceedings of the Human Factors Society, 31st Annual Meeting, 1987, pp. 1311-1314. Farrell 88Farrell, J. E. and A. E. Fitzhugh ``Image Quality of Digital Characters,'' Supplement to Investiga- tive Opthalmology and Visual Science, 1988, In Press. Gould 84 Gould, J. D. and N. Grischkowsky, ``Doing the Same Work with Hard Copy and with Cathode-Ray Tube (CRT) Computer Terminals,'' Human Factors, Volume 26, Number 3, June 1984, pp. 323-337. Gould 87a Gould, J. D. et al., ``Why Reading was Slower from CRT Displays than from Paper,'' Proceedings of CHI+GI 1987, April 1987, pp. 7-11. Gould 87b Gould, J. D. et al., ``Reading is Slower from CRT Displays than from Paper: Attempts to Isolate a Single-Variable Explanation,'' Human Factors, Volume 29, Number 3, June 1987, pp. 269-299. Naiman 88 Naiman, A. and J. Farrell, ``Modeling the Display and Perception of Grayscale Characters,'' SID 88 Digest, Volume 19, May 1988, pp. 424-427. -- Avi Naiman avi@dgp.toronto.edu
avi@dgp.toronto.edu (Avi Naiman) (11/08/88)
In article <19809@apple.Apple.COM> jp@Apple.COM (John Peterson) writes: >> David Casseres >John Peterson >> As to its being cheap to implement, it's true there is less hardware cost >> in anti-aliasing than there is in greater pixel density. But until someone >> makes a breakthrough or two, it requires some very intense computation >> right where you don't want it, i.e. right in the middle of your character- >> display loop where it trashes your display performance. > This is incorrect. I would not consider BitBlt (aka CopyBits) to be an > "intense computation." Like all other screen fonts, anti-aliased fonts are > pre-computed and cached. To display them, you copy rectangles of pixels onto > the screen. For the vast majority of applications (page layout, word > processing, etc) that's all the "computation" you need to do. If the approach taken is to pre-compute a single version of a grayscale font (for each font size and display resolution possible), then I would agree with John that copying bytes is not much more intensive a computation than copying bits. However, this approach restricts the flexibility of using grayscale for sub-pixel positioning of edges. In particular, one could not move a character left or right by less than a pixel of space; each character exists on an integral lattice which must coincide with the device's pixel grid. Alternatively, one could generate many grayscale versions of the same font at a particular size and for a specific device, each differing only slightly from the next in terms of the sub-pixel position of the target resolution sampling grid relative to the master resolution of the filtered characters. In this manner, one could do a more accurate job of approximating the spacing required between successive characters, by using the particular version of the character which minimizes the spacing error. In our context, if we have a half pixel error in the positioning of a character, one character pair may appear too 'closely' set by half a pixel, while the next pair seems too 'loosely' set by half a pixel. Where the size of a pixel is large relative to the size of the character, this can lead to disastrous spacing problems. Even for state-of-the-art monitors with a resolution of approximately two pixels per typographer's point (in each of x and y), when setting 10-point text (about .35 cm), a half pixel of error is about 10% of the average inter-character spacing (one quarter of the point size) while the variation between the spacing of pairs of characters can be as much as 20%. By using 8 different x-phases in generating the grayscale characters, this error can be reduced to 1.25% and 2.5%. For more common monitors (about 1 pixel per typographer's point), the errors are 20% and 40%, and 8 phases can reduce this to 2.5% and 5%. [Note that different y-phases can be utilized when there is a necessity for leading which is a non-integral multiple of the pixel size, as well as for superscripts, subscripts, and tabular data.] Due to the abundance of digital fonts available today (at virtually any size) and the requirement of sub-pixel positioning for accurate spacing, prefiltering all possible grayscale characters is impractical (in fact, it is impossible, since the user may always want a size which has not been made available). Therefore, I would agree with David Casseres' comment above, that what we need is the capability to dynamically generate the requested characters at the appropriate size, resolution, and phase, coupled with font-caching software to reduce the need to recompute already-generated characters. I contend that the research reported in the below-cited paper is a step in that direction. Naiman 88 Naiman, A. and A. Fournier, ``Rectangular Convolu- tion for Fast Filtering of Characters,'' Computer Graphics, Volume 21, Number 4, July 1987, pp. 233-242. -- Avi Naiman avi@dgp.toronto.edu
avi@dgp.toronto.edu (Avi Naiman) (11/08/88)
In article <4848@polya.Stanford.EDU> kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes: >In article <515@voodoo.UUCP> bhagwan@voodoo.UUCP (The Bhagwan) writes: > >> True enough...but....consider subpixel positioning. You'll need additional >> bitmaps for this. If you want 1/4 pixel positioning, you need 4 bitmaps. >I don't think you want subpixel positioning. If you have it, you get 4 >different appearances for each letter. This remains to be qualified. Will you really get four different 'appearances'? Sometimes yes, sometimes no. More to the point, at what character size / pixel resolution / viewing distance combinations will the 'appearances' be the same, but the visual impression be that of sub-pixel positioning? Unfortunately, no one has yet done the necessary experimentation to establish these parameters. Until then, it will be premature to respond to such questions except under very constrained circumstances. -- Avi Naiman avi@dgp.toronto.edu
peter@ficc.uu.net (Peter da Silva) (11/09/88)
In article <8811080203.AA15665@explorer.dgp.toronto.edu>, avi@dgp.toronto.edu
(Avi Naiman) explains why he needs sub-pixel positioning.
Ah. Light dawns. You're considering greyscaling as a tool in increasing
the effective resolution of a screen for the purpose of previewing a typeset
document. This is not the only application for greyscaled fonts. Pixel
positioning is fine for some applications... such as, for example, ordinary
text editing. A typical text editor only gives you character positioning,
after all. If greyscaled fonts can make the characters look better they're
a net win.
--
Peter da Silva `-_-' Ferranti International Controls Corporation
"Have you hugged U your wolf today?" uunet.uu.net!ficc!peter
Disclaimer: My typos are my own damn business. peter@ficc.uu.netraveling@vaxb.isi.edu (Paul Raveling) (11/11/88)
In article <8811080140.AA15368@explorer.dgp.toronto.edu> avi@dgp.toronto.edu (Avi Naiman) writes: > >>From my experience, I find it hard to believe that one can today >compare a screen font (regardless of whether or not there is grayscale) >with an *equivalent* hardcopy sample. ... Human perception makes it even harder to do an objective comparison. Particularly in fonts, humans often see things their mind has been trained to see based on fragmentary cues. The example I sometimes show is a 512x464 map image, digitized from a printed map, with the words "INDIAN OCEAN" printed in a clean-looking roman font. However, positioning a magnifier window over one of the N's show not only that the character is a ragged-looking array of pixels, but also that the vertical bars of the N don't exist at all! As a further exercise, positioning something such as a cursor over the serif at the end of a vertical bar causes the verticals to disappear, as observers see it. What people perceive normally is a fine line, less than 1 pixel wide, that doesn't actually exist. That perception is triggered by the pattern of serifs and the bold diagonal. Even perception of those parts of the letter that DO exist is cleaned up substantially by the observer's mind. While idiosynchrasies of perception make it harder to do unbiased evaluation of fonts, it may also be possible to employ them to advantage. --------------------- Paul Raveling Raveling@vaxb.isi.edu
avi@dgp.toronto.edu (Avi Naiman) (11/12/88)
In article <2173@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <8811080203.AA15665@explorer.dgp.toronto.edu>, avi@dgp.toronto.edu >(Avi Naiman) explains why he needs sub-pixel positioning. > >Ah. Light dawns. You're considering greyscaling as a tool in increasing >the effective resolution of a screen for the purpose of previewing a typeset >document. Not necessarily. Although previewing a typeset document is a good example, I see the trend in windowing systems heading towards more 'ergonomic' presentation of textual material. This has been amply demonstrated in 'research' prototype user interfaces which use proporational spacing, a variety of fonts and size, and context-sensitive typography. These advances are beneficial for editing, scanning, and reading all types of documents (including programs). > This is not the only application for greyscaled fonts. Pixel >positioning is fine for some applications... such as, for example, ordinary >text editing. A typical text editor only gives you character positioning, >after all. If greyscaled fonts can make the characters look better they're >a net win. Certainly. Perhaps this is merely a question of how far down the road we're looking. As a researcher, I'm considering the possibilities 5 to 10 years from now; as a developer needing to bring something to market now, I would probably concentrate on doing a 'good' job on a fixed-pitch grayscale font for a particular system. I still contend, though, that we do not understand what 'good' means yet -- in terms of the ramifications of using grayscale I discussed in earlier postings -- and that is where research efforts need to be focussed. -- Avi Naiman avi@dgp.toronto.edu
peter@ficc.uu.net (Peter da Silva) (11/15/88)
[Re: variable pitch greyscaled fonts for editing, etc...] I don't know. Maybe it's just me but my experience with wysiwyg editors for technical stuff (both programming and writing technical documentation) has been pretty uniformly negative. I hope you agree, at least, that a program should definitely be edited in a fixed-pitch font. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
hmm@laura.UUCP (Hans-Martin Mosner) (11/17/88)
In article <2226@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I hope you agree, at least, that a program >should definitely be edited in a fixed-pitch font. My programs are mostly written in Smalltalk-80, and I don't see why I should use a fixed-pitch font. I want them to be as readable as standard text... Is there any reason that a fixed-pitch font is better suited to programs ? Hans-Martin -- Hans-Martin Mosner | Don't tell Borland about Smalltalk - | hmm@unido.{uucp,bitnet} | they might invent Turbo Smalltalk ! | ------------------------------------------------------------------------ Disclaimer: Turbo Smalltalk may already be a trademark of Borland...
fox@garfield (David Fox) (11/17/88)
In article <2226@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >[Re: variable pitch greyscaled fonts for editing, etc...] > >I don't know. Maybe it's just me but my experience with wysiwyg editors for >technical stuff (both programming and writing technical documentation) has >been pretty uniformly negative. I hope you agree, at least, that a program >should definitely be edited in a fixed-pitch font. I agree that it is preferable to edit programs in a fixed pitch font. However, with anti-aliased fonts the pitch need not be an integral number of pixels. You could, for example, use a 4.5 by 6 pixel font instead of a 5x7 font, turning a 24x80 screen into a 28x89 screen. I don't think the question "Are anti-aliased fonts better or worse than regular fonts" is really the question we want to ask. In signal processing terms, the question would be "What is the best reconstruction filter for displaying text?" Up until now all we have much experience with is the box filter, where the value of the entire pixel is the value of the infinite resolution font sampled at only one point. (Really no filter at all.) I don't think that this lack of experience with other filters justifies the opinion that the box filter is the best. David Fox fox@cs.columbia.edu "It is very easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all." -Douglas Adams, "So Long, and Thanks for All the Fish"
spencer@spline.eecs.umich.edu (Spencer W. Thomas) (11/18/88)
In article <6022@columbia.edu> fox@garfield.UUCP (David Fox) writes: > In signal >processing terms, the question would be "What is the best >reconstruction filter for displaying text?" See "Filtering High Quality Text for Display on Raster Scan Devices", J Kajiya and M Ullner, Proc SIGGRAPH '81, pp 7-15. =Spencer (spencer@crim.eecs.umich.edu)
peter@ficc.uu.net (Peter da Silva) (11/19/88)
In article <703@laura.UUCP>, hmm@laura.UUCP (Hans-Martin Mosner) writes: > In article <2226@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >I hope you agree, at least, that a program > >should definitely be edited in a fixed-pitch font. > My programs are mostly written in Smalltalk-80, and I don't see why I should > use a fixed-pitch font. I want them to be as readable as standard text... > Is there any reason that a fixed-pitch font is better suited to programs ? I don't know about Smalltalk... it's a rather odd language to begin with, isn't it? According to "Bits of History, Words of Advice", it didn't even use the ASCII character set until something like Smalltalk-76 or later. In other languages it's often desirable to line up certain lexical units of the language that have nothing to do with indentation. This becomes extremely hard with a variable-width font. Tabs can help with indentation, but unless your source file contains a lot of formatting commands, how would you do this: char *macbuf[256], ungetbuf[256]; /* Buffers for pushback and macros */ char c_macro=128; /* current macro */ char *macptr = ""; /* Pointer to currently executing macro */ char *ungetptr = ungetbuf; /* Pointer to pushed-back characters */ This comment is also interesting: > I want them to be as readable as standard text... My biggest beef with variable-width fonts is prople who print programs in books and don't use a monospaced font. Having them readable as standard text makes them hard to read as programs. The worst offender is Loeliger's otherwise well written "Threaded Interpretive Languages" where he not only uses a variable width font but resorts to an ugly blocky token to indicate where significant spaces are... a quick check through my texts found only he and Wirth (of course) had eschewed monospace fonts for listings. Most switch between something like Times Roman for the text and Courier for the listings. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
crm@romeo.cs.duke.edu (Charlie Martin) (11/20/88)
In article <8811112202.AA21230@explorer.dgp.toronto.edu>, avi@dgp.toronto.edu (Avi Naiman) writes: > Not necessarily. Although previewing a typeset document is a good example, > I see the trend in windowing systems heading towards more 'ergonomic' > presentation of textual material. This has been amply demonstrated in > 'research' prototype user interfaces which use proporational spacing, > a variety of fonts and size, and context-sensitive typography. These advances > are beneficial for editing, scanning, and reading all types of documents > (including programs). I'm only peripherally (heh, heh) interested in text presentation, so I haven't been keeping up with the appropriate cog and perceptual psych literature, but it seems unlikely that sub-pixel positioning makes a whole hell of a lot of difference to perceived text quality. Current grey-scaling monitors I've dealt with have a resolution in the neighborhood of 90 d.p.i. If we have the appropriate hardware to do anti-aliasing based on some absolute position that's "continuous" --- a much finer positioning than the discrete 90 positions --- and mapped to the monitor using greyscale, the maximum error in position is still only 1 / 180 inches. Since this is less than 1/2 a printer's point, I have to *strongly* question whether this error is significant in typeset text --- because *nobody* adjusts to 1/2 a point, even in good old Benj. Franklin cold type --- and in fact, I question whether it is perceptible at all. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
john@trigraph.UUCP (John Chew) (11/26/88)
In article <2273@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In other languages it's often desirable to line up certain lexical units of >the language that have nothing to do with indentation. This becomes extremely >hard with a variable-width font. Tabs can help with indentation, but unless >your source file contains a lot of formatting commands, how would you do this: > >char *macbuf[256], ungetbuf[256]; /* Buffers for pushback and macros */ >char c_macro=128; /* current macro */ >char *macptr = ""; /* Pointer to currently executing macro */ >char *ungetptr = ungetbuf; /* Pointer to pushed-back characters */ How about: char *macbuf[256], ungetbuf[256]; /* Buffers for pushback and macros */ char c_macro=128; /* current macro */ char *macptr = ""; /* Pointer to currently executing macro */ char *ungetptr = ungetbuf; /* Pointer to pushed-back characters */ (where the comments are all at the same tab stop)? I never use right- aligned comments as (i) I think they look ugly (just my own aesthetics) (ii) I'm too used to working with limited disk space and look at the space characters needed to right-align things as an extravagant waste of disk space, and (iii) as you said, it's very difficult to do so with variable-width fonts :-). I use variable-width fonts when programming in Lightspeed (I mean THINK) C on my Mac, because I find them easier and more pleasant to read, and because they tend to be denser on average than fixed width fonts. The only reasons I would consider not using variable-width fonts are: (i) as you said, it is difficult to measure significant repeated white space (not a situation that comes up frequently in my code), and (ii) if I wish to distribute my code to more primitive systems that do not support my fonts, it will need to be re-formatted. 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}