[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] Bug in FT New Memory Face?
From: |
David Turner |
Subject: |
Re: [Devel] Bug in FT New Memory Face? |
Date: |
Fri, 15 Jun 2001 14:22:45 +0200 |
Hello Michael,
>
> Hello
>
> My application extracts a font file from a pdf file
> and writes it into a file to be read with FT_New_Face()
> and everything works as expected.
>
> Now I wanted to optimize this application and read
> the font file as it is already in memory with
> FT_New_Memory_Face(), but know the application crashes
> or FT_Load_Glyph() returns with error code 2945.
>
> Stack trace when the application crashes:
> fd1019f8 ec08e88d _realloc + 0000002d
> fd101a20 ec083733 realloc + 0000004f
> fd101a44 ecdfc8dd ft_realloc + 0000001d
> fd101a58 ecdfe2f2 FT_GlyphLoader_Check_Points + 00000196
> fd101a94 ece192b3 TT_Load_Simple_Glyph + 0000008f
> fd101aec ece19b31 load_truetype_glyph + 00000271
> fd101b88 ece1a743 TT_Load_Glyph + 00000337
> fd101c58 ece2057b Load_Glyph + 0000007b
> fd101c80 ecdfeb2a FT_Load_Glyph + 000001ae
> fd101cc0 80053bde FT2Font::getGlyphPixmap(unsigned short) + 000001d6
> fd101d0c 80053fc4 FT2Font::drawChar(BView *, int, int, int, int, int,
> unsigned short) + 00000038
> ...
>
> Is this a known bug?
>
No, but the bug your describing seems very strange. If you're on Unix,
the stream implementation automatically uses memory-mapped files, so
using FT_New_Memory_Face shouldn't change anything to the program's
behaviour.
Could you run the program with ElectricFence to detect some problems ?
Or could you send me and Werner, one of these faulty fonts to let us
inspect it. The smaller the font, the better..
Regards,
- David