Comment 24 for bug 185700

(In reply to comment #8)
> I agree that a configuration forcing hinting if application code explicitly
> disables it is a bad idea. It does not however seem to me that these
> fonts.conf settings are written with that intention - they are there to
> configure the right level of hinting for on-screen rendering, whatever the
> default may be. The default hinting seems to be "slight", and increasing it
> to "full" makes sense, but where it is set to off this should have no
> effect. If an application explicitly sets hinting to false, fonts.conf
> settings should not override that.

From fontconfig's perspective, hintfull is the default for "hintstyle". Some
screen settings may be setting this to something else and screen settings are
one sensible place to set hintstyle.

But the issue here is the "hinting" property. If hinting is false then
hintstyle will not be used. (The "rgba" property may also be having an
effect.)

Fixing the fontconfig configuration is going to be easiest way to fix this.

I'm not usually keen on overriding the user (or sysadmin's) configurations,
but could perhaps tolerate an exception here because turning hinting on is not
very useful for printing. The override would need to happen after
FcFontRenderPrepare().

gfxPangoFcFont, which calls FcFontRenderPrepare(), doesn't know whether the
font is for printing or not. The easiest way to provide this information
might be by adding a new property to the pattern in PrepareSortPattern().

Another option is to change the resolution of the printing surfaces to
something suitable for a printer (at least 300dpi). That way any hinting
effects become insignificant. (If hinting were significant at printer
resolutions then we would want hinting in the printer drivers.)

Apparently the reason why we don't do this now is that widgets with GTK themes
don't look right. But I don't think we should be using GTK themes for widgets
in printing anyway, so this could be turned off.

> Having read a bit about fontconfig, this makes me wonder what this is doing
> in the "pattern" instead of at a later stage as an actual rendering setting.
> I think the whole code path that deals with hinting, or adjusting the
> position of glyphs in any way based on raster parameters, should not at all
> be reached when printing, so these settings should have no effect then.

These are rendering settings. The same code paths are used for screen and
print layout (with different rendering parameters).