Fwd: Should we expect Liberation fonts to be installed? - wine-devel

12 Aug 2010


      Sorry, I failed at Gmail again. >_<
---------- Forwarded message ----------
From: Paul "TBBle" Hampson Paul.Hampson@pobox.com
Date: 12 August 2010 13:52
Subject: Re: Should we expect Liberation fonts to be installed?
To: Scott Ritchie scott@open-vote.org
On 8 August 2010 13:02, Scott Ritchie scott@open-vote.org wrote:
...
On 08/03/2010 01:57 PM, Scott Ritchie wrote:
...
I was looking through our fairly large collection of open font bugs and
realized that things might be a lot simpler if we took some opinionated
positions and just declared certain fonts to be dependencies and
expected all packagers to provide them.
This is similar to bundling our own Tahoma, except much less work.
This bug, for instance, prevents Photoshop from working unless there is
an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623
Wine doesn't seem to respect system-level fontconfig aliases, so even
though Liberation Sans is installed on the system Photoshop won't try to
use it in place of Arial.
But if however we assumed that Liberation Sans was installed, we could
make things much better: a link/substitution for Arial->Liberation Sans
could be provided in our own registry (and similarly for Times New Roman
and Courier).  An alternative is to simply symlink to the Liberation
Fonts in /usr/share/wine/fonts as though they were our own shipped fonts
(like Tahoma).
This would make Photoshop think Arial was present and keep it
functional.  Ideally the real Arial would be displayed if it was
installed (eg through winetricks corefonts or by installing the
distro-provided corefonts package).
A related question is whether to show "Arial" in the list of fonts (eg
notepad) when we're actually just providing a substituted Arial.  My
inclination says no, however I'm not sure how it works internally and
what an application would expect.
Assuming for a moment this is a good idea, what's the best
implementation?  My inclination is to say some registry font links, but
I'm not completely familiar with how that works.
Will font links in the registry be ignored when the real font is present?
(Wine-specific) Font Replacements will be ignored when the real font
is present. Those're the ones in HKCU\Software\Wine\Fonts\Replacements
and probably the ones you want to use. (Which could be supplanted or
supplemented by working FontConfig alias support...)
(GDI) Font Links (ie. the same registry entries Windows uses) are
fallbacks for missing glyphs. Those're the ones in
HKLM\SOFTWARE\Microsoft\FontLink\SystemLink
Font Substitutes _probably_ don't get ignored if a real font with that
name exists. Those're the ones in HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\FontSubstitutes and they're pretty purpose-specific.
The only entries we want for them in Wine are the ones described at
http://blogs.msdn.com/b/michkap/archive/2005/03/20/399322.aspx (which
should probably be the default in Wine anyway, at least the Tahoma
entry.)
(Which by-the-by highlights a mistake in my previous suggestion
towards bug 13829)
--
Paul "TBBle" Hampson, Paul.Hampson@Pobox.com
On 12 August 2010 13:52, Paul "TBBle" Hampson Paul.Hampson@pobox.com wrote:
...
(Wine-specific) Font Replacements will be ignored when the real font
is present. Those're the ones in HKCU\Software\Wine\Fonts\Replacements
and probably the ones you want to use. (Which could be supplanted or
supplemented by working FontConfig alias support...)
To be clear, I think the best first-step solution for this bug is for
Wine's Font Replacements code to read the aliases from FontConfig as
well as its own registry keys when building its list. (The latter
being taken over the former)
That would make the problem magically go away on systems that do
include appropriately-substitutable fonts.
--
Paul "TBBle" Hampson, Paul.Hampson@Pobox.com