> > To help in debugging it would be great if you can provide a small > stand-alone snippet which I can compile easily, together with small > input data if necessary. >
Hi Werner ttgload.c revision 1.205 broke incremental font support for type 42 fonts (postscript embedded truetype fonts), revision 1.95 t1gload.c broke type 1 incremental fonts. The cvs logs seem to explain why each change was made, each change effectively prohibits the loading of a font without glyphs. In the incremental interface all fonts load with 0 glyphs, glyph information is provided later. To reproduce the problem build ghostscript with freetype and send any postscript job with a type1 or type42 font, here is a simple test: /Palatino-Italic findfont 20 scalefont setfont 250 250 moveto (freetype) show showpage to build gs with freeype: make FT_BRIDGE=1 FT_CFLAGS=-I../freetype-2.3.8/include FT_LIB=./freetype-2.3.8/objs/libfreetype.a debug If the incremental API is for use only by ghostscript the fix is to predicate the the two changes on the incremental interface being undefined as the gs parser will check these conditions before synthesizing the font. If you have other clients of this interface we'll need to study this more. Thanks Henry >> What can we do to fix this up? Is our code wrong? How is this >> supposed to work. > > I rather suspect that a bug has crept into FreeType. > >> Do you have any tests for the incremental api? > > No, unfortunately. > > > Werner > _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel