Glyphs are always rasterised in device space so it does mean device space.
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.
-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?
