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

[Philip Race]

Applications cannot change the device transform and expect the same user 
space
metrics unless they specify fractional metrics to be ON.

In your example below you may already have a scaled graphics context
if you were printing (for example).

If you want no change to the user space positions or [as also implied] 
shapes of the glyphs
as the transform changes then you are asking for text that will not look
right at other resolutions. Printed text will look poorly spaced.

Changing what happens in the font system is not an option since it
will break many applications - even if it were the right thing to do - 
which it is not.

-phil.





On 4/26/16, 4:49 PM, Sergey Bylokhov wrote:
> 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?
>>>
>>
>
>