Re: [ft-devel] [ft] ttfautohint 0.4 has been released
Hi Erik! Do you have screenshots of your play with aflatin.c ? Would be interesting to see. thanks vern On 29 Oct 2011, at 20:16, Infinality wrote: Hi Vernon, I've achieved some results by selectively playing with the dist value in af_latin_compute_stem_width() in aflatin.c. The problem with doing this though is the lack of diagonal hinting in the autohinter. Things like W and A can start looking really thin when you force stems to something like 1 pixel wide. I would LOVE to see diagonal hinting get implemented, because it would really improve the quality of the autohinter. I'd also be interested to see if there is some sort of official answer to your question, as I'd certainly make use of it in my patchset. Currently I use a combination of emboldening, gamma correction, alignment and dist manipulation to make thinner fonts render in a more readable way. It would be nice to have one way to do it! Thanks, Erik (Infinality) On 10/27/2011 11:05 AM, vern adams wrote: 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. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ttfautohint Enjoy! Werner PS: Downloads from savannah.nongnu.org will redirect to your nearest mirror site. Files on mirrors may be subject to a replication delay of up to 24 hours. In case of problems use http://download-mirror.savannah.gnu.org/releases/ -- This project provides a library which takes a TrueType font as the input, remove its bytecode instructions (if any), and return a new font where all glyphs are bytecode hinted using the information given by FreeType's autohinting module. The idea is to provide the excellent quality of the autohinter on platforms which don't use FreeType. The library has a single API function, `TTF_autohint'; see `src/ttfautohint.h' for a detailed description. Note that the library itself won't get installed currently. A simple command-line interface to the library is the demo program `ttfautohint'; after compilation and installation, say ttfautohint --help for usage information, or say man ttfautohint to read its manual page. -- New in 0.4: * The bytecode has been changed to `create' twilight points. This should avoid rendering artifacts on some platforms. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ 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] ttfautohint 0.4 has been released
Werner, Not sure if this helps but it looks like it may!! I was playing in Fontforge with the prep table of a thin weight ttfautohinted font, trying to prevent pixel 'drop out'. At one point i simply replaced the whole prep table with PUSHW_1 511 SCANCTRL PUSHB_1 4 SCANTYPE The result (on Win XP greyscale and Cleartype) looked a LOT like the shredded rendering on iOS! MS Greyscale = https://lh6.googleusercontent.com/-YZlQfUB1PjU/Tqztfo8XFJI/BHw/qrT-G4mkTPI/s745/Screen%252520shot%2525202011-10-30%252520at%25252006.23.26.png MS Cleartype = https://lh6.googleusercontent.com/-qQZH_Phhfi0/Tqzr-04GT1I/BHo/1ATMNSXPmf0/s753/Screen%252520shot%2525202011-10-30%252520at%25252006.15.42.png The shredding looks very much like under iOS. Could it be that Apple's render engine on iOS doesn't like something in the prep tables of ttfautohinted fonts ? Maybe the instructions are fine, but the prep table is causing the issue? Something missing perhaps? -v On 28 Oct 2011, at 13:19, Werner LEMBERG wrote: Please see http://newtypography.co.uk/ttfautohint/ These are 4 forms that are guaranteed to get shredded :) Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft] ttfautohint 0.4 has been released
I would LOVE to see diagonal hinting get implemented, because it would really improve the quality of the autohinter. Autofit doesn't offer code into this direction. However, FontForge has code for diagonal autohinting (in file nowakowskittfinstr.c). You might have a look. Since it hadn't fit my needs for writing ttfautohint, I didn't examine the code in more detail. I'd also be interested to see if there is some sort of official answer to your question, as I'd certainly make use of it in my patchset. If you mean with `official' that I comment this, here's my answer: This needs a lot of investigation, since FreeType's autohinter has no concept to support diagonals. Maybe two additional, special passes with rotated outlines would work. For the moment, however, this is no issue for me, but I invite everyone to loop up papers which could provide ideas how to do that! Werner ___ 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
I was playing in Fontforge with the prep table of a thin weight ttfautohinted font, trying to prevent pixel 'drop out'. At one point i simply replaced the whole prep table with PUSHW_1 511 SCANCTRL PUSHB_1 4 SCANTYPE :-) This fails, of course. The result (on Win XP greyscale and Cleartype) looked a LOT like the shredded rendering on iOS! 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. Werner ___ 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? I wonder what the difference is between the way the Apple interpreter (Quartz) deals with prep commands in iOS (shredded fonts) compared to the way Quartz interprets a prep table in OSX (not shredded fonts)? And also, what's happening in the interpretation of a fonts prep table under Adobe's OSX versions of inDesign, Illustrator etc, that the Adobe app overrrides the OSX system interpreter. -v Unfortunately, the TTF reference manual of Apple says nothing about the scope of storage area elements. ___ 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
Maybe Apple's interpreter resets this area while rendering a new glyph? I wonder what the difference is between the way the Apple interpreter (Quartz) deals with prep commands in iOS (shredded fonts) compared to the way Quartz interprets a prep table in OSX (not shredded fonts)? I think we all do wonder :-) And also, what's happening in the interpretation of a fonts prep table under Adobe's OSX versions of inDesign, Illustrator etc, that the Adobe app overrrides the OSX system interpreter. The very problem is the creation process of the OpenType and TrueType specifications. First there were the implementations, then there were the standards. While Microsoft's implementation is directly derived from the Apple code, they have changed in considerably in the last 15 years or so without actually documenting all of the changes... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] regarding freetype 2 cubic curve flattening
Vivek, in fact the great work is David's, not mine - I made the original attempt, which was buggy, and then supplied a fix, but David wrote a new version which was justified mathematically and based on Hain's paper, as you mention. So I'll have to pass the responsibility for explaining it to David Bevan. Best regards, Graham On 30/10/2011 08:25, Vivek Rathod wrote: Hello Graham, I was looking at the new spline flattening algorithm that you and David worked on. The speed up due to this is fantastic. Great work! I could not understand the part of the code where you compare *s_limit* with *s *according to Hain's paper *dmax = (s/L) * dnorm ; *here s is not normalized. dmax is the tolerance for flatness and dnorm is the normalized flatness of the curve. so *s_limit* *= (dmax / dnorm) * L* ; by putting *dnorm* = 0.75 we get the permissible height of the control point for the curve not to be split. so should we not be comparing *s= abs(dy * dxi - dx * dyi)* with *s_limit * L *instead of *s* and *s_limit* ( because s is perpendicular distance of control point multiplied by L) ? Am I missing something very obvious? * *Thanks, Vivek Rathod ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2.4.7 no longer compiles on Mac OS X, 2.4.6 does
Hi all, Here is my draft to GNU-libtoolize graph.a target in freetype2-demos package. Also it improves make clean to remove graph.a itself. Please test and give me comment. It seems that glibtool --mode=link $(CC) -static libxxx.a ... ignores the list of normal object files, I had to pass the list of libtool object files. Thus, I changed the suffixes of graph.a objects from $(SO) to $(O). I expect that $(O) is same with $(SO) in non-GNU-libtool environment (freetype2/builds/*/*.mk set so), so no harmful impact. I added --mode=compile $(CC) -static to compile libtool object files, so there won't be extra time to compile the shared objects that are useless for graph.a. The next step of this improvement would be more abstraction for non-GNU-libtool environment and cross building (ar -r is too strict!). It requires the improvement of freetype2 makefiles, so it should be different changeset. Regards, mpsuzuki diff --git a/Makefile b/Makefile index 34aca88..b0b63dc 100644 --- a/Makefile +++ b/Makefile @@ -219,7 +219,9 @@ else else clean_demo: - -$(DELETE) $(subst /,$(SEP),$(OBJ_DIR_2)/*.$(SO)) + -$(DELETE) $(subst /,$(SEP),$(OBJ_DIR_2)/*.$(SO) $(OBJ_DIR_2)/*.$(O)) + -$(DELETE) $(subst /,$(SEP),$(OBJ_DIR_2)/*.$(SA) $(OBJ_DIR_2)/*.$(A)) + -$(DELETE) $(subst /,$(SEP),$(OBJ_DIR_2)/.libs/*) -$(DELETE) $(subst /,$(SEP),$(SRC_DIR)/*.bak graph/*.bak) -$(DELETE) $(subst /,$(SEP),$(SRC_DIR)/*~ graph/*~) diff --git a/graph/beos/rules.mk b/graph/beos/rules.mk index 70beaae..80b9b39 100644 --- a/graph/beos/rules.mk +++ b/graph/beos/rules.mk @@ -13,18 +13,25 @@ ifeq ($(PLATFORM),beos) # add the BeOS driver object file to the graphics library `graph.a' # - GRAPH_OBJS += $(OBJ_DIR_2)/grbeos.$(SO) + GRAPH_OBJS += $(OBJ_DIR_2)/grbeos.$(O) DEVICES += BEOS DEVICE_INCLUDES += $(GR_BEOS) # the rule used to compile the graphics driver # - $(OBJ_DIR_2)/grbeos.$(SO): $(GR_BEOS)/grbeos.cpp $(GR_BEOS)/grbeos.h + $(OBJ_DIR_2)/grbeos.$(O): $(GR_BEOS)/grbeos.cpp $(GR_BEOS)/grbeos.h + ifneq ($(LIBTOOL),) + $(LIBTOOL) --mode=compile $(CC) -static $(CFLAGS) $(GRAPH_INCLUDES:%=$I%) \ +$I$(subst /,$(COMPILER_SEP),$(GR_BEOS)) \ +$(X11_INCLUDE:%=$I%) \ +$T$(subst /,$(COMPILER_SEP),$@ $) + else $(CC) $(CFLAGS) $(GRAPH_INCLUDES:%=$I%) \ $I$(subst /,$(COMPILER_SEP),$(GR_BEOS)) \ $(X11_INCLUDE:%=$I%) \ $T$(subst /,$(COMPILER_SEP),$@ $) + endif # Now update GRAPH_LINK according to the compiler used on BeOS GRAPH_LINK += -lbe -lstdc++.r4 diff --git a/graph/rules.mk b/graph/rules.mk index 3389423..0fc70c1 100644 --- a/graph/rules.mk +++ b/graph/rules.mk @@ -27,22 +27,26 @@ GRAPH_H := $(GRAPH)/graph.h\ $(GRAPH)/gblblit.h -GRAPH_OBJS := $(OBJ_DIR_2)/grblit.$(SO)\ - $(OBJ_DIR_2)/grobjs.$(SO)\ - $(OBJ_DIR_2)/grfont.$(SO)\ - $(OBJ_DIR_2)/grfill.$(SO)\ - $(OBJ_DIR_2)/grswizzle.$(SO) \ - $(OBJ_DIR_2)/grdevice.$(SO) \ - $(OBJ_DIR_2)/grinit.$(SO)\ - $(OBJ_DIR_2)/gblender.$(SO) \ - $(OBJ_DIR_2)/gblblit.$(SO) +GRAPH_OBJS := $(OBJ_DIR_2)/grblit.$(O)\ + $(OBJ_DIR_2)/grobjs.$(O)\ + $(OBJ_DIR_2)/grfont.$(O)\ + $(OBJ_DIR_2)/grfill.$(O)\ + $(OBJ_DIR_2)/grswizzle.$(O) \ + $(OBJ_DIR_2)/grdevice.$(O) \ + $(OBJ_DIR_2)/grinit.$(O)\ + $(OBJ_DIR_2)/gblender.$(O) \ + $(OBJ_DIR_2)/gblblit.$(O) # Default value for COMPILE_GRAPH_LIB; # this value can be modified by the system-specific graphics drivers. # -COMPILE_GRAPH_LIB = ar -r $(subst /,$(COMPILER_SEP),$@ $(GRAPH_OBJS)) +ifneq ($(LIBTOOL),) + COMPILE_GRAPH_LIB = $(LIBTOOL) --mode=link $(CCraw) -static -o $(subst /,$(COMPILER_SEP),$@ $(GRAPH_OBJS)) +else + COMPILE_GRAPH_LIB = ar -r $(subst /,$(COMPILER_SEP),$@ $(GRAPH_OBJS)) +endif # Add the rules used to detect and compile graphics driver depending @@ -66,16 +70,25 @@ $(GRAPH_LIB): $(GRAPH_OBJS) # pattern rule for normal sources # -$(OBJ_DIR_2)/%.$(SO): $(GRAPH)/%.c $(GRAPH_H) +$(OBJ_DIR_2)/%.$(O): $(GRAPH)/%.c $(GRAPH_H) +ifneq ($(LIBTOOL),) + $(LIBTOOL) --mode=compile $(CC) -static $(CFLAGS) $(GRAPH_INCLUDES:%=$I%) $T$@ $ +else $(CC) $(CFLAGS) $(GRAPH_INCLUDES:%=$I%) $T$@ $ +endif # a special rule is used for 'grinit.o' as it needs the definition # of some macros like -DDEVICE_X11 or -DDEVICE_OS2_PM # -$(OBJ_DIR_2)/grinit.$(SO): $(GRAPH)/grinit.c $(GRAPH_H) +$(OBJ_DIR_2)/grinit.$(O): $(GRAPH)/grinit.c $(GRAPH_H) +ifneq ($(LIBTOOL),) + $(LIBTOOL) --mode=compile $(CC) -static $(CFLAGS) $(GRAPH_INCLUDES:%=$I%) \ + $(DEVICES:%=$DDEVICE_%) $T$(subst /,$(COMPILER_SEP),$@ $) +else $(CC) $(CFLAGS)
Re: [ft-devel] FreeType 2.4.7 no longer compiles on Mac OS X, 2.4.6 does
Here is my draft to GNU-libtoolize graph.a target in freetype2-demos package. Also it improves make clean to remove graph.a itself. Please test and give me comment. Looks good! Thanks for working on this. BTW, please test with FreeType's `make devel; make' also. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [ft] ttfautohint 0.4 has been released
Here is one sample of Myriad Pro I just took recently: http://www.infinality.net/images/1025myriad.png This is using autohint where dist is essentially snapped to integer pixels vertically. In most cases it works out very nicely, but you occasionally do get those vanishing stems like I was talking about. There is also other stuff going on here though too, including stem-alignment and adjustments to FIR filtering. This is newer code, but the existing infinality patchset does almost the same thing. If you'd like to play with it, it's here: http://www.infinality.net/blog/subpixel-hinting-patch-for-freetype/ Stem alignment isn't as good in this version though. I'll hopefully be getting the new patches out within a couple weeks. Erik On 10/30/2011 01:10 AM, vern adams wrote: Hi Erik! Do you have screenshots of your play with aflatin.c ? Would be interesting to see. thanks vern On 29 Oct 2011, at 20:16, Infinality wrote: ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2.4.7 no longer compiles on Mac OS X, 2.4.6 does
Werner LEMBERG wrote: Here is my draft to GNU-libtoolize graph.a target in freetype2-demos package. Also it improves make clean to remove graph.a itself. Please test and give me comment. Looks good! Thanks for working on this. BTW, please test with FreeType's `make devel; make' also. Thanks, just I've tested freetype2-demos with freetype2 tree built by `make devel; make' on GNU/Linux. It finishes successfully as attached following. # `make devel; make' does not work well on Mac OS X, I will try to fix. Regards, mpsuzuki gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I/tmp/freetype2/devel -I/tmp/freetype2/include -I./src -DFT_CONFIG_MODULES_H=ftmodule.h -o obj/ftbench.o src/ftbench.c -DUNIX -DHAVE_POSIX_TERMIOS gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I/tmp/freetype2/devel -I/tmp/freetype2/include -I./src -DFT_CONFIG_MODULES_H=ftmodule.h -o obj/common.o src/common.c gcc -o bin/ftbench obj/ftbench.o obj/common.o /tmp/freetype2/objs/libfreetype.a -lm -lbz2 gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I/tmp/freetype2/devel -I/tmp/freetype2/include -I./src -DFT_CONFIG_MODULES_H=ftmodule.h -o obj/ftdump.o src/ftdump.c -DFT2_BUILD_LIBRARY gcc -o bin/ftdump obj/ftdump.o obj/common.o /tmp/freetype2/objs/libfreetype.a -lm -lbz2 gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I/tmp/freetype2/devel -I/tmp/freetype2/include -I./src -DFT_CONFIG_MODULES_H=ftmodule.h -o obj/ftlint.o src/ftlint.c gcc -o bin/ftlint obj/ftlint.o obj/common.o /tmp/freetype2/objs/libfreetype.a -lm -lbz2 gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph -o obj/grblit.o graph/grblit.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph -o obj/grobjs.o graph/grobjs.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph -o obj/grfont.o graph/grfont.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph -o obj/grfill.o graph/grfill.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph -o obj/grswizzle.o graph/grswizzle.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph -o obj/grdevice.o graph/grdevice.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph \ -DDEVICE_X11 -o obj/grinit.o graph/grinit.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph -o obj/gblender.o graph/gblender.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph -o obj/gblblit.o graph/gblblit.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I./graph \ -I./graph/x11 \ -I/usr/include \ -o obj/grx11.o graph/x11/grx11.c ar -r obj/graph.a obj/grblit.o obj/grobjs.o obj/grfont.o obj/grfill.o obj/grswizzle.o obj/grdevice.o obj/grinit.o obj/gblender.o obj/gblblit.o obj/grx11.o ar: creating obj/graph.a gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I/tmp/freetype2/devel -I/tmp/freetype2/include -I./src -DFT_CONFIG_MODULES_H=ftmodule.h -I./graph \ -o obj/ftdiff.o src/ftdiff.c gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I/tmp/freetype2/devel -I/tmp/freetype2/include -I./src -DFT_CONFIG_MODULES_H=ftmodule.h -I./graph \ -o obj/ftcommon.o src/ftcommon.c gcc -o bin/ftdiff obj/ftdiff.o obj/common.o obj/ftcommon.o /tmp/freetype2/objs/libfreetype.a -lm -lbz2 obj/graph.a -L/usr/lib -lX11 -lm gcc -c -g -O0 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wredundant-decls -Wno-long-long -Wnested-externs -Wstrict-prototypes -I/tmp/freetype2/devel
Re: [ft-devel] FreeType 2.4.7 no longer compiles on Mac OS X, 2.4.6 does
[...] I've tested freetype2-demos with freetype2 tree built by `make devel; make' on GNU/Linux. It finishes successfully as attached following. Thanks! # `make devel; make' does not work well on Mac OS X, I will try to fix. Interesting. What's the problem? Werner ___ 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] regarding freetype 2 cubic curve flattening
On 30/10/2011 08:25, Vivek Rathod wrote: according to Hain's paper dmax = (s/L) * dnorm ; here s is not normalized. dmax is the tolerance for flatness and dnorm is the normalized flatness of the curve. so s_limit = (dmax / dnorm) * L ; by putting dnorm = 0.75 we get the permissible height of the control point for the curve not to be split. so should we not be comparing s= abs(dy * dxi - dx * dyi) with s_limit * L instead of s and s_limit ( because s is perpendicular distance of control point multiplied by L) ? It is actually not just cross-product but s = abs(dx * dxi - dx * dyi) / L otherwise the dimensionality is wrong. Some Hain's equations just need to be creatively modified to avoid divisions in the code. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
