Re: [ft-devel] [GSoC] ftinspect

2017-05-27 Thread Werner LEMBERG

> See v2 of the patchset attached. I
>  * rebased on master (only change was light vs slight if I catched that
>correctly)
>  * removed all C++11-related stuff (auto, override, static_assert,
>std::intptr_t)

I've now applied the last patch of your set manually to the git
repository, adjusting whitespace here and there and make it actually
compile (there was a missing header #include).

Thanks a lot!


Werner

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


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] [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] [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] [GSoC] ftinspect

2017-03-30 Thread Werner LEMBERG

> 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 :-/

> I think it would benefit from being upgraded, and possibly extended
> to support HarfBuzz shaping and variable fonts.

Yeah, definitely!

> AFAIK, the tool is GPL2, but I had been in contact with the author a
> few years ago, and he might be persuaded into relicensing the tool
> into, say, the FreeType license.

Given that this is not FreeType code I see no reason to do that.  It
should stay as a separate package.


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


Re: [ft-devel] [GSoC] ftinspect

2017-03-30 Thread Adam Twardoch (List)
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

I think it would benefit from being upgraded, and possibly extended to support 
HarfBuzz shaping and variable fonts. 

AFAIK, the tool is GPL2, but I had been in contact with the author a few years 
ago, and he might be persuaded into relicensing the tool into, say, the 
FreeType license. 

Sent from my mobile phone.

> On 30. Mar 2017, at 23:21, Philipp Kerling  wrote:
> 
> Am Donnerstag, den 30.03.2017, 12:23 +0200 schrieb Nikolaus Waxweiler:
>>> As far as gamma is concerned, it seems that Qt does not support the
>>> necessary blending calculations [1] that were implemented in the
>>> old
>>> utilities. So: Should the gamma blending work exactly the same as
>>> before (meaning that the blending code from gblender.c needs to be
>>> ported)?
>> 
>> I'm not familiar with Qt's painting system, does
>> QPainter::CompositionMode_SourceOver do any gamma correction? Or is
>> this what the bug report you referenced is about? 
> It does not. SourceOver is just plain alpha blending. The bug report is
> about providing gamma-corrected blending in some way or another, not
> necessarily integrated into SourceOver.
> 
>> I think that since ftinspect is to be a reference application, it
>> should support both sRGB and pow()-based gamma curves. The sRGB curve
>> would be more correct as the default (almost everything you see on a
>> screen is supposed to be in sRGB color and gamma space), but reality
>> testing at Adobe suggests 1.8.
>> 
>> If Qt can't handle this out of the box, I guess you'd have to
>> implement
>> custom pixel blending code anyway (custom composition mode?), might
>> as
>> well take existing code then.
> Yep, that's the plan. Also, the existing code does support the sRGB
> gamma curve (you can check it out in ftgrid or similar by setting gamma
> to the special value zero), so that would naturally be ported, too.
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] [GSoC] ftinspect

2017-03-29 Thread Philipp Kerling
Hi,

Am Mittwoch, den 29.03.2017, 20:05 +0200 schrieb Werner LEMBERG:
> > I just wanted to let you know that I have submitted a draft
> proposal
> > about improving ftinspect on the GSoC platform and would appreciate
> > any feedback you and other project members might have.
> 
> Ah, you have already submitted a final proposal (which I can only see
> after the deadline), so I haven't bothered to add more comments.
> Anyway, it looks excellent, thanks!
Oh, that was just to be extra safe to have something submitted before
the deadline hits. The "final" proposal can be replaced any number of
times until the application period ends. I wasn't even aware that you
would already see that I uploaded something as final. That said, the
contents are of course the same as in the draft, so thanks for looking
it through!

Regards,
Philipp

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


Re: [ft-devel] [GSoC] ftinspect

2017-03-29 Thread Werner LEMBERG

> I just wanted to let you know that I have submitted a draft proposal
> about improving ftinspect on the GSoC platform and would appreciate
> any feedback you and other project members might have.

Ah, you have already submitted a final proposal (which I can only see
after the deadline), so I haven't bothered to add more comments.
Anyway, it looks excellent, thanks!


Werner

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


Re: [ft-devel] [GSoC] ftinspect

2017-03-29 Thread Philipp Kerling
Hi again,

I just wanted to let you know that I have submitted a draft proposal
about improving ftinspect on the GSoC platform and would appreciate any
feedback you and other project members might have.

Best regards,
Philipp

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


Re: [ft-devel] [GSoC] ftinspect

2017-03-15 Thread Werner LEMBERG

>> Any patches to improve FreeType are highly welcomed :-)
>
> OK so I tried to make small commits so you can cherry-pick which of
> the changes you use (it's still mostly cosmetics though), but I am
> not sure how you would like to receive them.  I tried to open a
> patch item on Savannah, but it only allows the patches to be
> uploaded and downloaded one-by-one, which is quite tedious with 18
> commits.  Should I use git send-email or anything else?

Usually, I like patches sent by e-mail, even if they are numerous.
However, I ask you to wait a few days since I will do a new release.
After this is done, please send your patches (say, five attachments
per e-mail) so that I can review (and apply) them.

Alternatively, put your patches into a zip archive or something
similar and send it to the list.


Werner

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


Re: [ft-devel] [GSoC] ftinspect

2017-03-15 Thread Philipp Kerling
Hi,

Thanks for the quick reply!

Am Dienstag, den 14.03.2017, 22:41 +0100 schrieb Werner LEMBERG:
> ftbench: No.  ttdebug: This would be very nice, but it would blow up
> the task enormously.  Note that the FontForge font editor already
> comes with a TrueType bytecode debugger (using FreeType); this might
> give you an idea of the additional work.
Oh cool, never saw that since my distribution has not enabled it. Yeah
I already guessed that it would probably not be possible for GSoC. I
can add it as stretch goal/future work in the proposal though. 

> This is a good question.  I think Alexei or Nikolaus can say more.
> Note that it would be great to have a linear blending mode so that
> stem darkening gives the expected results.  Similarly, a non-linear
> blending could also be added to demonstrate why linear blending is a
> good thing...
Should be mathematically (i.e. minus rounding errors) the same as
linear blending with gamma=1.0, so I think that it is also covered once
 gamma is implemented.

> > I also have some thoughts about refactoring the existing code, but
> I
> 
> > should probably stop here for now.
> 
> 
> Any patches to improve FreeType are highly welcomed :-)
OK so I tried to make small commits so you can cherry-pick which of the
changes you use (it's still mostly cosmetics though), but I am not sure
how you would like to receive them. I tried to open a patch item on
Savannah, but it only allows the patches to be uploaded and downloaded
one-by-one, which is quite tedious with 18 commits. Should I use git
send-email or anything else?

Regards,
Philipp

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