kent@lloyd.camex.uucp (Kent Borg) (08/02/89)
In article <24101@iuvax.cs.indiana.edu> truel@silver.bacs.indiana.edu (Robert Truel) writes: > >I agree. Since apple is creating a new outline font capability in the >new system, I would like to encourage the inclusion of "fuzzy" fonts >in system 7.0. Aliases fonts should have considerably better quality >and much less eyestrain. Moreover the technology is available and >simple. Especially simple if the macintosh is creating bitmap fonts >on the fly. Want an answer in the form of a wild-ass prediction? Apple knows that fuzzy fonts are better, but Apple has *no* intention of making the new font manager output fuzzy fonts. Never. Rather, when they fix QuickDraw (i.e., give it all that PostScript can do, plus some) they will give *it* antialiasing. That way, not only will fonts be antialiased, but so will diagonal lines, circles, etc. Note to programmers: any 1-to-1 CopyBits calls will behave about the same in a new QuickDraw, but LineTo's and PaintOval's, etc., will get to take advantage of better quality, antialiased replacements. When given a choice, try to use the calls which will get better under the new QuickDraw. Avoid blitting stored bitmaps around when other QD calls will do. (Though when CopyBits-ing between different sized rects, antialiasing *will* likely help. Plus, you might well CopyBits to the screen from a depth-matched pixMap, which itself is antialiased. Things get tricky here...) When will a new QuickDraw hit? Well, I think they were at some point planning on having it be part of 7.0, but I don't know whether they still think so. Any of you have wild predictions about a new QuickDraw? Disclaimer: Apple has told me *nothing* about the future of QuickDraw. (Which tells me something--boy have they been tight lipped about it!) What I write here is an educated (??) guess. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
casseres@apple.com (David Casseres) (08/03/89)
In article <458@lloyd.camex.uucp> kent@lloyd.camex.uucp (Kent Borg) writes: > In article <24101@iuvax.cs.indiana.edu> truel@silver.bacs.indiana.edu (Robert Truel) writes: > > > >...Aliased fonts should have considerably better quality > >and much less eyestrain. Moreover the technology is available and > >simple. Especially simple if the macintosh is creating bitmap fonts > >on the fly. (I'm really answering Robert Truel's original posting, rather than Kent Borg's) Anti-aliased fonts MAY be more desirable in some applications. We don't know, because the research hasn't been done, whether they give less eyestrain -- they may give MORE eyestrain. Remember, the essence of anti-aliasing is that it removes the "jaggies" by blurring them. So eyestrain is a question, and so is readability. The only "better quality" that we KNOW about from anti-aliased fonts is that they LOOK better when you just look at them (as opposed to sitting down and doing some reading). Furthermore, the technology is not simple, especially if you are creating the fonts on the fly and don't want it to take all day. It's not worth doing unless you implement sub-pixel positioning, i.e. the ability to place a character (logically) on a grid that is finer than the screen resolution, using gray to "blur" it into the right place. This is because character positioning, not jaggies, is the main thing that makes text look funky and unreadable at low resolutions. But to do this means redoing the anti-aliasing every time each character has to be drawn, or else caching several versions of each character image. DISCLAIMER: I have no connection with the System 7.0 effort, or the outline fonts effort, or the font manager, and this posting consists of my very own opinions, not necessarily Apple's. David Casseres Exclaimer: Hey!
sho@pur-phy (Sho Kuwamoto) (08/03/89)
In article <458@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: > >Want an answer in the form of a wild-ass prediction? > >Apple knows that fuzzy fonts are better, but Apple has *no* intention >of making the new font manager output fuzzy fonts. > >Never. > >Rather, when they fix QuickDraw (i.e., give it all that PostScript can >do, plus some) they will give *it* antialiasing. That way, not only >will fonts be antialiased, but so will diagonal lines, circles, etc. Yes, I like the idea of anti-aliasing. No, I don't think we'll see it standardized in the near future. I was hoping that when the Mac II came out, they would at least implement an intelligent scaled CopyBits, but they didn't. I was thinking about this, and one of the main reasons that anti-aliasing would be difficult is that the programmer (or perhaps user, even) has complete control over the color palette. Try to anti-alias when all your colors have been set up as a rainbow + black & white. > [...] >When will a new QuickDraw hit? Well, I think they were at some point >planning on having it be part of 7.0, but I don't know whether they >still think so. > >Any of you have wild predictions about a new QuickDraw? > >Disclaimer: Apple has told me *nothing* about the future of QuickDraw. >(Which tells me something--boy have they been tight lipped about it!) >What I write here is an educated (??) guess. We've been hearing for a while about how great this new Quickdraw replacement (NuGraph? NuGraf?) is going to be. I believe it. Postscript is no prize. However, Apple hasn't even begun to issue any guidelines for future compatibility, esp with regards to color selection. At the very least, Apple should commandeer *4* colors out of any given palette, not two. Assign them to be the foreground, background, and intermediate shades. If the colors are not set correectly, anti-alising will be almost pointless. 32bit quickdraw was nice, esp the dithering, but it is only a tiny step forward, as far as I'm concerned. When the new QuickDraw comes, it will probably be completely incompatible with QuickDraw (like the new printing manager) or it will keep the old quickdraw stuff around as extra baggage, like the old color model. For example, how would you implement regions in a completely device independent manner? -Sho -- sho@risc.com <<-- more calories than a big lump of butter.
mjkobb@mit-amt.MEDIA.MIT.EDU (Michael J Kobb) (08/03/89)
In article <458@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >In article <24101@iuvax.cs.indiana.edu> truel@silver.bacs.indiana.edu (Robert Truel) writes: >> >>I agree. Since apple is creating a new outline font capability in the >>new system, I would like to encourage the inclusion of "fuzzy" fonts >>in system 7.0. Aliases fonts should have considerably better quality >>and much less eyestrain. Moreover the technology is available and >>simple. Especially simple if the macintosh is creating bitmap fonts >>on the fly. >Want an answer in the form of a wild-ass prediction? > >Apple knows that fuzzy fonts are better, but Apple has *no* intention >of making the new font manager output fuzzy fonts. > >Never. > >Rather, when they fix QuickDraw (i.e., give it all that PostScript can One thing, though, for both of you. Anti-aliasing is going to require some computation. If you watch the demo that apple has (or the one I saw, anyway) of the new outline fonts, it starts printing slowly, then speeds up as it begins to repeat characters it's already built. The demo was "filmed" on a Mac II (I don't know if it was a IIx or IIcx, but I suspect that it was) and it was still fairly slow. Now imagine throwing in all the computation for the anti-aliasing. The first characters are going to crawl. Displays with, say, 24-bit depth would be particularly hard-hit, I think. And Quick Draw won't be quick if it does anti-aliasing, either, since it doesn't use a build-once- then-reuse process... Finally, I talked to a guy from Apple about two months ago. His word was that Apple has no plans for anti-aliasing in this release. Oh, well. --Mike Standard disclaimers...
milo@ndmath.UUCP (Greg Corson) (08/03/89)
From article <2397@pur-phy>, by sho@pur-phy (Sho Kuwamoto): > In article <458@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >> >>Want an answer in the form of a wild-ass prediction? >> >>Apple knows that fuzzy fonts are better, but Apple has *no* intention >>of making the new font manager output fuzzy fonts. >> >>Never. >> >>Rather, when they fix QuickDraw (i.e., give it all that PostScript can >>do, plus some) they will give *it* antialiasing. That way, not only >>will fonts be antialiased, but so will diagonal lines, circles, etc. > I think the only real way to impliment GOOD anti-aliasing is in the video board hardware. You store 4x as many pixels and hardware average quads of pixels down to single ones. This isn't particularly difficult to do, but memory access has to be fast (althought that isn't much of a problem these days). The problem with doing it in SOFTWARE (ie quickdraw) is how to handle drawing overtop of already existing bits in a bitmap... You can't tell where the existing bits came from, their color or alignment from the anti-aliased image already in the video card...so how do you draw (accurately) anti-aliased images over top of it? The only way to do it in software AND allow random drawing of additions to the picture would be to have a "high" resolution non-antialiased off-screen bitmap in addition to the antialiased image on the video card RAM. Then you draw everything (bigger) on the off-screen bitmap, average groups of pixels as you go, writing them to the video card. It works...but is very expensive in CPU time and RAM. Doing the anti-aliasing in hardware is much more efficient and quite a bit faster...it still uses a lot of RAM, but not as much as doing a software anti-alias! Greg Corson 19141 Summers Drive South Bend, IN 46637 (219) 277-5306 {pur-ee,rutgers,uunet}!iuvax!ndmath!milo
louis@asterix.drev.dnd.ca (Louis Demers) (08/04/89)
In article <3300@internal.Apple.COM>, casseres@apple.com (David Casseres) writes: > Anti-aliased fonts MAY be more desirable in some applications. We don't > know, because the research hasn't been done, whether they give less > eyestrain -- they may give MORE eyestrain. Remember, the essence of > anti-aliasing is that it removes the "jaggies" by blurring them. So > eyestrain is a question, and so is readability. The only "better quality" > that we KNOW about from anti-aliased fonts is that they LOOK better when > you just look at them (as opposed to sitting down and doing some reading). I once heard of an experiment where people were presented two text, one on an ordinary bitmap screen an one on which the font were anti-aliased. The persons were then asked to correct the text. The text presented with the anti-aliased fonts had significantly more errors corrected than the text presented on the other screen. This study (done I beleive by IBM ... oops ;-) tend to support that readability is enhanced by anti-aliased fonts. Their report did mention something about readability, but I can't remember. Extrapolating, I would beleive that eye strain would also be reduced. ****************************************************************************** * Louis Demers * Defence Research Establishment Valcartier * * office = (418) 844-4424 * Electro-Optics Division * * lab = (418) 844-4265 * P.O. Box 8800 * * bed = (418) 839-9266 * 2459 PIE XI Blvd. * * louis@asterix.drev.dnd.ca * Courcelette, Quebec * * demers@ncs.dnd.ca * CANADA, G0A 1R0 * ******************************************************************************
truel@silver.bacs.indiana.edu (Robert Truel) (08/08/89)
In article <3300@internal.Apple.COM> casseres@apple.com (David Casseres): > >Anti-aliased fonts MAY be more desirable in some applications. We don't >know, because the research hasn't been done, whether they give less >eyestrain -- they may give MORE eyestrain. Remember, the essence of >anti-aliasing is that it removes the "jaggies" by blurring them. So >eyestrain is a question, and so is readability. The only "better quality" >that we KNOW about from anti-aliased fonts is that they LOOK better when >you just look at them (as opposed to sitting down and doing some reading). I don't have the studies, but I believe that the studies suggesting that readability increases was done either be IBM (as suggested on the net) or XEROX (my belief). However, I suggest that computer screens are not "so clear" that a small amount of controlled blurring would not be beneficial. I even remember it being suggested that the ringing done when the circuitry driving the electron beam goes from "full on" to "full off" is a major component of eyestrain, which can be relaxed somewhat by using greyscales. >Furthermore, the technology is not simple, especially if you are creating >the fonts on the fly and don't want it to take all day. It's not worth >doing unless you implement sub-pixel positioning, i.e. the ability to >place a character (logically) on a grid that is finer than the screen >resolution, using gray to "blur" it into the right place. This is because >character positioning, not jaggies, is the main thing that makes text look >funky and unreadable at low resolutions. But to do this means redoing the >anti-aliasing every time each character has to be drawn, or else caching >several versions of each character image. > Anti-aliasing merely requires generating a bitmap in a larger (double) resolution and then averaging some number of pixels (four) to determine the shade of gray to use. This intermediate step can of course be skipped when computing bitmaps from curves (the averaging being done in the process of computing the curves), but it seems that this would be a small amount of cpu time compare to calculating b-splines (or bezier curves) and grid shifting. Furthermore, there are more reasons for doing it than implementing sub- pixel positioning: It would allow oblique (italic) characters to be slanted at a less severe angle. It would remove the problem of highlighted text being completely black on a grayscale monitor (or am I the only one with this problem). It would be another first for the Macintosh software, and a huge experiment; if they really don't increase readibility, then no big deal, they go away. If they do, then Apple scores big (I see adds with pc's and people with glasses and big bottles of Excedrin vs. happy people with macintoshes :). It would give them a chance to work out the bugs before system 8. Someone else wrote: (sorry, I saved without the header) >One thing, though, for both of you. Anti-aliasing is going to require some >computation. If you watch the demo that apple has (or the one I saw, anyway) >of the new outline fonts, it starts printing slowly, then speeds up as it >begins to repeat characters it's already built. The demo was "filmed" >on a Mac II (I don't know if it was a IIx or IIcx, but I suspect that it >was) and it was still fairly slow. Now imagine throwing in all the >computation for the anti-aliasing. The first characters are going to crawl >Displays with, say, 24-bit depth would be particularly hard-hit, I think. >And Quick Draw won't be quick if it does anti-aliasing, either, since it >doesn't use a build-once-then-reuse process... I don't think that most people work in 32 bit color. Especially for text oriented things. And I am not encouraging 24 bit averaging. Two would be sufficient. Further even if it takes noticibly longer to produce the anti-aliased fonts (I believe unlikely), what you describe seems sufficient to convince alot of people to leave their macs on all of the time (if they don't already to save wear and tear on their hard drives). Bob Truel Robert N. Truel "Life sucks, of course, but it didn't have to suck quite like this" -- RJSJR truel@silver.bacs.indiana.edu truelr@iubacs.BITNET
amanda@intercon.uu.net (Amanda Walker) (08/08/89)
In article <24388@iuvax.cs.indiana.edu>, truel@silver.bacs.indiana.edu (Robert Truel) writes: > Anti-aliasing merely requires generating a bitmap in a larger (double) > resolution and then averaging some number of pixels (four) to > determine the shade of gray to use. Actually, although a 16-level gray scale is great for anti-aliasing scenes, characters are close enough to the screen resolution that you'd probably want to average 16 by 16 pixel areas (thus using a 256-level gray scale). For some time now I've been thinking about doing some actual empirical tests and actually building some anti-aliased fonts. I just seem to have misplaced the free time in which do so :-)... -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
dorner@pequod.cso.uiuc.edu (Steve Dorner) (08/08/89)
In article <24388@iuvax.cs.indiana.edu> truel@silver.bacs.indiana.edu (Robert Truel) writes about anti-aliasing being good for readibility: >I don't have the studies, but I believe that the studies suggesting that >readability increases was done either be IBM (as suggested on the net) or >XEROX (my belief). I remember seeing an article about research DEC had done in creating legible screen fonts. The claim in that article was that jaggies ARE NOT THE PROBLEM; that real benefits lie in serifs, proper letter shapes, and proper stroke weights. (Now, anti-aliasing may indeed help with stroke weights.) The fonts touted in the article were not smooth at all, as I remember. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
casseres@apple.com (David Casseres) (08/09/89)
In article <24388@iuvax.cs.indiana.edu> truel@silver.bacs.indiana.edu (Robert Truel) writes: > Anti-aliasing merely requires generating a bitmap in a larger (double) > resolution and then averaging some number of pixels (four) to > determine the shade of gray to use. I think the word "merely" is stretching it. For one thing, as Amanda Walker points out you probably want more than two gray levels in between black and white. It's going to involve significant processing and significant amounts of RAM. > This intermediate step can of course > be skipped when computing bitmaps from curves (the averaging being done > in the process of computing the curves), but it seems that this would be > a small amount of cpu time compare to calculating b-splines (or bezier > curves) and grid shifting. Calculating the curves is not the time-consuming part, as I understand it; filling the curves is, and boundary-testing is the hard part of filling algorithms. If you do multi-level gray-scaling at the boundaries, the worst part of the problem is suddenly much more complex. None of this stuff is impossible; but if you have to recreate a multi-level pixmap each time you draw a character (with sub-pixel positioning), and you don't want performance to go down the drain, it's a hard problem. David Casseres Exclaimer: Hey!
mjkobb@mit-amt.MEDIA.MIT.EDU (Michael J Kobb) (08/09/89)
In article <1989Aug8.151335.8232@uxc.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > >I remember seeing an article about research DEC had done in creating legible >screen fonts. The claim in that article was that jaggies ARE NOT THE PROBLEM; >that real benefits lie in serifs, proper letter shapes, and proper stroke >weights. (Now, anti-aliasing may indeed help with stroke weights.) The >fonts touted in the article were not smooth at all, as I remember. However, you will note that unless you have very high screen resolution, you cannot display proper serifs or even really good letter shapes. Meanwhile, if you anti- alias, you can use a gray pixel where a serif is supposed to appear, and the eye will interpret it as a serif. Also, by using gray pixels, you can make the eye perceive finer variations in letter shape, and of course, stroke weight. --Mike Standard disclaimers...
landman%hanami@Sun.COM (Howard A. Landman x61391) (08/17/89)
In article <3300@internal.Apple.COM> casseres@apple.com (David Casseres) writes: >Anti-aliased fonts MAY be more desirable in some applications. We don't >know, because the research hasn't been done, whether they give less >eyestrain -- they may give MORE eyestrain. Remember, the essence of >anti-aliasing is that it removes the "jaggies" by blurring them. So >eyestrain is a question, and so is readability. Readability is *NOT* a question. Anyone who has spent more than 1 minute looking at aliased and antialiased fonts at the same (small) size will know this without having to be told, but the research supports it also. Readability is measurably improved. Some research *has* been done into the eyestrain issue. The initial indications are that antialiasing reduces eyestrain, but further work is needed. >It's not worth >doing unless you implement sub-pixel positioning, i.e. the ability to >place a character (logically) on a grid that is finer than the screen >resolution, using gray to "blur" it into the right place. Yes. That's why Sun's new GX graphics card implements quarter-pixel positioning for text and graphics. (Now if I could just afford a SparcStation to stick it in ... :-) Howard A. Landman landman@sun.com
casseres@apple.com (David Casseres) (08/18/89)
In article <121923@sun.Eng.Sun.COM> landman%hanami@Sun.COM (Howard A. Landman x61391) writes: > Readability is *NOT* a question. Anyone who has spent more than 1 minute > looking at aliased and antialiased fonts at the same (small) size will > know this without having to be told... I have done that, and I do not know any such thing. I do know that the antialiased fonts look nice, but to assess readability requires a whole lot more exposure than 1 minute (I've had maybe 5). > ...but the research supports it also. Readability is measurably > improved. I guess there is some difference of opinion on the scope and quality of the research. What I've seen has been either very sketchy, or mostly made up of unsupported assertions. Readability is rather difficult to define in a rigorous and meaningful manner, and even more difficult to measure objectively. Perhaps you've seen research that I'm not aware of; I'd love to see it too if that's the case. David Casseres Exclaimer: Hey!