Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
The home and end characters (and some others) display fine in the source editor, but not in GTK entries (for example, the keybinding editor).
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.
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.
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.