Re: [ft-devel] [ttfautohint] Multiple scripts are now supported
Same problem here. But only when running on a gnulinux laptop. Bottom of window is outside the desktop at bottom of screen. Only way to access the run button is to use the modifier key to move the ttfautohintgui window, so that the top of the window goes outside the desktop at top of screen. Not an issue on big desktop screen and not an issue on an osx laptop. -v Khaled Hosny khaledho...@eglug.org 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. 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... ___ 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] [ttfautohint] Multiple scripts are now supported
Sorry for a dumb question; I've built on OSX with GUI and app info gives me.version 95.54-5648 Is that correct version for the latest git build? -v On 18 Oct 2013, at 23:42, Werner LEMBERG w...@gnu.org 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... ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint git source + gnulib issue
Now when running ./bootstrap i get the following; m4/sys_socket_h.m4 m4/sys_types_h.m4 m4/threadlib.m4 m4/unistd_h.m4 m4/warn-on-use.m4 m4/wchar_t.m4 Finished. You may need to add #include directives for the following .h files. #include fcntl.h #include getopt.h #include string.h #include unistd.h You may need to use the following Makefile variables when linking. Use them in program_LDADD when linking a program, or in library_a_LDFLAGS or library_la_LDFLAGS when linking a library. $(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise $(LTLIBTHREAD) when linking with libtool, $(LIBTHREAD) otherwise Don't forget to - add gnulib/src/Makefile to AC_CONFIG_FILES in ./configure.ac, - mention src in SUBDIRS in gnulib/Makefile.am, - mention -I gnulib/m4 in ACLOCAL_AMFLAGS in Makefile.am, - mention gnulib/m4/gnulib-cache.m4 in EXTRA_DIST in Makefile.am, - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC, - invoke gl_INIT in ./configure.ac. running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install --force -I gnulib/m4 --no-recursive autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I gnulib/m4 --force -I gnulib/m4 -I m4 autoreconf: configure.ac: tracing autoreconf: running: true --copy --force autoreconf: running: /usr/local/Cellar/autoconf/2.69/bin/autoconf --include=gnulib/m4 --force configure.ac:21: error: possibly undefined macro: AC_CONFIG_MACRO_DIRS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/local/Cellar/autoconf/2.69/bin/autoconf failed with exit status: 1 ./bootstrap: autoreconf failed again, is this an issue confined to OSX? or a wider issue? Not had the issue before. -v On 30 Jun 2013, at 04:06, Werner LEMBERG w...@gnu.org wrote: When pulling the ttfautohint sources from git, the gnulib directory is empty and running ./bootstrap fails (because gnu lib/gnulib-tool does not exist). Pulling gnulib manually from git into the ttfautohint source directory fixes this, and ttfautohint builds fine. Is this just me? :) or something more widespread? Fixed in git, thanks for the report! Werner ___ 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
[ft-devel] ttfautohint git source + gnulib issue
This seems to be OSX specific? So maybe someone else on OSX could confirm? When pulling the ttfautohint sources from git, the gnulib directory is empty and running ./bootstrap fails (because gnu lib/gnulib-tool does not exist). Pulling gnulib manually from git into the ttfautohint source directory fixes this, and ttfautohint builds fine. Is this just me? :) or something more widespread? -v ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
I have been testing the new adobe-Freetype CFF engine, and was wondering if the default 'darkness' of stem darkening is a little too high? How does the width of stems in a font effect the amount of darkness rendered? I think someone mentioned that thinner stems will render with relatively more darkness than thicker stems? Is that correct? Or is the amount of darkness a uniform value across all rendered fonts? thanks On 12 May 2013, at 06:39, Nikolaus Waxweiler madig...@gmail.com wrote: The most important dependency is on linear blending (or gamma correction) in the compositing of glyph images onto the screen. The stem darkening function assumes blending with a gamma close to 1.8. If linear blending is not used (e.g., gamma 1.0) then black text will appear too dark. This might be a situation where you'd want to disable stem darkening. But white text would suffer. It really is important to use proper blending! -Dave Thanks for the explanation! I just looked up a test of my monitor where it says that the gamma is somewhere between 2.1 and 2.5 depending on what you do in the OSD menu. How can I tell the CFF engine about that? Regards, Nikolaus ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
:) ah thanks. it was under my nose all the time. very interesting. On 12 May 2013, at 07:34, octoploid octopl...@yandex.com wrote: 12.05.2013, 15:52, Vernon Adams v...@newtypography.co.uk: I have been testing the new adobe-Freetype CFF engine, and was wondering if the default 'darkness' of stem darkening is a little too high? How does the width of stems in a font effect the amount of darkness rendered? I think someone mentioned that thinner stems will render with relatively more darkness than thicker stems? Is that correct? Or is the amount of darkness a uniform value across all rendered fonts? You should read src/cff/cf2font.c: 95 /* 96* Total darkening amount is computed in 1000 unit character space 97* using the modified 5 part curve as Avalon rasterizer. 98* The darkening amount is smaller for thicker stems. 99* It becomes zero when the stem is thicker than 2.333 pixels. 100* 101* In Avalon rasterizer, 102* 103* darkenAmount = 0.5 pixels if scaledStem = 0.5 pixels, 104* darkenAmount = 0.333 pixels if 1 = scaledStem = 1.667 pixels, 105* darkenAmount = 0 pixel if scaledStem = 2.333 pixels, 106* 107* and piecewise linear in-between. 108* 109*/ 110 if ( scaledStem cf2_intToFixed( 500 ) ) 111 *darkenAmount = FT_DivFix( cf2_intToFixed( 400 ), ppem ); 112 113 else if ( scaledStem cf2_intToFixed( 1000 ) ) 114 *darkenAmount = FT_DivFix( cf2_intToFixed( 525 ), ppem ) - 115 FT_MulFix( stemWidthPer1000, 116 cf2_floatToFixed( .25 ) ); 117 118 else if ( scaledStem cf2_intToFixed( 1667 ) ) 119 *darkenAmount = FT_DivFix( cf2_intToFixed( 275 ), ppem ); 120 121 else if ( scaledStem cf2_intToFixed( 2333 ) ) 122 *darkenAmount = FT_DivFix( cf2_intToFixed( 963 ), ppem ) - 123 FT_MulFix( stemWidthPer1000, 124 cf2_floatToFixed( .413 ) ); ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
I am also seeing the 'wavy text in ftview', with the Adobe engine + hinting: on. By 'wavy text' i assume we are meaning that some stems are not snapping to the xheight, baseline or capheight, but +1 or -1 pixel from those lines. Kubuntu 13.04 64bit. I would like to test this further, so i have some questions; 1. I have built+installed freetype after patching cffobjs.c to 'driver- hinting_engine= FT_CFF_HINTING_ADOBE;' Will this 'patched' freetype now force the adobe engine as my OS level engine? If not, how can i force the adobe engine at OS level. 2. Can anyone recommend a few CFF fonts with known good ps hints, to use in control tests? thanks -v On Friday, May 03, 2013 01:31:48 PM Ross Lagerwall wrote: On Fri, May 03, 2013 at 11:47:51AM +0200, Werner LEMBERG wrote: After trying on Fedora 19 64bit, Ubuntu 13.04 64bit with gcc 4.7 and gcc 4.6 with the same result, I eventually tried Ubuntu 13.04 32 bit and it seemed normal. Maybe it is a 64-bit issue? Yes, I think so. BTW, does `make devel' really works out of the box on your 64bit platform? I suppose that you have UINT_MAX = ULONG_MAX = 2^64 - 1 and if I read the code correctly, FreeType aborts with no 32bit type found -- please check your configuration files under these conditions... Please send me the output of echo '#include limits.h' | cpp -dM -E Yes, make devel appears to work except for the wavy text. Attached is the output of that command. Regards ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
On 1 May 2013, at 11:18, Dave Crossland d...@lab6.com wrote: On 1 May 2013 20:16, vernon adams v...@newtypography.co.uk wrote: That's look like good stuff. Will this new code also be integrated into ttfautohint library? :) Its CFF so no That's just plain lazy :) surely there's some crossover with ttf? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome
Maybe fontforge is doing this but… 3 things; 1. The problematic glyphs were 'special' in that they had been through ttfautohint and hinted as 'composites'. Unhinted, or hinted but without the 'composites' option, versions of same font had no problematic glyphs. 2. The problematic glyphs were 'special' in that they contained composites AND the .ttfautohint glyph. 3. Why does this issue only occur on OSX Chrome, and no other browser or browser/OS combo?? :) -v On 11 Apr 2013, at 00:54, Jungshik Shin (신정식, 申政湜) jungs...@google.com wrote: The latest finding from http://crbug.com/229010 : As it turns out, I do have access to the original font, as it is available at https://github.com/georgd/EB-Garamond . Very nice font, by the way. The font is, in fact, 1000upem, and makefont.py (part of the build process for the font) tells font forge to push the em to 2048. This seems to be the step causing the issue, as ttfautohint is leaving all these values alone. As a result, the issue appears to be in fontforge. There appear to have been related issues in the past as well, see http://sourceforge.net/mailarchive/forum.php?thread_name=1228364630.1432.0.camel%40lynchforum_name=fontforge-devel Jungshik ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome
Same font file goes to all browsers. Just to keep things simple. The font file would be a single autohinted file that gets served to whichever OS/browser calls for it, as you say OSX should ignore the truetype instructions. -v On 8 Apr 2013, at 22:24, Jungshik Shin (신정식, 申政湜) jungs...@google.com wrote: BTW, why would like to serve a font with hint instruction to OS X? OS X will not utilize the hint instructions. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome
Hi
I think the designer of the font actually found a 'work around' when generating
the fonts, so the page is rendering ok now. The 'work around' is not an ideal
solution though. I will test some more and see if the original issue is still
occurring. I will set up a test page too.
Many thanks
-vernon
On 27 Mar 2013, at 11:00, Jungshik Shin (신정식, 申政湜) jungs...@google.com wrote:
Having said that, I've tried your web page with Chrome 26.0.1410.5 dev
channel and I don't see any problem ('i', 'ff' and 'f'). I may have missed
what you see and I'm attaching a screenshot for you to take a look at. I
also tried Chrome canary (nightly build) 27.0.1454.0 and didn't see any
problem, either.
It's possible that Skia had a problem with fonts auto-hinted by ttautohint,
but the issue has been fixed since. What version of Chrome do you have?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome
test page at http://vernnobile.github.com/cloud-fonts.com/garamond.html
-v
On 27 Mar 2013, at 12:09, Jungshik Shin (신정식, 申政湜) jungs...@google.com
wrote:
Hi Vernon,
It'll be great if you set up a test page so that Skia team can play with it
if there's still an issue.
Thank you,
Jungshik
2013/3/27 Vernon Adams v...@newtypography.co.uk
Hi
I think the designer of the font actually found a 'work around' when
generating the fonts, so the page is rendering ok now. The 'work around' is
not an ideal solution though. I will test some more and see if the original
issue is still occurring. I will set up a test page too.
Many thanks
-vernon
On 27 Mar 2013, at 11:00, Jungshik Shin (신정식, 申政湜) jungs...@google.com
wrote:
Having said that, I've tried your web page with Chrome 26.0.1410.5 dev
channel and I don't see any problem ('i', 'ff' and 'f'). I may have missed
what you see and I'm attaching a screenshot for you to take a look at. I
also tried Chrome canary (nightly build) 27.0.1454.0 and didn't see any
problem, either.
It's possible that Skia had a problem with fonts auto-hinted by ttautohint,
but the issue has been fixed since. What version of Chrome do you have?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ttfautohint - render issue with composites on OSX CHrome
There appears to be a OSX Chrome render issue with specific glyphs auto instructed with ttfautohint. Please see http://www.georgduffner.at/ebgaramond/ On OSX Chrome all characters that are composite substitute glyphs are being rendered badly (part wiped out, missing stems etc) The site linked to above is using different gsub tables for substituting the 'f' with a 'longs' , 'i' with 'dotless i' + 'dot accent', 'f', 'f' pairs with 'ff' ligature etc. The fonts are autohinted with the 'hint composites' option selected, and the effected glyphs contain the ttfautohint dummy glyph used when autohinting composites. Please note it is only Chrome on OSX that shows this messed up rendering, other browsers on OSX render the glyphs fine. -v ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome
Isn't the freetype-devel list still used as the ttfautohint-devel list? Apologies if that's not the case, but i simply replied to the ft-devel post '[ft] ttfautohint 0.95 has been released' from 8th March to post this issue. -v On 26 Mar 2013, at 12:55, Alexei Podtelezhnikov apodt...@gmail.com wrote: Why do you think this is FreeType problem then? You really need to reproduce the problem with more directly, e.g. using ftview. There is this bug report http://savannah.nongnu.org/bugs/?33272 , which I believe is fixed as of FreeType 2.4.6. So, maybe, your chrome uses unfortunate old version - who knows. Please investigate. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome
Werner, It's an issue when ttfautohint is using dummy glyphs as a workaround for hinting composite glyphs. Untill know it was assumed that it was a problem free workaround. My report shows that it seems to be creating problems on OSX Chrome. Of course it could be a bug caused by something that OSX Chrome specifically does different to other browsers, and i will report it there too. How can i best help you with this? i have a mac and use Chrome :-/ -vernon On 26 Mar 2013, at 13:57, Werner LEMBERG w...@gnu.org wrote: However, since I neither have a Mac nor do I use Chrome, I fear that I can't help debug this issue. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] first auto-hinter infinality patch added to git
I know i've asked this before :) but, could this concept also be used to Decrease the xheight at particular char sizes? Because decreasing the xheight can also increase legibility at some small sizes on some fonts. -v On Sep 18, 2012, at 10:02 PM, Werner LEMBERG w...@gnu.org wrote: Folks, I've just committed a first experimental auto-hinter addition from the Infinality patch: What you could originally control by the environment variable `INFINALITY_FT_AUTOHINT_INCREASE_GLYPH_HEIGHTS' can now be handled with the new property `increase-x-height' (and even fine-tuned, not possible with the original implementation). From the documentation: For ppem values in the range 6 = ppem = ‘increase-x-height’, round up the font's x height much more often than normally. If the value is set to 0, which is the default, this feature is switched off. Use this property to improve the legibility of small font sizes if necessary. FT_Library library; FT_Face face; FT_Prop_IncreaseXHeight prop; FT_Init_FreeType( library ); FT_New_Face( library, foo.ttf, 0, face ); FT_Set_Char_Size( face, 10 * 64, 0, 72, 0 ); prop.face = face; prop.limit = 14; FT_Property_Set( library, autofitter, increase-x-height, prop ); Along these lines it should be possible to add other auto-hinter extensions. Erik? Werner ___ 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] ttfautohint 0.92 has been released
Werner, Would there be any significant differences between the hinting from a ttfautohint built using Freetype 2.4.7 against one built using say 2.4.10 ? thanks -v On 7 Aug 2012, at 21:24, Werner LEMBERG w...@gnu.org wrote: ttfautohint 0.92 has been released. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [autohint] improved handling of serif fonts
I was hoping this would fix the 'Q-tail' effect, but it hasn't. Please see the tails on uppercase Q's at 17, 16, 15 px https://lh5.googleusercontent.com/-kA_3D758Iks/T_GZDZ5yIeI/D4E/9Fl0PH15BIY/s949/ubuntu-XP-firefox-ttfautohint-wgGD.png ps i notice that file sizes of ttfautohinted fonts are only a slight % larger than the manual hinted originals now :) -v On 4 Jul 2012, at 16:28, Werner LEMBERG wrote: Folks, please test the current git. I have slightly changed the code in the auto-hinter which recognizes flat segments; it now accepts a broader group of shapes. As a consequence, handling of serif fonts like Palatino or Quattrocento should be much improved. I have also imported this code to ttfautohint. Cf. this bug report: https://savannah.nongnu.org/bugs/index.php?func=detailitemitem_id=36091 Werner ___ 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] [ttfautohint] stem width handling is now selectable
There is an aspect to all this which is maybe most relevant; how do these settings effect rendering across web browsers? I've got a bit lost keeping up with what rendering the different browsers on Windows* use now. The default on Chrome seems to be best, as it sensibly seems to not use Cleartype above approx 40pp's. Firefox is equally good if the user toggles on the different DirectWrite render options 'under the hood'. Does anyone know for sure what uses what now? I will try and do some extensive tests tomorrow; sans, serifs, win7, winXP, diff browsers, etc. I will prob add in Android too, as ttfautohint can effect fonts under Freetype too. -vern On 1 Jul 2012, at 20:13, Karsten Luecke wrote: When you say something like strong-stem-width=g gave a tiny (i think) better rendering could you please explain what your definition of better is, plus a link to comparison screenshots showing this setting vs the other setting? Stating something is better is as useful as stating that today you feel fine. :) Karsten On 01.07.12 15:51, vern adams wrote: Did a little testing using OpenSans Reg Bold under Win7 (cleartype greyscale) and WinXP (cleartype greyscale) but, to be honest, i didn't see any difference :) except under Win7 there the `--strong-stem-width=g gave a tiny (i think) better rendering. In theory, what difference should there be under which render settings? -v On 1 Jul 2012, at 12:49, Werner LEMBERG wrote: From the documentation: ### Stem Width and Stem Positioning `--strong-stem-width=`*string*, `-w`\ *string* : ttfautohint offers two different routines to handle stem widths and stem positions: 'smooth' and 'strong'. The former uses discrete values which slightly increase the stem contrast with almost no distortion of the outlines, while the latter snaps both stem widths and stem positions to integer pixel values as much as possible, yielding a crisper appearance at the cost of much more distortion. These two routines are mapped onto three possible rendering targets: - grayscale rendering, with or without optimization for subpixel positioning (e.g. Mac OS\ X) - 'GDI ClearType' rendering: the rasterizer version, as returned by the GETINFO bytecode instruction, is in the range 36\= version\ 38 and ClearType is enabled (e.g. Windows XP) - 'DirectWrite ClearType' rendering: the rasterizer version, as returned by the GETINFO bytecode instruction, is=\ 38, ClearType is enabled, and subpixel positioning is enabled also (e.g. Windows\ 7) GDI ClearType uses a mode similar to B/W rendering along the vertical axis, while DW ClearType applies grayscale rendering. Additionally, only DW ClearType provides subpixel positioning along the x\ axis. The command line option expects *string* to contain up to three letters with possible values '`g`' for grayscale, '`G`' for GDI ClearType, and '`D`' for DW ClearType. If a letter is found in *string*, the strong stem width routine is used for the corresponding rendering target. The default value is '`G`' which means that strong stem width handling is activated for GDI ClearType only. To use smooth stem width handling for all three rendering targets, use the empty string as an argument, usually connoted with '``'. In the GUI, the option is split into three sets of radio buttons to select the stem width routine for a given rendering target. Please test and enjoy! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ttfautohint] stem width handling is now selectable
Those shots were using the win7 system font viewer- which I think makes it plain old gdi cleartype?? Don't think direct write at system level comes until win8. I maybe wrong, but I thought dw was found in explorer 9 and Firefox 7+ but not the win system. -v Werner LEMBERG w...@gnu.org wrote: On closer inspection it is the 'G' option that gave the only 'different' rendering i saw, and it's not overall better anyway. If you say `-w G', this means that you get the smooth algorithm for gray and DW ClearType, and strong for GDI ClearType, at least in theory. Shots attached. Thanks! These are on Win7 Cleartype: So all three images are using DW ClearType? Then the logic in the font is not working correctly, since `-w G' and `-w g' should give the same (smooth) results, and `-w D' should show the strong rendering. :-( Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
it works! :) much thanks -v On 16 Jun 2012, at 05:00, Infinality wrote: * Fix Oxygen rendering if usint TT hinting, and other ttfautohinted fonts ___ 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
If no-one is familiar with David Kindersley's experiments with optical spacing it's well worth looking at. Info is scarce, except from http://www.kindersleyworkshop.co.uk/shop/optical-letter-spacing.php Basically DK built an apparatus for viewing lettering, to gauge spacing before he cut the lettering into stone. pic at http://www.flickr.com/photos/ebensorkin/4421715975/ The viewer used a filter that 'kind of' worked like a gaussian across the horizontal of each letter(x-axis). I can imagine that a similar digital guassian applied to characters would definitely speed up and improve manual spacing, and could be the basis of an underlying auto-spacing system too. -vern On 15 Jun 2012, at 22:16, Behdad Esfahbod wrote: I've been thinking about this approach for a couple years. Never got to try it. Mine is more mathematically rigorous, but really very similar. Essentially: convolve the glyph with a gaussian, then for any two glyphs, you want to set them next to eachother such that the integral of the gaussians for the two glyphs shifted and multiplied is a certain number. The width of the gaussian, and the certain number give you two axes to adjust 1) general spacing, and 2) how spacing functions around acute corners compared to straight lines. BTW, an approximation of it can be done using analytical algorithms instead of bitmapping. Maybe I give it a try finally. At any rate, someone has explored this space extensively already. I never got to read what he exactly does, has been on my TODO list. Checkout iKern. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint / Oxygen / infinality
Werner, Not sure i understand 100%, but isn't it significant that the infinality patched freetype only renders ttfautohinted fonts in this way? An infinality patched freetype (bug or not) renders other instructed truetype fonts perfectly normally afaik. -vern On 21/04/12 21:01, Werner LEMBERG wrote: Ok, so i've tested this with a infinality patched freetype 2.4.9 w Kubuntu. [...] Obviously a bug w.r.t. Erik's implementation of ClearType's compatibility mode. I've contacted Greg Hitchcock, asking for clarification. Werner -- b: code.newtypography.co.uk t: +44 (0)79-142-00506 e: v...@newtypography.co.uk ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint / Oxygen / infinality
Ok, so i've tested this with a infinality patched freetype 2.4.9 w Kubuntu. Using ftview or the system font viewer any truetype font instructed with ttfautohint (i'm using 0.8) renders as Erik has shown. Pretty much the same screwed up rendering that we saw with old versions of ttfautohint w iOS and converted font outlines in Adobe apps. Curiously web browsers aren't effected for me, nor is the system GUI if i use a ttfautohinted Oxygen for the system font. Just ftview etc. -v On 21/04/12 18:44, Infinality wrote: I've only been using browsers for these, but AFAIK it *should* be the same. :) On 04/21/2012 12:03 PM, vern adams wrote: Erik, Are you testing the rendering via web browsers only? Or do you get same results with e.g. ftview? -vern On 21 Apr 2012, at 16:51, Infinality wrote: Hi Vernon / Werner, I tried it out with the version of Oxygen you sent me, with similar results. I was also able to view it in Windows XP, and as I thought it renders fine there (although they filter the hell out of it). 1. This is the image in my original email. The settings I'm using here are: Infinality patches, native TT hinting. (I also have a custom FIR filter value set on the LCD filter for all of these images) http://www.infinality.net/files/oxygen-infinality-problems.png 2. This is what it renders like with native TT hinting if I disable all Infinality TT instruction tweaks: http://www.infinality.net/files/oxygen-freetype-tt-hinting.png 3. This is what it renders like with Infinality-patched autohinting (which uses slight hinting): http://www.infinality.net/files/oxygen-infinality-autohinting.png You can see with #2 that it's faithfully rendering the instructions as you'd expect, and it looks much like standard Freetype slight hinting, which you'd also expect, since ttfautohint is creating the TT hints from autohint. (The main difference between #2 and #3 is that #3 snaps horizontal stems to pixel boundaries, which normal Freetype slight hinting does not do. I personally prefer the stems to be snapped to integer pixels like this. It looks less dirty to me, however there are some issues with diagonal stem weights, which is a known issue since autohint doesn't do diagonal hinting at all.) After experimenting around with the TT tweaks in the infinality subpixel hinting patches, I am able to get rid of most of the artifacts by turning *on* SHPIX instructions. By default they are off in my patches because (my understanding is) this instruction was used historically as a hack to make outlines fit around pixels, and not much else. (See: http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx ). Is it possible to accomplish the same things that SHPIX is doing in ttfautohint with the more common MIRPs and such? Not only for my patches, but perhaps for other device compatibility? Thanks, Erik On 04/21/2012 02:07 AM, vern adams wrote: Many thanks for this Erik, You seem to have recreated the glitchy rendering that earlier versions of ttfautohint created on iOS and when adobe apps converted ttfautohinted fonts to outlines. That's very interesting i think, as it probably points to something important still going on. First though i think we should check that the issue is not with a particular buggy build of Oxygen; very occasionally a nightly build of an oxygen font has been sent to the git repo with weird extra points that could upset ttf instructions. I'll mail you some Oxygen fonts to test with and confirm that you get same rendering? Many thanks vernon On 21 Apr 2012, at 03:15, Infinality wrote: Hi guys, Today I tested out the TT-instructed Oxygen font from the KDE repo with my TT subpixel hinting patches. This is the result: http://www.infinality.net/files/oxygen-infinality-problems.png Yikes!!! After examining the TT instructions in the instructed version of the Oxygen fonts, it looks like the way that ttfautohint is generating instructions is substantially different than typical TT-instructed fonts. Since my patches are attempting to do what the MS rasterizer does (at least with legacy fonts), I'm curious how these render on Windows. Unfortunately I don't have a Windows system available to test that on at the moment, however my guess is that it renders just fine on Windows. I have a way to exclude certain fonts or individual glyphs within a font from using the tweaks that my patches employ (i.e. render it the way Freetype TT hinter does by default), but I'd rather not build up a giant hard-coded exclusion list of fonts generated by ttfautohint if at all possible. And, given that the TT subpixel hinting patches may soon land into Freetype, I'd like make them work nicely with other Freetype-related software. :D So, I'd like to adapt my TT hinting patches to gracefully handle fonts that have been hinted with ttfautohint. My question is this: Is there something unique about ttfautohint-ed fonts that indicates they are already taking into account subpixel-hinting? I know
Re: [ft-devel] A review of ttfauthint by designer of Siri
On 09/02/12 15:17, Werner LEMBERG wrote: So, in theory, it could be possible to add a feature to allow the user to set the threshold ? :) Not only in theory! We are going right now to implement that. Have a look at the `autohinter-properties' branch in the FreeType repository. Thats great! The unwanted conversion of `i' to `l' is a bug, I think (at least at this size). Alas, I don't know yet how to fix it. Seems to me another example of bad snapping, as i assume it's the dot of the 'i' snapping downwards and not the x-height of the 'i' snapping up to meet the dot?? It's rather that code is missing which checks that segments from different outlines have enough vertical separation. I have to investigate yet whether this is a problem in my bytecode or a general problem with the FreeType autohinter. It's allways been noticeable to me that when i manually hint fonts on Windows GDI, the font at small pt sizes renders on Freetype sytems with the x-height and Caps height lower than under Windows GDI. Therefore it makes sense that the reverse happens when we put 'freetype-hinted' fonts onto GDI Windows - they look too tall. In my opinion ttfautohint needs to use freetype libs that snap x-height and caps-heights lower than the standard freetype autohinter. Does that make sense? -vern Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A review of ttfauthint by designer of Siri
On 09/02/12 20:49, vernon adams wrote: It's allways been noticeable to me that when i manually hint fonts on Windows GDI, the font at small pt sizes renders on Freetype sytems with the x-height and Caps height lower than under Windows GDI. Therefore it makes sense that the reverse happens when we put 'freetype-hinted' fonts onto GDI Windows - they look too tall. In my opinion ttfautohint needs to use freetype libs that snap x-height and caps-heights lower than the standard freetype autohinter. Does that make sense? -vern For screenshots example of this see Oxygen Font – Manual Hinting versus the Freetype2 Autohinter at http://code.newtypography.co.uk. Freetype2 renders the 'native' Oxygen font at correct heights, but renders the manually hinted version not tall enough. -v ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A review of ttfauthint by designer of Siri
On 10/02/12 03:07, Infinality wrote: Hi Erik! Distortion measurement and outline optimization is what's needed. Not sure if this is easier, but I've thought that the easiest way conceptually would be to force at least 1 pixel between any two horizontal stems when available. Like, if you have 5px of height to work with, and 3 horizontal stems, you would always hint them to snap pixel 1, 3, and 5. Then the e will always look normal. (i.e. This won't happen: http://www.freetype.org/autohinting/image/hinted_e.png). That makes good sense. Of course you would have to go one step further - the lower edge of the gap between the 'i' stem and the 'i' dot must then serve as the x-height for the whole font. Of course, if you only have 4px of height you have to make a choice. Yes, and it's the same choice you'd have to make if your were manually instructing the font. Manually of course you could also instruct so that with the x-height at 5 pixels a delta instruction forced the dot of 'i', 'j' etc to get placed 1 pixel above that x-height, instead of in the pixel directly above the x-height. I'm pretty sure that (at least some of) the issues with the main body of i and j touching the dot will go away if the x-height can be made lower, in cases where this happens. I would be very interested to see that in action, and see what difference it would make to GUIs running on freetype-based OS's. I guess it would create the difference that you see in my screenshots at http://code.newtypography.co.uk/?p=2265 It's a matter of taste which one is preferred. -v Erik / Infinality ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A review of ttfauthint by designer of Siri
disclaimer - it's an article written by the guy who accused me of piracy, so my views may be biased :P For sure though, ttfautohint cannot better well executed manual hinting for fonts being rendered on windows GDI OS's. Would be more informational to see GDI grayscale and Directwrite comparisons too, because i think it would prove that quality manual hinting brings a bonus with GDI, but is non essential for the newer MS engines. -v On 08/02/12 20:46, Mostafa Hajizadeh wrote: Thought this might help: http://lettersfromsweden.se/ttfautohintingreview/ ___ 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] A review of ttfauthint by designer of Siri
On 08/02/12 21:53, Behdad Esfahbod wrote: On Wed, Feb 8, 2012 at 4:10 PM, vernon adams v...@newtypography.co.uk mailto:v...@newtypography.co.uk wrote: disclaimer - it's an article written by the guy who accused me of piracy, so my views may be biased :P Isn't it a compliment coming from a Swede? :) good point! :) The x-height issue should definitely be addressed though. And the file size thing is one of the first things I keep hearing about ttfautohint. I'm yet to checkout the code though. Does TTfautohint allways snap upwards, to the pixel edge above? rather than snapping to the pixel edge below, even if the pixel edge below is closest? When hinting manually the direction of snapping can be controlled, so i'm wondering if it could be controlled by the autohinter too. Does freetype do this already? If i look at manually hinted versus ttfautohinted fonts, at a range of sizes, and on GDI cleartype, greyscale, and Directwrite, i can see good manual hinting has the edge only on GDI at sizes below say 12pt. If the snapping at smaller sizes could be controlled in TTFautohint to get rid off i becoming l in some fonts, then overall i'd say ttfautohint is worth all the time saved from manual hinting. -v ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint now has a GUI
As a kde user, the qt dependency is a non-issue for me :p but... the build is reliant on qt4.8, which is still pre-release, so even i have to rebuild my whole qt libs to a non-stable state just for ttfautohint. Fun but overkill. Using the qt library for ttfautohint is understandable, but i suggest it needs to be aimed to build out of the box on the main linux distros, at the very least. Out of interest, do we know what the situation would be for someone porting ttfautohint to a cocoa etc build for osx? I know many would want that. -vern On 23/01/12 19:26, Werner LEMBERG wrote: Oh oh. Looks like the times of easy building of ttfautohint are gone :( It now requires a huge Qt library. I don't mind the ability to have a GUI tool but to require Qt in order to build a simple commandline app is somewhat of an overkill, especially if one wants to deploy the tool on a GUI-less server. I'd greatly appreciate an ability to build without the Qt dependancy. Will do. Also the build process seems to have added complication. I used to be able to build ttfautohint on Mac OS X as either a 32-bit Intel or a 64-bit Intel commandline app. Now calling: $ ./configure --with-freetype-config=`pwd`/../out/bin/freetype-config --prefix=`pwd`/../out \ CFLAGS=-Os -arch i386 no longer is sufficient because the Qt flags seem to insist on x86_64, and I don't yet know how to work around it. This is something I have to ask on a Qt forum. But even if I decide to build x86_64, the new bootstrap stuff adds even more complication to the mix. I downloaded the most recent libtool and installed it (bootstrap insisted on it), and now bootstrap pulls some gnulib stuff, which then seems to conflict with the headers that come pre-installed on my Mac OS X. See below. This shouldn't happen. Probably a bug. I'll report it to the gnulib people. Thanks for testing! Werner ___ 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] ttfautohint now has a GUI
On 24/01/12 08:46, Werner LEMBERG wrote: As a kde user, the qt dependency is a non-issue for me :p but... the build is reliant on qt4.8, which is still pre-release, so even i have to rebuild my whole qt libs to a non-stable state just for ttfautohint. Fun but overkill. Sorry for that. According to this http://labs.qt.nokia.com/2011/12/15/qt-4-8-0-released/ Qt has been released more than a month ago. Yes QT4.8 is released but it's use in actual linux distros is only found in developer/pre-release versions of kde. Stable release kde in the main distros currently is 4.7.* built on QT4.7 . Using the qt library for ttfautohint is understandable, but i suggest it needs to be aimed to build out of the box on the main linux distros, at the very least. I'll try to avoid a 4.8.0 dependency. Out of interest, do we know what the situation would be for someone porting ttfautohint to a cocoa etc build for osx? Qt binary packages seem to be available for Cocoa: http://qt.nokia.com/downloads/qt-for-open-source-cpp-development-on-mac-os-x/ I know many would want that. It seems I have to delve into the cross compilation business. Another completely new frontier for me... I would suggest the best way to go, if at all possible, is a native osx ttfautohint, rather than an X11 version . In the long run isn't that the most elegant solution? a linux/Qt built ttfautohint, and a, OSX/cocoa built ttfautohint? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint now has a GUI
On 24/01/12 11:32, Adam Twardoch (List) wrote: On 12-01-24 10:25, Werner LEMBERG wrote: AFAIK, Qt uses the native GUI elements of the host OS; it's just a wrapper to provide a consistent platform-independent interface. Regarding a special GUI for Cocoa: *I* won't do that :-) Yes, Qt on Mac or Windows definitely does not use X11. I can say that it *is* a good choice for a GUI tool. It's very flexible. The default widgets often don't look as compelling as the purely native controls (so a Qt app on Mac OS X does not look as good as a pure Cocoa app, more like a Carbon app), but it's definitely good enough. Good . I didn't know qt used native widgets on a mac . I assumed those several 100's of mb's were widget pixels :) Also, if possible, backwards compatibility with libtool would be easier for many users. -v I agree, however, that making a dependancy on Qt version 4.8 is currently a bit early. Using 4.7 would be recommended at this point, if possible. Best, Adam ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint now has a GUI
On 24/01/12 19:05, Werner LEMBERG wrote: I agree, however, that making a dependancy on Qt version 4.8 is currently a bit early. Using 4.7 would be recommended at this point, if possible. Compilation should work now with 4.7 (or even older versions). Adam, please try compilation again. I've forgotten to include configure's `config.h' header in the gui source code; maybe this is the reason for the clash between GNU getopt and Qt on your Mac. Werner yep! builds without a hitch on both Ubuntu 11.10 and OpenSuse 12.1 Will test on OSX later tonight. -v ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint 0.6 has been released
Could this be the same reason why 0.6 crashes for me on osx with a segmentation fault when autohinting any font? -v -Original message- From: Werner LEMBERG w...@gnu.org To: freetype-devel@nongnu.org Cc: roberts...@google.com, dcrossl...@google.com Sent: Tue, 27 Dec 2011, 06:29:50 GMT+00:00 Subject: Re: [ft-devel] ttfautohint 0.6 has been released ttfautohint 0.6 has been released. While testing google's new Roboto font (version 1.0), I found out that ttfautohint 0.6 crashes, unfortunately. Reason is the very weird glyph `nonbreakingspace' (its bbox is xMin=32767, yMin=32767, xMax=-32767, yMax=-32767, BTW) which is a composite glyph with a single component, namely `space'. However, `space' has no contours at all... Well, constructing such an anomaly is valid, but I haven't considered this case. Alas, it means a major redesign of some algorithms in ttfautohint. I'll release 0.6.1 after fixing this issue. Werner ___ 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] ttfautohint 0.4 has been released
On 30 Oct 2011, at 07:31, Werner LEMBERG wrote: Very interesting! Among other things, ttfautohint's `prep' table is used to set up some elements of the storage area. Maybe Apple's interpreter resets this area while rendering a new glyph? Unfortunately, the TTF reference manual of Apple says nothing about the scope of storage area elements. I'll send you a patch which uses elements from the cvt only. patch applied + rebuilt ttfautohint. Effect in iOS is same or possibly worse :-/ -v___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint 0.4 has been released
Hi, After some quick tests it seems that the same render issues on iOS printing to postscript printers on OSX remain, or at least partly(?) I should later test same font autohinted with v0.3 and look for differences/similarities. I have put iOS screenshots at http://newtypography.co.uk/ttfautohint/ Shots are from iOS 4.3.3, and i will test iOS5 later. I have been looking at the test fonts to see if maybe the font outlines or points are causing the issue but they seem healthy and render fine on all other scenarios. I have been trying to work out which glyph forms are most likely to get malformed but it doesnt seem to follow a pattern. Postscript printing on OSX gives the same malformations on the same glyphs. -v Thanks Werner. I will test this tonight :) Also - i have noticed ttfautohint has limitations when it comes to instructing very light weighted fonts. The autohinter is creating instructions that produce much too thin stems. The uniformity of the stems seems good :) but they are simply too thin and disappear at below 18-16 px. Could there be a way to set the autohinter to impose a minimum size of stem widths, for example?? I will post you screenshots later of the issue. -v On 27 Oct 2011, at 16:52, Werner LEMBERG wrote: ttfautohint 0.4 has been released. If you have had rendering problems on Apple computers, please try this version. Theoretically, those issues should no longer be there. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint vs FontForge
They are not comparable. As far as i know ttfautohint takes a completely different approach that fontforges autohinter. Ttfautohint is far better at auto hinting truetype fonts than the fontforge autohinter. Andrey, if you know how to get comparable results with fontforges autohinter, please tell your method :) Ttfautohint test screenshots at http://code.newtypography.co.uk/?p=1037 -vernon On 19 Oct 2011, at 02:13, Andrey V. Panov wrote: On 18 октября 2011, Werner LEMBERG wrote: the next three months I'm intensively working again on ttfautohint, Why don't enhance existing autohinter in FontForge? Currently it is more advanced and it is reasonable to add more features/fixes to FontForge instead of writing new one from scratch. -- Andrey V. Panov http://canopus.iacp.dvo.ru/~panov/ ___ 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] ttfautohint: The next round
Great news Werner :) Re: the gui - with control over something like 'controlling the width of blue zones', it would be ideal if the user had a preview/visual feedback of what any blue zone tweaking was doing. Same with other controls; some kind of 'preview' would be ideal. vernon On 17 Oct 2011, at 20:26, Werner LEMBERG wrote: Folks, the next three months I'm intensively working again on ttfautohint, thanks to the pledgie campaign! I'm especially grateful to FontLab and Google which both provide a substantial amount of money. The two main issues I will work on are . fixing the bytecode to make it work reliably with Apple's TrueType engine (I've already started with that, and I estimate to provide a new release in about two weeks) . writing a GUI for easier control In case you have special wishes, now it's the right time to tell me! Please look into the TODO file to check whether your idea is already covered: http://repo.or.cz/w/ttfautohint.git/blob_plain/HEAD:/TODO Werner ___ 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] ttfautohint: How to install
Hi, sorry i forgot about that.
Patch wouldn't apply
i get -
patching file tafpgm.c
patch: malformed patch at line 14: };
My patch file looks like this (taken from your post) -
diff --git a/src/tafpgm.c b/src/tafpgm.c
index 1268e29..3874844 100644
--- a/src/tafpgm.c
+++ b/src/tafpgm.c
@@ -4298,6 +4298,11 @@ unsigned char FPGM(bci_hint_glyph) [] = {
ENDF,
+ PUSHB_1,
+100,
+ FDEF,
+ ENDF,
+
};
-vern
On 7 Jul 2011, at 12:51, Werner LEMBERG wrote:
Attached is a patch for tafpgm.c; please apply temporarily to make
the `fpgm' table four bytes longer.
Thanks for that.
Have you been able to test that? Are fonts generated with the
slightly larger `fpgm' table rendered correctly, or do you still get
an egg-shaped `O' glyph?
Otherwise, I'm going to contact Greg Hitchcock from Microsoft, asking
for help. Perhaps he can explain what's going on.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
Thanks for that. Also, how easy might it be to implement an Option that auto-instructs only the Y-axis ? One thing i'm noticing is that font file sizes almost double as a result of ttfautohint (10-20% more than manual hinting) and I'm wondering if much of the x-axis stuff might be not-so-essential for adequate hinting. Just a thought. -vern On 30 Jun 2011, at 14:05, Werner LEMBERG wrote: Attached is a patch for tafpgm.c; please apply temporarily to make the `fpgm' table four bytes longer. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
The 'final image' is simply the ttfautohint instructions with the addition of links (double links work best in this instance). I did no extra hinting from fontlab - what you see afaik is pixel fitting from the ttfautohint instructions, plus the effect of the additional links. Sadly Fontlab has no function to see or manipulate the actual TT instructions, so i can't see what how the actual instructions differ when i add the links. I think it's interesting that if i look at the same font in FontForge's Gridfitmode, then i don't see the egging issue at all. Is it possible that Fontlab's TT rendering is much more like the microsoft engines? It definitely looks like the rendering in the screenshots i took from Windows7. Is any of this helping ? :) I'm temped to look at the font in MS VisualTruetype and look at the raw instructions when i add links. -vern On 30 Jun 2011, at 09:27, Werner LEMBERG wrote: (above) Upper case 'O', ttfautohint version, opened in Fontlab 'Truetype hinting' mode, showing alignment zones pixels arranged by ttfautohints instructions. 27 ppem. Note the egging at top curve, as snapping is to pixel at TOP of alignment zone. Thanks. Is your image the final result of the hinting process with FontLab? I get a similar result (i.e., the egged shape) only before applying the last instruction of the glyph, IUP[y] (in function 47)... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft] ttfautohint 0.1 has been released
Builds runs for me on OSX 10.6.8 but on Ubuntu 11 i get Error code `0x06' while autohinting font each time i try and run. Seemed to have built fine tho. -vern On 30 Jun 2011, at 08:43, Werner LEMBERG wrote: ttfautohint 0.1 has been released. It is available from http://sourceforge.net/projects/freetype/files/ttfautohint Werner ___ Freetype mailing list freet...@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft] ttfautohint 0.1 has been released
ahh thanks - default for libfreetype.so install is /usr/local/lib. Ubuntu had installed old freetype libs to /usr/lib. :) now fixed working. many thanks -v On 30 Jun 2011, at 13:40, Werner LEMBERG wrote: Builds runs for me on OSX 10.6.8 but on Ubuntu 11 i get Error code `0x06' while autohinting font each time i try and run. Seemed to have built fine tho. Are you sure that FreeType 2.4.5 is installed, and that you link to that library version (libfreetype.so.6.7.0)? You can check the library's location with the `ldd' program: ldd /usr/local/lib/ttfautohint Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
On 25 Jun 2011, at 06:56, Werner LEMBERG wrote: Please try the current git snapshot and play with the options --hinting-range-min and --hinting-range-max. Currently, the default value for hinting-range-max is 1000; this means that the autohinter tests all ppem values up to 1000 to find hinting sets. However, the larger the ppem, the larger the blue zones. And by design, the autohinter ignores blue zones which are larger than 3/4 pixels. If you limit hinting-range-max to a value where the blue zones are still handled, the generated bytecode uses this hinting set for all larger sizes also. Finding a good value for hinting-range-max has to be done with trial and error, but a waterfall already indicates bad sizes, so hinting-range-max must be less than that). hmm i have tested varying min-range max-range - by shifting ranges i can get the 'egging issue' to move up/down a ppem size, so the issue persists but just at different ppem's. The adverse effects of having a very small value for hinting-range-max must be analyzed also; it essentially means that some horizontal segments which at larger ppem values no longer align are still treated as edges. Maybe it helps if I introduce options to manipulate the `gasp' table, making it possible to set an upper limit for applying hints. From my experience i doubt that the gasp table will hold any magic bullets, especially under DirectWrite. Finally, I don't know yet whether it makes sense to directly manipulate the 3/4 pixels limit (perhaps by deactivating this threshold completely). This needs further testing. Worth a try. I have opened up a ttfautohint version of Ubuntu Font in FontLab, where i can use a 'gridfit' mode (just as in FontForge) but i can also add Visual TrueType commands and see the resulting effect on the pixels. So i tested the 'o' glyph. It seems to me that the egging issue is caused by the top curves of the 'o' snapping to the top edge of the pixel that corresponds to that alignment zone, if i force these curves to snap to the bottom edge of the alignment zone pixel then the egging is fixed! Of course then i need all pixels in the alignment zone to snap to the bottom of the pixel to get uniform x-height throughout all glyphs. Could there be a way to force pixel snapping to the bottom of pixel in some alignment zones like this with ttfautohint? many thanks -vernon ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
Thanks again for your invaluable help in testing ttfautohint! My pleasure. Very keen to see a working autohinter available to font designers :) The feedback i'm getting from my screenshots is that the ttfautohint output is overall superior under DirectWrite to the original hinted fonts. Just seems to be a little extra 'something' needed to get the GDI sorted too :) Please try the current git snapshot and play with the options --hinting-range-min and --hinting-range-max. Currently, the default value for hinting-range-max is 1000; this means that the autohinter tests all ppem values up to 1000 to find hinting sets. However, the larger the ppem, the larger the blue zones. And by design, the autohinter ignores blue zones which are larger than 3/4 pixels. If you limit hinting-range-max to a value where the blue zones are still handled, the generated bytecode uses this hinting set for all larger sizes also. Finding a good value for hinting-range-max has to be done with trial and error, but a waterfall already indicates bad sizes, so hinting-range-max must be less than that). Yep. I will test these ranges make available any relevant screenshots. The adverse effects of having a very small value for hinting-range-max must be analyzed also; it essentially means that some horizontal segments which at larger ppem values no longer align are still treated as edges. Maybe it helps if I introduce options to manipulate the `gasp' table, making it possible to set an upper limit for applying hints. Finally, I don't know yet whether it makes sense to directly manipulate the 3/4 pixels limit (perhaps by deactivating this threshold completely). This needs further testing. I am curious - as i understand it(?) ttfautohint uses freetype to find snap zones etc from which it bases it's TT instructions output. So what mileage could there be in using a patched freetype tree with ttfautohint? I'm thinking of some of Infinality patches that have attempted to tweak Freetype's hinting routines. Some i think were attempting to give more aggressive, cleartype-like rendering. Is there anything to learn from those patches when tweaking ttfautohint? many thanks -vern Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
Hi Werner, Do you think it's possible that the autohinter can be tweaked to lessen the effects of the aggressive vertical filtering of GDI? or is it already at the limits of what's possible for GDI? The feedback i'm getting from my screenshots is that the ttfautohint output is overall superior under DirectWrite to the original hinted fonts. Just seems to be a little extra 'something' needed to get the GDI sorted too :) many thanks -vern On 21 Jun 2011, at 14:33, Werner LEMBERG wrote: there's still some 'curve flattening' at large sizes, but less marked now. I will post some full waterfall tests later today to check all point sizes up to 48 ish. The reason for the difference is an incredibly aggressive vertical filtering with GDI, I believe. Have a look at the attached images to compare how ftview and Win98's GDI render glyph `o' from the ttfautohint version of the Ubuntu font: Ubuntu-R-TA-o-48px-1.0gamma-ftview.png Ubuntu-R-TA-o-48px-Win98-GDI-Chrome12.png GDI apparently paints horizontally isolated pale pixels as white, and blackens isolated dark pixels. I consider this plain ugly. At 48px, the glyphs in the top waterfall (Win98 GDI rendering) on the above web page look as if they had been rendered without anti-aliasing... The FontForge snapshots demonstrate how the hinted outlines differ between the original hinting in Ubuntu (Ubuntu-R) and the ttfautohint version (Ubuntu-R-TA): Ubuntu-R-TA-o-48px.png Ubuntu-R-o-48px.png As you can see, the ttfautohint intentionally aligns the hinted outline (green) at half-pixel borders, making it almost the same shape as the unhinted outline (black). On the other hand, the original Ubuntu hinting is far more aggressive even at that large size, rounding to integer pixel values. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
http://code.newtypography.co.uk/ Just posted screenshots of ttfautohint output under DirectWrite (Cleartype Grayscaling). Interesting. imo, generally the ttfautohint output is superior to the original fonts' output, though there are some glitches, e.g. dot accents are malformed. -vern___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] new ttfautohint screenshots
I have posted new screenshots from my testing with Werner's ttfautohint library. Goto http://code.newtypography.co.uk/ Have tested - UbuntuFont, Vera Sans, Vera Sans Bold, Playfair, Copse. Looking good. The shots so far are from the biggest headache, Windows GDI Cleartype, but i will also soon post shots from Windows DirectWrite (FireFox 4 5), where the autohinter creates superior font rendering than ye olde manual hinting imho :) Needless to say that autohinter is giving good results with Freetype engine too. -vern ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
However, I don't understand where the differences come from. Nothing in the hinting instructions added by ttfautohint is specific to ClearType. It uses a large number of twilight points which is probably unusual a bit, but this doesn't explain how the asymmetry can come into existence. Well i have no technical knowledge of the rendering stuff behind Cleartype or Freetype, but my eyes tell me that they render the same TT instructions differently Mhmm. Up to now I've *never* seen a font rendered with FreeType which shows such a large deviation from the Windows font engine. I believe that FreeType's output is quite trustworthy. heh. Really? Depends what you mean by 'large deviation' i guess. I only ever seem to see differences between Windows font rendering and the other OS's :) Maybe there are problems with my bytecode. Well - your bytecode seems to work fine for hinting under Freetype, but not under Windows GDI. You should probably look at the newest screenshots at http://code.newtypography.co.uk I tested Ubuntu Font Droid Serif with the Windows' 'system font viewer' on XP and Win7, both with GDI-Cleartype. Some very glitchy stuff happens with the ttfauto hinted fonts at larger sizes - 36pts on Ubuntu Font, 48pts on Droid Serif. I have tested and replicated those glitches on different PC's so they are for real! :) Must do some full waterfall tests to see what else is happening at other sizes. More testers and more eyes would be good too. Perhaps I can activate my contacts to the font people at Microsoft, asking for help in case the rendering problems you observe are also present in Win7. That would be good. Any light shed on how Cleartype utilises TT instructions would be great. But the bad rendering happens with and without ClearType, right? The rendering glitches seem to be specific to the GDI-Cleartype rendering, and absent (as far as i can see) from the new (FireFox4 IE9) DirectWrite-Cleartype rendering. -vern ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
On 19 Jun 2011, at 16:37, Werner LEMBERG wrote: I'm guessing the render differences are caused by my tests being run on WinXP Win7. Interesting. Is Win7 OK? Does WinXP only fail? On Chrome the Win7 XP were near identical, as the browser uses GDI on both OS's. I will do some tests using the system font viewer in Win7 XP, to remove the chance of browser interference. Are your ftview shots from Windows? No, from Linux. But they should be absolutely identical since ftview renders the glyphs directly as graphics, bypassing the operating system's font handling completely. But isn't it the system's (in our case, Windows) font handling that needs to be targetted? No point making an autohinter that can output great graphics but renders the fonts not-so-great in the browser :) Interestingly Chrome on Linux seems to override a font's hinting settings now!? Could this be part of the improved font rendering that's rumoured for ChromeOS? Standard hinted, autohinted not hinted versions of Ubuntu Font render same on Ubuntu Chrome! Hmm. Overriding the user's preferences is not optimal IMHO. I'm guessing that this behaviour is in line with the Chrome OS direction where the browser is at the core. Of course a user can still set own prefs for screen rendering, Chrome OS is linux after all. On Ubuntu Firefox4 the combination of ttfautohint + version 1 gasp gives superior rendering to manually hinted original Ubuntu Font imo (see attached pngs) :-) conclusion - Legacy Windows is the worst target :) However, I don't understand where the differences come from. Nothing in the hinting instructions added by ttfautohint is specific to ClearType. It uses a large number of twilight points which is probably unusual a bit, but this doesn't explain how the asymmetry can come into existence. Well i have no technical knowledge of the rendering stuff behind Cleartype or Freetype, but my eyes tell me that they render the same TT instructions differently Perhaps I can activate my contacts to the font people at Microsoft, asking for help in case the rendering problems you observe are also present in Win7. That would be good. Any light shed on how Cleartype utilises TT instructions would be great. It's not purely an OS version issue though - the big difference on Windows is between GDI and DirectWrite. XP is GDI only (i believe), wherease Win7 apps are able to render under either GDI or DirectWrite. Hence - FFox 4 and IE9 on Windows utilise DirectWrite for superior font rendering. It's very likely that Win8 will use primarilly DirectWrite (if not purely). Same goes for the new MS Phone OS. With DirectWrite, hinting instructions become almost arbitrary. So... main target for font hinting is Windows GDI imo. many thanks -vern Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
Hi updated ttfautohint from the repository made a better waterfall test page. The ttfauto hinting looks much better imo, though still not 100% perfect yet :) i have now also included a test of a version of Ubuntu Font with TTF instructions tables replace by instructions from Fontforge's autohint autoinstruct process. have included the screenshots attached here. Hope that's ok for people - if not i can in future post them to the web only. Chrome 12 on WinXP, GDI Cleartype. On 20 Jun 2011, at 19:44, Werner LEMBERG wrote: Using ftview, I see problems with FreeType also: The baseline is ragged. And indeed, I've done an addition instead of a subtraction in the bytecode, making the computation of blue overshoot values incorrect. This is fixed now in the git repository; please update and regenerate your test files! Maybe this change is sufficient to improve the rendering with Windows GDI also. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
I have added detailed shots to http://code.newtypography.co.uk/?p=898 At 400% magnification the difference does not look so great, but at 100% the difference in rendering is noticeable. I'll leave hinting interpreation to the experts, but to my eyes the vertical extremes of curves are not being flattened quite enough, thus creating extra sub-pixels (see the 400x magnifications). This seems to be the opposite of what is happening at other px sizes where the vertical extremes of curves tend to get overflattened, e.g. the 'O' at 15, 19, 21px. -vern On 18 Jun 2011, at 04:42, Werner LEMBERG wrote: Of note is that at larger sizes (20px - 30px) the rendering breaks up on curves. Is it possible that the autohinter is not yet set to instruct those larger sizes? What do you mean with `breaks up'? Please give more details what exactly you think is bad. The hinting range is set to 8ppem-1000ppem, BTW, so these sizes are covered. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
I've carried out some simple tests using ttfautohint with the Ubuntu Font on Win XP Win7, Chrome12 Firefox4. The screenshots are at http://code.newtypography.co.uk/ Looks good so far, but i shall test more fonts, particularly a serif and a bold display face. I chose Ubuntu Font as i know it's well documented that Dalton Maag put a lot of professional hours into it's truetype instructions. thanks Werner! vern On 17 Jun 2011, at 08:31, Werner LEMBERG wrote: but i am embarrassed to admit that i have built the library but have not found how to use the 'autohint' function :) a quick howto, please! One important thing I've forgotten to mention: You need the current git version of FreeType to test the ttfautohint library; the `configure' test for 2.4.4 in ttfautohint is a fake currently since 2.4.5 hasn't been released yet. I know, I know, I should have done this already weeks ago :-| In case you are running a Unix box (this includes recent Macs), please use the attached script which downloads and builds ttfautohint and FreeType in a subdirectory called `ttfautohint-build'. For convenience, the created `ttfautohint' binary is static and not dependent on other libraries. After successful compilation, you can find it in `ttfautohint-build/out/bin', and you can copy it to any other directory. If you run the script another time, it will update the git repositories instead of downloading, then do a complete build again. Calling `ttfautohint' is simple: ttfautohint in-file out-file for example ttfautohint Bevan.ttf Bevan-TA.ttf As mentioned earlier, there aren't options right now. Note that the program runs quite slow; adding a progress indicator is on my TODO list also. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: Milestone reached!
great. but i am embarrassed to admit that i have built the library but have not found how to use the 'autohint' function :) a quick howto, please! vern On 16 Jun 2011, at 21:20, Werner LEMBERG wrote: One major problem still remains which I have to resolve in the next days: Composite glyphs are rendered incorrectly. I've fixed that now. However, letting the autohinter handle subglyphs separately will always produce inferior results if compared to handling all subglyphs together at the same time. In particular, diacritics are sometimes positioned too near to the base letter. So please test the library! As usual, comments, suggestions, critique, etc., is highly welcomed. Werner ___ 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] ttfautohint: Milestone reached!
Werner, Sounds good. I think i remember you saying that ttfautohint will not have a GUI. Is that still the case? vernon On 15 Jun 2011, at 11:28, Werner LEMBERG wrote: [Vern, I take the liberty to answer on the list also.] That's very interesting and gives some pretty good results. If no-one else has done so i am happy to run some specimen tests produce screenshots. This would be great! Please wait a few days until I've fixed the problem with composite glyphs (I'm nearly done, and the solution was much easier than expected); I'll then send another mail to the list. Are there plans with ttfautohint to give the user any abilities to vary/manipulate hinting parameters? Yes. However, I need input from experienced designers like you who tell me what shall be configurable. The first parameter to be added is the size range covered by hinting. For the moment, it is fixed to 8=ppem=1000. Another one is whether the original font's outline shall be used, or whether the font's original hinting shall be applied (at the font units level, which means 2048 ppem for most TrueType fonts). Some fonts like ArialMT *always* apply hints to some composite glyphs to shift one or more subglyphs. Note that the latter option will probably take some time to implement. Finally, there is the problem of glyphs which can't be addressed with a cmap directly, like small caps which are activated by an OpenType feature. Similar to FreeType's autohinter, such glyphs don't get any special consideration and are treated by the default hinting module (in FreeType this is the `cjk' module currently, and in ttfautohint it can be either `dummy' or `latin', to be controlled by another yet-to-be-written configuration option :-). This is quite a generic problem and needs separate attention; for the moment it is beyond my work on ttfautohint. So please comment and make suggestions! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
