Re: [ft-devel] [GSoC] ftinspect
> 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)
Date: Fri, 31 Mar 2017 09:56:43 +0200 From: Khaled HosnyOn 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
>> “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
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 (金) の 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
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
> 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
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 Kerlingwrote: > > 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
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
> 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
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
>> 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
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