Re: [ft-devel] Updates for gf driver.

2018-07-08 Thread Werner LEMBERG
> ==5604== LEAK SUMMARY:
> ==5604==definitely lost: 80 bytes in 2 blocks
> ==5604==indirectly lost: 45,388 bytes in 129 blocks

BTW, why are you allocating so much memory blocks?  `ftexample.c'
asks for a single character, I thus expect that the GF driver loads
only a single glyph...


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] Updates for gf driver.

2018-07-08 Thread Werner LEMBERG

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

00111000
0001
01101100
1010
00101000
00000000
01000100

  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.00)
  y scale: 0 (0.00)
  ascender: 0.00
  descender: 0.00
  height: 0.00
  max advance: 0.00
  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.00
  linear y advance: 0.00
  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 

Re: [ft-devel] Theme designs for the FreeType Website

2018-07-08 Thread Werner LEMBERG

> I found CMU Typewriter on fontlibrary.org, which does provide a
> server.  A little bit slower than Google Fonts, but I think the
> slight delay is OK for code snippets. Addition of Computer Modern to
> Google Fonts is pending:
> 
>   https://github.com/google/fonts/pull/1129
> 
> Once that is available, we can switch.

Very nice, thanks!  A small nit: Please adjust the font size factor of
CMU a bit to make its x height similar (or near similar) to the
x height of body font.  Hopefully, there is a CSS solution for that.

> I was tempted to change all fonts to CMU Serif for the nice TeX look
> but it took a noticeably longer time for the font to load.

Please don't.  As much as a like CMU Typewriter I actually dislike the
other CM shapes. :-)


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] Problems in GF_Glyph_Load function.

2018-07-08 Thread Parth Wazurkar
>
> > I found the buglet, it was in `gf_free_font' function. Now, it is
> > properly allocating the `bitmap' and glyph metrics,
>
> Good!
>
> > but `ftexample' is not showing the image of the glyph.  I am not
> > able to figure out why is it not showing an image.  Can you point
> > out some possible error? Please help.
>
> Right now I'm on vacation, doing some hiking in Tyrol.  Maybe today
> evening I can have a look – in case I'm not too tired.  No promises,
> sorry.
>
Ok. No problem.
Thanks.

Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] Problems in GF_Glyph_Load function.

2018-07-08 Thread Werner LEMBERG

> I found the buglet, it was in `gf_free_font' function. Now, it is
> properly allocating the `bitmap' and glyph metrics,

Good!

> but `ftexample' is not showing the image of the glyph.  I am not
> able to figure out why is it not showing an image.  Can you point
> out some possible error? Please help.

Right now I'm on vacation, doing some hiking in Tyrol.  Maybe today
evening I can have a look – in case I'm not too tired.  No promises,
sorry.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel