Comment 23 for bug 185700

Revision history for this message
In , Alsbergt-mozilla (alsbergt-mozilla) wrote :

As for the broader issue, to recap first the general notes:

hinting, RGBA, and pixel sizes of fonts are meaningless in print or vector output (and the first two also pretty unnecessary on high-resolution raster output, but that does not apply to pixel displays), and any meaning artificially given to them in vector space for supposed analogy with raster rendering just distorts the vector output.

If using a font rendering mechanism to detect the metrics of glyphs for individual character positioning (by the symptoms and discussion it seems that this is happening, since if plain strings are provided to the PostScript show operator, it uses the constant metrics embedded in the font, and the kerning wouldn't ever differ), then a pure vector rendering mechanism should be used, and not one that assumes any pixelization or sampling, as when the PostScript/PDA renderer processes the fonts, it is doing this completely in vector space.

And for the specific fonts.conf issue:

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.

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. I do not really know Cairo however and realize that parts of its interface may not be making this functionality modular enough. As I mentioned, a real fix at the root may involve bigger changes, and if the problematic assumptions go beyond Mozilla code, I can't expect more than a careful workaround from here.