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