The following 7 tests currently fail with poppler due to:
Poppler does not correctly handle knockout groups
https://bugs.freedesktop.org/show_bug.cgi?id=12185
and we've verified with acroread that the cairo-pdf output
does render as intended there. The disabled tests are
clip-operator, operator-clear, operator-source, over-above-source,
over-around-source, over-below-source, and over-between-source.
The stream handling has been changed to support writing the content to
one or more group objects. Each page has a top level knockout
group. The first operation in the knockout group paints another group
containing the content. Fallback images are painted from the knockout
group. This ensures that fallback images do not composite with any
content under the image.
These are useful programs, but they don't belong in test/.
They are never used in the test suite at all. Instead, these
should exist in some demo package, or as applications in their
own right.
(The motivation for the removal is that someone just encountered
a build error with one of these. And I'm not interested in debugging
build errors for unused components.)
A pixman bug had kept this from being correct earlier. It
works now as long as pixman includes the following fix:
8ff7213f39edc1b2b8b60d6b0cc5d5f14ca1928d
rasterize traps that extend outside of the image bounds correctly
I've been seeing failures with the PS backend for these tests
for a while. This is in spite of the face that we've had a PS-
specific reference image for each of these tests. I'm not sure
what the difference is between my current system and the
system used to generate the original ps-specific reference
images.
One thing we definitely need to do is to bundle fonts with the
test suite to avoid problems like this. Another is to start
documenting the systems used to generate reference images.
I get very confused with ghostscript versioning, but I can
at least say that "gs --version" reports 8.15.3 here, (though
the package appears to have an 8.56 version).
The following 4 tests recently started drawing with native operations
in the place of image fallbacks, so we need ps-specific reference images
to account for minor rasterization differences: over-above-source,
over-around-source, over-below-source, and trap-clip.
This method is for use in vector backends, where fill immediatly followed by
stroke command with the same path can be emited in the same backend command.
This commit also factorize the detection of such cases in the meta surface
backend and automatically call the fill_stroke method on replay.
Whilst testing the fallback surface, the resultant image was being
clipped to the screen size. Be conservative and refuse to create
windows (for CAIRO_CONTENT_COLOR surfaces) that are larger than the
screen.
As well as marking the XRender extension unavailable in
_cairo_boiler_player_xlib_disable_render(), we need to clear any
XRender derived information stored during the surface creation.
These were recently added, (as part of sparse integration?), but they
break boilerplate which reaches into at least cairo-types-private.h
and cairo-scaled-font-private.h. But boilerplate cannot see cairoint.h
or else it gets the internal sybol renaming, (with the INT_ prefix),
and then all the test suite tests refuse to link.
If this change reverts some recently-added functionality, (or
cleanliness), then we'll just need to find some other way to add that
back again without the breakage.
Apparently, our much-beloved error message, (just look at how many people
love to quote it in bugzilla entries), was removed during the switch to
the new pixman. It was replaced with an obscure failure of a nil surface
being returned, (leading to obscure failures or false "out of memory"
errors).
So we're putting this back now, (even though we _really_ want to ensure
that this message never gets printed in practice).
Previously, the code was just using cairo_format_t which is much more limited
than the formats supported by pixman, (so many "odd" X server visuals would
just fall over).
This avoids a potential crash from the Render extension being cleaned
up during XCloseDisplay before the cairo CloseDisplay hook goes on to
call into XRenderFreePicture.
This isn't necessarily more correct than the old code using the doubles,
but it does result in bit-for-bit color equivalence when comparing the
results against the image backend. So that's both good consistency, and
more ease is using the test suite to verify things.
The analysis surface now keeps track of two regions: supported
operations, and unsupported operations. If the target surface returns
CAIRO_INT_STATUS_FLATTEN_TRANSPARENCY, the analysis surface will check
if any previous operation intersects with this operation. If there is
nothing previously drawn under the operation, the status is changed to
supported.
The meta surface has two new functions:
_cairo_meta_surface_replay_region()
_cairo_meta_surface_replay_and_create_regions()
During the analysis stage, the paginated surface replays the meta
surface using _cairo_meta_surface_replay_and_create_regions(). The
return status from each analyzed operation is saved in the meta
surface. The _cairo_meta_surface_replay_region() function allows only
operations from either the supported or unsupported region to be
replayed. This allows the paginated surface to replay only the
supported operations before emitting a fallback image for each
rectangle in the unsupported region.
Seems like all over the code, we have been using negated device_offset
values for glyph surfaces. Here is all the math(!):
A device_transform converts from device space (a conceptual space) to
surface space. For simple cases of translation only, it's called a
device_offset and is public API (cairo_surface_[gs]et_device_offset).
A possibly better name for those functions could have been
cairo_surface_[gs]et_origing. So, that's what they do: they set where
the device-space origin (0,0) is in the surface. If the origin is inside
the surface, device_offset values are positive. It may look like this:
Device space:
(-x,-y) <-- negative numbers
+----------------+
| . |
| . |
|......(0,0) <---|-- device-space origin
| |
| |
+----------------+
(width-x,height-y)
Surface space:
(0,0) <-- surface-space origin
+---------------+
| . |
| . |
|......(x,y) <--|-- device_offset
| |
| |
+---------------+
(width,height)
In other words: device_offset is the coordinates of the device-space
origin relative to the top-left of the surface.
We use device offsets in a couple of places:
- Public API: To let toolkits like Gtk+ give user a surface that
only represents part of the final destination (say, the expose
area), but has the same device space as the destination. In these
cases device_offset is typically negative. Example:
application window
+---------------+
| . |
| (x,y). |
|......+---+ |
| | | <--|-- expose area
| +---+ |
+---------------+
In this case, the user of cairo API can set the device_space on
the expose area to (-x,-y) to move the device space origin to that
of the application window, such that drawing in the expose area
surface and painting it in the application window has the same
effect as drawing in the application window directly. Gtk+ has
been using this feature.
- Glyph surfaces: In most font rendering systems, glyph surfaces
have an origin at (0,0) and a bounding box that is typically
represented as (x_bearing,y_bearing,width,height). Depending on
which way y progresses in the system, y_bearing may typically be
negative (for systems similar to cairo, with origin at top left),
or be positive (in systems like PDF with origin at bottom left).
No matter which is the case, it is important to note that
(x_bearing,y_bearing) is the coordinates of top-left of the glyph
relative to the glyph origin. That is, for example:
Scaled-glyph space:
(x_bearing,y_bearing) <-- negative numbers
+----------------+
| . |
| . |
|......(0,0) <---|-- glyph origin
| |
| |
+----------------+
(width+x_bearing,height+y_bearing)
Note the similarity of the origin to the device space. That is
exactly how we use the device_offset to represent scaled glyphs:
to use the device-space origin as the glyph origin.
Now compare the scaled-glyph space to device-space and surface-space
and convince yourself that:
(x_bearing,y_bearing) = (-x,-y) = - device_offset
That's right. If you are not convinced yet, contrast the definition
of the two:
"(x_bearing,y_bearing) is the coordinates of top-left of the
glyph relative to the glyph origin."
"In other words: device_offset is the coordinates of the
device-space origin relative to the top-left of the surface."
and note that glyph origin = device-space origin.
So, that was the bug. Fixing it removed lots of wonders and magic
negation signs.
The way I discovered the bug was that in the user-font API, to make
rendering the glyph from meta-surface to an image-surface work I had
to do:
cairo_surface_set_device_offset (surface, -x_bearing, -y_bearing);
_cairo_meta_surface_replay (meta_surface, surface);
cairo_surface_set_device_offset (surface, x_bearing, y_bearing);
This suggested that the use of device_offset for glyph origin is
different from its use for rendering with meta-surface. This reminded
me of the large comment in the xlib backend blaming XRender for having
weird glyph space, and of a similar problem I had in the PS backend
for bitmap glyph positioning (see d47388ad75)
...those are all fixed now.
Previously we were ignoring ctm translation in scaled fonts when hashing, but
still storing it into the scaled font. Now we zero the translation components
when storing.
