New to Typophile? Accounts are free, and easy to set up.
Create an account
Typophile RSS | More Feeds
All fonts from Just Another Foundry are now also available as webfonts:
i love the Facitizer. Such a great concept for previewing the font in use.
Yep, it's brilliant Tim.
Also, I see you are hedging your bets one which spelling of "web font" wins out. ;)
The Facitizer is very cool. Look, Ma, I'm being all self-referential.
Wow, that crashed Chrome, John. Firefox handled it, tho.
Thanks for the comments! Oops, hadn't thought about recursions. Should be quite easy to fix that in the code.
As to the "webfont" vs "web font" question, I wasn't aware of my inconsistencies. See my reply over in the other thread.
Congratulations, Tim! Only Facit Web mentions “hand hinting”. Is it optimized for Cleartype or Greyscale rendering?
Frode, Facit Web only contains TT-hints in vertical direction but they are set/checked manually, all styles, all glyphs. You could call y-only hinting "optimized for Cleartype" but this is a bit of an euphemism.
I will investigate into serving CFF-based WOFFs to Firefox 3.6 on Windows for some my webfonts, which seems to render a bit better.
Basic hinting or size specific delta hints?
I have not used delta hints but I wouldn't call it "basic" either.
Delta hints are not necessarily a sign of good hinting. I consider them more of a fix if you don't get things to work otherwise, and if you try hard you nearly always find a solution using size-unspecific hints.
Have a look at the R of Facit Web Semibold:
I think it works quite well across all sizes but it isn't a trivial solution either. Should I interpolate the upper of lower edge of the middle stroke? Which endpoints work best for the interpolation? Rounding distances, destinations, up or down, or not at all?
It takes quite a bit of trying out things so it's probably not much quicker than working delta hints. It just feel a bit cleaner to me.
Frode, there are different kinds of delta hints. Outline delta hints move either individual points (final deltas) or sections of outline (medial deltas), and are used most in hinting for b/w rendering and some aspects of greyscale. In what I think of as ‘subpixel hinting’ or ‘CT hinting’, far fewer delta hints are necessary (and the CT renderer by default ignores all x-direction deltas anyway), and as Tim notes one should only use deltas to tidy up situations that other kinds of hinting have not resolved as you would like. Since GDI ClearType treats the y-direction as if it were b/w rendering, i.e. without any antialiasing in that direction, there may be some situations in which y-direction outline deltas are needed. [DWrite ClearType applies y-direction greyscaling in combination with x-direction colour antialiasing, so is more forgiving.]
It is also possible to delta alignment zones, e.g. to pop up or down the x-height at a particular size.
It is worth pointing out that much depends not only on the style of the typeface but also on the writing system. A great example of this is the MS Meiryo font, which uses y-direction outline deltas to apply traditional stroke reduction techniques to maintain legibility at small sizes.
This looks very cool Tim!
>Should I interpolate the upper of lower edge of the middle stroke?
I'd go with the upper, rounding it slightly up to grid ("sround 73", e.g.) after interpolation.
>Which endpoints work best for the interpolation?
Interpolation of what? Or, be sure the reference points you use have been rounded or interpolated into their final places, and then you can use them to locate other points, and then those points can be used as references to interpolate as well, if required.
>It takes quite a bit of trying out things so it's probably not much quicker than working delta hints.
Well, delta hinting your way to size independent outline fonts for the web is sad, and not likely to last long as this is not only size, but rendering dependent.
@John: I need to try my hands at this very soon. I’m afraid all my stupid questions are driving you guys mad.
This looks very good, Tim.
I kind of hate webfonts… I just don't think there's enough resolution on computer screens for this to work! No amount of anti-aliasing will change that. Type is supposed to be black on white, not black with multi-coloured or grey halos on white… why are we forcing this…? Anti-aliased type on screen at small sizes, it just doesn't cut it.
I get it, we want to be able to use any typeface on our websites; and that's fine and logical and even a bit noble, to allow that freedom, but it only works with anti-aliasing turned on and some people (ok, “I”) don't want anti-aliased small text on screen and never use it. With no anti-aliasing, JAF's menu on the left and the text under the samples looks like some free font with uneven stroke widths all around. The same happens, for instance, at FontFeed, and SomeRandomDude, which I discovered just the other day, is a mess… some smaller italic texts can't even be read (that's on Chrome, mind you). I don't want to be forced to use anti-aliasing to be able to read stuff…
I do really like Herb, though! Gorgeous! And Lapture's nice. And the Facitizer's a pretty good idea, despite what I think about the subject.
Sorry for the rant. :X
rDm>I don't want to be forced to use anti-aliasing to be able to read stuff…
You are not forced... compelled perhaps. You can make your own style sheets, you can turn off other people's fonts, you can compel your browser to use your choice and size.
Nevertheless, I hear you stating the obvious, the web text bug is a whole lot bigger than the millenium time bomb that didn't even seem to go off.
It is also possible to delta alignment zones, e.g. to pop up or down the x-height at a particular size.
This is something I seriously considered (and tried) but in that particular case, it didn't seem to improve things.
However, I used this tweak: the tips of the ascenders and descenders are always rounded towards the baseline, so they tend to get proportionally shorter in small sizes. Some kind of primitive optical sizing.
I'd go with the upper, rounding it slightly up to grid ("sround 73", e.g.) after interpolation.
I did try that but it didn't feel right to me. This is a more of stylistic decision: in this particular font, I prefer the middle stroke rather a bit too low than too high.
Or, be sure the reference points you use have been rounded or interpolated into their final places, and then you can use them to locate other points, and then those points can be used as references to interpolate as well, if required.
This is more or less how I did it. I found that in some cases, un-rounded points (attached to a rounded point with an unrounded single link) can be useful as an endpoint for interpolation.
I fixed the recursions and many other little things in the Facitizer.
Btw, this one works in a similar fashion. Unfortunately, I couldn't get it to work in combination with the Facitizer.
>Also, I see you are hedging your bets one which spelling of "web font" wins out.
While I think it's an extremely wise idea for producers and customers like for font shops to keep their "web fonts" and "print fonts" separate, unless what I'm trying to say absolutely demands the distinction, I'm trying to drop the "web" out of "web fonts" as much as I can.
Fonts are fonts. As time goes on, those charged with design will learn what the screen demands and what the printed page demands. "Web fonts" invites vaguery. It's too broad and can mean too many things.
Hey, I'm just sayin'...
See here, Ruben.
Congrats on the service and the facitizer.
In comparing the facitizer to what I recently saw from Extensis - their Type Drawer previewer - is there any way to select the blocks of text that you would like to see swapped out? (And then, in a true miracle, pop up a set of controls for editing line-height, word spacing, etc...?)
Even so, the facitizer is a nifty marketing device. Nice.
Thanks, Frode. That's really a bit too technical for me, and I think the point's being missed. Maybe I'll just create a new thread. Or maybe not, why bother? :P
I'm so sorry for hijacking your thread, Tim; I really do commend the efforts shown by JAF, regardless of all this, and I do think the Facitizer is great.
In fact, I think it's perfect that you're offering your whole collection as webfonts and that you're even offering to even work with other fonts; that really is what should be done. All fonts should be ready to “withstand the test of web” – I'll go further and say “aliased web” –, even if they were designed with maybe a newspaper or display applications in mind. I also don't think that we should treat typefaces which will be used by “the common user” in Word or whatever, mainly for printing, as needing less hinting, because these people (i.e., my parents) utterly reject the use of better-suited typefaces based precisely on what they see on the screen, which sucks unless you're using Verdana or Georgia – and never corresponds to what is then printed – (and we call them WYSIWYG), which then leads to everyone printing everything in Verdana at large sizes, since these people sometimes also do not realize that there's a zoom control on the program and do not have the sensitivity to imagine the page on screen as the final printed page. They just use Word as if they were using Notepad and whatever comes out the printer's fine – this is of the responsibility of OS makers and typedesigners alike, because we were trying to make things just work and, in a sense, we failed.
It's actually kind of funny; developers created Verdana so that we'd have a great typeface for the screen and ignored the need for every typeface to look good on screen, which then leads to people assuming that Verdana is the only typeface which you can actually read and then writing and printing everything with it, when it was in fact created mainly (maybe that's a bit of an overstatement, but still) with the screen in mind. They shouldn't have to know that the media are fundamentally different. It shouldn't matter.
Then we get historians and graphic designers saying that the democratization of text-composing and printing led to a substantial downfall in the quality of the printed work. Ironic! That's in some part due to the fact that the techniques didn't actually evolve (as in “weren't developed”) into being easy to use and intuitive; in many ways we are actually still using metal type, just in a less physically and more mentally/virtually extrapolated cumbersome way.
Maybe I'm just an idealist… :P
I should stop writing, now.
I think the problem with your comment is you assume forcing delicate shapes into a strict pixel grid is a better solution.
Frode: ...you assume forcing delicate shapes into a strict pixel grid is a better solution.
In order to judge the quality of a solution, it's necessary to understand what the problem is that it tries to solve. Forcing ‘delicate shapes’ into a b/w pixel grid is surely a lousy solution to individual typeface fidelity, but it can be an excellent solution to readability on screen. Ironically, the more delicate the shapes, the more likely that they will be unreadable at low resolution unless they have the delicateness hinted out of them and fitted to a grid like a virtual Verdana.
It used to be the case that hinting was what made screen fonts, and the TT hinting language is powerful enough that the typeface design didn't matter a heck of a lot: you could take a print media typeface like Times New Roman, ill-suited to screen readability, hint the heck out of both outlines and spacing, and get something pretty readable on screen. [Indeed, the hinting language is powerful enough that David could make Augsburger Initials legible at text sizes on screen. Don't try that with FontLab, though.] Non-linear and subpixel antialiasing has killed that approach. It greatly improves WYSIMLTIT -- what you see is more like the individual typeface --, but at the cost that hints won't get you from a non-screen type to a screen font any more. So if you want halfway readable text on screen, you have to start with a design for screen. And if you want optimised readability, then you have to start with a different design for each size.
Right. What I mean is more or less what John said: of course it is not a better solution if you're the typeface, but it does make for better reading. That's sad from our point of view, but unless we successfully lobby computer manufacturers and the whole world to up the pixel count and the resolution, that's something which seems inescapable, to me.
The pixel grid will not allow many variations, of course; at some point, with a relatively small number of typefaces, you will have had all the possible variations on each glyph, since we're talking about fixed shapes and a small area of pixels. But that's how it goes, I don't think there's any way around it. I don't feel great about sacrificing the identity of a typeface either, I don't. I feel you, there. But in the end this isn't about the typeface or its designer, it's about the reader and the reading experience.
Don't take me the wrong way, Frode, I didn't mean to criticize anyone. I'm well aware that things aren't as simple as I put them. But I've thought about this and don't see any other way around it. We can improve the screens and forget hinting forever, improve hinting and make do with what's possible, or stick with Verdana, Georgia and friends. Right now it's a battle that can't be won. Not at small and medium sizes on a pixel grid, anyway.
But that's just my silly point of view. I'm not trying to revolutionize anything or to end anti-aliasing (I wouldn't if I tried, I mean, I'm no one); I'm just stating what seems to be obvious but often forgotten or ignored so that it's out there. From what I read I never see this acknowledged and accepted. Sometimes it seems as if anti-aliasing is wonderful, and I really don't see it. I don't think it is. Again, I mean at small and medium sizes. At large sizes, yes, it's great and it works, because then we're talking about smoothing which isn't larger than the stroke of the letter itself.
...unless we successfully lobby computer manufacturers and the whole world to up the pixel count and the resolution...
The resolution of smaller, mobile devices is increasing significantly. The trouble for larger, compuer screens is that as resolution goes up the attrition rate also increases. The more pixels you squeeze into a screen, the more screens you end up having to junk because of dead pixels or other manufacturing failures.
But in the end this isn't about the typeface or its designer, it's about the reader and the reading experience.
We can improve the screens and forget hinting forever, improve hinting and make do with what's possible, or stick with Verdana, Georgia and friends.
Or we can design device size and rendering environment specific typefaces. In effect, we can do at the outline creation stage what we used to do at the hinting stage.
No worries, Ruben. I did not take your comments as critizism. I’m not sure which way is best. Blackness is not the only factor to effect readability. I consider lettershapes and spacing more important, but I’m far from an expert in these matters.
In some way, our critique is not primarly of webfonts. The problem is screen resolution vs. rendering.
John, I’ve been experimenting with size specific design, but my knowledge is really limited.
Frode: Blackness is not the only factor to effect readability. I consider lettershapes and spacing more important...
If shapes and spacing are important to readability -- as they surely are --, then that must be for a reason, having to do with how they contribute to word recognition in our perceptual and cognitive systems. Shapes in our perceptual field have spatial frequency, and changes in stroke density affect spatial frequency as much or more than changes in stroke thickness and distanct. This suggests to me that, in reading, there is no shape recognition independent of stroke density.
Now, I think it is relevant to this discussion that for many hundreds of years textual communication involved media in which sign shape and spacing were inconsistent, not only in the inevitable variation in manuscript writing but also through most of the history of printing due to uneven inking, worn sorts, etc.. The historical period of near-perfect repetition of shapes in printing and the regular repetition of bitmaps on screen is very short. But what has always been much more consistent than sign shape -- until the advent of antialiased text on screen -- is stroke density. So I'm inclined to think that stroke density is at least as important as shape and spacing, and probably more so. This is why I think ClearType is better than Apple's full fuzz rendering, because it does a better job of maintaining perceptual stroke contrast.
As stated, John, I’m no expert.
So I'm inclined to think that stroke density is at least as important as shape and spacing, and probably more so.
Up to the comma it’s pretty much what I said. Basically: They all play their part.
>John, I’ve been experimenting with size specific design,
>but my knowledge is really limited.
Zoom is the enemy. If the interface were to allow the reader to choose from among a predetermined set of sizes - which in most instances is perfectly acceptable and adequate for accessibility - size specific design would be a lot more practical to implement.
But "page zoom" has become preferred over "text zoom". And with extremely small screen sizes like those on mobile browsers and touch interfaces, it's easy to see why it won out. No need to give up screen real estate to a resizing widget with a menu, and it's the kind of thing that computer algorithms do so well - recalculate. Readers might lose out, designers might go nuts, but this is what we've got. The machines won this round of the readability wars.
Wait, there might be a second round on this one.
JH> In effect, we can do at the outline creation stage what we used to do at the hinting stage.
Okay! I demonstrated an antialiased series in Franky (which is proofed on some thread here somewhere).
Your turn! You demonstrate an aliased quality outline font series. And don't forget the fractional sizes.
David, I was talking about the process for making optimised screen fonts then and now: using hints vs using outlines. I didn't mean to imply that screenfonts now are going to look the same as screenfonts then. The renderers have changed and we don't have the options we used to have. I don't know of a reasonable way to make an aliased quality outline font series in a forced antialiasing environment such as Windows with CT smoothing enabled. With a carefully chosen UPM value, evenly divisible by pixel height, and a squared up outline one could minimise outline haze on full pixels at a specific size, but I don't think that technique is extendable to a series because the UPM would need to change for each type size and that does my head in.
Here's an example of pseudo-aliased outline designs rendered in GDI ClearType. As you can see, even without curves and with the outline snapped to a strict grid there is a pale colour fringe due to the way the CT filtering works.
Way to go, Tim!
Thinking about pseudo-aliased outline fonts some more:
The easiest way to produce these at a range of sizes might be to first hint a selected typeface for aliased rendering, then use a bitmap striker to create a size instance, then tightly trace the bitmap at the target UPM grid. A considerable amount of this process can be automated.
[I've thought before that, if I were a type designer and wanted my typeface to work perfectly on screen without losing much of its personality – and it's likely that I would, depending on the uses of the typeface, of course –, I'd rather have some format in which I could have not only the outlines but then also a bitmap font for every size I wanted that would be called unto action inside programs; something could know the height of the glyphs and just use the right bitmap font. Hinting seems too complicated, variable and time consuming, I think I'd rather draw all the glyphs by hand in various sizes just by clicking specific pixels. I'm just saying. :P This is a bit why I did Leiria, I loved designing it and I love using it as my Notepad typeface of choice.]
rDm> I'd rather have some format in which I could have not only the outlines but then also a bitmap font for every size I wanted...
Look, you are not against antialiasing, just poorly hinted antialised fonts. Hints are perfectly capable of delivering screen fonts as good as any bitmap, aliased or antialised and you'd not know the difference.
JH> ...use a bitmap striker to create a size instance...
Perhaps, but if you return to your thread on the MS Cleartype white paper, what you'll read from Mr. Hitchcock is that we're only given the option (on windows), to turn our size independent hints, or our size independent hints greatly compressed by function definitions, into incredibly verbose size dependent hints. So normal hints are X, compressed hints are X/2 and Greg's suggestion for the quality-minded (which includes many millions of Windows users besides rDm), is 16-25X.
Since the appearance of the fonts does not change a bit from one hint scheme to the next, the disservice this offers is focused on Windows web users, where file size is a factor in the quality of experience. I'm told this could get much uglier if I really, really want it to, but I've promised to flip a coin when the time comes.:)
JH> ...there is a pale colour fringe due to the way the CT filtering works....
But did you know, you can diminish this effect by using the type on a yellow background ;p.
RF> Zoom is the enemy.
And all this time, I thought near-ignorance (aka a little bit of knowledge), was the enemy. Thanks!
Tim, the facitizer -- Brilliant! :)
So, Ikea took Futura away from us? Just Another Foundry is bringing it back!
I thought that was worth a thread of its own:
Sorry, couldn't resist the tempation. Btw, for the actual Futura fonts, I had to resort to Fontdeck.
David, I'm not disagreeing with your comments regarding the size impact of subpixel oriented hinting, but I'm not sure how relevant they are to what I've called pseudo-aliased outline screen fonts. I'm talking about using as a source fonts that have been hinted for b/w, aliased, full pixel display, and then wrapping size-specific outlines to those pixel patterns at size-specific UPM values to minimise fringing (the latter method might also apply to antialised size-specific fonts, no?).
The ab example in my illustration doesn't have any hinting at all. It also has no curves. File size for such a font would be pretty minimal for an outline font.
Here's a comparison of, top, 12ppem Georgia aliased; middle, GDI CT'd; bottom, pseudo-aliased.
There's an interesting perceptual effect: the colour in the CT'd rendering is more obvious the closer you get to the screen, while the colour fringing in the pseudo-aliased is more noticeable at a greater distance and less noticeable at closer range.
Well, that's enough of that.
Propose: new gasp table version for embedded bitmaps in CT environment.
I said to myself, I shouldn’t participate in every rendering thread, but this is just getting too interesting.
colour fringing in the pseudo-aliased is more noticeable (John)
True – but this also happens because of the wrong colors: either yellow color is too bright or blue too dark.
I would say these two colors were made in HSL (HSV) color space, because they differ only in Hue (Hue as defined in HSL). Which might lead to conclusion, that they differ only in hue, but in reality they do differ in brightness too – although they shouldn’t. And because I see much more blue color fringing in the last example, I would say it happened because of this: HSV is not as perfect as L*a*b*. As explained on Wikipedia: Disadvantages.
edit: Previous reasoning is correct if we assume that stems are exactly in the grid. I also see the same effect in "ab" example, which does have "outline snapped to a strict grid".
Miha, in both pseudo-aliased examples, the outlines were snapped to a strict grid. For editing ease, I set the UPM to 1200, so that for my 12ppem sizes I would have a grid in units of 100.
I don't know much about colour space issues. I became a type designer because I didn't want to deal with colour, and figured that after 550 years of blackish ink on whiteish paper type wasn't about to change. :(
The illustrations were made on Windows Vista, from inside the FontLab TT hint preview window, presumably using the system standard sRGB colour space.
Screenshot of a different kind:
And full pixel zoom:
I'm trying to get a subpixel zoom image too, but Zoomin keeps crashing when I turn on subpixel display.
JH> I'm not sure how relevant [subpixel oriented hinted fonts] are to what I've called pseudo-aliased outline screen fonts.
"Pseudo-aliased outline" screen fonts seem to me a subset of the weight range of subpixel oriented hinted fonts. I.E. where the weights (of Franky e.g.) are whole pixels, pseudo-aliased outlines result.
David: "Pseudo-aliased outline" screen fonts seem to me a subset of the weight range of subpixel oriented hinted fonts. I.E. where the weights (of Franky e.g.) are whole pixels, pseudo-aliased outlines result.
Something like pseudo-aliased outlines may occur as a natural subset of subpixel oriented hinted (SPOH) fonts, but there are a couple of differences between the approaches. In the SPOH fonts, at least as demonstrated by Franky, you are working with curves and diagonals, so the pseudo-aliasing only applied to vertical and horizontal stem positioning: rounded and diagonal features are fully antialiased. In a P-A font, all outlines are wrapped to full pixel boundaries, with no curves or diaognals, hence no intentional antialiasing. The colour fringing is an unwanted artefact of the particular rendering method's colour filtering, not antialiasing in the typical sense of font smoothing. Finally, while some weights of SPOH fonts may behave in ways very similar to P-A fonts, i.e. when those weights correspond to full pixels, in P-A fonts every size and weight would be fitted to full pixels (made possible by modifying the UPM at each size).
By the way, I'm not advocating P-A fonts, and think there's a lot more mileage in your SPOH approach, but you challenged me to ‘demonstrate an aliased quality outline font series’. I'm not going to sit down and built such a series, but I think I've demonstrated the method that would get us as close as the colour filtering artefacts permit. The possibly cool aspects of the method are being able to automate outline creation from size strikes of aliased bitmaps from all those fonts we spent so much time hinting for b/w rendering, and modifying the UPM for each size font to avoid rounding of the grid. The latter technique could also be applied to SPOH fonts.
Wow – these are very cool screenshots, John.
So, the outlines were snapped to a strict grid, which means that RGB values of yellow (on the left of the stem) and blue (on the right) are really supposed to be symmetrical, according to ClearType.
As said before, if we see the HSL values of these two colors, they differ only in Hue. But if we convert it to another color model which has more accurate model of how human eye perceives color, we notice the colors are actually more different then they should be.
So, what is actually the criticism?
Colors fringing is not the same. It is darker/more visible on the right of the stems (or less dark on the left). This also explains why I was sometimes more bothered with blue color than red in ClearType, but I always thought it is just practical limitation of some variable on my side, and not theoretical. (I say this for black text on white, for other colors it could be different!)
But … there are also limitations of such color corrections. They are more computationally intensive, maybe much too much for the small difference they make. And maybe more important, they could make CT rendering less accurate, more blurry, and with less contrast. Unfortunately, it is hard to test to what extend is this true.
Actually, the more I think about it more complicated it seems.
There is also a very nice coincidence – I’ve been experimenting with different renderings of Georgia too, since Ruben (rubenDmarkes) posted his comments. The last example is mine: