gmane.comp.fonts.freetype.user

Re: [ft] Windows CE port

Werner LEMBERG — 2008-11-24T08:19:55

Thanks, applied to the CVS. Hopefully, the next time such fixes are directly reported to us. Werner

Re: [ft] Windows CE port

Vincent Torri — 2008-11-23T11:59:57

On Sun, 23 Nov 2008, Werner LEMBERG wrote: in the file freetype-2.3.7-src.tar.bz2, there is a README file that explains exactly the modifications, and there is a patch that is in the patch/ subdir. Mainly: * a patch specific for windows ce for libtool (in ltmain.sh). I have already reported that, so I hope that the next libtool release will have that patch. So i don't think that you are interested in that change. * the changes i found in the gnuwin32 freetype 2.3.5 package. Vincent Torri

Re: [ft] Windows CE port

Werner LEMBERG — 2008-11-23T11:53:20

Nice! Any changes necessary which are not yet in the FreeType sources? Werner

Re: [ft] ftmac.c

Ryan Schmidt — 2008-11-23T05:51:17

Ok, sounds like this is the newer more modern version? And this is the older legacy version? Then I don't understand this paragraph. Did you reverse the paths or did you mean it that way? Because based on your first two paragraphs, I would have thought src/base/ftmac.c is the version that will be kept, having had the old pre-Mac OS X code removed, and builds/mac/ ftmac.c will eventually go away.

[ft] Windows CE port

Vincent Torri — 2008-11-22T13:32:44

Hey, this mail is just to inform you that I have made a freetype port using the cegcc cross toolchain. You can find the packages in SF: http://sourceforge.net/project/showfiles.php?group_id=173455&package_id=285919 (Freetype 2.3.7) regards Vincent Torri

Re: [ft] Minimizing small file reads

=?UTF-8?Q?=E2=98=82Josh_Chia_(=E8=B0=A2=E4=BB=BB=E4=B8=AD)?= — 2008-11-18T09:52:05

_______________________________________________ Freetype mailing list Freetype< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Minimizing small file reads

Mickey Gabel — 2008-11-18T09:57:39

What about loading the font completely into memory and having FT2 work on the loaded buffer? suzuki toshiya wrote:

Re: [ft] Minimizing small file reads

suzuki toshiya — 2008-11-18T10:10:52

Hi, As Mickey Gabel has proposed, it is possible to load a font face from a memory image that is copied from a font file. Please check FT_Open_Face() API http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Open_Face and its argument http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Open_Args It is possible to make a FT_Face object from a memory image. If you want a concrete example, please check an implementation of a private internal function open_face_from_buffer() in src/base/ftobjs.c. Regards, mpsuzuki ☂Josh Chia (谢任中) wrote:

Re: [ft] Minimizing small file reads

suzuki toshiya — 2008-11-18T05:34:30

Hi, In the system supporting memmap() and FreeType2 is configured to use it, the number of system call would be much reduced in comparison with the system without memmap. In the target platform which you're working for, memmap() is available? Or, available and configured to use it, but you think still too many read system call is executed? Regards, mpsuzuki ☂Josh Chia (谢任中) wrote (2008/11/18 10:39):

[ft] Minimizing small file reads

=?UTF-8?Q?=E2=98=82Josh_Chia_(=E8=B0=A2=E4=BB=BB=E4=B8=AD)?= — 2008-11-18T01:39:11

_______________________________________________ Freetype mailing list Freetype< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Font broken or FreeType?

Peter Weilbacher — 2008-11-17T08:43:49

Somehow that sentence came out wrong. I meant that I'll post here again if I find problems doing that, not that I will never even try... And indeed, now that I used the fix in the original app, I can confirm that the problem is gone there, too. Thanks again, Peter.

Re: [ft] Font broken or FreeType?

Peter Weilbacher — 2008-11-12T23:52:32

Hi Werner, I was away but now at least I managed to test with the reduced testcase and with that the problem indeed seems to be gone. Thanks! (I also wanted to also check with the original app, but that has other problems, so I will postpone that. Will post here again, if I do, but I don't think that will happen.) Cheers, Peter.

Re: [ft] Font broken or FreeType?

Werner LEMBERG — 2008-11-03T22:41:00

This is fixed now in the CVS. Please test. Werner

Re: [ft] Font broken or FreeType?

Werner LEMBERG — 2008-11-03T13:01:00

Confirmed. Reason is that the `subrs' array is filled in a non-standard way (probably due to an error during conversion from TTF to PS): subroutine 626 is defined twice. This isn't an error per se, but until now I've never encountered such a font, and FreeType doesn't handle this well: the last subroutine isn't stored by FreeType, causing the problem you've observed. Will try to find a fix soon. Werner

Re: [ft] Font broken or FreeType?

Werner LEMBERG — 2008-10-30T23:07:18

Please send the font to me privately. Werner

[ft] Font broken or FreeType?

Peter Weilbacher — 2008-10-30T11:45:16

I encountered a problem with FT_Load_Glyph() using the "Helvetica Italic" font (HELVI.PFB) that is included with OS/2. It fails for one glyph (499 starting from 0) with error code 0xa0 ("opcode syntax error"). The short program below demonstrates it. I can easily provide the font, if needed. Now, to find out if it's the font that is broken or FreeType just stumbles over a quirk in a correct font, I tried to verify the problem with FontForge. Perhaps I don't know how to properly handle that program, but it doesn't expose any problems. (Just that FontForge seems to sort the glyphs differently, 499 is not the one that I am trying to load, the ones around it have different names, too). Thanks in advance for any hints! Peter. ---------------------- brokenHelvI_test.c ----------------------- // sample output for broken font: // $ brokenHelvI_test.exe HELVI.PFB 499 // 1: error=0xa0 for HELVI.PFB glyph 499 // 2: error=0xa0 for HELVI.PFB glyph 499 #include "ft2build.h" #include FT_FREETYPE_H #include

Re: [ft] freetype question

Werner LEMBERG — 2008-10-29T17:02:33

Sample code, please -- you should provide a *minimal* example which compiles fine with ANSI C (without graphics, of course). Werner

[ft] freetype question

ayoub mejri — 2008-10-29T15:46:43

_______________________________________________ Freetype mailing list Freetype< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Freetype2 functions

Werner LEMBERG — 2008-10-21T04:49:11

Check the documentation of FT_First_Char and FT_Get_Next_Char Again, check the documentation! -> FT_Get_Char_Index. Werner

[ft] Freetype2 functions

Sivaprasad CG — 2008-10-20T11:21:55

Dear All, Is there any function in freetype2, which list out all the unicodes in the given font. Suppose I am opening timesnewroman.ttf, can i get all the unicode values that are supported by this font file using the Freetype2 functions. Is there any function in freetype2, in which i can query a particular unicode value in a particular font file. Regards Sivan

CodeWarrior project file is not ready to build (Re: [ft] Mac Build- Desperate)

2008-10-13T15:10:44

Dear CodeWarrior users, In this weekend, I was trying to improve a project file for CodeWarrior IDE builds/mac/ftlib.prj.xml to support 3 architechtures: CFM MSL, Mach-O MSL, Mach-O BSD. And, I found that CW project file (both of traditional binary and XML formats) could not store the pathnames of source files. When I copy the project file to vanilla source tree of FreeType2, CW starts to scan the source tree and determine which source files should be compiled. This is the root of the problem reported by RJJ (2 years ago, sorry): Why CW tries to compile builds/amiga/src/base/ftsystem.c instead of src/base/ftsystem.c? When a CW project file tells CW to load a source file named "ftsystem.c", it cannot specify the directory including the file. The CW crawls all directories (maybe in the alphabetical order) and loads the first file named "ftsystem". Therefore, builds/amiga/src/base/ftsystem.c is prioritized than src/base/ftsystem.c. I could not find any switches to prevent or restrict this scanning behavi