MuPdf / Fitz
Raph Levien
raph at casper.ghostscript.com
Thu Jul 11 02:01:18 PDT 2002
On Wed, Jul 10, 2002 at 10:17:18PM -0400, Antony Courtney wrote:
> Hi Tor,
[snip]
> Your wish list for Fitz looks good to me. A couple of quick responses:
>
> >Fonts ... personally I'd just skip hinting and be well rid of that extra
> >layer of complexity. But for 1-bit rendering on low-res devices I suppose
> >that it is a must. How common are they? Is it worth it? We still need
> >sub-pixel correct widths when calculating, line breaks should not be
> >dependent on output device/resolution.
>
> Interesting. This is where I show my ignorance and lack of experience
> with the nitty gritty of font rendering. I thought the whole motivation
> for font hinting was to ensure that fonts still look good when rendered
> at small point sizes on video displays. But I guess you and Raph seem
> to think that sub-pixel accuracy and anti-aliasing mitigate the need for
> hinting? I'm sure you are both right, but if either of you has any
> pointers to pages on this debate (particularly if it has side-by-side
> renderings for comparison!) that would be great.
Yes, we should gather various renderings. There's a lot of work out
there. TT hinting (MacOS9, Win9x) and analytically unhinted (Quartz)
are the most well known, but Acrobat 5's T1 rendering is also very
interesting (this is "subtle hinting" as I posted before).
Hinting is controversial. Here's a very brief summary:
Non-aa at low res (300 dpi and below), hinting is critical. Otherwise,
you get unacceptable variations in stroke width, objectionable loss
of symmetry, and so on.
Hinting usually works by slightly distorting the outlines prior to
rendering. What hinted TT rendering does is distort the outline, as
optimized for the non-aa case, then render using aa. The result is
better contrast than the unhinted case, and smoother outlines than
the non-aa case. Even so, the letterforms are quite distorted, and
other artifacts can also arise (the extreme thinness of the diagonal
stroke in the MS Times '2' is typical).
Unhinted rendering avoids the distortions and artifacts, and thus
looks a lot more like the "real" font. The downside is that the
contrast is lower. Some people call it "blurry" and complain that
it causes fatigue and even headaches.
The tradeoff between hinted aa and non-hinted aa is resolution
dependent. At roughly 140 dpi and above, the difference in contrast
becomes subtle enough not to matter, so non-hinted is a clear win.
But 140 dpi displays are still rare.
Most of the current momentum behind non-hinted aa is from Apple,
who uses it exclusively in Quartz.
Note, also that TT fonts can be tuned for AA display, as has been done
with the fonts that Microsoft ships with Reader. These are very
pretty, in my opinion.
> Also, a terminology question: What do we mean when we say "sub-pixel
> accuracy"? Do you mean doing all of the calculations in floating point
> or fixed point and only rounding to pixel coordinates when rendering?
> Or do you mean doing sub-pixel rendering in the sense described on the
> FreeType page, which only works on LCD screens? (Or is there some other
> sense I'm not considering.)
Another sense. Rendering text with subpixel accuracy is roughly
equivalent to rendering the entire string at very high resolution and
subsampling down. Thus, the initial coordinate position for each glyph
may have a fractional component in the target coordinate system.
Without sub-pixel positioning accuracy, you tend to render and
subsample each glyph independently. The initial coordinates get
quantized to integer pixels. As a result, individual glyphs move +/-
0.5 pixel compared with the accurate case. The result is an
objectionable unevenness in spacing.
Hints tend to quantize to single pixels anyway, so the need for
subpixel positioning in hinted render modes basically goes away (AR5's
subtle aa hinting is an exception, though).
[snip - I addressed most of the other points in response to tor's email]
> >I presume Fitz will be written in ANSI C.
>
> Amen.
Heh. It is the most pleasant language from which to do language bindings.
> >We should really really really get fonts right. It's one of the messiest
> >problems in systems today. Fontconfig goes a long way to solve some issues,
> >but is not panacea.
>
> Sounds good to me.
Yes, and to do it right is going to require careful drawing of the
lines between the various responsible modules. In particular, the
Fitz core is not the place to do font discovery and the like.
Even so, if we can give a good story to application developers ("do
this with your fonts, and they will come out well"), it's a major
win.
Raph
More information about the fitz-dev
mailing list