freetype-devel
[Top][All Lists]
Advanced

[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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]