Re: [ft-devel] new CFF engine
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
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
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
:) 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
Hello Werner, while testing the fantastic new engine, I found that much prefer to turn off stem darkening, because it really makes CFF fonts stand out compared to (autohinted) Truetype fonts... It's jarring to switch between websites and alternate between fat and thin looking text. I'm thinking that maybe it should either be turned off by default or stem darkening should also be turned on for other font types by default. And maybe made configurable from fontconfig like what the Cleartype tuner on Windows 7/8 does. What do you think? Regards, Nikolaus ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
I'm thinking that maybe it should either be turned off by default or stem darkening should also be turned on for other font types by default. While this is not possible for native TrueType, stem darkening for smaller sizes is already part of the Infinality patch for the auto-hinter, and this will be added to upstream in the not too distant future. And maybe made configurable from fontconfig like what the Cleartype tuner on Windows 7/8 does. Yes, maybe. However, stem darkening is a font driver property and not to be changed font-wise. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
While this is not possible for native TrueType, [...] I mean `native TrueType hinting'. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
And maybe made configurable from fontconfig like what the Cleartype tuner on Windows 7/8 does. Yes, maybe. However, stem darkening is a font driver property and not to be changed font-wise. Werner Within the new CFF hinter, stem darkening automatically accounts for font weight. At a given size, the darkening amount is greater for light fonts and less for bold fonts. 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
I've build freetype2 and freetype2-demos with clang's -fsanitize=undefined. Here's what I get when run ftview on an otf font: [...] All those issues should be fixed in the git repository. Please rerun your test and report whether you still get errors. Werner PS: The just committed changes don't fix the `jumping glyphs' issue. I'm working on it. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
04.05.2013, 14:07, Werner LEMBERG w...@gnu.org: I've build freetype2 and freetype2-demos with clang's -fsanitize=undefined. Here's what I get when run ftview on an otf font: [...] All those issues should be fixed in the git repository. Please rerun your test and report whether you still get errors. Thanks for the quick fix. Two (minor) issues remain for otf fonts: /var/tmp/freetype2/src/cff/cffload.c:1317:38: runtime error: left shift of negative value -100 /var/tmp/freetype2/src/cff/cffparse.c:438:18: runtime error: left shift of negative value -117 For tty fonts I get these warnings: /var/tmp/freetype2/src/base/fttrigon.c:135:18: runtime error: left shift of negative value -2080768 /var/tmp/freetype2/src/base/fttrigon.c:134:18: runtime error: left shift of negative value -9977856 /var/tmp/freetype2/src/truetype/ttinterp.c:1537:17: runtime error: left shift of negative value -1 /var/tmp/freetype2/src/truetype/ttinterp.c:1514:30: runtime error: left shift of negative value -7615 /var/tmp/freetype2/src/truetype/ttinterp.c:1521:30: runtime error: left shift of negative value -2957 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Two (minor) issues remain for otf fonts: [...] For tty fonts I get these warnings: [...] Thanks again. Should be fixed now in git. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
04.05.2013, 16:44, Werner LEMBERG w...@gnu.org: Two (minor) issues remain for otf fonts: [...] For tty fonts I get these warnings: [...] Thanks again. Should be fixed now in git. Unfortunately your last commit breaks true-type hinting in certain cases (see attached picture). It also introduces two new issues: /var/tmp/freetype2/src/cff/cffgload.c:999:37: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' /var/tmp/freetype2/src/cff/cf2intrp.c:1461:63: runtime error: left shift of 255 by 24 places cannot be represented in type 'FT_Fast' (aka 'int') attachment: ubuntu_hint_distort.png___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Unfortunately your last commit breaks true-type hinting in certain cases (see attached picture). Should be fixed in git, please test. It also introduces two new issues: /var/tmp/freetype2/src/cff/cffgload.c:999:37: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' /var/tmp/freetype2/src/cff/cf2intrp.c:1461:63: runtime error: left shift of 255 by 24 places cannot be represented in type 'FT_Fast' (aka 'int') OK, I've simplified too much. Fixed also. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Everything runs error free now. And the 64-bit problem is also fixed. Thanks for testing. Theoretically, I've also fixed clang issues with other font formats, but it's easy to miss them... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
04.05.2013, 18:58, Werner LEMBERG w...@gnu.org: Unfortunately your last commit breaks true-type hinting in certain cases (see attached picture). Should be fixed in git, please test. It also introduces two new issues: /var/tmp/freetype2/src/cff/cffgload.c:999:37: runtime error: left shift of 255 by 24 places cannot be represented in type 'int' /var/tmp/freetype2/src/cff/cf2intrp.c:1461:63: runtime error: left shift of 255 by 24 places cannot be represented in type 'FT_Fast' (aka 'int') OK, I've simplified too much. Fixed also. Many thanks Werner. Everything runs error free now. And the 64-bit problem is also fixed. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
04.05.2013, 19:13, Werner LEMBERG w...@gnu.org: Everything runs error free now. And the 64-bit problem is also fixed. Thanks for testing. Theoretically, I've also fixed clang issues with other font formats, but it's easy to miss them... One last issue: /var/tmp/freetype2/src/raster/ftraster.c:1827:17: runtime error: left shift of negative value -2 /var/tmp/freetype2/src/raster/ftraster.c:1979:18: runtime error: left shift of negative value -4 /var/tmp/freetype2/src/raster/ftraster.c:1966:16: runtime error: left shift of negative value -7 /var/tmp/freetype2/src/raster/ftraster.c:1968:16: runtime error: left shift of negative value -7 ... Should be easy to fix, because it's always the SCALED macro. IOW something like this should suffice: -#define SCALED( x ) ( ( (x) ras.scale_shift ) - ras.precision_half ) +#define SCALED( x ) ( ( (unsigned long)(x) ras.scale_shift ) - ras.precision_half ) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
On Thu, May 02, 2013 at 11:50:41PM +0200, Werner LEMBERG wrote: Basically, I took the following steps: $ git status # On branch master nothing to commit, working directory clean $ git rev-parse HEAD 9bf75e08199794c4a5fcefcbfe71b5d39f42e46d $ make devel make $ cd ../freetype2-demos $ git status # On branch master nothing to commit, working directory clean $ git rev-parse HEAD 41f1d2780959f7341e93a75065eed6e66fe21dec $ make $ bin/ftview 12 ~/Downloads/SourceCodePro_FontsOnly-1.017/OTF/SourceCodePro-Regular.otf # then press 6 and H The screenshot is attached. Doing *exactly* the same, I don't get such jumping glyphs. I'm running a 32bit GNU/Linux box with gcc 4.6.2. Please say (omitting the paths) FT2_DEBUG=any:7 ftview 12 SourceCodePro-Regular.otf logfile then press `6', `H', and `q'. For reference, I'm posting what I get. Please send your results to me privately to avoid too many large e-mails sent to the list. Werner 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? -- Ross Lagerwall ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Hello Werner, do I understand this correctly: 1. The new engine only works for .otf fonts with included hints and does nothing for .ttfs 2. Setting the new engine as the default like in your mail sets it up automatically for all .otf fonts regardless of hinting settings in fontconfig, meaning I don't have to do anything else to bask in fontilicious glory? Regards, Nikolaus ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Please send me the output of echo '#include limits.h' | cpp -dM -E From your 64bit box, I mean. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
1. The new engine only works for .otf fonts with included hints and does nothing for .ttfs Correct. Similar to TTFs, however, an eternal rule applies: A badly hinted font appears better if displayed without hints (or with auto-hinting). But this is beyond the control of FreeType, entering the realms of FontConfig... 2. Setting the new engine as the default like in your mail sets it up automatically for all .otf fonts regardless of hinting settings in fontconfig, meaning I don't have to do anything else to bask in fontilicious glory? Yep. But note the `eternal rule' above :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
03.05.2013, 11:48, Werner LEMBERG w...@gnu.org: 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 I've build freetype2 and freetype2-demos with clang's -fsanitize=undefined. Here's what I get when run ftview on an otf font: /var/tmp/freetype2/src/sfnt/ttcmap.c:908:18: runtime error: left shift of negative value -1 /var/tmp/freetype2/src/cff/cffload.c:1317:38: runtime error: left shift of negative value -100 /var/tmp/freetype2/src/cff/cffparse.c:438:18: runtime error: left shift of negative value -290 /var/tmp/freetype2/src/cff/cffgload.c:1007:23: runtime error: left shift of negative value -5 /var/tmp/freetype2/src/cff/cffgload.c:996:35: runtime error: left shift of 255 by 24 places cannot be represented in type 'FT_Int32' (aka 'int') /var/tmp/freetype2/src/cff/cf2blues.c:197:9: runtime error: left shift of negative value -22 /var/tmp/freetype2/src/cff/cf2blues.c:199:9: runtime error: left shift of negative value -1 /var/tmp/freetype2/src/cff/cf2blues.c:246:9: runtime error: left shift of negative value -261 /var/tmp/freetype2/src/cff/cf2blues.c:248:9: runtime error: left shift of negative value -1 /var/tmp/freetype2/src/cff/cf2stack.c:189:14: runtime error: left shift of negative value -5 /var/tmp/freetype2/src/cff/cf2hints.c:110:19: runtime error: left shift of negative value -21 /var/tmp/freetype2/src/cff/cf2hints.c:123:24: runtime error: left shift of negative value -20 /var/tmp/freetype2/src/cff/cf2stack.c:163:14: runtime error: left shift of negative value -555 /var/tmp/freetype2/src/cff/cf2intrp.c:1455:15: runtime error: signed integer overflow: 16769920 * 256 cannot be represented in type 'int' ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
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 -- Ross Lagerwall #define __DBL_MIN_EXP__ (-1021) #define __UINT_LEAST16_MAX__ 65535 #define __ATOMIC_ACQUIRE 2 #define _POSIX2_BC_SCALE_MAX 99 #define RE_DUP_MAX (0x7fff) #define __FLT_MIN__ 1.17549435082228750797e-38F #define __UINT_LEAST8_TYPE__ unsigned char #define __flexarr [] #define __stub_fchflags #define __INTMAX_C(c) c ## L #define __CHAR_BIT__ 8 #define SHRT_MAX __SHRT_MAX__ #define __UINT8_MAX__ 255 #define __WINT_MAX__ 4294967295U #define PIPE_BUF 4096 #define MQ_PRIO_MAX 32768 #define __GLIBC_PREREQ(maj,min) ((__GLIBC__ 16) + __GLIBC_MINOR__ = ((maj) 16) + (min)) #define _POSIX2_BC_DIM_MAX 2048 #define _POSIX_TTY_NAME_MAX 9 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __SIZE_MAX__ 18446744073709551615UL #define __stub_putmsg #define __WCHAR_MAX__ 2147483647 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L) #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 #define __GCC_ATOMIC_CHAR_LOCK_FREE 2 #define _POSIX_THREAD_THREADS_MAX 64 #define __USE_BSD 1 #define _POSIX2_BC_STRING_MAX 1000 #define __FLT_EVAL_METHOD__ 0 #define SHRT_MIN (-SHRT_MAX - 1) #define __ASMNAME2(prefix,cname) __STRING (prefix) cname #define __unix__ 1 #define SSIZE_MAX LONG_MAX #define __stub_setlogin #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2 #define _POSIX_DELAYTIMER_MAX 32 #define __SYSCALL_WORDSIZE 64 #define __x86_64 1 #define XATTR_SIZE_MAX 65536 #define __UINT_FAST64_MAX__ 18446744073709551615UL #define __SIG_ATOMIC_TYPE__ int #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 0 #define __UINT_FAST8_MAX__ 255 #define __LEAF , __leaf__ #define __LDBL_REDIR1(name,proto,alias) name proto #define _LIMITS_H___ #define __DEC64_MAX_EXP__ 385 #define __INT8_C(c) c #define __UINT_LEAST64_MAX__ 18446744073709551615UL #define __always_inline __inline __attribute__ ((__always_inline__)) #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __fortify_function __extern_always_inline __attribute_artificial__ #define NAME_MAX 255 #define SCHAR_MAX __SCHAR_MAX__ #define __UINT_LEAST8_MAX__ 255 #define __GCC_ATOMIC_BOOL_LOCK_FREE 2 #define __UINTMAX_TYPE__ long unsigned int #define __linux 1 #define __DEC32_EPSILON__ 1E-6DF #define __stub_sigreturn #define __unix 1 #define __UINT32_MAX__ 4294967295U #define _POSIX_AIO_MAX 1 #define _POSIX_PIPE_BUF 512 #define __LDBL_MAX_EXP__ 16384 #define _POSIX2_EXPR_NEST_MAX 32 #define _ATFILE_SOURCE 1 #define __WINT_MIN__ 0U #define __linux__ 1 #define SCHAR_MIN (-SCHAR_MAX - 1) #define _POSIX_AIO_LISTIO_MAX 2 #define __LDBL_REDIR_NTH(name,proto) name proto __THROW #define __SCHAR_MAX__ 127 #define __USING_NAMESPACE_STD(name) #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) #define __KERNEL_STRICT_NAMES #define __INT64_C(c) c ## L #define __NTH(fct) __attribute__ ((__nothrow__ __LEAF)) fct #define __DBL_DIG__ 15 #define __GCC_ATOMIC_POINTER_LOCK_FREE 2 #define _POSIX_LINK_MAX 8 #define COLL_WEIGHTS_MAX 255 #define _POSIX_SOURCE 1 #define __SIZEOF_INT__ 4 #define __SIZEOF_POINTER__ 8 #define __attribute_used__ __attribute__ ((__used__)) #define USHRT_MAX (SHRT_MAX * 2 + 1) #define _POSIX_CHILD_MAX 25 #define __USER_LABEL_PREFIX__ #define __GLIBC__ 2 #define __END_DECLS #define __CONCAT(x,y) x ## y #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __GNU_LIBRARY__ 6 #define __FLT_EPSILON__ 1.1920928955078125e-7F #define PATH_MAX 4096 #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __nonnull(params) __attribute__ ((__nonnull__ params)) #define __DEC32_MAX__ 9.99E96DF #define _POSIX_NAME_MAX 14 #define RTSIG_MAX 32 #define __INT32_MAX__ 2147483647 #define __SIZEOF_LONG__ 8 #define __STDC_IEC_559__ 1 #define __STDC_ISO_10646__ 201103L #define __UINT16_C(c) c #define __DECIMAL_DIG__ 21 #define _POSIX2_RE_DUP_MAX 255 #define __USE_FORTIFY_LEVEL 0 #define __gnu_linux__ 1 #define MAX_INPUT 255 #define __attribute_warn_unused_result__ __attribute__ ((__warn_unused_result__)) #define _POSIX_LOGIN_NAME_MAX 9 #define DELAYTIMER_MAX 2147483647 #define __LDBL_HAS_QUIET_NAN__ 1 #define __attribute_const__
Re: [ft-devel] new CFF engine
On 13-05-03 05:47 AM, Werner LEMBERG wrote: 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 On most 64 bit platforms int is still 32 bit. -- behdad http://behdad.org/ ___ 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
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. Yep. This is a 64bit issue; I'm already investigating. 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? Yes. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
I've build freetype2 and freetype2-demos with clang's
-fsanitize=undefined. Here's what I get when run ftview on an otf
font:
ttcmap.c:908:18: runtime error: left shift of negative value -1
[...]
Thanks. clang is *very* picky :-) Virtually all compilers do the
right thing for left shifting negative values in case the result fits
into the data type...
May I ask you to apply the attached patch and re-run the test? It
should remove the errors in cffgload.c; I'll try to fix the other
errors in due course, after getting your confirmation that I'm doing
the right thing.
Werner
diff --git a/src/cff/cffgload.c b/src/cff/cffgload.c
index fc01d98..86fa371 100644
--- a/src/cff/cffgload.c
+++ b/src/cff/cffgload.c
@@ -968,11 +968,14 @@
/* this is an operand, push it on the stack */
+
+/* if we use shifts, all computations are done with unsigned */
+/* values; the conversion to a signed value is the last step */
if ( v == 28 )
{
if ( ip + 1 = limit )
goto Syntax_Error;
- val = (FT_Short)( ( (FT_Short)ip[0] 8 ) | ip[1] );
+ val = (FT_Short)( ( (FT_UShort)ip[0] 8 ) | ip[1] );
ip += 2;
}
else if ( v 247 )
@@ -993,10 +996,10 @@
{
if ( ip + 3 = limit )
goto Syntax_Error;
- val = ( (FT_Int32)ip[0] 24 ) |
-( (FT_Int32)ip[1] 16 ) |
-( (FT_Int32)ip[2] 8 ) |
-ip[3];
+ val = (FT_Int32)( ( (FT_UInt32)ip[0] 24 ) |
+( (FT_UInt32)ip[1] 16 ) |
+( (FT_UInt32)ip[2] 8 ) |
+ (FT_UInt32)ip[3] );
ip+= 4;
if ( charstring_type == 2 )
shift = 0;
@@ -1004,12 +1007,12 @@
if ( decoder-top - stack = CFF_MAX_OPERANDS )
goto Stack_Overflow;
-val = shift;
+val = (FT_Int32)( (FT_UInt32)val shift );
*decoder-top++ = val;
#ifdef FT_DEBUG_LEVEL_TRACE
if ( !( val 0xL ) )
- FT_TRACE4(( %ld, (FT_Int32)( val 16 ) ));
+ FT_TRACE4(( %ld, (FT_Int32)( (FT_UInt32)val 16 ) ));
else
FT_TRACE4(( %.2f, val / 65536.0 ));
#endif
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Yes, make devel appears to work except for the wavy text. Attached is the output of that command. Thanks. So `int' is 32bit. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
03.05.2013, 16:23, Werner LEMBERG w...@gnu.org: I've build freetype2 and freetype2-demos with clang's -fsanitize=undefined. Here's what I get when run ftview on an otf font: ttcmap.c:908:18: runtime error: left shift of negative value -1 [...] Thanks. clang is *very* picky :-) Virtually all compilers do the right thing for left shifting negative values in case the result fits into the data type... May I ask you to apply the attached patch and re-run the test? It should remove the errors in cffgload.c; I'll try to fix the other errors in due course, after getting your confirmation that I'm doing the right thing. Thanks. Yes, the cffgload.c errors are gone now. BTW the following hack: diff --git a/src/cff/cf2types.h b/src/cff/cf2types.h index ac6a022..5f09ce0 100644 --- a/src/cff/cf2types.h +++ b/src/cff/cf2types.h @@ -66,7 +66,7 @@ FT_BEGIN_HEADER /* fixed-float numbers */ - typedef FT_Int32 CF2_F16Dot16; + typedef long CF2_F16Dot16; FT_END_HEADER Makes the wavy lines problem go away here, but unfortunately all glyphs with descenders are not rendered anymore... ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Thanks for the clarification :) Say, are there parts or tricks in the new engine that could be carried over to .ttf rendering or the auto-hinter? I would love to see improvements to typeface fidelity with hintslight :) Regards, Nikolaus ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Thanks for the clarification :) Say, are there parts or tricks in the new engine that could be carried over to .ttf rendering or the auto-hinter? I would love to see improvements to typeface fidelity with hintslight :) Well, stem thickening at small sizes is already available in the Infinality patch for the autohinter :-) It will take some time, however, until it gets integrated upstream. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
o == octoploid octopl...@yandex.com writes: o One issue that I've noticed is that turning hinting on o and using the new engine results in bad rendering (wave- o like) with many fonts. o See the attached screenshot (Minion font) as an example. That screenshot duplicates what I saw. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
o == octoploid octopl...@yandex.com writes: o Compiler is gcc-4.8. I also used 4.8. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
WL == Werner LEMBERG w...@gnu.org writes: WL Thanks. So `int' is 32bit. The only system I'm aware of where int was 64 bits was alpha. (Cray's first alpha systems went so far as to have sizeof(char)==sizeof(int)== sizeof(long)==sizeof(int64_t)==1.) Everyone else, as far as I remember, kept int==int32_t to avoid the porting issues seen on ILP64. Certainly all of amd64, arm64, sparc64, mips64, ppc64 are I32/LP64. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Hi Werner, Looks like a very exciting development! I'm just getting ready to do some testing in Ghostscript, and I noticed a missing header inclusion. Trivial patch attached. Cheers, Chris On Wed, 01 May 2013 20:11:31 +0200 (CEST) Werner LEMBERG w...@gnu.org wrote: Folks, Adobe, in collaboration with Google, has contributed a new CFF parsing and hinting engine. The last few months it was my job to fully integrate the code into FreeType, and I'm very pleased with the results. Here are links to the relevant blogs: http://adobe.ly/12mJWGv http://google-opensource.blogspot.com/2013/05/got-cff.html Look at the comparison images :-) Below are the relevant parts of the CHANGES file (which also give details how to enable it); as you can see, there are also a bunch of improvements for ftview and ftdiff. I plan to release 2.4.12 in about a week. Please test and enjoy! Werner == - We have another CFF parsing and hinting engine! Written by Dave Arnold darn...@adobe.com, this work has been contributed by Adobe in collaboration with Google. It is vastly superior to the old CFF engine, and it will replace it in the next release. Right now, it is still off by default, and you have to explicitly select it using the new `hinting-engine' property of the cff driver: ... #include FT_CFF_DRIVER_H FT_Library library; int engine = FT_CFF_HINTING_ADOBE; ... FT_Property_Set( library, cff, hinting-engine, engine ); The code has a (mature) beta status; we encourage all users to test it and report any problems. [...] - Using the `H' key, it is now possible to select the CFF engine in both `ftview' and `ftdiff'. - It is now possible to directly select the LCD rendering mode with the keys `A'-`F' in `ftview'. The key mapping for cycling through LCD modes has been changed from `K' and `L' to `k' and `l', and toggling custom LCD filtering is no longer mapped to key `F' but to key `L'. - In `ftdiff', key `x' toggles between layout modes: Either use the advance width (this is new and now the default) or the bounding box information to determine line breaks. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel From 05a0da6fa15a4d424fcc4555bce8cc88b8b0ecd4 Mon Sep 17 00:00:00 2001 From: Chris Liddell chris.lidd...@artifex.com Date: Thu, 2 May 2013 08:41:22 +0100 Subject: [PATCH] Add missing header. src/cff/cffgload.c - add #include FT_CFF_DRIVER_H --- src/cff/cffgload.c |1 + 1 file changed, 1 insertion(+) diff --git a/src/cff/cffgload.c b/src/cff/cffgload.c index 7d62a9f..fc01d98 100644 --- a/src/cff/cffgload.c +++ b/src/cff/cffgload.c @@ -21,6 +21,7 @@ #include FT_INTERNAL_STREAM_H #include FT_INTERNAL_SFNT_H #include FT_OUTLINE_H +#include FT_CFF_DRIVER_H #include cffobjs.h #include cffload.h -- 1.7.10.4 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
I'm just getting ready to do some testing in Ghostscript, and I noticed a missing header inclusion. Trivial patch attached. Applied, thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Please forgive my naive question, but how would one enable the new engine by default for testing? Is the following enough? diff --git a/src/cff/cffobjs.c b/src/cff/cffobjs.c index ebcf189..1b8643d 100644 --- a/src/cff/cffobjs.c +++ b/src/cff/cffobjs.c @@ -1056,8 +1056,8 @@ /* set default property values */ -driver-hinting_engine= FT_CFF_HINTING_FREETYPE; -driver-no_stem_darkening = FALSE; +driver-hinting_engine= FT_CFF_HINTING_ADOBE; +driver-no_stem_darkening = TRUE; return FT_Err_Ok; } This is too much. The following suffices: -driver-hinting_engine= FT_CFF_HINTING_FREETYPE; +driver-hinting_engine= FT_CFF_HINTING_ADOBE; Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
I noticed in ftview that, as 24 ppem, the baselines and the xheight of any glyph with a round baseline are one pixel lower than the other glyphs when using the Adobe engine. Toggling forced autohint after switching to the Adobe engine makes the issue very obvious. I'm at commit 2048f02e15d658517f23ad2493b7ee53b72c605a. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
I noticed in ftview that, as 24 ppem, the baselines and the xheight of any glyph with a round baseline are one pixel lower than the other glyphs when using the Adobe engine. Toggling forced autohint after switching to the Adobe engine makes the issue very obvious. I'm at commit 2048f02e15d658517f23ad2493b7ee53b72c605a. I don't get this. Which font? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
One issue that I've noticed is that turning hinting on and using the new engine results in bad rendering (wave- like) with many fonts. See the attached screenshot (Minion font) as an example. This seems to be the same effect which James has reported. Attached is what I get with exactly the same parameters. We now have to find out what causes the difference. How did you compile the library and the demo programs? Werner inline: Minion.png___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
02.05.2013, 22:32, Werner LEMBERG w...@gnu.org: One issue that I've noticed is that turning hinting on and using the new engine results in bad rendering (wave- like) with many fonts. See the attached screenshot (Minion font) as an example. This seems to be the same effect which James has reported. Attached is what I get with exactly the same parameters. We now have to find out what causes the difference. How did you compile the library and the demo programs? git clone (both)... cd freetype ./autogen.sh ./configure -prefix=/usr make sudo make install cd ../freetype2-demos make Compiler is gcc-4.8. ___ 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 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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] new CFF engine
Will this new code also be integrated into ttfautohint library? :) Not directly, since ttfautohint can't handle CFFs. However, maybe the algorithm influences the auto-hinter also which in turn could influence ttfautohint. Werner ___ 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] new CFF engine
Its CFF so no That's just plain lazy :) surely there's some crossover with ttf? Not really, since TrueType doesn't have the concept of `hints' at all. ttfautohint emulates Type 1 hints to a certain extent, but those hints are created by algorithm (i.e. by FreeType's auto-hinter), while real CFF hints are usually crafted manually. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
