Bug 11477 - Fallback of glyphs not covered by default cascade list not working
Summary: Fallback of glyphs not covered by default cascade list not working
Status: CONFIRMED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: unspecified
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Kristian Rietveld (inactive)
URL:
Depends on:
Blocks:
 
Reported: 2013-03-29 14:57 UTC by Mikayla Hutchinson [MSFT]
Modified: 2017-07-21 00:34 UTC (History)
5 users (show)

Tags: gtk+
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 11477 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Mikayla Hutchinson [MSFT] 2013-03-29 14:57:14 UTC
The home and end characters (and some others) display fine in the source editor, but not in GTK entries (for example, the keybinding editor).

⇱⇲ etc.
Comment 1 Kristian Rietveld (inactive) 2013-03-30 09:29:46 UTC
These two particular characters are in the Menlo font. It looks like CoreText falls back to this font to render these characters. Interestingly, Menlo is not present in the font fallback list that we get from CoreText.

XS uses the Menlo font as code font by default and that seems to be why the characters are present in the source editor but not anywhere else.

I am trying to figure out how CoreText  determines to fallback to Menlo. If Menlo is hardcoded in CoreText (at least there's a CFSTR "Menlo" in the CoreText binary), we should hard code it as well at the appropriate place.
Comment 2 Kristian Rietveld (inactive) 2013-04-01 05:01:52 UTC
Even though there is a string "Menlo" present in the CoreText binary, it is not read during execution.

Instead, a completely non-trivial fallback mechanism is used that is apparently present next to the hard coded default font fallback lists. It goes something like this:

 - In CoreText, there are methods TFontCascade::CreateSystemWideFallback() and TDescriptorSource::CopySystemWideFallbackDescriptor()
 - These seem to trigger TXTRegistry::CopyFontForCharacter()
 - This goes to the ATS.framework, function XTCopyFontForCharacter(). This function first checks a local reject cache, then a local font registry but finally calls upon a global font registry.
 - The implementation of the global font registry will actually send a request OUT OF PROCESS to fontd, using XTSendCopyFontForCharacter.
 - fontd receives this request (XTHandleCopyFontForCharacter) and appears to resolve it using a persistent font registry, which is actually a sqlite3 database.


So hard coding Menlo is not an option to me, because we would start to hard code more fonts every time we find some character for which a fallback font is not automatically found. Having Pango call fontd or parse the sqlite database will be troublesome as this kind of stuff may change between OS X releases.

To properly solve this, I think the options are:

  1) We need some method in Pango to be able to use CoreText functionality to resolve a font for a character, if the default font fallback list does not contain a font which covers the character. Or, more globally, you want to have an interface in Pango to have the system libraries perform font fallback before shaping takes place. This would be beneficial for Windows as well.

  2) Pango needs its own font registry code on OS X (based on fontconfig or otherwise), essentially replicating what is already supported by OS X. A problem with this on OS X will be that typically every .app ships its own Pango and incompatible versions need their own version of the font registry (that you likely want to store in ~/Library).


I will also poll the Pango maintainer for an opinion.
Comment 3 Kristian Rietveld (inactive) 2013-04-20 06:06:03 UTC
I have discussed this situation with the Pango maintainer and a Mozilla developer. We have come to the conclusion that option 1) as described above is the right way to move forward. The idea is to add functionality to PangoFontsets (a representation of a font fallback list) so that as a last resort we can call into the system libraries to resolve a font for a given character.

This same functionality can be used to improve the situation on Windows in the future. In general, the Windows support would look like this (which is similar to how FireFox handles fonts):
 - We have a default font fallback list consisting out of a set of default fonts that handle common languages.
 - If the glyph to be rendered is not covered by the fonts on this list, we call into the system libraries.


Would Xamarin be willing to sponsor some development time to fix this bug properly upstream? I think we can get something working within a man week.