RFR: 8246104: Some complex text doesn't render correctly on macOS

Johan Vos jvos at openjdk.java.net
Fri Jul 2 12:37:08 UTC 2021


On Thu, 1 Jul 2021 22:21:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/font/MacFontFinder.java line 83:
>> 
>>> 81:             Stream<Path> stream = Files.list(Paths.get("/System/Library/Fonts"));
>>> 82:             stream.forEach(f -> PrismFontFactory.getFontFactory().registerEmbeddedFont(f.toString()));
>>> 83:         } catch (IOException e) {
>> 
>> registerEmbeddedFont() is intended to be used for fonts embedded in an application not for system fonts. 
>> Also is there anywhere else we are hard-coding /System/Library/Fonts. Apple move things around.
>> Also as well as likely needing to use a different call to register, you should make sure that the API
>> is registering all the fonts in a collection.
>> Finally (I think) what happens if you print ? The font info needs to be passed over to J2D.
>
> Another thought .. after doing this do these "." fonts appear in the list of fonts reported by
> javafx.scene.text.Font.getFontNames() ?
> 
> I suspect they really should not ..

They are in there. But with the current approach for CT glyph-parsing, I see no other way. The parsing is done in native code (e.g. OS.CTLineCreateWithAttributedString()) but we extract the required font from the returned runs, e.g. 
`String fontName = CTFontCopyAttributeDisplayName(actualFont);`
Next, the `fontName` is searched for, but if it is not in the "public" list of fonts, this fails. So if we don't make these dot fonts public, this approach doesn't work.

-------------

PR: https://git.openjdk.java.net/jfx/pull/547


More information about the openjfx-dev mailing list