[cairo] Serious concerns about cairo

[Behdad Esfahbod]

On Mon, 2006-09-25 at 18:25 -0400, Bill Spitzak wrote:

> I. Proposed fix for the transforms:
> 
> * The current font (it's transformation), the current pen, and the 
> current dash pattern, are "frozen" in device space at the moment they 
> are specified. Changing the CTM does not change these settings. This is 
> already true of the clip path, the source pattern, the destination surface.
> 
> * Font metrics that return rectangles (such as bounding boxes, offsets 
> to parts of the image, and the horizontal/vertical advance pairs) return 
> a rectangle with the same *area* as if the font was not rotated. This 
> appears to be the most useful value. Rotating the CTM after specifying 
> the font is not recommended, so we don't care about preventing 
> intersections, and any other solution results in huge boxes.

Not sure what this exactly means, but I believe the huge boxes are more
useful than any other interpretation.  They can be used to draw bounding
boxes after all.


> * Requesting things like the font and pen inverse-transforms the device 
> coordinates to the ctm. This matches how font metrics are returned.
> 
> * Add an api to specify the pen as a 2x2 matrix, used to transform a 
> .5-radius circle to get the pen. This is so that a get-pen api can work.

Instead of a 2x2 matrix, use a regular matrix and use the translation
components to shift the pen.  That is consistent with the font matrix,
and actually not quite useless.


> * Dashed lines are done by inverse-transforming the path to pen space, 
> converting the path to dashes using the simpler unit circle for the pen, 
> and then transforming the resulting path back and filling it. Thus 
> dashes will scale with the size and shape of the pen.
> 
> * There is a "dash size" variable, and the dash pattern is multiplied by 
> this before use to make the dash. This is for back compatability. The 
> older set-pen that takes a single number r for the pen sets the pen 
> matrix to [r 0 0 r]*ctm and sets the dash size to 1/r. Add an api to 
> directly get/set the "dash size".

This works.  Or we may be able to come up with more interesting ways to
keep backwards compatibility.


> II. Proposed fix for "hairline" mode:
> 
> Currently any software that wants to draw anything like this cannot use 
> Cairo's transforms. Also the thick-or-blurry lines by default really 
> annoy new users of Cairo. And this would eliminate probably 90% of the 
> requests for "turn off antialiasing".
> 
> * Hairline mode completely replaces the stroke algorithm with different 
> code when turned on.
> 
> * Setting the line width to zero (or setting the pen to a degenerate 
> matrix) puts Cairo into "hairline" mode. Setting the pen to a non-zero 
> size (including negative) turns off hairline mode.

A degenerate pen matrix is completely useful on its own.  For example,
to emulate a calligraphic pen.  Ok, you probably don't want the
degenerate case for that, but it is well-defined already.  Charging it
to do something else is confusing.

Why not add an explicit hairline mode?  If you set the pen, hairline
mode is gone.  Ugly, but better than overloading the pen.


> * If the CTM is degernate, then setting a non-zero pen does *not* result 
> in hairline mode, but instead in an invisible pen (stroke is a no-op). 

Why?  A degenerate CTM can be used to mark shadow of a path on a plane.
It should just work.


> * A new cairo context defaults to hairline mode.

This totally breaks current API


> III. Fonts:
> 
> I have a simple requirement for any text api:
> 
> * To draw a UTF-8 string, there is an api that takes a pointer to the 
> string, it's length, and NOTHING ELSE, and the result is the text 
> appears on the output surface. Any structure or context or anything else 
> other than the cairo_t is by my definition, NOT "fun or easy to use", 
> and thus contrary to Cairo's design goals.

That's the current toy API indeed.

> It sounds like the only solution is that Cairo should contain a layout 
> engine, possibly by doing the work necessary to extract if from Pango. 
> The "toy api" needs to call this, just like it is doing on the Mac and 
> Windows anyway. Text is formatted into an infinitly-wide rectangle to 
> the right of this point (IE if the backend decides to do bidi and draw 
> right-to-left, the last character is put to the right of this point).

I have plans for the user-font API to let the toy API switch to higher
level systems like Pango transparently (if you set it up, which should
be a matter of a single Pango call done just once.)


-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
        -- Dan Bern, "New American Language"