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, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
