I very much agree with Marcus, hinting is NOT worth the effort. Consider
that hinting is really only absolutely necessary at font sizes less then 24
(excluding <5 which are going to be illegible no matter what). Embedding
bitmaps is much easier. For my most recently released font (
http://www.dustismo.com/fonts/Dustismo.zip ) I spent about 5 weeks
designing the glyphs, then I spent about a month trying to properly hint
ONE character and I finally gave up and embedded bitmaps for sizes 7-22
which took about a month. It looks quit nice on my windows machine (it -
of course - looks like crap on linux). The guy who did times new roman
said he spent two years on the hinting alone, consider he could have
embedded bitmaps for the same result and probably 1/30 the time.
If anyone here has actually tried to properly hint a font I think they will
agree that it is a most frustrating endeavor.
Thanks
Dustin
cheapskatefonts.com
At 05:52 PM 8/21/2002 +0100, you wrote:
>Another quick discussion related to font file format philosophy:
>
> Is hinting really worth the effort?
>
>Font file formats (even scalable ones) in principle ought to be
>relatively simple creatures. The only aspect that really adds enormous
>amounts of complexity, both with regard to the development of the
>renderer as well as with regard to the creation of the fonts, is the
>automated control point adjustment based on hinting information. Is that
>type of scale-independent hinting really a good idea in the long run?
>
>I'd like to argue that this is not necessarily the case, and would be
>interested in hearing your more generic insights and opinions into the
>subjects.
>
>Main points:
>
> - Even entry-level printing devices have now reached pixel sizes
> of 20 �m or less, and many use in addition non-binary pixel
> values for anti-aliasing, such that the changes of up to half a
> pixel width to the outline when hinting is applied really does
> not affect visible quality any more in printouts.
>
> - For DTP applications, it is important that the on-screen
> representation approximates as closely as possible the printed result
> in a device-independent way, and hinting severely interferes
> with that goal as it changes glyph spacings and sizes.
> Experienced users know the problem that for example Microsoft Word
> reformats a document if you change the resolution of the output device,
> whereas Acroread uses unhinted glyph metrics in order to utilize
> PDF as a truely device-independent format, which I find preferable.
>
> - Neither web browsers nor GUIs have any need for exact freely
> selectable glyph sizes. As long as a sufficiently smooth set of
> glyph sizes with high-quality bitmaps is available, rounding to the
> nearest font size that can be rendered in high quality is
> perfectly acceptable (with say ~20% tolerance).
>
> - The number of necessary bitmaps is relatively small. Glyphs less than
> 5 pixels high are unreadable anyway, with or without hinting, and
> glyphs larger than around 50 pixels are sampled well enough such that
> hinting starts to become unnecessary for a pleasant look, especially when
> anti-aliasing is applied as well.
>
> Therefore only for a single decade of glyph pixel sizes are manual
> adjustments actually necessary. If the acceptable step size between
> two font sizes is in the order of 20%, then manual adjustments are
> necessary only for around 14-17 font sizes.
>
> - Manually adjusting an unhinted glyph outline for a particular
> low-res presentation can be done in one of two ways:
>
> a) edit the resulting bi-level bitmap (switch some pixels
> on or off to improve the looks)
> b) manually snap control points to a nearby pixel boundary
>
> Option a) is very easy to do and requires only readily available
> bitmap software. I estimate that I can manually fix bitmap glyphs
> at a rate of around 100 glyphs per hour. Option b) has the advantage
> that it is compatible with anti-aliasing. I'm not sure how fast it
> could be done; it would need a specialized software tool. The snapping
> information can probabaly be compressed down to less than 4 bits
> per control point and hinted scaling factor.
>
> - I understand that the area of scale-independent hinting instructions
> in font file formats has some patent problems. (?)
>
> - In spite of the sophisticated hinting mechanisms available in
> TrueType fonts, it seems that places like Microsoft Typography
> do not make very significant use of it and embeds handedited
> bitmaps instead.
>
>So if we start one day some significant Free Outline Font project, shall
>we really stick with existing TrueType/OpenType technology, or shouldn't
>we skip the automatic hinting mess altogether and just add either
>bitmaps or corrected control points for those scaling factors where,
>let's say, the x-height is one of
>
> $ perl -e 'for ($i=5; $i<=50; $i=int($i*1.2+0.5)) {print "$i, "};'
> 5, 6, 7, 8, 10, 12, 14, 17, 20, 24, 29, 35, 42, 50
>
>or
>
> $ perl -e 'for ($i=4; $i<=64; $i*=sqrt(sqrt(2))) {print (int($i+0.5) .
> ", ")};'
> 4, 5, 6, 7, 8, 10, 11, 13, 16, 19, 23, 27, 32, 38, 45, 54, 64,
>
>The application would then specify to the renderer a font size and a
>maximum tolerance (e.g., 20%), and if a hand hinted set of control
>points is available within the tolerance, then the renderer will use
>that that beautified on-screen font size instead of the exact requested
>one.
>
>(With regard to preferred numbers of font sizes, I believe that
>neighboring fonts should be a factor 2^{1/4} = 1.1892 apart, because
>this means for paper fonts that for example an A4->A3 magnification will
>lead again to an exactly available font size. If you didn't understand
>the last idea because you are North American, read then please have a
>look at <http://www.cl.cam.ac.uk/~mgk25/iso-paper.html>.)
>
>Just some food for thought ...
>
>Markus
>
>--
>Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
>Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
>
>_______________________________________________
>Fonts mailing list
>[EMAIL PROTECTED]
>http://XFree86.Org/mailman/listinfo/fonts
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
