[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Updates for gf driver.
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] Updates for gf driver. |
Date: |
Sun, 08 Jul 2018 23:24:07 +0200 (CEST) |
[commit f7a27bf38847b4531164f042088535604d3cd2ec]
> I am attaching the example program I am using for checking output,
> its the same `example1.c' program but with some slight modifications
> to see the num_glyphs allocated.
Some comments.
* Your `ftexample.c' can't work correctly. In function `draw_bitmap'
there is the following comment:
/* for simplicity, we assume that `bitmap->pixel_mode' */
/* is `FT_PIXEL_MODE_GRAY' (i.e., not a bitmap font) */
Surprise, surprise! GF *is* a bitmap font, where
`bitmap->pixel_mode' is FT_PIXEL_MODE_MONO...
In other words, you have to adapt both `draw_bitmap' and
`show_image' to handle the mono format, having 1bit per pixel.
Honestly spoken, it's kind of disappointing that you completely
ignored this comment while modifying `ftexample.c'.
* Irrespective of that, there are big memory leaks. Calling
FT2_DEBUG=any:7 \
valgrind --leak-check=full \
./ftexample cmr10.600gf 0 \
2> ftexample.log
gives the attached log (using a `make devel; make' compilation).
* The next peculiarity is the size of the created bitmap. I'm not
sure what glyph gets displayed at index 48 (the charcode value of
`0' as used in the command above), but the height of the resulting
bitmap size, 4x7, looks far too small.
* Showing `bitmap' at begin of `draw_bitmap' with the debugger, I see
(gdb) p *bitmap
$1 = {
rows = 7,
width = 4,
pitch = 5,
buffer = 0x76f440 "",
num_grays = 0,
pixel_mode = 1 '\001',
palette_mode = 0 '\000',
palette = 0x0
}
which is also strange: A pitch of 5 implies at least a width of
4 * 8 + 1 = 33
pixels (since we have 8 pixels per byte). However, `width' has
value 4...
* If I display the 7 rows bit-wise, I get this:
0000000000000011111110000000000000000000
0000000000011111111111110000000000000000
0000000001111110000011111100000000000000
0000000011111000000000111110000000000000
0000001111100000000000001111100000000000
0000001111000000000000000111100000000000
0000011111000000000000000111110000000000
Whatever this is, it looks cut off.
Please fix these issues ASAP!
Werner
==5604== Memcheck, a memory error detector
==5604== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5604== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==5604== Command: ./ftexample cmr10.600gf 0
==5604==
FT_Open_Face: Requesting face 0
FT_Stream_Open: opened `cmr10.600gf' (24148 bytes) successfully
TTF driver
SFNT driver
not a font using the SFNT container format
Type 1 driver
not a Type 1 font
CFF driver
SFNT driver
not a font using the SFNT container format
not a CFF font header
CID driver
not a CID-keyed font
PFR driver
not a PFR font
Type 42 driver
not a Type42 font
Windows FNT driver
not a Windows FNT file
PCF driver
... try gzip stream
... try LZW stream
... try Bzip2 stream
not a PCF file
BDF driver
not a BDF file
GF driver
gf_load_font: GF_ID(131) found
gf_load_font: GF_POST_POST(249) found
gf_load_font: GF Postamble found
gf_load_font: Allocated bitmap table
number of glyphs: allocated 128
FT_Open_Face: New face object, adding to list
FT_Open_Face: Creating glyph slot
FT_New_GlyphSlot: Creating new slot object
FT_New_GlyphSlot: Return 0x0
FT_Open_Face: Creating size object
FT_Open_Face: Return 0x0
FT_Request_Size (gf driver):
x scale: 0 (0.000000)
y scale: 0 (0.000000)
ascender: 0.000000
descender: 0.000000
height: 0.000000
max advance: 0.000000
x ppem: 0
y ppem: 0
GF_Glyph_Load: glyph index 48
FT_Load_Glyph: index 48, flags 0x4
x advance: 4.531250
y advance: 2.109375
linear x advance: 0.000000
linear y advance: 0.000000
bitmap 4x7, monochrome bitmap (mode 1)
FT_Done_Library: close faces for type42
FT_Done_Library: close faces for truetype
FT_Done_Library: close faces for type1
FT_Done_Library: close faces for cff
FT_Done_Library: close faces for t1cid
FT_Done_Library: close faces for pfr
FT_Done_Library: close faces for type42
FT_Done_Library: close faces for winfonts
FT_Done_Library: close faces for pcf
FT_Done_Library: close faces for bdf
FT_Done_Library: close faces for gf
==5604==
==5604== HEAP SUMMARY:
==5604== in use at exit: 64,104 bytes in 138 blocks
==5604== total heap usage: 211 allocs, 73 frees, 361,757 bytes allocated
==5604==
==5604== 32 bytes in 1 blocks are definitely lost in loss record 4 of 11
==5604== at 0x4C2A110: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5604== by 0x4C747C: ft_alloc (ftsystem.c:76)
==5604== by 0x41923A: ft_mem_qrealloc (ftutil.c:146)
==5604== by 0x4190E0: ft_mem_realloc (ftutil.c:102)
==5604== by 0x46F43C: GF_Face_Init (gfdrivr.c:236)
==5604== by 0x40BAFA: open_face (ftobjs.c:1375)
==5604== by 0x40D854: ft_open_face_internal (ftobjs.c:2447)
==5604== by 0x40BC36: FT_New_Face (ftobjs.c:1438)
==5604== by 0x40426A: main (ftexample.c:104)
==5604==
==5604== 45,436 (48 direct, 45,388 indirect) bytes in 1 blocks are definitely
lost in loss record 11 of 11
==5604== at 0x4C2A110: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5604== by 0x4C747C: ft_alloc (ftsystem.c:76)
==5604== by 0x41903C: ft_mem_qalloc (ftutil.c:76)
==5604== by 0x418FC4: ft_mem_alloc (ftutil.c:55)
==5604== by 0x46EB3C: gf_load_font (gflib.c:417)
==5604== by 0x46F21A: GF_Face_Init (gfdrivr.c:172)
==5604== by 0x40BAFA: open_face (ftobjs.c:1375)
==5604== by 0x40D854: ft_open_face_internal (ftobjs.c:2447)
==5604== by 0x40BC36: FT_New_Face (ftobjs.c:1438)
==5604== by 0x40426A: main (ftexample.c:104)
==5604==
==5604== LEAK SUMMARY:
==5604== definitely lost: 80 bytes in 2 blocks
==5604== indirectly lost: 45,388 bytes in 129 blocks
==5604== possibly lost: 0 bytes in 0 blocks
==5604== still reachable: 18,636 bytes in 7 blocks
==5604== suppressed: 0 bytes in 0 blocks
==5604== Reachable blocks (those to which a pointer was found) are not shown.
==5604== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5604==
==5604== For counts of detected and suppressed errors, rerun with: -v
==5604== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
- [ft-devel] Updates for gf driver., Parth Wazurkar, 2018/07/05
- Re: [ft-devel] Updates for gf driver., Parth Wazurkar, 2018/07/05
- Re: [ft-devel] Updates for gf driver.,
Werner LEMBERG <=
- Re: [ft-devel] Updates for gf driver., Werner LEMBERG, 2018/07/08
- Re: [ft-devel] Updates for gf driver., Parth Wazurkar, 2018/07/09
- Re: [ft-devel] Updates for gf driver., Werner LEMBERG, 2018/07/09
- Re: [ft-devel] Updates for gf driver., Parth Wazurkar, 2018/07/09
- Re: [ft-devel] Updates for gf driver., Werner LEMBERG, 2018/07/09
- Re: [ft-devel] Updates for gf driver., Parth Wazurkar, 2018/07/09
Re: [ft-devel] Updates for gf driver., Parth Wazurkar, 2018/07/09