Menu
▾
▴
#23 Windows font backend
Hello,
Now that there are a bunch of subscription font services around---including Monotype's, which seems to be absolutely amazing value---that load fonts without adding them to the normal font directory, it would be really really useful if it were possible to use these with LaTeX.
In order to support font embedding, the Windows API lets you extract the entire font file using GetFontData if the appropriate bit is unset, so what I was thinking---assuming I can't load the OTF data from memory, which it looks like I can't---was to write it out to a temporary file, set the font filename appropriately, then delete it after I'm done.
The main thing that I still need to investigate is how this would interact with the caching process---would there be things persistently stored that ought not to be?
Before I get started, would people indeed be interested in merging this back to mainline, and if so, am I biting off a larger project than I can chew?
Thanks,
Lachlan
Have you checked whether such "subscription" fonts actually allow extraction of the entire file? I'd be somewhat surprised if they do....
Rather than copying the complete font to a temporary file, and then loading that file by name, a more "windows-native" implementation would be to work directly with win32 APIs (e.g. create an HFONT with CreateFont, select it into an HDC, and use GetFontData as the basis for harfbuzz font callbacks). This would probably be more performant, and would avoid the potential licensing issues of whole-font extraction to a file.
Note that in addition to extending xetex, you'll need to consider what to do about xdvipdfmx, as it also needs access to the font. If you extract the entire font file, and then address it by pathname, things should "just work" .... but this also means the extracted font isn't really temporary: xetex can't delete it, because xdvipdfmx still needs it. And if you make xdvipdfmx delete it after use, we'd have the disconcerting situation whereby you can run "xetex -no-pdf" to create an .xdv file; then you can run xdvipdfmx to generate a .pdf; but if you try to re-run xdvipdfmx on the same .xdv, it will fail.
The better solution, I think, would be to make xdvipdfmx also use the font directly via windows APIs; presumably, it could also look up the font and use GetFontData, etc., to access it. But this does mean adding a platform-specific extension to the driver as well as to the xetex engine.
Yes, it definitely does, I checked before creating the ticket---it has to, otherwise Word, etc. couldn't produce PDF output.
I agree that it would be better to use the font straight from memory, I was somewhat deterred by the FontInst interface which specified a filename. But there are ways around that.
As a starting point, though, could one not just use GetFontData and FT_New_Memory_Face in place of FT_New_Face? Does xdvipdfmx address the font by filename now?
That should basically work for xetex, AFAICS.
xdvipdfmx will take a bit more work, I think. It used to include code that used freetype to access font data, and relied on that for opentype fonts in xetex output, but a couple of years or so back, when the code was merged back with the dvipdfmx sources, that was removed and it now reads all fonts directly from files using its own code.
What you could probably do would be to mark the native_font_def with a flag of some kind to say that you're passing a Windows font face name instead of a filename, and then add code in xdvipdfmx that detects this, does the same Windows font resource lookup as xetex, and uses GetFontData to grab the font data it needs instead of reading a file.
Which xdvipdfmx source tree do you mean? The only one that I've found is from years and years ago, and still uses Freetype.
The current source is maintained in the TeXLive svn repository. (If you're referring to the old repository at sil.org, that hasn't been updated in years, as you say....not since I left SIL, presumably. I should see if I can get it taken down, I guess.)