Re: [ft-devel] Conversions and Branch on Repository
On Sun, Jun 03, 2018 at 10:07:13PM +0200, Werner LEMBERG wrote: > >> I'm going to test this and apply the header reformatter to > >> `master'. > > > > OK! > > This is now done with two monster commits. Thanks for the script, > Nikhil, and bye bye to old block header format! > > In total, FreeType's public header files now need 600kByte less. The last commit seems to be broken in some places, line like this are gone: /* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */ Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Contribution to freetype
On Sun, Mar 18, 2018 at 12:13:03PM +0100, Werner LEMBERG wrote: > > In the namespace definition of XML, such strings looking like as URL > > are required as the identifiers, and often unreachable URL causing > > 404 error. But it is not broken in the conformance of XML spec. > > OK, thanks. I was just curious and tried to get more information :-) See the “Composite Fonts” section in: https://msdn.microsoft.com/en-us/library/system.windows.media.fontfamily(v=vs.110).aspx Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Head table upem value from FT_Face for (color) bitmap fonts?
On Fri, Feb 16, 2018 at 03:23:57PM +0200, Dominik Röttsches wrote: > Can we potentially change the behaviour so that FreeType still exposes this > value for bitmap fonts, even though it's not useful in all cases? Or is > this a non use-case for FreeType and clients should parse the head table on > their own for such a situation? As a workaround, instead of parsing the “head” table yourself, you can use FT_Get_Sfnt_Table(face, FT_SFNT_HEAD) which returns TT_Header struct. Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] TrueType kern table subtable format ignored?
On Tue, Sep 12, 2017 at 12:20:36AM +0200, Werner LEMBERG wrote: > >> Kerning table format 2 is not supported on Windows, AFAIK. Why not > >> directly using GPOS kerning? > > > > Looks to me like kern format2 can be much faster than equivalent > > GPOS. > > OK. Let's see whether this is true :-) > > However, how are you going to solve the issue w.r.t. lack of Windows > support? You don’t care about Windows support in Chrome or Android (or HarfBuzz-using environments in general) :) Regards, Khaled ___ 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
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] ftview / ftstring proposal
On Fri, Sep 23, 2016 at 10:27:59AM -0400, Alexei Podtelezhnikov wrote: > These are the default strings that I plan to hard code: Arabic and Indic will be of very limited value since the tool does not support OpenType layout. Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] rendering mode of Firefox on Windows 10
On Thu, Nov 05, 2015 at 07:43:21PM +0100, Werner LEMBERG wrote: > > >> according to browserstack, the current release 41 of Firefox on > >> Windows 10 seems still to use the GDI framework, which implies font > >> rasterizer version 37, [...] > > > > I suspect that browserstack uses remote windows desktop connection > > or some such which I have noticed to be using Windows XP-like font > > rendering. > > Hmm. How do you explain then that both Chrome and Edge use version 40 > on browserstack? I see, Firefox uses DirectWrite only when 3D acceleration is enabled and GDI otherwise, so this might be the case here. Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] rendering mode of Firefox on Windows 10
On Thu, Nov 05, 2015 at 11:26:44PM +0300, Nikolay Sivov wrote: > On 05.11.2015 22:06, Khaled Hosny wrote: > >On Thu, Nov 05, 2015 at 07:43:21PM +0100, Werner LEMBERG wrote: > >> > >>>>according to browserstack, the current release 41 of Firefox on > >>>>Windows 10 seems still to use the GDI framework, which implies font > >>>>rasterizer version 37, [...] > >>> > >>>I suspect that browserstack uses remote windows desktop connection > >>>or some such which I have noticed to be using Windows XP-like font > >>>rendering. > >> > >>Hmm. How do you explain then that both Chrome and Edge use version 40 > >>on browserstack? > > > >I see, Firefox uses DirectWrite only when 3D acceleration is enabled and > >GDI otherwise, so this might be the case here. > > Hm, I wonder if that's because they also make use of Direct2D, because I > don't think DirectWrite necessary talks to d3d system. Although it's > possible some sophisticated logic to have system-wide font cache service to > cache generated bitmaps or defer computations, and d3d is used for that > directly or not, but I never heard about it. > > gfx.font_rendering.directwrite.enabled was false, toggled to true, no > difference. > > gfx.font_rendering.cleartype_params.force_gdi_classic_for_families indeed > contained something by default, I tried to reset to empty string, no change. > Also if it really applies to specific family my guess would be that > RasterInfo font won't be affected, as it's never on the list by default. Check about:support, and see of you have 3D acceleration (you might find something about DirectWrite there too, I don’t remember for sure). Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Improved Arabic auto-hinting
On Fri, Aug 07, 2015 at 05:24:17PM +0200, Werner LEMBERG wrote: I've verified that the vertical position for the joining glyphs are the same in his font... I can't reproduce any improvements so far. This effect: https://www.flickr.com/photos/behdad/34769511/ still happens in my limited testing. ... and apparently this doesn't work as universally as I've hoped. Please send me the font privately and tell me how to reproduce this image. With this font: https://github.com/googlei18n/noto-fonts/blob/master/unhinted/NotoNaskhArabic-Regular.ttf and this command-line: $ hb-view ./NotoNaskhArabic-Regular.ttf نستعلیق \ --font-size 400 --background 000 --foreground ff \ | display Thanks. IMHO, this is not a bug in the autohinter; it's a font bug: The overlapping of glyphs isn't constructed correctly, which makes repeated drawing of the overlapping parts problematic, as described in your blog entry. For comparison, here an image using a font by Titus with the same hb-view command. Another image shows how the joining parts are designed to avoid (or to reduce the effects of) exactly this problem. Per (old?) Microsoft recommendation [1], both approaches are incorrect. Regards, Khaled 1. https://www.microsoft.com/typography/cursivescriptguidelines.mspx ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] OS X Framework support for CMake
On Fri, May 16, 2014 at 08:13:22AM +0200, Werner LEMBERG wrote: Simple patch to CMake files that adds support of building OS X framework. Applied, thanks, with minor formatting. Please check whether everything's allright. Can be pulled from here: https://github.com/stopiccot/freetype2/commits/cmake_framework The next time, please attach the result of `git format-patch', which I much prefer to cloning the whole repository – apparently it is not possible at github to directly get a commit formatted as a patch file... But maybe I'm just too dumb :-) https://github.com/stopiccot/freetype2/commit/bbf1dbf6c2929dee768bea1edbd8340d909ee2ee.patch But git pull g...@github.com:github.com/stopiccot/freetype2, should have worked as well. Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] OS X Framework support for CMake
On Fri, May 16, 2014 at 03:52:24PM +0200, Werner LEMBERG wrote: apparently it is not possible at github to directly get a commit formatted as a patch file... https://github.com/stopiccot/freetype2/commit/bbf1dbf6c2929dee768bea1edbd8340d909ee2ee.patch Aah, thanks. But where can I find this on the github web interface? No idea, I always just append .patch (or .diff) to the commit URL, I don't even remember where I learnt about this. But git pull g...@github.com:github.com/stopiccot/freetype2 should have worked as well. Ok. Will try the next time. However, I still think that for small to medium sized patches `git format-patch' is *the* choice for communication within mailing lists – in particular, it gets archived. Sure, it was just in case you didn't know about this one as well :) Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Microsoft size-specific design selection mechanism
On Tue, Oct 22, 2013 at 04:59:43PM +0200, Behdad Esfahbod wrote: http://typedrawers.com/discussion/470/new-microsoft-size-specific-design-selection-mechanism Would be nice to add support for this. I like to use it in fontconfig. I think something is missing here, I see only the size range, but how related fonts with different optical sizes are grouped together? Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Microsoft size-specific design selection mechanism
On Sun, Oct 27, 2013 at 09:25:38PM +0100, Behdad Esfahbod wrote: On 13-10-27 09:14 PM, Khaled Hosny wrote: On Tue, Oct 22, 2013 at 04:59:43PM +0200, Behdad Esfahbod wrote: http://typedrawers.com/discussion/470/new-microsoft-size-specific-design-selection-mechanism Would be nice to add support for this. I like to use it in fontconfig. I think something is missing here, I see only the size range, but how related fonts with different optical sizes are grouped together? Usual family, width, weight, stretch. I see, but I wounder why the size feature had special support for grouping fonts together... Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ttfautohint] Multiple scripts are now supported
On Tue, Oct 22, 2013 at 03:26:10AM +0200, Werner LEMBERG wrote: In my system ttfautohint window is too long and does not fit into the screen for some reason, making the run button not accessible, and GNOME Shell (in its infinite wisdom) does not let me move the window beyond its top bar. With this patch the controls are split into two columns (three actually, the middle column is empty for padding), so that it fits more nicely in the screen. Thanks for the idea. I have now modified the GUI to switch to a horizontal design if the available display height is not sufficient for the vertical design. Please test. Looks good, thanks. Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ttfautohint] Multiple scripts are now supported
On Sat, Oct 19, 2013 at 08:42:44AM +0200, Werner LEMBERG wrote: I still have to polish the documentation Attached a patch for a minor typo. Regards, Khaled From b1c1870f7d7e247d0a402d27b9e97ab42f942dab Mon Sep 17 00:00:00 2001 From: Khaled Hosny khaledho...@eglug.org Date: Sun, 20 Oct 2013 00:11:19 +0200 Subject: [PATCH] Typo: close the code tags --- doc/ttfautohint-1.pandoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/ttfautohint-1.pandoc b/doc/ttfautohint-1.pandoc index 4f54403..026351b 100644 --- a/doc/ttfautohint-1.pandoc +++ b/doc/ttfautohint-1.pandoc @@ -788,8 +788,8 @@ Table: `hebr` character ranges Character range Description - - - `0x0590` - `0x05FF Hebrew - `0xFB1D` - `0xFB4F Alphabetic Presentation Forms (Hebrew) + `0x0590` - `0x05FF`Hebrew + `0xFB1D` - `0xFB4F`Alphabetic Presentation Forms (Hebrew) If a glyph's character code is not covered by a script range, it is not -- 1.8.4.1 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ttfautohint] Multiple scripts are now supported
In my system ttfautohint window is too long and does not fit into the screen for some reason, making the run button not accessible, and GNOME Shell (in its infinite wisdom) does not let me move the window beyond its top bar. With this patch the controls are split into two columns (three actually, the middle column is empty for padding), so that it fits more nicely in the screen. Not sure if this is the best approach, I hardly know anything about Qt or GUI design. Regards, Khaled On Sat, Oct 19, 2013 at 08:42:44AM +0200, Werner LEMBERG wrote: Folks, ttfautohint now supports multiple scripts, following the recent modifications to FreeType. Note that command line option `-f' has been changed to take an argument that selects the fallback script(*), and `--latin-fallback' has been consequently renamed to `--fallback-script'. I still have to polish the documentation and check one potential hinting bug, however, the program is essentially ready for a new interim release, 0.97, which I would like to publish within a week. The next step is integration of HarfBuzz to properly handle glyphs without cmap entries. After this, I plan to make release candidates for version 1.0 :-) If you are brave and can compile by yourself from git, please test! Werner (*) Sorry for changing the command line interface again, however, I will do so if necessary until I release version 1.0... From a8344a6f3828903df04400743d904c002067ea08 Mon Sep 17 00:00:00 2001 From: Khaled Hosny khaledho...@eglug.org Date: Sun, 20 Oct 2013 00:56:12 +0200 Subject: [PATCH] [gui] Split the layout into two columns In my system ttfautohint window is too long and does not fit into the screen for some reason, making the run button not accessible, and GNOME Shell (in its infinite wisdom) does not let me move the window beyond its top bar. With this patch the controls are split into two columns (three actually, the middle column is empty for padding), so that it fits more nicely in the screen. --- frontend/maingui.cpp | 34 -- 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/frontend/maingui.cpp b/frontend/maingui.cpp index aaac0de..96443eb 100644 --- a/frontend/maingui.cpp +++ b/frontend/maingui.cpp @@ -1071,7 +1071,7 @@ Main_GUI::create_layout() // // stem width and positioning // - stem_label = new QLabel(tr(Strong Stem Width and Positioning:)); + stem_label = new QLabel(tr(bStrong Stem Width and Positioning:/b)); stem_label-setToolTip( tr(bTTFautohint/b provides two different hinting algorithms that can be selected for various hinting modes. @@ -1161,28 +1161,26 @@ Main_GUI::create_layout() gui_layout-addWidget(snapping_label, row, 0, Qt::AlignRight); gui_layout-addWidget(snapping_line, row++, 1, Qt::AlignLeft); - gui_layout-setRowMinimumHeight(row, 20); // XXX urgh, pixels... - gui_layout-setRowStretch(row++, 1); - - gui_layout-addWidget(wincomp_box, row++, 1); - gui_layout-addWidget(pre_box, row++, 1); - gui_layout-addWidget(hint_box, row++, 1); - gui_layout-addWidget(symbol_box, row++, 1); - gui_layout-addWidget(dehint_box, row++, 1); - gui_layout-addWidget(info_box, row++, 1); + gui_layout-setColumnMinimumWidth(2, 20); // XXX urgh, pixels... + gui_layout-setColumnStretch(2, 1); - gui_layout-setRowMinimumHeight(row, 20); // XXX urgh, pixels... - gui_layout-setRowStretch(row++, 1); + row = 4; + gui_layout-addWidget(wincomp_box, row++, 3); + gui_layout-addWidget(pre_box, row++, 3); + gui_layout-addWidget(hint_box, row++, 3); + gui_layout-addWidget(symbol_box, row++, 3); + gui_layout-addWidget(dehint_box, row++, 3); + gui_layout-addWidget(info_box, row++, 3); - gui_layout-addWidget(stem_label, row, 0, Qt::AlignRight); - gui_layout-addWidget(gray_box, row++, 1); - gui_layout-addWidget(gdi_box, row++, 1); - gui_layout-addWidget(dw_box, row++, 1); + gui_layout-addWidget(stem_label, row++, 3); + gui_layout-addWidget(gray_box, row++, 3); + gui_layout-addWidget(gdi_box, row++, 3); + gui_layout-addWidget(dw_box, row++, 3); gui_layout-setRowMinimumHeight(row, 20); // XXX urgh, pixels... - gui_layout-setRowStretch(row++, 1); + gui_layout-setRowStretch(row++, 3); - gui_layout-addWidget(run_button, row++, 1, Qt::AlignRight); + gui_layout-addWidget(run_button, row++, 3, Qt::AlignRight); // create dummy widget to register layout QWidget* main_widget = new QWidget; -- 1.8.4.1 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Latin, Cyrillic, and Greek fonts questions
On Sun, Sep 22, 2013 at 08:49:29AM +0200, Werner LEMBERG wrote: Folks, I have two questions: 1. Do Cyrillic or Greek outline fonts exist which don't contain the ASCII characters a-z, A-Z, and 0-9? Most of GFS fonts do not contain the ASCII letters: http://www.greekfontsociety.gr/pages/en_typefaces1.html 2. Do you know of any Cyrillic or Greek fonts where the lowercase and uppercase glyph heights differ from the heights of the Latin glyphs? Given that all three alphabets share e.g. characters `A' and `o', this rather sounds implausible, but who knows... Not exactly what you are asking for, but GFS Philostratos’ Latin lowercase is just a copy of the uppercase, though the Greek part has true lowercase. Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] X-Height CapHeight
On Wed, Aug 21, 2013 at 04:29:07PM +0200, another gol wrote: Hi, Would be nice to have x-height capheight published (I know I'm not the first one to ask). I fully understand that they're only available in a truetype chunk, but when the info is there, it beats having to guess it. Both are quite important for balanced text vertical centering. If the font has them, they will be in the OS/2 table: http://www.freetype.org/freetype2/docs/reference/ft2-truetype_tables.html#TT_OS2 Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] vertBearingY of CFF glyphs is always unscaled
On Thu, Apr 04, 2013 at 06:14:07AM +0200, Werner LEMBERG wrote: [CCed Behdad] I had an issue with vertical text layout in HarfBuzz, in short we have the calculation: y = metrics.horiBearingY - (-metrics.vertBearingY) and since horiBearingY is scaled with font size while vertBearingY is not, the result was completely wrong resulting in misplaced glyphs (it was mysterious because it affected only glyphs where the value of this calculation was used, and the degree of misplacement changes with font size). I fear that support for the various vertical metrics components is severely broken in FreeType. In particular, values are computed differently for different font formats. To fix this for all font formats it would be necessary to investigate the issue in great detail; in particular, we need a detailed comparison with the MS and Apple engines: Some comments in FreeType indicate that, for example, the OpenType specification and recommendations contradict the actual implementation in Windows (and/or OS X). Do you have some time to devote to this issue? Or maybe another volunteer? I fixed my immediate problem by using FT_LOAD_NO_SCALE and then scaling on my own (since I don't want embedded bitmaps nor hinting anyway). I'd like to look into vertical typesetting in general in the next months, but right now I know very little about it to promise anything. Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] vertBearingY of CFF glyphs is always unscaled
Hi all, While debugging some mysterious glyph positioning issue, I found that the vertBearingY of CFF glyphs is always the same no matter what font size is. The attached patch fixes the issue for me, though I'm not sure if this is the right place to scale the metric. Regards, Khaled diff --git a/src/cff/cffgload.c b/src/cff/cffgload.c index 30996c1..c8d130d 100644 --- a/src/cff/cffgload.c +++ b/src/cff/cffgload.c @@ -2988,6 +2988,7 @@ /* Then scale the metrics */ metrics-horiAdvance = FT_MulFix( metrics-horiAdvance, x_scale ); metrics-vertAdvance = FT_MulFix( metrics-vertAdvance, y_scale ); + metrics-vertBearingY = FT_MulFix( metrics-vertBearingY, y_scale ); } /* compute the other metrics */ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Glyph metrics figures on the website
On Sun, Oct 28, 2012 at 08:45:14AM +0100, Werner LEMBERG wrote: and the conversion from PDF to SVG is not optimal; at least not with inkscape. If you want a good PDF to SVG converter, try pdf2svg (a small tool using Poppler and Cairo, but handles text much better than Inkscape): http://www.cityinthesky.co.uk/opensource/pdf2svg Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Getting the kerning pairs in under O(n*n)
On Wed, Oct 03, 2012 at 02:38:40PM -0700, Vinnie Falco wrote: Please don't forget that FreeType's job is to render glyphs, nothing else. My opinion is that since FreeType opens the font file, it might as well process everything that is in it. That is easy to say :) Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Fontforge-devel] Peter Wiegel's auto spacing idea
On Thu, Jun 14, 2012 at 08:06:42PM +0100, Vernon Adams wrote: could that be done in fontforge too? FontForge has programable auto kerning feature (one can supply FontForge with a Python function that computes the amout of kerning needed). http://fontforge.sourceforge.net/autowidth.html Regards, Khaled ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint configure --with-freetype-config is broken
Hi all, Commit 6076a72 seems to have broken ttfautohint's `configure --with-freetype-config`, attached a little patch to restore it. Regards, Khaled diff --git a/configure.ac b/configure.ac index f0721cf..25a2ac9 100644 --- a/configure.ac +++ b/configure.ac @@ -60,7 +60,7 @@ AM_CONDITIONAL([WITH_DOC], [test x$with_doc != xno]) AC_ARG_WITH([freetype-config], [AS_HELP_STRING([--with-freetype-config=PROG], [use FreeType configuration program PROG])], -[], +[freetype_config=$withval], [freetype_config=yes]) if test $freetype_config = yes; then ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [PATCH] Versions of ttfautohint dependencies
Hi all, I successfully built ttfautohint (from git master) with autoconf 2.65, libtool 2.2.2, and Qt 4.6, all less than the versions specified in bootstrap.conf and configure.ac. So unless there is a reason not to require the higher version, I suggest lowering the dependencies. Regards, Khaled diff --git a/bootstrap.conf b/bootstrap.conf index e037915..771cf29 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -71,9 +71,9 @@ fi # Build prerequisites buildreq=\ -autoconf 2.68 +autoconf 2.65 automake 1.11.1 git1.5.5 -libtool2.4 +libtool2.2.2 tar- diff --git a/configure.ac b/configure.ac index e0c6d95..f6c2bb7 100644 --- a/configure.ac +++ b/configure.ac @@ -29,7 +29,7 @@ gl_INIT AC_TYPE_UINT64_T AT_WITH_QT -AT_REQUIRE_QT_VERSION([4.7]) +AT_REQUIRE_QT_VERSION([4.6]) if test x$with_qt != xno; then AC_MSG_CHECKING([for QLocale::quoteString]) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
