Stop using CGFont APIs with macOS system fonts (only use CTFont / NSFont)
Categories
(Core :: Graphics: Text, task)
Tracking
()
People
(Reporter: mstange, Unassigned)
Details
(Whiteboard: [mac:deprecated])
We are using some deprecated APIs in our system font handling, and it's causing problems with every new version of macOS.
Examples: Bug 1201318, bug 1672842, bug 1675185, and most recently, bug 1732629.
We should find a solution that is less brittle. In particular, we should stop trying to get the font name of a system font, and we should never convert between the CGFont and CTFont representations. It would be great if we could go straight from the NSFont to the CTFont, somehow.
|
||
Comment 1•4 years ago
|
||
It would be great if we could go straight from the NSFont to the CTFont, somehow.
...or maybe we could eliminate the use of NSFont as well, and do everything using CTFont APIs?
|
Reporter | |
Comment 2•4 years ago
•
|
||
Sure, that should work too. But the NSFont APIs we're calling in LookupSystemFont do look like the right tool for the job.
... Oh, NSFont* and CTFontRef are the same thing! These docs say the following about CTFont: "Its reference type, CTFontRef, is toll-free bridged with UIFont in iOS and NSFont in OS X."
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 3•3 years ago
|
||
One of the open questions is how to serialize the CTFont across processes. I think this serialization currently involves the font name. Here are some docs for serializing and deserializing CTFonts / CTFontDescriptors:
https://developer.apple.com/library/archive/documentation/StringsTextFonts/Conceptual/CoreText_Programming/FontOperations/FontOperations.html#//apple_ref/doc/uid/TP40005533-CH4-SW25
So it's just a dictionary of attributes. The font name might be in the dictionary, but we shouldn't assume a font name anyway.
The open question is whether this attribute dictionary serialization actually works for system fonts.
Description
•