On Tue, 20 Nov 2018 22:35:58 +0300, Dmitry Timoshkov dmitry@baikal.ru wrote:
Byeongsik Jeon bsjeon@hanmail.net wrote:
Even if we do not consider bug # 41639, now Wine GDI has a problem using the wrong advance value for MS legacy fonts( with hdmx table) at the v40.
Could you elaborate?
[skipped]
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.
http://lists.nongnu.org/archive/html/freetype/2018-11/msg00012.html Without FT_Property_Set, adding some flag to FT_Load_Glyph seems to be a good solution.