[cairo] [poppler] Printing with poppler on Windows

[Christoph Lindemann]

> The problem with making poppler use win32 fonts is that I don't think
> windows will accept the fonts extracted from a PDF. TrueType fonts
> should be ok although I don't whether windows will work with subsetted
> fonts.

Subsetted fonts are supported just fine. You can also use the
CreateFontPackage and MergeFontPackage functions to merge subsetted
fonts.

> CFF fonts would need to be placed inside an OpenType wrapper.
> Type 1 fonts require the pfm file for windows to be able to use them,
> and this is not embedded in the PDF. I expect that all this could be
> made to work but it would take some effort to work out what works in
> windows and work out how to modify the embedded fonts (eg by adding
> missing tables, generating a pfm file) to get windows to load them.

FontForge does (as far as I know) support conversions between different
formats . Maybe parts of the code can be used in cairo. FontForge has a
BSD like license.

> There are also issues with font name collision and lifetime of fonts
> that poppler would need to resolve [1].
> 

There are also some issues with font uninstalling, as the fonts are
removed asynchronous, and they are NOT reference counted (at least not
within the same process). So if you install and uninstall the same font
several times, you might end up with the font not being installed. As an
example:

1. You install "font a" (with AddFontResourceEx or similar)
2. You draw text with "font a"
3. You uninstall "font a" (with RemoveFontResourceEx or similar)
4. You install "font a" 
5. You draw text with "font a"
6. You uninstall "font a"

Then, as the uninstall at (3) is asynchronous, you might get in the
situation where the font is installed again (4), but before it is used
in (5) the asynchronous remove (3) finishes. So the font might not be
available anymore (at 5).

This applies to the whole process! So especially when using multiple
threads (fx. for printing) you can end up with problems.

A solution in cairo might be to rename (to a unique ID) the fonts
(rewrite the font tables) when adding a font resource, and then
maintaining an internal font mapping table between cairo and GDI.
This would also free any application, which is using cairo, from having
to worry about font collisions. And would ensure that the win fontmapper
does indeed use the provided font resource, and not another already
installed where the font name happens to be the same.

As an extra note, the problem described above gets specially interesting
when the font is a obfuscated subset font. Like some applications use
when saving PDF documents, to prevent the font from being reused. In
this situation, you will end up with garbage text (when the font was
removed) when the windows fontmapper tries to substitute the font with
another installed font.