Hello Bedhad, for the maximum precision, simply tell FreeType to load glyph outlines in "original units" the outline points will be in integer coordinates, that should be scaled to whatever device pixels with the equation:    device_x = original_x * character_size_in_pixels / face->units_per_EM which is equivalent to:    device_x = original_x * character_size_in_points / ( 72 * device_dpi * face->units_per_EM ) (simply use the FT_LOAD_NO_SCALE bitflag when loading the glyph; this will also keep the metrics in font units too, by the way). <a href="http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_LOAD_XXX">http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_LOAD_XXX</a> if it turns out that you prefer to not use FreeType for rasterization, (which can be a good idea, depending on context), I encourage you to do your own pixel filtering as well. the algorithms are relatively simple. cheers - David <div class="gmail_quote">2008/5/15 Behdad Esfahbod <<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>>: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, It's quite well-known by now that in cairo animation, text is always jagged and jittery, even with all hintings disabled.  The main reason for that is that we currently do not support sub-pixel text positioning and round glyph positions to integers.  Our workaround so far has been to recommend cairo_text_path();cairo_fill() instead of cairo_show_text().  That's far from perfect, but should do the job.  Or one would think so...  Apparently it doesn't.  So I sat down a while ago and tried to figure out what's going on.  And I did. Check the image:  <a href="http://www.flickr.com/photos/behdad/2493693932/sizes/o/" target="_blank">http://www.flickr.com/photos/behdad/2493693932/sizes/o/</a> source code is attached.  The left column is what you get from cairo_show_text(), the middle one is cairo_text_path();cairo_fill(), and the last column is if you take the path of the font at size 12 and let cairo scale the path, then fill it.  The graph suggests that the problem with the middle column is that we are asking FreeType for glyph outline at each size, and being beat by FreeType's limited precision (26.6 fixed type).  In fact, seems like that's contributing to our ugly show_text() results too.   Needless to say, we want to achieve results as good as the third column. So how do fix this then?  For show_text(), we want to implement sub-pixel glyph positioning.  I suggest we do a 4x4 or 8x4 grid.  Each glyph then will have up to 32 renderings.  May also make sense to add a new metrics-hinting mode to just hint the Y metrics.  That's what Apple does I guess.  Anyway, to implement subpixel positioning, I suggest we add something like: cairo_int_status_t _cairo_scaled_glyph_lookup_subpixel (cairo_scaled_font_t *scaled_font,                                     unsigned long index,                                     cairo_fixed_t x, cairo_fixed_y,                                     cairo_scaled_glyph_info_t info,                                     cairo_scaled_glyph_t **scaled_glyph_ret); unsigned long _cairo_scaled_glyph_get_subpixel_index (cairo_scaled_glyph_t *scaled_glyph); Basically this will create a new cairo_scaled_glyph_t for each position on the subpixel grid.  Each position on the subpixel grid also has an index, with index 0 mapping to pixel-aligned coordinate. Raster backends (and the fallback path) then will be changed to:  - convert glyph position to fixed  - fetch the glyph for the fixed position  - round the fixed position and render the fetched glyph there To make it less error-prune we can make the x,y in/out such that the rounding is done in one place.  Or better, make it take double x,y as input and return int x,y as output. The bigger problem though, is how to implement this in the xlib backend. Obvious solution is to make the Xrender glyph id be the combination of input glyph id and the subpixel index.  That works great for most fonts as their glyph id is limited (to 64k), but not for user-fonts.  With user-fonts one may use the full range of glyph ids and that's a valid usecase.  Then the input-glyph-id + subpixel-index space is larger than the Xrender glyph space and we have to use multiple Xrender glyphsets. Maybe we can reserve the high byte of the Xrender glyph space for subpixel-index, and upon seeing input glyphs that have non-zero high byte, use additional glyphsets for those.  That definitely works.  Is just a bit clumsy. Next step is, fixing paths.  Turns out we are going towards completely skipping FreeType's rasterizer and having cairo rasterize all fonts.  We may need to fix bugs in the non-AA rasterizer to match FreeType's, but ignoring that fact, it's quite possible to do that currently.  But! With the current plan to move to calling into FreeType for subpixel filtering, we may have some problems.  Worst case it's that we rasterize, then convert into a FT bitmap, do filtering, then convert back.  Not terribly bad, but also not ideal.  While doing that, we may as well add font-backend API for subpixel filtering.  Then we can use FreeType to do subpixel rendering of user-fonts.  Yay! Ok, to paths.  So, if hinting is set to none, we want to always ask font backend for glyph path at a fixed font size, and scale it in cairo.  I'm not sure if we need to cache the scaled version.  If not, then we can cache the path on the font_face instead of the scaled_font.  That would be neat indeed, but needs quite some code refactoring.  What should the fixed size we pass to FreeType be?  It should be something to maximize precision.  We can actually use some really large size (like 1024), that makes FreeType do all its math in 16.16 instead of 26.6.  And we'll then "scale it down" to 256, such that cairo essentially holds it as 16.16 instead of 24.8 too.  That gives us more than enough precision.  The sharing should happen based on whether hinting=off or not.  So much for paths. It's only fair to also talk about metrics at this point.  If metrics-hinting is off, we should also use metrics from a fixed size, scaled by cairo.  It gets trickier here.  Cairo returns metrics in user space.  So, for a fixed font matrix, regardless of the ctm matrix, one should get the same metrics.  This is indeed needed to ensure that a zoomed-in print preview of a book typeset using pangocairo has the exact same line breaks that the actual print does.  The scaled-font code takes glyph metrics from backends in font space and converts to user-space by applying the font matrix.  That is, it's completely independent of the ctm.  That's good.  We just need to ensure that for metrics-hinting=off, we use the metrics for the font at a fixed size.  That is, like what we need for paths.  This time however, we probably do need to cache the sizes for different font matrices.  So we can't just cache it on font_face_t.  We need a new object, that has all the identifying properties of cairo_scaled_font_t except for the CTM.  Then whether metrics-hinting is off or on decides whether we should share or not share this object across scaled-fonts with different CTMs. Humm...  To add to the confusion... we currently don't share anything across scaled fonts that have different ctm/font_matrix, but the same ctm*font_matrix.  We can share the glyph renderings.  So that's another thing to share.  And that one is in fact unconditional. And if and when we fix these all.  We should also make the scaled-font layer not cache glyphs for sizes larger than some large value (128?), and just do path();fill() everytime.  Some measurements are in order. So, that's it.  Who volunteers for which part? :) Cheers, -- behdad <a href="http://behdad.org/" target="_blank">http://behdad.org/</a> "Those who would give up Essential Liberty to purchase a little  Temporary Safety, deserve neither Liberty nor Safety."        -- Benjamin Franklin, 1759 _______________________________________________ cairo mailing list <a href="mailto:cairo@cairographics.org">cairo@cairographics.org</a> <a href="http://lists.cairographics.org/mailman/listinfo/cairo" target="_blank">http://lists.cairographics.org/mailman/listinfo/cairo</a> </blockquote></div>