Fwd: Should we expect Liberation fonts to be installed?

[Paul "TBBle" Hampson]

Sorry, I failed at Gmail again. >_<

---------- Forwarded message ----------
From: Paul "TBBle" Hampson <Paul.Hampson at pobox.com>
Date: 12 August 2010 13:52
Subject: Re: Should we expect Liberation fonts to be installed?
To: Scott Ritchie <scott at open-vote.org>


On 8 August 2010 13:02, Scott Ritchie <scott at 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 at Pobox.com

On 12 August 2010 13:52, Paul "TBBle" Hampson <Paul.Hampson at 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 at Pobox.com