We use the full matrix in hash computation, but only compare the
non-translation items in equality check. This is no bug though,
as we set the ctm translation components of a scaled font to zero
explicitly. But the change makes the hash and equal functions
consistent, which is good.
Since there is an implicit precedence in the ranking of the analysis
return codes, provide a function to centralize the logic within the
analysis surface and isolate the backends from the complexity.
Images in PDF are scaled to a unit square. In PS we set the
ImageMatrix to do the same. When the image is painted we scale the
graphics state to paint the image at the right size. In the case of
Type 3 fonts consisting of bitmap images we want to paint the images
at their original size so we scale the graphics state by the image
width and height.
The bug was that we were scaling by the width/height in the glyph
metrics. For non rotated fonts this worked. However for rotated fonts
the width/height of the glyph images may be larger than the
width/height in the glyph metrics. This resulted in a Type 3 font
where the glyph images were scaled slightly smaller than they should
have been.
Two changes here:
* Replace move_to;line_to;move_to;line_to sequences with
move_to;line_to;line_to when feasible.
* Close paths for round glyphs.
Both improve the stroke rendering of the joint.
The first change also saves 3 bytes per joint (33 such joints).
Which we have just left unused for now. To reclaim them one need
to update the charset table. Something for a lazy Sunday afternoon
scripting task.
In the saving department, we can save further by:
- Getting rid of the left/ascent/descent values as we compute
glyph bounding box automatically. Then we can liberally use
the right value to adjust glyph advance width. Saves three
bytes per glyph (there's 96 glyphs in the font).
- First operation is always a move_to. So we can remove the 'm'
for that. Ugly though.
And the charset has zeros for the first 32 entries. Can get rid of
that too at the expense of handling it in the code...
In total, combining the above we can save some 500 bytes. The font
currently takes about 3.7kb.
The font data and rendering is adapted from Keith Packard's Twin
window system. The hinting stuff is not ported yet, but hey, it renders!
The implementation uses user fonts, and the user font backend is modified
to use this font face (which we call "twin" font face internally) when
a toy font is needed.
The font face layer is then modified to use this font if:
- The toy font face "cairo" is asked for, or
- No native font backend is available, or
- The preferred native font backend fails to return a font with
STATUS_UNSUPPORTED. No font backend does this right now but
the idea is to change FreeType to return it if no fonts found
on the system.
We also allow building with no font backends now!
The new doc/tutorial/src/twin.c file tests the twin face at various
sizes.
The release notes for 1.7.6 say that we had dropped this
function, but apparently we had only planned to do that
and didn't actually get around to it until now.
Thanks to the RELEASING insctructions which gave a diff
command that pointed out this problem.
We reverted the public API for setting lcd_filter font options
back in 1b42bc8033 , but we had left the implementation which
would examine fontconfig and Xft properties for the option, and
which would call into freetype for subpixel glyph rasterization.
However, I recently realized, (and the test suite had been trying
to tell me for a while), that this approach would cause a
regression for users who were previously using sub-pixel text,
but without sub-pixel rendering built directly into freetype.
That's not acceptable, so all the code is coming out for now.
There is an implicit precedence when analyzing patterns for
compatibilty, in order of descending precedence:
fatal error
unsupported
needs image fallback
needs meta-surface analysis
success.
So wehen we have two patterns, we need to check both analysis statuses
simulataneously, in order to correctly report the combined status.
The primary bug here was some missing braces. The code was conditionally
assigning to backend_status, but then unconditionally checking for the
value assigned. The result was the leaking of an internal status value
(CAIRO_INT_STATUS_ANALYZE_META_SURFACE) which finally resulted in
an incomplete PDF file in the mask-transformed-similar test case.
While fixing this, also avoid re-using the backend_status variable so
much so that the code is more readable.
Since these functions are static we don't really need the full
name. And these two functions were both so long that they were
causing some serious line-wrap issues.
Commit 20b1b33c0f added some "paranoid checks" to our png
loading code. One of these was checking that if png_get_IHDR
first reports an interlace value other than PNG_INTERLACE_NONE
that after we call png_set_interlace_handling then we do
get PNG_INTERLACE_NONE from the next call to png_get_IHDR.
However, libpng doesn't seem to actually have that behavior.
When testing cairo_image_surface_create_from_png with an
interlanced PNG file, (which the test suite happens not to
do---even now), the call to png_set_interlace_handling is
doing the trick, but the check for PNG_INTERLACE_NONE is
failing.
So, with the check in place, loading an interlaced PNG image
fails with CAIRO_STATUS_READ_ERROR. By simply removing
that check, an interlaced image loads just fine.
I renamed those generated files to Makefile.*.features but forgot to
update ignore lists. Carl already added the new ones, but didn't
remove the old ones.
I know that I didn't create these Makefile.win32.features files,
so I assume that they are the result of Behdad's build magic and
that he just forgot to add them to .gitignore.
This reverts commit c9ec82f3a8, which
notably caused regresions in the mask and clip-operator tests.
Obviously I'm not smart enough to fix bugs. Since the computer found the
assertion failure, I need to train the computer to fix the bugs as well.
The win32 build system has no way to install anything, but it has
full knowledge of what needs to be installed (which headers). So
we now report files to be installed at the end of the build.
We are being cheap and don't define the cairo_utf8_to_utf16 function
if no one is using it. Previously PS surface was not using it, but
after the pdf-operators merge, it was.
Before this commit, building with PS but without PDF failed. Fixing.
We never do #ifdef-type conditions on CAIRO_HAS_* macros, because we
want to allow setting them to zero. Then if we need to enable a feature
if either of PS or PDF is enabled, the proper syntax is:
#if CAIRO_HAS_PS_SURFACE || CAIRO_HAS_PDF_SURFACE
This works because the preprocessor replaces any unknown identifiers with
zero. Some versions of gcc had a bug that got them very confused with
complex versions of the above. As a workaround for that I have been using
the uglier version:
#if CAIRO_HAS_PS_SURFACE+0 || CAIRO_HAS_PDF_SURFACE+0
which magically worked around that bug. Or more recently replacing that
with the duplicated version:
#if CAIRO_HAS_PS_SURFACE
...
#endif
#if CAIRO_HAS_PDF_SURFACE
...
#endif
Both are uglier than the original. Since the gcc bug was very short lived
and there's lots of software out there relying on the original form to work,
moving back to the simple version seems harmless.
We don't need to tessellate edges strictly above or below the
hit-test point.
(Patch split and modified by Chris Wilson to apply to cairo_in_stroke()
as well - all bugs are his alone.)
Both the source and mask need to be analyzed and checked for an
UNSUPPORTED operation before determining the best course of action.
As before this is simply decided based on the requirements of the
source.
If either point lies on the limit and the other outside, adjust the line
to be parallel to the boundary. This adjusts the previous test where both
points needed to be entirely outside.
Use the utility functions _cairo_box_from_rectangle and
_cairo_box_round_to_rectangle() instead of open-coding. Simultaneously
tweak the whitespace so that all users of traps look similar.
When reporting the extents of the traps, constrain them to the imposed
limits. This is relied upon in the analysis-surface which sets the
limits on the traps (based on clip/surface extents) and then reports the
extents of the traps as the region of the operation.
Avoid the iterative search for the extreme points by first checking the
most likely arrangement (as produced by cairo_rectangle() under no
transformation).
A surface pattern under an extreme transformation could lie entirely in
the negative quadrant. This would trigger the fixup such that it's lower
left corner was clamped to the origin, but the upper right corner was left
unchecked. This could result in the width,height being negative and
wrapping around to large values instead of being clamped to 0.
The meta-surface workaround an old bug, which is no longer present in the
tree and open-coded the surface snapshot. However, the workaround itself
was buggy (not respecting the surface content). The lesson to take away
from this is not to add workarounds in test code for bugs in the library!
As PS has different semantics regarding a zero-length dash, we need to
adjust the dash array before emitting. However, we need to modify a copy
of the dash array since the same array may be used by the meta-surface
when replaying to an image fallback.
The expected behaviour for masking in Cairo is to set the mask according
to the current active matrix and apply unchanged to the masked surface.
In SVG, the mask element is bound to the masked object and thus the local
matrix from that image object applies to the nested mask as well.
Attached is a small patch for substracting the matrix of a image
surface from the matrix of the mask to comply to Cairo's behaviour.
I did not test for other stuff like vectors or text and would expect this
part is incomplete.
