freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] RE: Adding options to the PS Hinter


From: Owen Taylor
Subject: Re: [Devel] RE: Adding options to the PS Hinter
Date: Wed, 3 Jul 2002 12:53:34 -0400 (EDT)
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/21.1

David Chester <address@hidden> writes:

> Greetings.
> 
> I think, for a start, those screenshots (the "horizontal stem alignment"
> ones) look pretty good.  This is clearly a better way to implement what I
> was doing in the xfthack.
> 
> There are still some areas for improvement.  For instance, in the Nimbus
> Roman examples with horizontal stem alignment, sizes 8 and 9, and sizes
> 11 and 12 come out looking identical.  The solution is to make sizes 8
> and 9 have exactly the same height, but for 8 to be a bit narrower and 9
> to be a bit wider than normal.  For now, I've found temporary luck in
> hard coding the heights and widths of Microsoft's WebFonts for sizes
> 10-15.  This is obviously not the best solution, but it works for me for
> now.  My website has some examples

I'm not sure it's wrong to have lowercase 8 and 9 points be the same
width; the reason that this happens is that we are still dealing with
integer advance widths. Subpixel positioning can produce distinctly
better looking results for inter-glyph spacing, but requires caching
the glyphs in multiple "phases". 

(I'm not sure how many would be needed, at least 4, possible more.)

It's possible, certainly, that something better could be done with
the font metrics even sticking to integer metrics. Right now, the
metric computation is done without respect to the hinting; really
if the glyph ends up taking more space when hinted, the metrics
should be adjusted. (This is done with the TT bytecode hints.)

> In addition, I've found that some careful gamma adjustments can make a
> lot of difference, and sometimes can be a more graceful replacement for
> stem snapping. The idea is to lighten the lighter pixels, while leaving
> the darker ones alone.  For example, if the stem of an unhinted arial
> lowercase "l" is 1.25 pixels wide, the rendered "l" might result in a
> column of 255-value pixels alongside a column of 64-value pixels.  Here,
> we could use a gamma adjustment lighten the 64-value pixels to close to
> white, and the "l" would appear sharper.  The advantage to this over stem
> snapping is that you don't see that jump from 1- to 2-pixel-wide stems at
> around size 15, and the weight remains consistent throughout the sizes. 
> Again my website has some examples.

"Gamma" is certainly an area which needs some consideration and experimentation.

 - Rendering using Xft currently introduces considerable distortion because 
   of the  natural gamma of the monitor; the effect on unhinted text is
   a general boldening of dark-on-light text, and thinning of light-on-dark 
   text.

 - The dark-on-light boldening effect actually can look more attractive
   than text composited with gamma correction. (At small sizes, gamma
   corrected text can look anemic because the dominent color is 
   gray, not black.)

   The light-on-dark thinning never looks good; this is why unhinted
   text generally looks OK dark-on-light, but far less good inverted.
 
 - For stem-snapped text (and to a less extent, stem-aligned text), only the 
   diagonals and curves are boldened, which produces uneveness in the
   final output.

 - The right way to get the boldening effect is probably to apply a 
   curve curve to the grayscale characters, then do gamma correction 
   when compositing. This allows boldening for all foreground/background
   combinations.

See:

 http://www.xfree86.org/pipermail/render/2002-June/001856.html

And the screenshots linked to in the followup at:

For a link to some samples I did in the followup:

 http://people.redhat.com/otaylor/fonts/gamma-screenshots/

Regards,
                                        Owen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]