<Swing Dev> [9] Review request for 8132119 Provide public API for text related methods in SwingUtilities2

[Sergey Bylokhov]

On 27.04.16 1:50, Phil Race wrote:
> Glyphs are always rasterised in device space so it does mean device space.

I don't argue with it, the question is how to round.

> The identity transform therefore happens to always return a user space
> advance is that is an integer, but it is not bound to be so under any
> other transform.

I am not sure that this is correct. The simple example:

BufferedImage bi = new BufferedImage(width, height,TYPE_INT_ARGB);
int length = g2d.getFontMetrics().stringWidth(TEXT);
Graphics2D g2d = bi.createGraphics();
g2d.scale(2, 2);
length = g2d.getFontMetrics().stringWidth(TEXT);

In what space will be the length? I assume that this is the user space. 
Note that if in the second time we get 13 pixels we will round it to 7 
(but rendering will be done to 6.5 * 2 = 13). My suggestion in the fix 
is to make this round on the lower level and use the same values as 
stringWidth() and during rendering.

>
> -phil.
>
> On 04/26/2016 03:28 PM, Sergey Bylokhov wrote:
>> On 27.04.16 0:34, Phil Race wrote:
>>> Fractional metrics being "off" does not mean that *user space* advances
>>> need to be integers,
>>> it refers to *device* space advances. Of course if your API does not
>>> support floats you have a
>>> problem - particularly if - you are character advance adding in which
>>> case it is better to ask the
>>> font system for the overall advance of the text.
>>> https://docs.oracle.com/javase/8/docs/api/java/awt/RenderingHints.html#KEY_FRACTIONALMETRICS
>>>
>>
>> The documentation says that in case of "fm-off" the "simplified system
>> based on integer device positions is typically used" + "rounding
>> advance widths for rasterized glyphs to integer distances", it does
>> not say that the "integer distance" should be rounded to the nearest
>> device/pixel. It says that "rounding operations as the high quality
>> and very precise definition of the shape and metrics of the character
>> glyphs must be matched to discrete device pixels" I guess we should
>> confirm the specification because results of the fix will be "discrete
>> number of device pixels", isn't it?
>>
>


-- 
Best regards, Sergey.