Basically, it's evil to write a loop like:
while ((c -= 4) > 0) {
...
}
for one reason that doesn't work if c is unsigned. And when c is signed, if
for some reason c is about -MAXINT, then it will overflow and not work as
expected.
It's much safer (and more gcc warning friendly) to rewrite it as:
unsigned int c;
while (c >= 4) {
...
c -= 4;
}
Behdad chased this bug down when looking into bug #7593. This
bug is what finally motivated us to figure out how to get -Wextra
(for the "always true" comparisons of unsigned variables against
negative values).
The documentation for GetGlyphOutline() states that outline returned is grid
fitted and if an application requires an unmodified outline it can request an
outline for a font whose size is equal to the font's em unit.
This seems to suggest that the solution to this bug would be to obtain the
unmodified outline data and scale it to the required size.
https://bugs.freedesktop.org/show_bug.cgi?id=7603
The setting of current point to (0,0) is actually harmless, but it
definitely looks like a bug, (since after close_path the current point
is really the last move point).
We don't keep track of last move point here, nor do we even need to.
So we can be consistent with _cairo_path_fixed_close_path by not
adjusting current point at all, (the subsequent move_to coming right
behind the close_path will fix up the current point).
Besides the bug fix, this is a user-visible change since the new
move_to element after the close_path element can be seen in the
results of cairo_copy_path, so we document that here.
We are also careful to fix up _cairo_path_fixed_line_to to defer to
_cairo_path_fixed_move_to to avoid letting the last_move_point state
get stale. This avoids introducing the second bug that is also tested
by the close-path test case.
There are still some problems in the resulting output:
PDF: Rotated font ends up being blurry in final PNG (not too important)
PS and SVG: There's an incorrect offset being applied somewhere.
which should be set to device_transform_inverse, not device_transform.
Moreover, no negation is needed anymore, as that has been working around
the inverse matrix :-).
Using NULL is encouraged for pointers. While fixing that, it turned out
that the comments indicating the current index were wrong, so I'm fixing
them too.
if we don't want it. This stuff is tricky, but I hope to explain: In your
fontconfig configuration, you may match on "font", or on "pattern". Turning
subpixel on typically looks like:
<match target="font">
<test qual="all" name="rgba">
<const>unknown</const>
</test>
<edit name="rgba" mode="assign"><const>rgb</const></edit>
</match>
This works good enough, and if you set to ANTIALIAS_GRAY, this will not
override that. Now one may forget to match on "font" target, or intentionally
match on the pattern. That happens before cairo font options are substituted
in the pattern. So, to give a hint of subpixel in your config file, you can
write:
<match target="pattern">
<edit name="rgba" mode="assign"><const>rgb</const></edit>
</match>
You don't really need to check for current values, as FcConfigSubstitute is
run before merging cairo_font_options_t in. What this patch does, is to reset
pattern's rgba property if the font options explicitly ask for ANTIALIAS_GRAY.
This is the only place in cairo-ft-font.c that we use FcPatternDel, so I
thought some explanation is needed.
otherwise, it looks like "I don't care" and fontconfig configuration is
allowed to decide to turn subpixel on. This fixes the bug that subpixel
colors where showing up in fallback images in PS/PDF/SVG backends, observed
in the test fallback-resolution.
This only affects the image fallback in those backends, and avoids getting
colored pixels there if user's fontconfig configuration turns subpixel on.
This doesn't quite fix that problem though, more changes are needed/coming.
as it's not portable and lack of it could seriously break the truetype
subsetting code. Now, instead of using int32_t and int64_t, we use
multiple int16_t items, to avoid any alignments. Fortunately, we are
not using any of the fields involved, so no code changes necessary.
