Date: Fri, 31 Mar 2017 09:56:43 +0200
From: Khaled Hosny
On Fri, Mar 31, 2017 at 09:36:56AM +0200, Philipp Kerling
wrote:
> 2017-03-31 (?) ? 09:19 +0200 ? Khaled Hosny :
> > ?make CXX="g++ -std=c++98"? does the trick, but
TrueTypeViewer uses
> > Qt 3
> >
>> “make CXX="g++ -std=c++98"” does the trick,
Great news, thanks!
>> but TrueTypeViewer uses Qt 3 as well, so that one is hopeless.
>
> -std=c++98 was still not enough in my case (gcc 6.3.1). I've fixed
> the two issues that appeared then [1] which allowed it to compile.
> You still need
>> I personally see little value in that though and think that LIGHT
>> (with stem darkening and proper blending) is perfectly fine for
>> pretty much everything.
>
> Ok, AF_LATIN_HINTS_HORZ_SNAP is not a big deal, but
> AF_LATIN_HINTS_STEM_ADJUST is and should not be done for LCD.
I fully
On Fri, Mar 31, 2017 at 7:56 AM, Nikolaus Waxweiler
wrote:
> > Subpixel rendering obliterates the concept of pixel boundary itself.
> > Anything but light does not make any sense.
>
> Hm, the ClearType docs say that stem snapping can happen even in
> subpixel rendering mode
> Subpixel rendering obliterates the concept of pixel boundary itself.
> Anything but light does not make any sense.
Hm, the ClearType docs say that stem snapping can happen even in
subpixel rendering mode (at smaller-than-pixel boundaries) and I think
the core web fonts and even some newer fonts
>>> I am shocked to see that autohinter snaps stems when targeting LCD
>>> as if MONO [...]
>
> I don't see a problem. The stem snapping happens at the threefold
> horizontal resolution, so what?
Subpixel rendering obliterates the concept of pixel boundary itself. Anything
but light does not
On Fri, Mar 31, 2017 at 09:36:56AM +0200, Philipp Kerling wrote:
> 2017-03-31 (金) の 09:19 +0200 に Khaled Hosny さんは書きました:
> > “make CXX="g++ -std=c++98"” does the trick, but TrueTypeViewer uses
> > Qt 3
> > as well, so that one is hopeless.
> -std=c++98 was still not enough in my case (gcc 6.3.1).
2017-03-31 (金) の 09:19 +0200 に Khaled Hosny さんは書きました:
> “make CXX="g++ -std=c++98"” does the trick, but TrueTypeViewer uses
> Qt 3
> as well, so that one is hopeless.
-std=c++98 was still not enough in my case (gcc 6.3.1). I've fixed the
two issues that appeared then [1] which allowed it to
> 2.6.5 and 2.7.1 are able to read face 0 of the two fonts, but git
> version fails with error code 9.
Fixed in git, thanks for the report.
Please test!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
On Fri, Mar 31, 2017 at 07:02:09AM +0200, Werner LEMBERG wrote:
>
> > TrueType Viewer by Rogier van Dalen already is a FreeType-based font
> > viewer and hinting debugger with a quite decently designed Qt-based
> > GUI.
> >
> > https://github.com/rogiervd/fonttools
> >
> >
>> Uh, doesn't that just do "light" hinting on the x-axis?
>
> No, MONO is brutal.
I think you are misreading the code. Stem snapping
(AF_LATIN_HINTS_HORZ_SNAP) is *not* mono! This would be rather
AF_LATIN_HINTS_STEM_ADJUST.
AF_LATIN_HINTS_HORZ_SNAP is *slightly* adjusting the stem width by
>> I am shocked to see that autohinter snaps stems when targeting LCD
>> as if MONO [...]
I don't see a problem. The stem snapping happens at the threefold
horizontal resolution, so what?
> Uh, doesn't that just do "light" hinting on the x-axis? E.g. adjust
> the outer edges of vertical stems
12 matches
Mail list logo