I am not 100% sure what you are getting at, but maybe
"render each such character" could be rephrased as
"query the advance of each such character".
But I would not point to charWidth() for this because
it is not adequate for all code points.
Does that clear it up ?
-phil.
On 4/23/20, 9:49 AM, Sergey Bylokhov wrote:
On 4/23/20 9:34 am, Philip Race wrote:
No, I don't see the relationship.
charWidth() is accurate if you use the FontMetrics from the render
context.
If it is always accurate why it is not recommended in the new
documentation? Why we suggest to "render each such character".
299 * None of these are exposed and they are all implementation
details,
300 * and there is no practical way to determine this. An
application
301 * which needs a better estimate of the maximum advance, and
knows
302 * the subset of characters it expects to display could render
303 * each such character to find the widest, but as discussed
above,
304 * since the displayed width of a {@code String} is not
necessarily
305 * the sum of the advances the value needs to be used with
caution.
-phil.
On 4/23/20, 9:19 AM, Sergey Bylokhov wrote:
Hi, Phil.
Isn't all/some of the new text in getMaxAdvance() is also applicable
to charWidth()?
If I read the current doc properly then it looks like the
charWidth() should return "advance"
of some specific "advance", and getMaxAdvance() is "just" maximum
value of any possible
results from the charWidth().
On 4/22/20 12:49 pm, Philip Race wrote:
bug : https://bugs.openjdk.java.net/browse/JDK-8230672
webrev : http://cr.openjdk.java.net/~prr/8230672/
Loosen up the spec. a lot to reflect reality.
I considered deprecating the method but there isn't any easy
replacement,
so it would just be annoying to old code.
This will clearly need a CSR which I will draft once we agree on
the text here.
-phil.
