I don't have any appetite for changing things here right now. Meaning it
needs a lot of thinking about.
I was nervous about this when the PR was proposed : see my comment in
https://github.com/openjdk/jdk/pull/22670
----
One thing this fix does is change the logic which we have today
FROM
Let the font have first say. If it maps the code point, use what the
font provides,
the font should know what it is doing. And only map to zero if the font
does not support the code point
TO
Never mind what the font says, these are always invisible and zero width.
I have no easy way to know how this is going to work out in practice.
----
The points raised here mainly re-assert that nervousness and make me
re-think if the changes in that PR were right.
These are the only APIs that (supposedly) tell you if a font really maps
a code point.
Important to figure out if a font supports Chinese, or Arabic.
Unfortunately, the macOS implementation - which was contributed by Apple
- is nearly useless because it'll answer using fall back fonts,
so everything is mappable. That still bugs me and I think whilst its
fine to eliminate "boxes", its not fine that you have no idea which
font really is a good font for Arabic ..
Arguably we need APIs that are more direct about support for particular
scripts etc, but the history is what it is.
But what if we added fallbacks on other platforms too ? At this point
all of these APIs are utterly useless.
So this suggests these APIs should report what the specific font
actually maps.
But on the other hand, it is confusing if it says it can't but then does.
So a lot of this is existing, but I am not inclined to make a few
special code points cause us to turn everything upside down.
I think ideally there should be a separation between what a specific
named font can do and what the platform can substitute
But these are concepts that largely came along after these APIs were
designed.
New API ? How does that help older releases ? So what works for everyone ?
I could go on .. but there are more pressing font problems I've been
working on without time to finish.
-phil.
On 3/28/25 10:38 AM, Daniel Gredler wrote:
Hi all,
After some of the recent fixes for default-ignorable characters [1, 2]
I'm wondering what the expected behavior for the following methods is
w.r.t. default-ignorable characters (or really any invisible glyphs):
Font.canDisplay(char)
Font.canDisplay(int)
Font.canDisplayUpTo(String)
Font.canDisplayUpTo(char[], int, int)
Font.canDisplayUpTo(CharacterIterator, int, int)
The JavaDoc for the first two methods explicitly states "checks if
this Font has a glyph for the specified character", which is clear
enough, but doesn't match the method name since in reality any font
can display e.g. U+200B (zero width space) regardless of whether it
has a glyph in the font, since U+200B will always map to the invisible
glyph and will be skipped during layout / rendering.
The JavaDoc for the last three methods is more ambiguous, seeming to
focus on whether or not the font "can display" the string. Again,
characters which map to invisible glyphs do not need glyphs in the
font, so flagging them as "can't display" seems questionable.
Basically, I'm wondering whether these five methods should be
communicating that chars which map to invisible glyphs can be
displayed, regardless of whether the font has a glyph for them.
Thoughts?
Take care,
Daniel
[1] http://www.unicode.org/L2/L2002/02368-default-ignorable.html
[2] https://github.com/openjdk/jdk/pull/22670
