Currently if you have fonts-droid-fallback installed and run a program via
wine that uses both Japanese characters and Latin characters you will get
tofu characters for English (squares) [Broken Characters.png]. Removing the
fonts-droid-fallback package fixes this problem [Working Characters.png].
This seems to occur because the font provided in fonts-droid-fallback
(DroidSansFallbackFull.ttf) lacks Latin characters. This can easily be
observed with Font Viewer by selecting Lorem Ipsum [Lorem Ipsum.png].

This problem only affects wine and may be due to wine partially supporting
Uniscribe [1]. There's a few ways to go about fixing this issue though.

First of all Google has abandoned the droid font [2] so it could be argued that
the font should be removed from Debian.

Another option is to go back to older versions of the font where Latin
characters were present at some point in time Google removed a significant
amount of characters from the droid font. I believe this change occurred in
commit 034b20c102ee2e7ec1da09e2b080f35be4a5cf54 [3]. So going back to
commit 0abd8a79cc19658305dae81e3eca32b45f268f96 [4] would restore many
of the missing characters.

Another option would be to change all packages recommending
fonts-droid-fallback to suggesting it instead so it's not installed by
default.

Ultimately though these are just suggestions because I am unable to figure
out why wine cannot handle DroidSansFallbackFull.ttf's lack of Latin
characters.

[1] https://wiki.winehq.org/Uniscribe
[2] https://github.com/google/fonts/issues/1223
[3]
https://android.googlesource.com/platform/frameworks/base/+/034b20c102ee2e7ec1da09e2b080f35be4a5cf54
[4]
https://android.googlesource.com/platform/frameworks/base/+/0abd8a79cc19658305dae81e3eca32b45f268f96

Please see attachments mentioned in the original bug report.

Hi Konomi,

Quoting Konomi Kitten (2022-04-08 21:21:08)

To me this sounds like an issue in Wine, not in this font.

I mean, if an application chooses to load a _fallback_ font without
first trying other fonts that contains Latin1 characters, then it sounds
like that application is not really using that font as intended.
that fact in itself is not a reason for Debian to stop using it.

If you meant to imply some underlying reason for Debian avoiding the
Droid font, then please elaborate.

The purpose of Droid Sans Fallback is to provide a *lighweight*
fallback.

If you want rich coverage, then instead use Noto.

If you want medium coverage, then instead use a subset of Noto.

If an application cannot choose another font, then... That's a bug in
that application, and it seems very wrong to me to change the font or
every other package to try play along with that.

Sorry if I am missing something here - then please try elaborate.


 - Jonas

Quoting Konomi Kitten (2022-04-08 21:21:08)

[...]

Looking at that list, it seems Wine uses non-free fonts as fallback at
least for Latin1 characters.

Perhaps the problem is that Wine asks only for a specific non-existing
font, without fallback e.g. to "sans-serif", causing generally sensible
fonts to be ignored as fallback and only the extremely fallback-ish
Droid to be picked.  Then the solution is likely to patch Wine to
explicitly pick fonts available in Debian (e.g. speific Noto fonts as
appropriate).

Locally on your own system you can try define fontconfig substitutions
for each of the fonts listed in that Uniscribe list missing in Debian,
starting with "Microsoft Sans Serif".


Kind regards,

 - Jonas

is extremely knowledgeable with fonts or wine or both to chime in.

There is one thing I found during my testing, if you open
DroidSansFallbackFull.ttf with FontForge [FontForge.png] and do the
following: Element -> Font Info -> Unicode Ranges you'll see that the font
declares at least according to Font Forge that it does support Basic Latin
U+0020-U+007E/95. Double clicking these entries will jump to the relevant
characters and when I double click Basic Latin it obviously jumps to an
empty set of characters.

I noticed when I checked other ranges too such as Thai U+0E00-U+0E7F1/87
that
they too are missing their characters.

Considering Font Forge states: "This pane is information only and shows the
characters actually in the font..." is it possible that when Google removed
the extra characters in the commit I cited in my original report that they
failed to update what ranges the font supports or something along those
lines?

Again, I am no expert in fonts or FontForge but I hope this might be a
useful clue for someone that is.