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.
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.
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
Add a load_truetype_table function to cairo_scaled_font_backend_t and
use it to load the truetype sfnt tables. Implement this with freetype
for the freetype font backend and use GetFontData for win32. Atsui
remains unimplemented, and still falls back to type3 fonts.
New internal function _cairo_surface_set_font_options is used to set them.
cairo_surface_create_similar propagates the font options of the other
surface into the newly created surface. Fixes bugs with font options in
fallback images and bug 4106.
