[vlc-devel] [PATCH 0/4] freetype: font fallback

[Jean-Baptiste Kempf]

On 22 Oct, Salah-Eddin Shaban wrote :
> Here (finally!) is font fallback using Uniscribe on Windows, FontConfig on Linux, and the XML configuration files on Android.

A-MA-ZING! Nothing short of that.

This close #5353 #2336 #4973 #5123 #5144 #5847 #7729 #7990 #8641 #12141
#12432 bug reports and probably many others.

> I had to use Uniscribe on Windows because font linking turned out to be very unreliable.

I agree it was a good decision.

> It works for some combinations of families/scripts only.

I'm afraid we will need DirectWrite to have a better support.


> On Android I'm using the configuration files system_fonts.xml and fallback_fonts.xml. Newer versions of Android have the newer configuration in fonts.xml but they are required to keep the old files in sync. Right now there is no point in supporting the newer config since we do not have support for different weights, BCP language tags etc.

Yes, that's the right way.

> I tested the Android code on Linux after copying the fonts and config files from 2 Android devices. I think the code should work on Android without problems.

I will spend time testing it next week with devices from 2.3.7 to 6.0.

> Certain discrepancies among platforms have forced some complications into the code. Right now I'm using a master family list that holds information about families and fonts obtained from the system, while fallback lists only reference this information in the master list to avoid unnecessary replication. Families in Android can be referenced by many different names so the family_map dictionary will contain multiple keys that map to a single family.

OK. That's expected, tbh.

> Populating fallback lists is done differently on each platform. On Android everything is loaded at startup when the XML files are parsed, and all fallback families reside within the "default" fallback list. On other platforms each family can have its own list of fallback families that are tried in order. FontConfig supplies us with fallback lists that seem to be guaranteed to cover all Unicode scripts. Whereas on Windows we have to populate the lists progressively. When a fallback for a given combination of family/codepoint is requested we try the fallback list of that family, and if no font is found that contains that codepoint we try UniscribeFallback, and add the resulting font to the list to speed up later searches.

I believe your code should say that.

> Some optimizations can be done if necessary, like moving successful fallback families to the top of fallback lists, or keeping track of failed codepoints for which no font exists to avoid searching for them again. This can happen harmlessly e.g. for Unicode control characters which will be removed later anyway by HarfBuzz or RemoveZeroWidthCharacters.

Good idea. But first, working; them perf.

> Also regarding performance, the fallback lists returned by FontConfig can be very long and may cause a slight pause in playback the first time a list is initialized, if the required codepoint happens to be in a font somewhere at the end of the list. One way to avoid that could be to trigger loading the fallback list of the default font at module load time. Or we can revert to the method used in the previous RFC patch, which behaves more like the Uniscribe method.

idem.

> The values in GetBestFont are arbitrary. You may want to change them. This function aims to fix two issues. If a family contains only a regular face and an Italic face is requested we should still return the regular face and let FreeType do synthetic styling. With font attachments this was not being done. The other issue is that not all styles of a family support the same scripts or codepoints. As an example the Italic face of Arial has no Arabic support whereas the regular face does. So with the font set to Arial, Italic Arabic text was appearing as missing glyphs.

I value your opinion on this. But once again, comments would be nice.

> Some exciting changes have been made to the FreeType module and text rendering in general, like text segments and on-the-fly text scaling! A few changes had to be made to the itemization code. I hope I did not break anything.

Yes, text-segment is a nice addition, so we stop managing 2 rendering
functions and HTML parsing...
Text scaling was requested since so long time...

> Salah-Eddin Shaban (4):
>   freetype: font fallback structs and functions
>   freetype: font fallback for Linux
>   freetype: font fallback for Android
>   freetype: font fallback for Windows

I renamed your Linux to "Fontconfig", because Solaris, BSDs and others
are using fontconfig, even without being a Linux.

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device