Fri 15 Jul 2016 08:39:23 AM UTC, comment #14:
This is now fixed in git, please test!
|
Sat 25 Apr 2015 05:58:31 AM UTC, comment #13:
For those glyphs, the blue zones don't apply, because there are no real horizontal segments at bottom of the outer outlines of the large round structures, necessary as `anchor points'! Compare `O' with `Q', or `C' with `Ç'. While there are means to manually correct that quite easily in ttfautohint (which is based on FreeType's auto-hinter), the auto-hinter fails more and more if you are going to reduce the allowed deviation from a horizontal straight line. And your patch does exactly that.
Have a look here:
http://www.freetype.org/ttfautohint/doc/ttfautohint.html#control-instructions-file
|
Fri 24 Apr 2015 03:47:55 PM UTC, comment #12:
Aren't there a blue zone for all those `Q', `Ç', Ş', `ş', `ę'. I am surprised that they depend on this parameter so much.
|
Fri 17 Apr 2015 07:31:25 AM UTC, comment #11:
> I just do not see as many problems. I see some misses
> at the top and the bottom of some characters with
> diacritics, but not all that you mention.
See below for the exact recipe how I did the comparison.
> I understand how tough it is to judge their
> (pseudo)extremes.
No, it's not. All problems I mention are easy to see if you do blink comparison.
> I am puzzled that 4 degree allowance even helps in many
> (but admittedly not all) cases.
This I haven't investigated at all. I agree that some changes are probably side effects only. Nevertheless, before modifying such a fundamental hinting parameter, we have to understand the changes, and we have to be very careful to not introduce degradations.
Our discussion shows that it is more important than ever to finally introduce a font test database that collects renderings from prominent fonts, and that before releasing a new version the test suite is run, and the images are compared.
0. Set up two directory trees for compiling both freetype2 and freetype2-demos. I call them `14' and `32'. Clone the git repositories into those directories.
0. Edit `devel/ftoption.h' and comment out AF_CONFIG_OPTION_USE_WARPER (in both `14' and `32').
0. In `32', change `afhints.c' to use factor 32 (i.e., apply Alexei's patch).
0. In `14', compile `freetype2' with `make devel; make', then compile `freetype2-demos' with `make'. Repeat this in `32'. This ensures static compilation, avoiding any side effects.
0. I use virtual desktops, and I set up the left one for `14' and the right one for `32'. In both I execute `ftview -l 1 16 *' to scan my Windows font directory using light AA mode. I also open a screen magnifier on both desktops. Now I can switch easily back and forth (with key shortcuts, of course), doing a blink comparison. I'm attaching two images for `georgia.ttf' to demonstrate my setup. As can be seen, the differences are very easy to spot.
(file #33699, file #33700)
|
Fri 17 Apr 2015 02:40:07 AM UTC, comment #10:
I just do not see as many problems. I see some misses at the top and the bottom of some characters with diacritics, but not all that you mention. I understand how tough it is to judge their (pseudo)extremes. I am puzzled that 4 degree allowance even helps in many (but admittedly not all) cases.
|
Wed 15 Apr 2015 09:46:28 AM UTC, comment #9:
= Value 32 =
Many Windows 7 fonts, mostly checking Latin and Greek glyphs. I've only tested at 16ppem using the light hinting mode (key `B' in ftview), without the warper code.
== worse: ==
- angsab.ttf (Angsana New Bold): `{'
- calibri.ttf (Calibri Regular): uppercase Greek Phi
- cambriab.ttf (Cambria Bold): uppercase Greek Phi
- Candarab.ttf (Candara Bold): `l', lowercase Greek phi
- comicbd.ttf (Comic Sans MS Bold): `₤'
- constanb.ttf (Constantia Bold): `Ç'
- constani.ttf (Constantia Italic): `Q'
- cour.ttf (Courier New Regular): `§'
- framd.ttf (Franklin Gothic Medium Regular): `Ç'
- frank.ttf (FrankRuehl Regular): `9' (but digits are special)
- Gabriola.ttf (Gabriola Regular): `H'
- GenBasR.ttf (Gentium Basic Regular): `Ç'
- georgiai.ttf (Georgia Italic): `G', `k', `l'
- georgia.ttf (Georgia Regular): `Q', `ü', `{', `}', `ì'
- micross.ttf (Microsoft Sans Serif Regular): `$', `Ç', `Ş'
- palab.ttf (Palatino Linotype Bold): `Ų', `Qu' (note that value 14 doesn't produce an optimal result either for `Qu')
- segoeuii.ttf (Segoe UI Italic): `Ş', `ş', `ę', `{', `}'
- sylfaen.ttf (Sylfaen Regular): `R', `æ'
- timesbd.ttf (Times New Roman Bold): `O'
- timesi.ttf (Times New Roman Italic): `ζ'
- trebucbi.ttf (Trebuchet MS Bold Italic): `ζ', `ξ'
- trebuc.ttf (Trebuchet MS Regular): `$', `ę'
- verdana.ttf (Verdana Regular): `á'
== better: ==
- Candarab.ttf (Candara Bold): `Q'
- GenBasR.ttf (Gentium Basic Regular): upper single and double quotes
- trebucbi.ttf (Trebuchet MS Bold Italic): `¢'
- verdanaz.ttf (Verdana Bold Italic): `æ'
In simsunb.ttf (SimSun-ExtB Regular), the improvements and deteriorations for CJK glyphs are approximately the same. In times.ttf, I see hardly a difference.
As a summary, I don't think that value 32 is an improvement for light hinting, which is by far the most important auto-hinting mode. On the contrary: I see a lot of degradations.
|
Sat 11 Apr 2015 11:40:23 AM UTC, comment #8:
Will do so. Please give me some days.
|
Sat 11 Apr 2015 02:06:48 AM UTC, comment #7:
Detailed list of improvements going from 14 to 32:
Times 16 ppem: Greek lambda, Latin E, Greek Xi, Cyrillic De
Times 24 ppem: Intergral sign
Palatino 16 ppem: Latin E
Detailed list of regresions:
Palatino 16 ppem: 5/8
Werner, may I dare you to find more regressions?
|
Fri 10 Apr 2015 03:28:30 AM UTC, comment #6:
I have not found any problems with serifs. In fact E has improved in both times.ttf and papa.ttf. I am ready to test more.
(file #33622, file #33623)
|
Thu 09 Apr 2015 02:26:00 PM UTC, comment #5:
It used to be 12 (4.7°) in the original autofitter commit and changed to 14 (4.1°) in FreeType 2.3.5 without any explanation. I will check for any regressions in serifs.
|
Thu 09 Apr 2015 04:41:22 AM UTC, comment #4:
Alexei, your fix is overly simplistic, and I object to it as-is since it throws out the baby with the bath water.
On a small scale, allowing slanted lines is especially important to correctly find serifs. All problems you mention are on a large scale, so we have to find a means to prevent false positives for such situations.
|
Thu 09 Apr 2015 02:41:51 AM UTC, comment #3:
Gabriola.ttf of Windows 7/8 is a font with plenty of sub-4° slants. The attached image shows plenty of distortions caused by overly aggressive autohinting.
(file #33608)
|
Wed 08 Apr 2015 01:57:07 PM UTC, comment #2:
I believe that 4.1° slant is too much to be considered vertical. I am attaching a file that shows gradual improvement in rendering as we tighten the angle from 4.1°, to 3.6°, to 2.4°, to 1.8°.
I think that this is the right fix. Spitting the feature (the whole left edge) won't fix it: you will just see piecewise ladder of vertical segments.
Proposed fix on top of current git:
(file #33594)
|
Wed 05 Feb 2014 06:39:35 PM UTC, comment #1:
Without having time currently to analyze it further, I think this is a bug in the auto-hinter algorithm of creating segments: Each line between consecutive on or off points gets a direction: up/down, left/right, or unspecified. The algorithm allows a certain deviation (approx 4°) from horizontal or vertical lines, still counting them as up/down or left/right. Such lines are collected and form a segment; normally, all points along a segment get the same coordinate.
The problematic glyph has a series of such slightly sloped lines, and all of them point into the same direction, which is very unusual. The auto-hinter then normalizes them brutally to a vertical line, not taking into account that the effect culmulates unfavorably.
A quick solution is to disable the auto-hinter by using FT_LOAD_NO_AUTOHINT – it gets used automatically for this font since it doesn't contain any bytecode instructions.
|
Fri 24 Jan 2014 04:12:26 PM UTC, original submission:
Attached a subset TrueType font which has for its 'R' glyph an outline (using FT2.5.2) which is slightly different than what we see within Acrobat or Windows. I.e. FT makes its left side going a bit right way instead the other renderers make it going a bit left way.
Attached as well a screenshot which probably explains better what is meant as difference: the red filled area is what FT returns as glyph, the black stroke outline what we get with the other renderers.
Any idea what the real issue is ?
|