[cairo] Cairo in Google Summer of Code
Bill Spitzak
spitzak at thefoundry.co.uk
Mon Mar 17 19:27:32 PDT 2008
Well I can't edit the page but here are mine:
[Medium] Make stroke width and font transforms be frozen at the time
they are set, rather than modified by changes to the ctm
(linewidth(2);scale(2) should produce 2-unit wide lines, not the 4-unit
wide lines it currently does). This will make Cairo consistent with how
it treats pattern and gradient transforms, with how Pango works, make
Cairo's transforms usable by an Illustrator-style program, match OpenGL
and make future 3D enhancements to Cairo possible. This will require
replacing the pen api with a 2x2 matrix, and possibly other changes.
Will also require analysis of how much, if any, of existing Cairo-using
code will be broken by this change, and how and if back-compatibility
should be provided.
[Hard] Hinting mode (or "make 1-pixel thick lines work the way users
expect"). Add a mode to draw fills and strokes "nicely" without the
calling program having to know how big the pixels are. This is very
similar to, and probably as hard as, font hinting. Currently Cairo tries
to accurately draw a filtered scaled image but this is often not what is
wanted: the inability to draw 1-pixel lines frustrates novices, and the
fuzzy appearance of tiny images discourages Cairo use for icons.
[Hard] Adjacent-polygon fix. Lots of users try to draw a mesh of
polygons with their edges touching in order to fill the plane with a
colored image. Attempting this on Cairo produces artifacts because the
edges are antialiased and the image has very thin cracks between the
polygons. A huge number of graphics produced popular proprietary and
open-source programs are this way and it is impractical to fix them to
overlapping shapes. Come up with a solution to this.
[Hard] Usable+"fun" font api. The official method of drawing text in
Cairo is not "fun" (which was supposed to be a design criteria for
Cairo). The official method of drawing text (Pango) is much too complex
for use by applications, though toolkits can call it. The majority of
programmers use the "toy" api, even though it is depreciated, because it
much more resembles the expected api and can be learned without study.
Selecting the font for either requires back-end-specific code so the
only portable api is to use the default font. Make a new Cairo font api
which does the following:
* Select a font using a single string name that is portable between
backends and can be imbedded into a <font=name> code in Pango. Add a
simple api that will list a reasonably-large subset of the available
font names, so that a portable font chooser can be written, and so that
multiple programs all show the same set of available fonts.
* All assigned Unicode points draw a correct glyph (ie what is actually
selected is a fully-populated "font set"). The "toy" api will then
clearly display the contents of a string, which is very useful for
editors and other contexts where the data is more important than the
presentation.
* Add a "fun" wrapper around Pango to encourage it's use. It should take
a string to display (with embedded html-style codes) and a rectangle to
put it into (unless the current path could be used, which would be
neat), and it should use the cairo current font.
More information about the cairo
mailing list