Re: [ft-devel] [GSoC] ftinspect (Re: Freetype-devel Digest, Vol 146, Issue 23)

2017-03-31 Thread Hin-Tak Leung
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 > >

Re: [ft-devel] [GSoC] ftinspect

2017-03-31 Thread Werner LEMBERG
>> “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

Re: [ft-devel] autohinter for LCD

2017-03-31 Thread Werner LEMBERG
>> 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

Re: [ft-devel] autohinter for LCD

2017-03-31 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] autohinter for LCD

2017-03-31 Thread Nikolaus Waxweiler
> 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

Re: [ft-devel] autohinter for LCD

2017-03-31 Thread Alexei Podtelezhnikov
>>> 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

Re: [ft-devel] [GSoC] ftinspect

2017-03-31 Thread 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 > > as well, so that one is hopeless. > -std=c++98 was still not enough in my case (gcc 6.3.1).

Re: [ft-devel] [GSoC] ftinspect

2017-03-31 Thread Philipp Kerling
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

Re: [ft-devel] 2.6.5 and 2.7.1 are able to read the two fonts, but git version fails

2017-03-31 Thread Werner LEMBERG
> 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

Re: [ft-devel] [GSoC] ftinspect

2017-03-31 Thread Khaled Hosny
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 > > > >

Re: [ft-devel] autohinter for LCD

2017-03-31 Thread Werner LEMBERG
>> 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

Re: [ft-devel] autohinter for LCD

2017-03-31 Thread Werner LEMBERG
>> 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