[cairo] Cairo in Google Summer of Code

[Kai-Uwe Behrmann]

Am 18.03.08, 11:22 +0200 schrieb Gerdus van Zyl:

> Is it just me or is most of the problems inappropriate for somebody
> like a SoC candidate that is just starting on the cairo code base?
> 
> All the sucessfull SoC projects I have seen were
> a) self contained unit - eg. something than does not touch too many
> existing code and can be written "seperately" and then integrated.
> (lookup-table-based rasterizer?)

Did you see the post of Daniel Kraft? He explicitely referes to the above 
algo as beeing interessting.

> b) non controversial - this way the candidate does not fight a part of
> the community
> c) visible and fun - braggable results eg. I made cairo 20% faster!
> See this cool new thing people can do!
> 
> I personally would like to see Blur/Convolution Filters and
> Screen/Overlay blend modes, but that is more pixman than cairo, i
> think.
> 
> Just my 2 cents.

Only an observation.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org


> On Tue, Mar 18, 2008 at 4:27 AM, Bill Spitzak <spitzak at thefoundry.co.uk> wrote:
> > 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.
> >
> >