Byeongsik Jeon bsjeon@hanmail.net wrote:
For example:
$ ttx -l tahoma.ttf | grep hdmx hdmx 0x40968415 106152 19188 $ ttx -t hdmx tahoma.ttf
ppem: 9 10 11 12 13 14 t: 3 3 4 5 4 5
Tahoma 't' width=685 EM=2048. liear scaled advance=ROUND(ppem * 685 / 2048). t: 3 3 4 4 4 5
wordpad_tahoma_t_111213px.png shows the actual rendered image. We can see the 5px advance applied in the ppem 12px 't'.
I used 't' as an example to show prominent differences, but it also applies to other characters. This problem will cause a difference in text layout between Wine and native Windows. Of course, it does not appear in programs with their own layout engines, or programs using DirectWrite.
Is there a reason why freetype doesn't do what Microsoft documentation implies to be a responsibility of the font rasterizer?
It's v35. http://lists.nongnu.org/archive/html/freetype/2017-09/msg00036.html
And, it is registered as an issue. But it has a low priority for Freetype maintainer.
I'd suggest to either ask Werner to give a higher priority to that bug, or find someone else able to fix it properly on Freetype side instead of hacking Wine (or any other 3rd party project) with adding workarounds for this bug.