PDF Files with Type 1 fonts fail to open in any version of
ghostscript prior to 8.54. The problem is the hex encoding of the
encrypted portion of the font. The PDF reference says this should
only be in binary.
(cherry picked from d81de15804 commit)
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).
We'd been wanting some of the warnings in -Wextra for a long time,
but we had failed in tryingto squelch some of the undesired warnings.
We finally figured out how to do this correctly by simply ordering
the warnings correctly.
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.
