Welcome to Typophile
Please Sign in.
@Karsten: I think with goal 1 and 2 you are describing two mutually exclusive goals similar to what I illustrated in §6.1.0 “Trueness” to the Outlines, with the exception of the actual sub-pixel downsampling filter which I generally cannot choose. In said illustration a range of “hinting” strategies are shown with increasing “trueness” to the outlines, for a range of rendering methods, point sizes, DPIs, and gamma corrections. The range of “hinting” strategies and the combinations of buttons are not conclusive or complete, but hopefully comprehensive enough to hint at the flexibility of what “hinting” can do. A similar table is in §6.1.1,
The fact that we are debating rendering methods and the pros & cons of “hinting” at all corroborates my understanding that we (still) don’t have enough pixels and hence we have to find workarounds. Workarounds represent compromises of some sort, and they don’t work equally well for every end-user and in every application. For instance, in a print preview scenario I may prefer a rendition that is closest to the outlines and the page color I’m about to get from the printed page, while in an online reading scenario I may prefer the highest stroke density or rendering contrast.
These are some of the options I may want to have, others may want other options, more options, or fewer options, just so long as their preferred method is among the options. Some people seem to get fits with the slightest hint of a color fringe, some cannot use any anti-aliasing at all because this disables their screen readers, at which point the most typographically correct page color and the truest-to-the-outline rendition become an accessibility obstacle.
Whether having options is the source of any problems Microsoft may have, or an ansatz for making typographic peace and provide for accessibility, what this engineer sees is a number of problems and hence he is looking for solutions.
“Most designers just want to design type, not program TT instructions.” Sure! Most musicians just want to make music, not repair their violins, tune their pianos, or record their demo tapes. They hire luthiers, piano tuners, or recording engineers to do the job.
With a little bit of homework about acoustics, microphone placement, and recording devices, they can record their own demo tapes, simply because the resolution of these devices has become high enough that dealing with “digital” has become a non-issue.
Not the same with fonts: We still have to deal with “digital” and with tools that bridge that gap, or try to bridge that gap. I won’t blame anyone for not wanting to program TT instructions—I don’t exactly “enjoy” it either. It’s a means for getting the job done, hence I deal with it—period.
Beat> Unless, of course, Apple’s example reflects your preference, in which case hinting is a non-issue.
Sometimes... I wish I was just a user ;)
Beat: The fact that we are debating rendering methods and the pros & cons of “hinting” at all corroborates my understanding that we (still) don’t have enough pixels and hence we have to find workarounds. Workarounds represent compromises of some sort, and they don’t work equally well for every end-user and in every application.
Nor, it should be added, for every font for every end-user in every application. The one-size-doesn't-really-fit-all-but-we'll-act-as-if-it-does approach to text rendering employed by the OS, application and device makers is failing readers by making it impossible for font developers to optimise type even for one environment, let alone multiple competing environments all pretending to be the one size that fits all.
J.H.> The one-size-doesn't-really-fit-all-but-we'll-act-as-if-it-does approach to text rendering employed by the OS, application and device makers is failing readers...
You make unreadability seem like a pandemic, when in fact "the OS, application and device makers" is pretty much limited to the sector of Windows users on low res devices. Vast sectors of whom you site are fine, including Kindle users, iOS users, desktop Mac users, I assume higher resolution mobile Windows uses are fine as are Windows desktop uses above 120, or is it 144 dpi?
So, the ugly problem is when defining "the web" as a product target for font development. Then that ugly sector is right in the middle of the target, and there is no help but that found in letter drawing, variations on a style and simpleton hinting.
E.S.> ...Zuzana Licko’s contribution to quantising, which she did when she designed Base 9 and Base 12 in 1995.
For sure, and in fact your comment spurred me to revise my classifications of quantizing to include "for purely stylistic reasons independent of resolution completely."
Good points. Getting the font to work on one’s low-res computer doesn’t guarantee making the best out of the font design on the iPhone, iPad, Droid, Xoom, or Kindle, to name but a few, and vice versa.
True of absolute quantizing, but the combo of relative quantizing, and optical design for small sizes goes far in getting fonts to work on the web.
Or a least that's what I hear from FB RE users at Webtype.com, even on windows.
The scary issues are that: even if you "go RE", or if rendering did suddenly use x hints everywhere, there are still a lot of "holes" in people's abilities to get good web font quality. another scary issue is that low res trag has as much negative effect on the white as on the black. Because it's proportionally less, there being more white than black even in the noodliest kanji, white's less prone to error evidence than black. As much as we think blacks out of control, white is really out of our control In web type unless, its completely surrounded by black.
But that's not even the scariest thing, much of this thread is concerned with the stuff between black and white. What the hintish sing is that the white is the world, black bringeth content and "grey" is presentation. That's kinda broken on windows text to some extent for the long term, and according the hintish, it's not getting much better w/DW. Which does take us to the scariest thing they sing, "subpixel position in x, and we never know what will come next, do it in y and you can kiss content goodby."
Keep in mind, the hintish don't care a walloon's summer gob for much besides text, and text at low res, as is their hintish way. But they warn that if "anyone's" next move is to go sub pixel in y, in low res text, there could be an up-y-zing from the hintish, as there'd be nothing left to do but draw funnier letters than ever in the history of funny letter drawing.
David: You make unreadability seem like a pandemic, when in fact "the OS, application and device makers" is pretty much limited to the sector of Windows users on low res devices. Vast sectors of whom you site are fine, including Kindle users, iOS users, desktop Mac users, I assume higher resolution mobile Windows uses are fine as are Windows desktop uses above 120, or is it 144 dpi?
Some readers in some of those environments are ‘fine’ with some fonts. That was my point: Beat had only identified the ‘end-user’ and the ‘application’ as variables, whereas every single typeface design is a variable. In some mobile device environments, the availability of different fonts is still so limited that we won't know what problems exist for varied typography until we hit them. [The fonts you made for the Palm Pre, for example, are very good, but I have no idea how other fonts will behave in that environment because it isn't possible yet.] I know from my own experience that reading on the Mac desktop is not ‘fine’ for lots of fonts, through no fault of the fonts which, ironically, are sharper and with better stroke density for ‘the sector of Windows users on low res devices’ because of the hinting that Apple is not applying.
I'm not debating that it is possible to create fonts for any particular environment that will render well in that environment and, at sufficiently high resolutions, in other environments too. You do it; I do it. What I am suggesting is that the demand of those environments that any typeface thrown at them will be rendered in the same way -- with y-direction smoothing whether appropriate or not, with sub-pixel positioning whether appropriate or not, and, yes, without access to variations whether appropriate or not -- force compromises too far for many fonts. Mere readability can always be addressed by using a different font, but then readability can be addressed by always using Georgia and Verdana everywhere. Typography can't be addressed in that way: it needs to admit of variety and that means being able to render individual fonts in the way best suited to those particular fonts. And serving readers means more than merely serving readability.
David: another scary issue is that low res trag has as much negative effect on the white as on the black. Because it's proportionally less, there being more white than black even in the noodliest kanji, white's less prone to error evidence than black. As much as we think blacks out of control, white is really out of our control In web type unless, its completely surrounded by black.
In subpixel rendering, the ‘white’ can be very problematic because it is in fact blue and orange and yellow etc. and the amount of colour bleed in nominally white areas relative to stroke thickness and proximity at text sizes is such that the colour bleed off one black stem or terminal ends up affecting the rendering of nearby black stems or terminals, even though there is something like a full pixel distance of nominal‘white’ between them. This is something I've been struggling with recently in bold weights of Bengali.
In effect, the white space between two proximate black features is a small impressionist landscape.
J.H. >The fonts you made for the Palm Pre... I have no idea how other fonts will behave in that environment because it isn't possible yet.
1. It's webOS-based, so it's open to @FF as far as I know. 2. the resolution there is high enough so that most fonts will work within whatever size range they are targeted for, i.e. with optical adjustments and not quantizing.
In general, I'm not at all worried about type quality on mobile devices. If it's a smart device developer, the resolution should simply disappear to the user. And for the most part, when the resolution disappears to the user, the font issues do to.
J.H.> ...Georgia and Verdana everywhere[!] Typography can't be addressed in that way: it needs to admit [a] variety and that means being able to render individual fonts in the way best suited to those particular fonts
Too bad now. You should 'ave joined my anti-OFF, anti-WOFF and anti-CT, pro-EPAR Chicken Little dances when the sky was still supportable...for Latin.
J.H.>I've been struggling with recently in bold weights of Bengali.
For non-Latin 3rd party web fonts on Windows, the prognosis is likened unto a candle in a substantial wind. There are non-Latin issue far more scary than anything I've said here. It seems like MS doesn't care to serve the far east in the long run?
This was all generally worse before Apple returned to the TT spec a few months ago and allows overlapping contours again. Having each platform broken in it's own way, was almost too much for me to take. Just imagine targeting a Kanji font for the web, where one platform demands hints, and the other demands continuous non-overlapping contours:o
J.H.>...the ‘white’ can be very problematic...
I understand but again, there is relative and absolute white. Once a user adjusts to local "white", by running their biological pre-program, they're off saccading. Adjusting to local "black" has been made into another issue, as we all know.
J.H.>...a small impressionist landscape.
This must involve curves? My experience with most little white anti-aliased spaces is that they get more Mondrian than Matisse?
Beat: “For RGB rendering, blue (#69B5E9) on orange (#FFD093) yields 1.57:1”
There is the exact same color of the whole pixel and the same contrast of the whole pixel for this combination on both RGB and BGR screens. Your calculations include only whole pixels, but doesn’t include the positive subpixel effect which is not only lost but made worse on BGR screen.
Here is an example of single “stems”, one column has reversed colors. Using only whole pixel colors one would calculate the same contrast for both combinations in a row. But one column is always noticably worse. I think that the order of subpixels also effects the contrast ratio.
I think numbers are apropriate but along with a visual representation of blurriness and contrast. First, I tried to illustrate the relation between them eliminating all other variables although weight is also increasing (it’s far from perfect, specially middle column):
If defined mathematically, blurriness could be expressed as absolute or relative (when depending on dpi and stem size). Thinking a little more there are different levels of blurrines even with the same filter – blurriness also depends on the strenght of colors (which is a user setting in CT). Which means that correct mathematical description includes two numbers, which becomes more unintuitive … probably. So I made greyscaled images, magnified three times. Each subpixel is represented as a grey pixel with the matching lightness as defined in Lab color space (simply desaturating is less accurate).
The last image is the comparison of two letters that David and Mike posted and which were compared here.
What I am interested in is what does it all mean when classified through legibility and how well is the design of a typeface preserved. This are two different goals, and such black & white distinction can be useful, but I can see so much possibilites in between … somehow similar to text typeface design for print where there are many levels of how legible yet different a typeface is. Some designers choose to make optical sizes or grades which is a high level of control. With current rasterisers it’s like choosing one option for everything, even if I imagine the limits of resolution.
The negative effects of blurriness and reduced stroke density can be seen in very small sizes. What I am wondering is what are the positive sides? If we see the blurriness through the lens of how well are stems fitted to the grid, it is bad. But the goal of gridfitting is having high legibility which is primarily achieved through letter forms with high stroke density and sharpness. On the other hand this makes glyphs more similar and makes spacing worse – the problem is in definition what is the most appropriate for each size and to what extend. This two properties are directly connected to reduced legibility, and the criterion of how much are glyphs similar to their true design wasn’t included.
John: “In effect, the white space between two proximate black features is a small impressionist landscape.”
Beautiful, isn’t it :-)
miha> I think that the order of subpixels also effects the contrast ratio...
Excellent. Perhaps you can mathematically prove that this order is related to reading direction, and then we'll be finished with this issue of low resolution ideals in type, and some other screen readability issues, for all time:)
Nooo, that means no more rendering threads on Typophile, I like them :)
Lol, then take it as a more limited "we". With the semi-random fringing of CT like dried concrete up to their ankles, and the fully random fringing of DW like almost-dry concrete to their navel, there will be no end of someone's desire to discuss rendering. I'll be done though.:)
@Miha: If you must test my ability to process numbers, re-read my http://post (“[…] text rendered for a BGR screen is viewed on an RGB screen” […]).
But you’re missing the point of the ‘ill’ example: We are at the limit of what can be resolved by pixels. Whatever you see rendered is a compromise. And debating the relative merits of one’s favorite compromises is supremely futile.
One of the main points I’m making in the Raster Tragedy Revisited is this: “Hinting” is not about deltaing pixels nor about touching up undesirable color fringes. At the limit of what pixels can resolve, “hinting” in TT is programming strategies that enable a spectrum of favorite compromises.
This is possible, even with the Windows rasterizer that I had to compromise for the sake of shoehorning existing fonts with their notion of “hinting” into ClearType duty. This is only partly possible if the application forces sub-pixel positioning at the resolution limit. This is not possible at all if the operating system ignores all instructions at the resolution limit.
What I don’t know is why an app or OS would do this:
Without genuine answers to any and all of the above I’m afraid we’ll continue to move in circles.
Beat> But you’re [miha] missing the point of the ‘ill’ example: We are at the limit of what can be resolved by pixels.
Exactly my experience, though we're beyond said limit in practice. The only safety for "single stroke" glyphs on Windows, is to design them as wide as possible, without of course making it obvious. You see people doing something like this in font design, though obviously, when they add serifs to single stroke glyphs that would normally be serifless. Using some-serifing from the start of a design can work, but stylistic bastardization can be the result otherwise.
The bottom line, is that hints, CT, and sub-pixel positioning, on Windows, do nothing much to help this ill thing in many sans, at the bottom of the size spectrum.
@eriks Thanks for that. ironically i actually still have the emigre poster the article was printed on! :) duh, of course hence the names 'base 9' and 'base 12'
"Zuzana Licko’s contribution to quantising, which she did when she designed Base 9 and Base 12 in 1995."
I still think there's some mileage in the approach of getting key point sizes of a design to gridfit in order to aid hinting & rendering in the intermeadiate sizes. In practice it does seem to make the autohinting of x-heights, baselines. caps go relatively glitch free.
>I still think there's some mileage in the approach of getting key point sizes of a design to gridfit in order to aid hinting & rendering in the intermeadiate sizes
If there were key sizes, as opposed to one, and it's whole multiples, or, if these had any effect on the unhinted appearance of the intermediates, this'd be a great suggestion — really! ;)
Curcio1, C., A., Sloan, K., R., Kalina, R., E. & Hendrickson, A., E. (1009). Human photoreceptor topography. The Journal of Comparative Neurology, 292(4), 497-523.
Che resolution? ;-)
La resolución que no tenemos, pero pues que todavía podemos reconocer la cara del muy famoso líder, nos dicen que ya no la necesitamos. Deberían bastar pocos pocos píxeles para todos…
Che, rendered at 24px
How about at 12px?
Still recognize his face? How about this one at 12px?
Would you like to try 24px?
Common, that’s like body text at 200 DPI…
¡Viva la resolución!
Che as a pun for Que ;-)