We still don't handle these format codes of course, (they're meaningless
for the context in which they're used here).
Note that we previously avoided adding these to avoid people being forced
to upgrade pixman just to get two enum values that cairo doesn't really
care about. But now we're depending on a new pixman anyway, (for the
pixman_format_code_to_masks function), so we'll go ahead and do this now.
This allows us to do a much more general and complete implementation of
_pixman_format_from_masks and _pixman_format_to_masks so that we'll
even pick up new pixman formats as they get added.
The cairo_path_extents function can perform better than either
cairo_stroke_extents or cairo_fill_extents, so provide that
pointer from the documentation of the other two functions.
And also move the _cairo_surface_set_resolution() into
_cairo_win32_printing_surface_start_page as the DC ctm may be changed
between pages.
This bug was found in Inkscape now that they are using the cairo
win32-printing surface for printing on Windows.
If during analysis the bounding box of an operation or the number of
traps is 0, the operation is marked as natively supported. The problem
here is if the operation is unsupported by the backend, we get an
assertion when the operation is replayed during
CAIRO_PAGINATED_MODE_RENDER.
This bug was found in Inkscape when printing to the
win32_printing_surface a page that has been layed out as landscape but
landscape paper had not been selected in the print dialog.
Fix this by being careful not to mark unsupported operations as
supported during analysis even they may not be visible on the page.
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 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.
strdup() and friends require at least _BSD_SOURCE or
_XOPEN_SOURCE >= 500 to be defined for the prototypes to be included.
For the time being, add the define to each source file that requires one
of the BSD functions.
