| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Conflicts:
test/dash-caps-joins-ps-argb32-ref.png
test/degenerate-path-ps-argb32-ref.png
test/degenerate-path.c
|
|
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.
|
|
instead of poking at the loadflags.
|
|
|
|
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.
|
|
Quite a few fields were missing, but all zero, so didn't matter
practically, but comments were out of synch.
|
|
and make sure that _cairo_ft_load_truetype_table returns UNSUPPORTED
if the version of FreeType used doesn't support FT_Load_Sfnt_Table.
|
|
|
|
to make the output deterministic and fix valgrind errors.
|
|
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.
|
|
|
|
|
|
|
|
Shouldn't make /any/ difference at all in any case.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
cairo_show_page
cairo_copy_page
cairo_in_stroke
cairo_in_fill
|
|
|
|
|
|
Annoying, but a function doc should have a body, not only "Returns", or
gtk-doc will not pick it up.
|
|
such that we can test the struct sizes in a test.
|
|
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.
|
|
warnings-cleanup branch
|
|
Conflicts:
src/cairo-font-subset.c
|
|
|
|
|
|
|
|
|
|
This approach to fixing the bug is valid since there is code in pixman
for rendering to BGR images, (which is why cairo 1.0 worked with BGR X
servers for example). But, since we don't want to advertise additional
image formats we implement this through a new cairo_internal_format_t.
This is rather fragile since we don't want to leak any internal formats
nor do we ever want an internal format to be used somewhere a real
format is expected, (and trigger a CAIRO_FORMAT_VALID assertion failure).
More comments than code are added here to help compensate for the
fragility and to give some guidance in fixing this mess in a better way
in the future.
|
|
This fixes the bug reported against GTK+ here:
http://bugzilla.gnome.org/show_bug.cgi?id=349826
|
|
|
|
|
|
In addition to helping us preserve a sharp line between which symbols are
part of the public API and which are private parts of the implementation,
this can also help mozilla avoid clashes between its modified, internal
copy of cairo and the system version of cairo. See the mozilla bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=341874
|
|
|
|
Reference v1.6
|
|
|
