commit 9d61f7db80 broke API by making the
CAIRO_FONT_TYPE_ATSUI symbol not work anymore. However, this symbol was part of
Cairo's public API and should continue working this way.
For PNG_COLOR_TYPE_GRAY images the bKGD value is read from white.gray
which was uninitialized, triggering the "PNG warning = Ignoring attempt
to write bKGD chunk out-of-range for bit_depth" reported by Emmanuel
Pacaud. This patch sets the background gray value to white, the same as
for RGB images.
Commit 158b32b60b reduced excess
decimals emitted for the TJ operator. However it only fixed the first
of the two locations in pdf-operators where the TJ position
adjustments are emitted.
The emulation of the PDF 'TJ' operator in the PS prolog was
incorrectly updating the glyph position between strings. The glyph
position values are a negative x offset that are in 1/1000 unit of
text space. We were incorrectly multiplying the number by -0.0001
instead of -0.001. We also need to transform this to device space
before calling rmoveto.
This change in reference image was triggered by the following commit
in the pixman library:
commit f2d8a5caa63596739b4dc47c00daaaafd9f522e2
Author: Søren Sandmann <sandmann@redhat.com>
Date: Mon Mar 10 23:41:52 2008 -0400
Add rounding epsilon for NEAREST filter after transformation, not before.
This hasn't appeared in a pixman release yet. So for now, getting
correct results is a matter of "use latest pixman". Soon we'll
have a new pixman release and we'll make cairo depend on that.
This support involves allocating a 16-bit grayscale ramp as well
as a 5x5x5 RGB color cube. Afterwards, the 256 colors are queried
and an array is generated mapping from r3g3b3 colors to the closest
available color. Both the queried colors and the reverse mapping
are stored in a new visual-specific cairo_xlib_visual_info_t
structure which hangs off of the cairo_xlib_screen_info_t.
Both the color-cube allocation and the distance metric could be
improved by someone sufficiently motivated, (for example, allocating
and matching in a perceptually linear color space rather than just
in RGB space). Also, making this work well in the face of a changing
color map, or in the case of GrayScale, StaticGray, or DirectColor
visuals are left entirely as exercises for the reader. StaticColor
support should be fine as is, but is entirely untested.
The numbers output in the TJ array for adjusting the horizontal
position of the next glyph are in 1/1000 of the text space
units. Rounding these numbers to an integer should still provide
sufficient precision.
We use the rounded numbers to update the text position in
pdf-operators so subsequent numbers in the TJ array will compensate
for the rounding error.
The %g conversion specifier is for printing numbers that were at some
time stored in a cairo_fixed_t type and as a result have their
precision limited by the size of CAIRO_FIXED_FRAC_BITS.
Using %g will limit the number of digits after the decimal point to
the minimum required to preserve the available precision.
The PS/PDF CTM is transformed to the user space CTM when emitting
paths to be stroked to ensure the correct pen shape used. However this
can result in rounding errors.
For example the device space point (1.234, 3.142) when transformed to
a user space CTM of [100 0 0 100 0 0] will be emitted as
(0.012, 0.031).
Fix this by rescaling the user space CTM so that the path coordinates
emitted to the PDF file stay within the range the maximizes the
precision. The line width and dashing is also rescaled to be the same
size in the rescaled CTM.
We're moving the assertion up from inside _pixman_format_to_mask
to its callers. This will allow us to selectively eliminate the
assertion from the supported xlib backend, while leaving it in
the unsupported glitz and xcb backends for now.
We use the floating-point value later, and we can end up with weirdness
such as negative colors due to the precision mismatch of our fixed
point vs. floating point type. So just do everything in floating
point.
Instead ensure the fill and stroke are each analyzed separately.
This fixes a bug in the PS output where if a fill-stroke with a
translucent fill resulted in a fallback image with the stroke clipped
to the fill path.
The PDF/PS backends change the ctm to user space when emitting and
stroking a path. When the user space ctm does not alter the pen shape
we can avoid changing the ctm.
This patch optimizes the most common case where the user ctm is
[1 0 0 -1 0 y] due to conversion from cairo to PDF coordinates.
Now that the PS backend is using PDF operators, it uses the glyph
metrics in the font to position each glyph in a string. This exposed a
bug in Type 1 fallback where the glyph width and height was used in
the charstrings instead of x_advance/y_advance. This was causing
strings to print diagonally due to the no zero y_advance.
In some cases (in my case, having an external monitor attached to my
MBP), Quartz seems to default to grayscale AA even when it should be
using subpixel AA. CGContextGetAllowsFontSmoothing returns FALSE in
this case (pretty sure this is a Quartz bug). We can force subpixel
AA in this case by setting CGContextSetAllowsFontSmoothing.
