Reconfiguring a CTFont's cascade makes used underlying font ambiguous

[drott]

More details in: https://bugs.chromium.org/p/chromium/issues/detail?id=132252#c162 , copied from there

"In hb-coretext.cc we are reconfiguring the shaping CTFont to change it to a shortened cascade list. For that we are creating a font descriptor with a cascade list attribute which contains only the LastResort font, then we call CTFontCreateCopyWithAttributes.

From hb-coretext.cc:

CTFontDescriptorRef last_resort_font_desc = get_last_resort_font_desc ();
CTFontRef new_ct_font = CTFontCreateCopyWithAttributes (ct_font, 0.0, NULL, last_resort_font_desc);

This leads to switching from a CTFont whose URL attribute points to
file:///System/Library/Fonts/Helvetica.dfont
to a CTFont whose URL attribute points to
file:///Users/drott/Documents/Font/Type1%20Helvetica/Helvetica/Linotype/Helvetica

The latter CTFont causes problems downstream since we cannot access this file outside the sandbox.

This font URL attribute change and remapping to the new font is a somewhat unexpected side effect of the CoreText API call.

One possible mitigation is to compare the URL attributes before and after and discard the reconfigured font if the URL has changed. This comes at a performance cost since we are unable to reconfigure the cascade list, but could probably be considered acceptable since the expected frequency of occurrence of this situation is rather low.

I also tried defining different types of font descriptors to stay on the same system font, which did not succeed. I tried CTFontCopyDescriptor, then copying this descriptor to a modified one with the additional cascade list configuration, but this also fails, since the copied descriptor only contains a name and a size attribute.

I also tried creating a font descriptor that matches URL, name and size, which lead to a stalled renderer process since the font matching does not succeed or is really slow."