In order to Unicode-enable the PostScript driver, it needs information about about font encodings that isn't present in Adobe's AFM file format (glyph names for character encodings greater than 256). For Type 1 fonts with a standard encoding, the driver can use the encoding in the Adobe Glyph List. (There's no other choice.)
TrueType font designers, however, seem to regard glyph naming as an opportunity to express their creativity. Besides, the information is present in the TrueType font files, so the driver might as well use it.
The driver could read this information directly from the font files, but this would make Wine dependant on the FreeType libraries, and that doesn't strike me as a wonderful idea. Instead, I have cobbled together a small program which reads a TrueType font file and creates a "TrueType Font Metrics" file, which is very similar to an AFM file. (This program does use the FreeType library.)
Anyone have any objections to using this approach as a interim measure?
Ian Pilcher wrote:
In order to Unicode-enable the PostScript driver, it needs information about about font encodings that isn't present in Adobe's AFM file format (glyph names for character encodings greater than 256). For Type 1 fonts with a standard encoding, the driver can use the encoding in the Adobe Glyph List. (There's no other choice.)
TrueType font designers, however, seem to regard glyph naming as an opportunity to express their creativity. Besides, the information is present in the TrueType font files, so the driver might as well use it.
The driver could read this information directly from the font files, but this would make Wine dependant on the FreeType libraries, and that doesn't strike me as a wonderful idea. Instead, I have cobbled together
What do you find objectionable about making wine work more closely with FreeType?
From the end user perspective, printing in Wine sucks right now due to
the fact that you've got to manually make all these AFM files (or now your proposed TT equivalent), and then just kind of hope that the printer has the font available. If you're printing to a local inkjet or something and you have Ghostscript set up just so, it'll work, but it acts horribly if you're printing to a remote PS device.
The only way that that problem can be solved is if we can automatically upload a T1 version of any given font to the PS file. We can only do that if we have access to the glyph outline data, which would require linking to something like FreeType in some way.
When we were doing WPO2K for Linux at Corel, we used Bitstream's commercial font server for this purpose. It had an extended API that you could use to get at additional font characteristics and glyph outlines. It was a major pain to use, and it appears to be the top reason that end users have problems with the product (font server configuration is a nightmare for newbies). It's a shame that we didn't use FreeType instead.
What I'd love to see happen with fonts in Wine is this:
- shift the x11drv and wineps over to using the DDK Font Engine APIs that are currently just stubs.
- Implement a FreeType font driver that links to Freetype and uses the FreeType APIs for all font metrics data as well as rasterization.
- Implement an X11-dependant font driver in the Font Engine to rely on as a backup if FreeType isn't available.
Using FreeType more directly would also allow Wine to do serious typography - the metrics data available from X is awful compared to what you can get directly from FreeType, and doing anything less gives you subtle variations in glyph placement that can completely mess up the decision of where to break a line. If we ever want to see people using Wine for serious graphics and page layout applications, we have no choice but to go for the FreeType approach.
Now, all of that said, I don't actually have the time to help with any of this directly (unless someone wants to throw a contract my way, of course). All I can really do is cheer you on from the sidelines should you decide to go for it, and perhaps offer the occasional nugget of advice. Speaking of which, I do hope that you've seen the font & printing code in the Corel wine tree. It may not do you much immediate good, but I suspect that it could be a usefull reference point.
Good luck! -Gav
Gavriel State wrote:
What do you find objectionable about making wine work more closely with FreeType?
Absolutely nothing. I just don't think the immediate benefit of getting at TrueType encodings justifies creating the dependency at this time.
What I'd love to see happen with fonts in Wine is this:
shift the x11drv and wineps over to using the DDK Font Engine APIs that are currently just stubs.
Implement a FreeType font driver that links to Freetype and uses the FreeType APIs for all font metrics data as well as rasterization.
Implement an X11-dependant font driver in the Font Engine to rely on as a backup if FreeType isn't available.
I agree with all of this. I did say that these font metrics files are an interim solution.
Now, all of that said, I don't actually have the time to help with any of this directly (unless someone wants to throw a contract my way, of course). All I can really do is cheer you on from the sidelines should you decide to go for it, and perhaps offer the occasional nugget of advice. Speaking of which, I do hope that you've seen the font & printing code in the Corel wine tree. It may not do you much immediate good, but I suspect that it could be a usefull reference point.
I don't have the time or the skills to do this. For now, I just want to get the driver Unicode-enabled.
-
Gavriel State -
Ian Pilcher