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
 > > as well, so that one is hopeless.
 > -std=c++98 was still not enough in my case (gcc
 6.3.1).
 
> That was only for the other utilities, I gave up on the
 viewer once I
 realized it uses Qt 3 since I have no easy way to get it
 here.
 
Don't quite parse that. OTOH, I had a quick look. Knowing qt4 and qt5 are 
current, fedora still provides qt3 devel stuff. Also, qt4 ships a migration 
tool, called 'qt3to4', if that helps.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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 -std=c++98 and depending on the distribution might
> have to change the name of the Qt library.  Fedora for instance only
> ships the multi-threaded version of Qt3, which can be selected with
> make CXXFLAGS="-std=c++98" QT_LIBRARY="qt-mt"

On my openSuSE 64bit box I must also change `-L$(QTDIR)/lib' to
`-L$(QTDIR)/lib64'; to do that I'm using

  libsubdir=lib

  MACHINE := $(shell uname -m)
  ifeq ($(MACHINE), x86_64)
libsubdir=lib64
  endif

  [...]

  LDFLAGS=-L$(QTDIR)/${libsubdir} -l${QT_LIBRARY}

> As for the application, the most prominent feature is probably the very
> extensive TT debugging.

Indeed.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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 agree.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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 (at smaller-than-pixel boundaries) [...]
>

Perhaps they want to emulate stem darkening by quantizing the stem widths
away from 0. I do not see any other reason, like you said...


> 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.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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 like Calibri do it.. out
of habit? For GDI-mode?

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.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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 make any sense.

>>> I suspect this bug is intentional to deal with color fringes
>>> without filtering.
> 
> Maybe, yes.  However, I don't see a bug.  You first have to prove that
> you get better LCD results without stem snapping :-)

I'll do it if you insist.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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).

That was only for the other utilities, I gave up on the viewer once I
realized it uses Qt 3 since I have no easy way to get it here.

Regards,
Khaled

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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 compile.
You still need -std=c++98 and depending on the distribution might have
to change the name of the Qt library. Fedora for instance only ships
the multi-threaded version of Qt3, which can be selected with
 make CXXFLAGS="-std=c++98" QT_LIBRARY="qt-mt"

As for the application, the most prominent feature is probably the very
extensive TT debugging. For glyph rendering I think that the ftinspect
already has the upper hand since it allows setting more rendering
options, zooming etc.
That said, ftinspect could (in the future) use some of the options
available for text rendering like whether to use ligatures or not.
Since the code uses Qt3 and a custom rendering library, I reckon that
not much of it can be salvaged.

[1] https://github.com/rogiervd/fonttools/pull/1

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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
> > 
> > http://home.kabelfoon.nl/~slam/fonts/truetypeviewer.html
> 
> Basically, this is excellent code – *not* based on FreeType, but his
> own implementation.  The debugger works both forwards and backwards,
> something the FreeType debugger can't do.
> 
> Unfortunately, it is written in high-level C++ that no longer compiles
> with modern compilers.  I tried twice to update, and I failed twice.
> It's too C++ for me :-/

“make CXX="g++ -std=c++98"” does the trick, but TrueTypeViewer uses Qt 3
as well, so that one is hopeless.

Regards,
Khaled

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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
using discrete values.  AF_LATIN_HINTS_STEM_ADJUST always snap to full
pixels.

> Have you ever wondered why the stem darkening works in LIGHT only
> and does not work with LCD?  The proposed fix is here:
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=Harmony=e47feb03cca26b4c8c683f43821438001471597d

It might be useful to do first stem darkening and then stem snapping.
However, this needs investigation.  Simply switching off (discrete)
stem snapping is premature, I believe.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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 to the pixel grid without changing
> stem width?  That would be compatible with the description of
> FT_LOAD_TARGET_LCD.  I don't think the autohinter can actually hint
> for mono display.

This is a misunderstanding due to bad wording, I think.  We are not
talking about mono rendering on LCD.

>> I was actually contemplating making LCD synonymous to LIGHT.
> 
> How about altogether removing hinting of vertical stems? ;)

Definitely not.  The `strong' auto-hinter is not that bad as you two
are implying, IMHO, and maybe someone comes and further improves it.

>> I suspect this bug is intentional to deal with color fringes
>> without filtering.

Maybe, yes.  However, I don't see a bug.  You first have to prove that
you get better LCD results without stem snapping :-)


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel