bugThe FreeType Project - Bugs: bug #58352, B/W hinting differences of...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58352: B/W hinting differences of "a" and "z" in Tahoma if compared to Windows

Submitter:  None
Submitted:  Mon 11 May 2020 04:04:09 PM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.10.3

Jump to the original submission

Wed 02 Dec 2020 02:41:15 AM UTC, comment #40: 

About 1/64 of curvy dropouts would have this ambiguity. Therefore, it should not be too hard to notice any regression. So far we did not see any, nor did we receive any bug reports.

This is such old technology to obsess about. The dropouts were cool 25 years ago. Do you realize how little it matters now with dramatically increased screen resolutions? Do you realize that Windows is certainly not the most dominant OS counting all screens in use? The role of dropouts with oversampling is even smaller. Do you realize that you basically work on TD for your own amusement? This is fine, of course, when you are young.

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 01 Dec 2020 08:13:56 PM UTC, comment #39: 

Your patch is not the actual rendering method that is used, and therefore risks causing regressions elsewhere. Type Design did not bother to attempt reproducing your patch because it is meaningless with respect to getting every single case right. However, with the correct method, the correct rendering of a at 16ppem was reproducible in the development of TD renderer.

Anonymous
Tue 01 Dec 2020 07:00:07 PM UTC, comment #38: 

It is certainly possible to explore corner cases with synthetic fonts, but the cost-benefit is minuscule if any. It is just not useful. Do you really think that somebody uses opposite conttour orientation intentionally? They probably might in Andromeda galaxy, our universe is large, of course. For the real *world*, we fixed Tahoma a and p, which indeed counts a progress. (It is only now you begin to combine rounding and averaging in one expression, which is a good too). We analyzed Tahoma z and realized that FreeType's solution is more accurate.

Feel free to continue reproducing GDI faults and post them here, of course, but I will close the bug. Please open a new bug if a widely *used* font exhibits something strange. Do not waste your time on synthetic fonts unless you can corroborate your findings with in the real *world* or crash FreeType.

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 01 Dec 2020 04:13:49 PM UTC, comment #37: 

Note that this subdivider formula is ONLY for finding the fractional edges. The integer edges, as necessary for determining whether dropout control exists and for finding where filled pixels start and end, are done with a completely separate and completely different formula that uses integer computation to trace edges through the spline.

Anonymous
Tue 01 Dec 2020 04:11:11 PM UTC, comment #36: 

Round half down average formula for midpoint: (1+a+(2*b)+c)>>2
Round half up average formula for midpoint: (2+a+(2*b)+c)>>2
Round half down average formula for off curve point: (a+b)>>1
Round half up average formula for off curve point: (1+a+b)>>1

Anonymous
Tue 01 Dec 2020 04:08:44 PM UTC, comment #35: 

To clarify when doing smart dropout control to find the fractional position within a horizontal scanline, you round half down if the start point is lower than the end point, half up if the start point is higher than the end point, in both dimensions.

To clarify when doing smart dropout control to find the fractional position within a vertical scanline, you round half down if the start point is to the left of the end point, half up if the start point is to the right of the end point, in both dimensions.

Anonymous
Mon 30 Nov 2020 09:06:29 PM UTC, comment #34: 

Found the actual smart dropout control used in TrueType rendering!

Correct smart dropout control is guaranteed with this method

Calculate the midpoint as the average of four: the two on curve points, and the off curve point twice. The average is rounded in the 26.6 space. If half rounding case, round down in the dimension you want to find the fractional smart dropout position, and round towards the start point in the other dimension that specifies which scanline.

While the midpoint is not located on the dropout scanline,
{

If the scanline you want to find the dropout control is above the midpoint, subdivide the spline upwards,
{
Set the start point of the spline to the midpoint
Set the off curve point of the spline to average of the end point and the off curve point. The average is rounded same as the midpoint
}

If the scanline you want to find the dropout control is below the midpoint, subdivide the spline downwards,
{
Set the end point of the spline to the midpoint
Set the off curve point of the spline to average of the start point and the off curve point. The average is rounded same as the midpoint
}

Recalculate the midpoint as mentioned.

}

Anonymous
Sat 21 Nov 2020 08:20:50 PM UTC, comment #33: 


comment #22:

> To reproduce smart dropouts a la GDI, first we need to floor the profile coordinates to 26.6 and then apply smart dropout rounding. Then the increased resolution would not change dropout control outcome, which probably makes sense.
>
> Here is the patch that fixes Tahoma-16ppem-a and Tahoma-12ppem-P. Should we apply it?


> --- a/src/raster/ftraster.c
> +++ b/src/raster/ftraster.c
> @@ -460,7 +460,8 @@   Function_Sweep_Step(
>            (Bool)( x - FLOOR( x ) >= ras.precision_half )
>
>    /* smart dropout rounding */
> -#define SMART( x1, x2 )  FLOOR( ( (x1) + (x2) - 1 ) / 2 + ras.precision_half )
> +#define SMART( x1, x2 )  FLOOR( ( (x1) + (x2) - ( ras.precision >> 6 ) ) / 2 \
> +                                + ras.precision_half )
>
>  #if FT_RENDER_POOL_SIZE > 2048
>  #define FT_MAX_BLACK_POOL  ( FT_RENDER_POOL_SIZE / sizeof ( Long ) )


>


Note, just a hack that happens to fix these particular glyphs but is not the actual dropout control used and may cause regressions.
The actual rounding method used is round to the nearest 26.6, but in half rounding cases it rounds towards the latter of the two endpoints (round half up if the endpoint is larger than startpoint, round half down if the endpoint is less than startpoint). With the tests being performed in TD renderer, this makes it render & in TrueTypefonttest2 at #49824 properly but does not fix the a in Tahoma at 16ppem.

Anonymous
Mon 28 Sep 2020 08:56:47 AM UTC, comment #32: 


comment #31:

> Thanks for the documentation of your algorithm.
>
> Regarding a test suite: How else can you ensure that rendering results are identical?
>
> There might be more problems with FreeType's dropout implementation, and you are invited to provide patches to fix this.


Ok so the reason for the test suite being mandatory is because it is the only way to ensure rendering results are identical. But where did you hear it is mandatory for every TrueType renderer to ensure rendering results are identical? Is this in the specification or was this confirmed by Microsoft?

I have no idea what FreeType rasterizer code exactly does. This is not my code so I have no idea how the algorithms work (or don't). Neither do you have any idea about my code so of course you wouldn't be able to incorporate the patch in comment #22 into TD renderer, and it works the other way too so I do not know how the patch works to be able to incorporate it in TD renderer, and neither would I be able to fix Edge dropout control glitching in FreeType.

Anonymous
Mon 28 Sep 2020 06:56:22 AM UTC, comment #31: 

Thanks for the documentation of your algorithm.

Regarding a test suite: How else can you ensure that rendering results are identical?

There might be more problems with FreeType's dropout implementation, and you are invited to provide patches to fix this.

Werner LEMBERG <wl>
Group administrator
Sun 27 Sep 2020 12:31:49 PM UTC, comment #30: 

To keep track of the best known method for dropout control see https://pixelbuilding.createaforum.com/quadratic-pixel-building/dropout-control/

Anonymous
Sun 27 Sep 2020 12:27:58 PM UTC, comment #29: 


comment #28:

> It's an unfortunate fact of life that the specification is not sufficient: there are so many corner cases not discussed.  For the sake of the zillion fonts that have been created with VOLT and other MS tools it is mandatory to imitate MS rendering.
>
> In other words, every implementation of a B/W renderer has to contain a test suite of fonts that check the rendering results against the MS renderer [and yes, FreeType still lacks this essentially].  If necessary, the results have to be adjusted (using whatever means is necessary to achieve that).
>
> In a certain way this is reverse engineering, but I consider it unavoidable.  As many, many fonts show, people are relying on the corner cases!  While it would be almost always possible to slightly adjust the TrueType code to avoid them, we can't discuss away the undeniable fact that people don't do that while developing fonts.
>


The official specification is well known to not match the actual Microsoft renderer whatsoever, and is not reliable in the slightest for determining TrueType rendering behavior. It seems that FreeType has some remnants of specification based implementation and this is problematic because the Rule 2 in specifications was badly worded (in particular, center of the pixel on outlines is specified to specifically enable the pixel, but what it actually does is simply select the higher winding value), but FreeType goes out of its way to take it literally, which the Microsoft renderer (as well as TD renderer) doesn't.

The problem is the patched dropout control is obfuscated, leading to suspicion this is Microsoft code. And a specification of the patch was requested, not the official OpenType specification which is useless.

Where did you find out that a test suite against the official Microsoft renderer is mandatory in every TrueType bilevel renderer?

Anonymous
Sun 27 Sep 2020 07:10:50 AM UTC, comment #28: 

It's an unfortunate fact of life that the specification is not sufficient: there are so many corner cases not discussed.  For the sake of the zillion fonts that have been created with VOLT and other MS tools it is mandatory to imitate MS rendering.

In other words, every implementation of a B/W renderer has to contain a test suite of fonts that check the rendering results against the MS renderer [and yes, FreeType still lacks this essentially].  If necessary, the results have to be adjusted (using whatever means is necessary to achieve that).

In a certain way this is reverse engineering, but I consider it unavoidable.  As many, many fonts show, people are relying on the corner cases!  While it would be almost always possible to slightly adjust the TrueType code to avoid them, we can't discuss away the undeniable fact that people don't do that while developing fonts.

Werner LEMBERG <wl>
Group administrator
Sun 27 Sep 2020 05:47:28 AM UTC, comment #27: 


comment #26:

> This is certainly not MS code.  Neither Alexei nor I have access to that.


However, it is obfuscated in a way a specification reader cannot understand that. TD renderer is unable to reproduce this method no matter what is being used.

Anonymous
Sat 26 Sep 2020 06:01:54 PM UTC, comment #26: 

This is certainly not MS code.  Neither Alexei nor I have access to that.

Werner LEMBERG <wl>
Group administrator
Sat 26 Sep 2020 05:57:59 PM UTC, comment #25: 


comment #22:

> To reproduce smart dropouts a la GDI, first we need to floor the profile coordinates to 26.6 and then apply smart dropout rounding. Then the increased resolution would not change dropout control outcome, which probably makes sense.
>
> Here is the patch that fixes Tahoma-16ppem-a and Tahoma-12ppem-P. Should we apply it?


> --- a/src/raster/ftraster.c
> +++ b/src/raster/ftraster.c
> @@ -460,7 +460,8 @@   Function_Sweep_Step(
>            (Bool)( x - FLOOR( x ) >= ras.precision_half )
>
>    /* smart dropout rounding */
> -#define SMART( x1, x2 )  FLOOR( ( (x1) + (x2) - 1 ) / 2 + ras.precision_half )
> +#define SMART( x1, x2 )  FLOOR( ( (x1) + (x2) - ( ras.precision >> 6 ) ) / 2 \
> +                                + ras.precision_half )
>
>  #if FT_RENDER_POOL_SIZE > 2048
>  #define FT_MAX_BLACK_POOL  ( FT_RENDER_POOL_SIZE / sizeof ( Long ) )


>


That's copied Microsoft code, isn't it? It is not acceptable to use piracy and the new version of FreeType might get taken down. Please express this in form of a specification so that renderer programmers can implement it.

Anonymous
Sun 13 Sep 2020 06:14:08 PM UTC, comment #24: 

A fix is committed.

Alexei Podtelezhnikov <podtelez>
Group Member
Fri 11 Sep 2020 06:29:02 AM UTC, comment #23: 

Yes, I think we should apply it.

I think this would be an excellent test for Greg Williamson's GSoC work.  Can you contact him to set up tests so that the right fonts and rendering mode gets used?

https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2020-greg

Werner LEMBERG <wl>
Group administrator
Wed 09 Sep 2020 03:18:20 AM UTC, comment #22: 

To reproduce smart dropouts a la GDI, first we need to floor the profile coordinates to 26.6 and then apply smart dropout rounding. Then the increased resolution would not change dropout control outcome, which probably makes sense.

Here is the patch that fixes Tahoma-16ppem-a and Tahoma-12ppem-P. Should we apply it?

--- a/src/raster/ftraster.c
+++ b/src/raster/ftraster.c
@@ -460,7 +460,8 @@   Function_Sweep_Step(
           (Bool)( x - FLOOR( x ) >= ras.precision_half )

   /* smart dropout rounding */
-#define SMART( x1, x2 )  FLOOR( ( (x1) + (x2) - 1 ) / 2 + ras.precision_half )
+#define SMART( x1, x2 )  FLOOR( ( (x1) + (x2) - ( ras.precision >> 6 ) ) / 2 \
+                                + ras.precision_half )

 #if FT_RENDER_POOL_SIZE > 2048
 #define FT_MAX_BLACK_POOL  ( FT_RENDER_POOL_SIZE / sizeof ( Long ) )


Alexei Podtelezhnikov <podtelez>
Group Member
Tue 08 Sep 2020 03:36:25 AM UTC, comment #21: 

Below are the traces of FreeType correctly calculating the smart dropout pixel.

Tahoma-16ppem-a:
  y=1 x=[ 0.043212890625; 0.969726562500] -> x=1 dropout=5

Tahoma-12ppem-P:
  x=4 y=[ 3.021728515625; 3.987304687500] -> y=4 dropout=5


It is hard to argue with this formula

  pxl = FLOOR( ( x1 + x2 - 1 ) / 2 + ras.precision_half );




Alexei Podtelezhnikov <podtelez>
Group Member
Sat 05 Sep 2020 01:59:22 AM UTC, comment #20: 

Thanks! I am under impression that most of the reported glitches are related to curves passing close by.  So I wanted to rule hinting out before testing the next hypothesis: flattening the curve is too aggressive and still grabs the pixel on the concave side. I cannot imagine that the dropout rule is not followed and the right pixel has preference over the left one.


Alexei Podtelezhnikov <podtelez>
Group Member
Fri 04 Sep 2020 08:41:20 PM UTC, comment #19: 

The problem with glyph 'a' is definitely not hinting, as the image shows: similar to FreeType, both pixel centers are outside of the contour.

Maybe this is related to #58951.




Werner LEMBERG <wl>
Group administrator
Fri 04 Sep 2020 03:49:41 PM UTC, comment #18: 

Then we are back to MDRP, where FreeType does better job than GDI in preserving parallel lines 2--3 and 7--8. Therefore, reverse engineering GDI flaws is the only dubious choice. I am no longer interested in Tahoma-15ppem-z.

Werner, would please post Tahoma-16ppem-a from VTT?


Alexei Podtelezhnikov <podtelez>
Group Member
Fri 04 Sep 2020 04:27:57 AM UTC, comment #17: 

Nope, it's not.  VTT reports the following coordinates at 15px for B/W hinting:

   x         y
0  6         0
1  0         0
2  0         0 57/64
3  4 58/64   7
4  0         7
5  0         8
6  6         8
7  6 16/64   7  9/64
8  1  5/64   1
9  6         1


Werner LEMBERG <wl>
Group administrator
Fri 04 Sep 2020 03:09:51 AM UTC, comment #16: 

I think I solved tahoma-15ppem-z. It is the vertical interpolation of point 2 between points 1 and 8 that makes the difference:

65*139/157 = 56.7 rounded to 57. This is how FreeType places it based on unscaled coordinates.
65*64/74   = 56.2 rounded to 56. This is where it is placed based on scaled coordinates from my tests.

Then the whole line 2--3 is slightly shifted. Can somebody confirm that point 2 is at 56 in Windows?


Alexei Podtelezhnikov <podtelez>
Group Member
Thu 03 Sep 2020 09:36:57 PM UTC, comment #15: 

In Tahoma-15ppem-z, the sequence of SDPVTL, RDTG, MDRP keeps the lines 2--3 and 7--8 parallel. FreeType finds the best solution for its current point positions. I would need the entire outline generated by Windows to investigate further.

Alexei Podtelezhnikov <podtelez>
Group Member
Mon 31 Aug 2020 01:17:10 PM UTC, comment #14: 

This proof-of-concept fix demonstrates that Tahoma-15ppem-z likely glitches in MDRP.


diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index 2c6fc05..83440da 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -6262,7 +6262,7 @@   Ins_MDRP(

     org_dist = PROJECT( exc->zp1.cur + point, exc->zp0.cur + exc->GS.rp0 );

-    exc->func_move( exc, &exc->zp1, point, SUB_LONG( distance, org_dist ) );
+    exc->func_move( exc, &exc->zp1, point, SUB_LONG( distance, org_dist ) - 1 );

   Fail:
     exc->GS.rp1 = exc->GS.rp0;


In short, rounding the distance and then calculating the (rounded) move might be slightly problematic.

Alexei Podtelezhnikov <podtelez>
Group Member
Fri 22 May 2020 06:53:39 AM UTC, comment #13: 

FreeType 2.10.2 is indeed extremely glitchy. A renderer with a competing rasterizer is TD renderer 2.0, but it's extremely glitchy too. That's why it is extremely important to research the Microsoft bilevel renderer (all other Microsoft renderers are based on the bilevel renderer).

- <_194785>
Thu 21 May 2020 11:53:11 AM UTC, comment #12: 

1)
I also tried once again to reproduce the "Y". Now I found nothing anomalous. You are right.


2)
But I found two more errors:
Font: Tahoma
Letter: bad "C"
Letter: bad "G"

A new *.png is attached.


Tim <bapinta>
Thu 21 May 2020 11:52:06 AM UTC, comment #11: 

1)
I also tried once again to reproduce the "Y". Now I found nothing anomalous. You are right.


2)
But I found two more errors:
Font: Tahoma
Letter: bad "C"
Letter: bad "G"

A new *.png is attached.

Tim <bapinta>
Thu 21 May 2020 10:35:22 AM UTC, comment #10: 

So,

Rasterizer errors reported:
Microsoft Tahoma 'a' at 16ppem: dropout control error caused by either a rounding error or lack thereof.
Microsoft Tahoma 'g' at 14ppem and 15ppem: The pixel is extremely close to the outline, but by some unknown rounding rule it must be off, and FreeType doesn't implement that rule. (it's pretty much the same in both sizes)
Microsoft Tahoma 'P' at 12ppem: Extremely close dropout control, similarly to 'a' at 16ppem.
Half pixel glitching: This error was not observed in Tahoma (though theoretically possible) but instead has its own bug report.

Hinter errors reported:
Microsoft Tahoma 'z' at 15ppem: the point 3 is at an incorrect location.

Can't reproduce:
Microsoft Tahoma 'Y': What version of FreeType have you used? When I tested it, it didn't show a glitch in 2.9.1 or 2.10.2.

Note: Those lists should not be used to count the amount of errors, because there are many renderer errors and the reported ones are not all of them.

- <_194785>
Wed 20 May 2020 08:29:25 PM UTC, comment #9: 

I have added another example:

Font: Tahoma
Letter: bad "P" at High: 9px


Tim <bapinta>
Wed 20 May 2020 08:28:12 PM UTC, comment #8: 

I have added another example:

Font: Tahoma
Letter: bad "P" at High: 9px

Tim <bapinta>
Wed 20 May 2020 10:18:34 AM UTC, comment #7: 


comment #1:

>
> 'a' at 16 ppem: the left pixel should be on according to the simple dropout rule. Instead the right pixel is on.
>


Are you sure it is the simple dropout rule being used here?

- <_194785>
Sun 17 May 2020 01:51:24 PM UTC, comment #6: 

I have added some more examples (see attachment):

Font: Tahoma
Letter: bad g
Letter: bad Y

Tim <bapinta>
Sat 16 May 2020 07:37:49 PM UTC, comment #5: 

comment #4:

> I completely agree that z at 15ppem might be a bytecode issue: the point 3 is adjusted but not snapped to the grid. We might ask Werner to look at the bytecode if the point 3 can be "fixed". On the other hand, the pixel is so close to the outline that the rounding error might be in the profile calculation.


In FreeType it appears to be at coordinates {4 57/64, 7 0/64} while in Microsoft it's at coordinates {4 58/64, 7 0/64}. The rasterizer doesn't appear to be problematic in this case. Could be a rounding error in a hinting instruction.

- <_194785>
Fri 15 May 2020 12:24:49 PM UTC, comment #4: 

I completely agree that z at 15ppem might be a bytecode issue: the point 3 is adjusted but not snapped to the grid. We might ask Werner to look at the bytecode if the point 3 can be "fixed". On the other hand, the pixel is so close to the outline that the rounding error might be in the profile calculation.

Alexei Podtelezhnikov <podtelez>
Group Member
Fri 15 May 2020 12:17:07 PM UTC, comment #3: 

Dropout control direction:

https://i.imgur.com/NZ4Hhh4.png

This is the actual Microsoft rendering.

Dropout control is a massive nightmare to implement properly. (The points are off by 1÷64 of a pixel horizontally)

At a five times larger ppem size: https://i.imgur.com/D7L1tVr.png

And if I extend that triangle: https://i.imgur.com/eRNiML7.png

- <_194785>
Fri 15 May 2020 11:29:49 AM UTC, comment #2: 

This is really two separate issues: the "a" in 16ppem and the "z" in 15ppem.

And both issues also occur in TD renderer, despite using a different rasterizer: https://i.imgur.com/eyXj2xL.png

The z is a weird one because for some reason on the two renderers (Microsoft and FreeType) the pixel ended up being on different sides of the outline: https://i.imgur.com/TWGipAL.png so this is not a rasterizer issue but something else caused it, and the result of TD renderer is no different from FreeType because it's the outline that's problematic.

In the a, the dropout control is so close that in the Microsoft renderer, which is the reference, it goes to the left. FreeType rasterizer and TD renderer rasterizer instead chose to the right. This causes the issue. If I set this character in GDI rotated 90° clockwise, the dropout control now went in the other direction, suggesting that this particular case is a matter of rounding (because halfway rounding cases result in asymmetry) and should be researched further.

- <_194785>
Mon 11 May 2020 08:40:01 PM UTC, comment #1: 

ftgrid from ft2demos demonstrates 2 incredibly close calls

'z' at 15 ppem: the pixel in question looks to be barely inside the outline. It is possible that this is a rounding discrepancy in either hinting or rendering.

'a' at 16 ppem: the left pixel should be on according to the simple dropout rule. Instead the right pixel is on.


Alexei Podtelezhnikov <podtelez>
Group Member
Mon 11 May 2020 04:04:09 PM UTC, original submission:  

When anti-aliasing is deactivated, then "a" and "z" of the font Tahoma are not hinted like they are in Windows.

ttached are some examples. You can see there, the differences between Windows and Linux. Please note, that all picture samples are zoomed 2x, so that we can better see the differences. Make sure that you view the images 1:1 (100%) and that anti-aliasing is switched off in the image viewer. (For example Menu->Edit->Settings in "Nomacs").
-> In Linux I have either a bad hinted "a" but a good hinted "z" or a good hinted "a" but a very bad hinted "z". In Windows 7, I always have both letters good hinted.

You can also compare this:
https://lists.nongnu.org/archive/html/freetype/2020-05/msg00000.html

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #49742:  tahoma-a-15px-VTT.png added by wl (19KiB - image/png)
file #49137:  bad_C_and_G.png added by bapinta (20KiB - image/png)
file #49135:  bad_hinted_big_P.png added by bapinta (15KiB - image/png - see comment #8)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bapinta (Posted a comment)
  • -email is unavailable- added by _194785 (Posted a comment)
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by wl (Updated the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-01 podtelez StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-09-13 podtelez StatusConfirmed Ready For Test
        Planned ReleaseNone 2.10.3
    2020-09-04 wl Attached File- Added tahoma-a-15px-VTT.png, #49742
    2020-05-21 bapinta Attached File- Added bad_C_and_G.png, #49137
    2020-05-20 bapinta Attached File- Added bad_hinted_big_P.png, #49135
    2020-05-17 bapinta Attached File- Added Bad@hinted@Y,@g@Win-Lin@Tahoma.png, #49104
    2020-05-11 wl StatusNone Confirmed
        Assigned toNone wl
        SummaryWhen anti-aliasing is deactivated, then &quot;a&quot; and &quot;z&quot; of the font Tahoma are not hinted like they are in Windows. B/W hinting differences of "a" and "z" in Tahoma if compared to Windows
    2020-05-11 None Attached File- Added a@and@z@Win7@and@Linux@comparison.png, #49058

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code