Sorry, I'm late for another work.
On Tue, 20 Nov 2018 12:47:09 +0000, Huw Davies huw@codeweavers.com wrote:
On Tue, Nov 20, 2018 at 11:40:45AM +0900, Byeongsik Jeon wrote:
Unfortunately, this patch can't solve bug #41639. FT_LOAD_TARGET_MONO works correctly only in Freetype 2.8.1+, but bug #41639 is about Freetype 2.7. http://lists.nongnu.org/archive/html/freetype/2017-09/msg00032.html
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/truetype/tt...
In Freetype's truetype interpreter version 40, The hdmx table and modifications to phantom points are ignored. Only FT_LOAD_TARGET_MONO applies v35 internally (Freetype 2.8.1+).
If it's only bad for versions between 2.7 and 2.8 I think we can leave it. The patch to fix it in between those versions was too ugly.
This problem is resolved by correcting the wrong advance problem described below. Bug #41639 is a B/W rendering problem for the outline that are not hinted horizontal direction.
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?
1. https://docs.microsoft.com/en-us/typography/opentype/spec/tt_instructing_gly... --- Phantom points The Microsoft rasterizer v.1.7 or later will always add four “phantom points” to the end of every outline to allow either widths or heights to be controlled (MS rasterizers earlier than v.1.7 only add two phantom points, allowing only widths to be controlled).
If the entire set of contours for a glyph requires “n” points (i.e., contour points numbered from 0 to n-1), then the scaler will add points n, n+1, n+2, and n+3. Point “n” will be placed at the character origin, point “n+1” will be placed at the advance width point, point “n+2” will be placed at the top origin, and point “n+3” will be placed at the advance height point. For an illustration of how these phantom points are placed, see Figure 2-1 (points 17, 18, 19, 20) and Figure 2-2 (points 27, 28, 29, and 30).
All four phantom points may be controlled by TrueType instructions, with corresponding effects on the sidebearings, advance width, and advance height (in the case of vertical positioning) of the instructed glyph. The side bearings, advance width, and advance height are computed using these phantom points and are called the device-specific widths and heights (since they reflect the results of grid fitting the width or height along with the glyph to the characteristics of the device). The device-specific widths or heights can be different from or identical to the linearly scaled widths or heights (obtained by simple scaling operations), depending on the instructions applied to the phantom points.
Before applying a TrueType instruction on height related phantom points (n+2 and n+3), use GETINFO[ ] to check that the rasterizer is a MS rasterizer v.1.7 or later. ---
2. https://docs.microsoft.com/en-us/typography/opentype/spec/recom#39hdmx39-tab... --- 'hdmx' Table This table improves the performance of OpenType fonts with TrueType outlines. This table is not necessary at all unless instructions are used to control the "phantom points", and should be omitted if bits 2 and 4 of the flags field in the 'head' table are zero. (See the 'head' table documentation in Chapter 2.) Microsoft recommends that this table be included for fonts with one or more non-linearly scaled glyphs (i.e., bit 2 or 4 of the 'head' table flags field are set). ---
3. https://docs.microsoft.com/en-us/typography/opentype/spec/head --- uint16 flags
Bit 2: Instructions may depend on point size; Bit 4: Instructions may alter advance width (the advance widths might not scale linearly); ---
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.
