[cairo] Cairo in Google Summer of Code

[Behdad Esfahbod]

On Mon, 2008-03-17 at 19:27 -0700, Bill Spitzak wrote:
> Well I can't edit the page but here are mine:

You can.  Need to create an account first, but no magic there.


> [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.

I don't think this needs to be a Summer of Code project.  There's not
much code to write there.  Someone needs to just sit down and do it.


> [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.

I don't think this is similar to font hinting at all.  For font hinting,
one has the entire font glyph data at hand.  We already have a mode for
this in cairo: it's called ANTIALIAS_NONE.  Again, this is one of those
features that keeps coming up (not incidentally, by you), but nobody
cares enough to go ahead and implement it.  No sure it would make a
great SoC project.


> [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.

Throwing problems we cairo developers have no solution for at students
and hoping that they come up with a solution for it doesn't work.


> [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 

In all the ideas above you try to imply that a majority of people don't
want what cairo currently does.  You have a very skewed idea of majority
or cairo users IMO.  Sure, go ahead and use toy API.  But if you want
something that works with other languages, you know where to look at.
Oh, and the toy API is not deprecated BTW.


> 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.

This is so far from true.  Seen cairo_select_font_face()?


>  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.

That's pretty much what cairo_select_font_face() does.


> 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.

So you're suggesting we duplicate much of code from Pango in cairo, just
for fun in toy API?  Doesn't sound good.


> * 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.

Ok, this paragraph suggests that you don't know much about complex text
rendering.  In that case I can't blame you for pushing for more toy text
API.


All those said, after my recent user-font code lands, I will implement a
pangocairo user-font font face to plug pango into cairo's toy text API.


> * 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.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759