[cairo] Reducing decimal digits in PS/PDF output

[Adrian Johnson]

Now that cairo has switched to 24.8 fixed-point the available precision
after the decimal point in path coordinates has been halved. It would
make sense to only output the minimum number of digits after the decimal
point to preserve the precision available in cairo_fixed_t.

I have on the following branch a set of 5 patches for reducing the
number of digits after the decimal place in the PS/PDF output:

http://gitweb.freedesktop.org/?p=users/ajohnson/cairo.git;a=shortlog;h=precision

The largest impediment to reducing the precision out the PS/PDF output
is the use of the user space CTM for stroking. For example, assuming 3
decimal places, the path coordinates (1.234, 2.345) when used in a
stroke with a user space CTM of [100 0 0 100 0 0] will be output as
(0.012, 0.023).

The first patch performs rescaling of the user space CTM used in strokes
to keep the CTM in the range where the transformed path coordinates
retain maximum precision. The line width and dashes are also scaled to
be the same size in the new CTM.

A new format specifier '%g' has been added to cairo-output-stream.c for
printing doubles that have previously been stored in a cairo_fixed_t. It
uses only the minimum number of decimal places required to preserve the
available precision in cairo_fixed_t. All the path functions in
cairo-pdf-operators.c have been changed to use %g.

If we switch to passing doubles in paths all the way through to the
vector backends it would make sense to add API for specifying precision
since we would have up to 18 decimal places available instead of the 3
we get with 24.8 fixed-point.

Some reduction in the decimal places used when outputing text has been
made. The TJ text operator emitted by _cairo_pdf_operators_show_glyphs()
accepts an array of glyph strings with an optional number between each
string that applies an adjustment to the horizontal position of the next
string of glyphs.

For example:

[<010203> 123.456789 <04020a> 76.234567 <09>] TJ

As the numbers that adjust the glyph position are in 1/1000 of a unit of
text space, I think rounding to an integer should still provide enough
precision. The last patch performs this rounding. So the output will
look like:

[<010203> 123 <04020a> 77 <09>] TJ

Any comments on these patches? Are there any issues with the CTM scaling?