date:20180810

Re: [ft-devel] Tiny Docs Patch

2018-08-10 Thread Werner LEMBERG



> I suggest this tiny patch in the documentation of the driver properties:
> 
> ```
> diff --git a/include/freetype/ftdriver.h b/include/freetype/ftdriver.h
> index 2384dc61..c893c545 100644
> --- a/include/freetype/ftdriver.h
> +++ b/include/freetype/ftdriver.h
> @@ -383,7 +383,7 @@ FT_BEGIN_HEADER
> *
> *   {
> * FT_Library  library;
> -   * FT_UInt hinting_engine = FT_CFF_HINTING_ADOBE;
> +   * FT_UInt hinting_engine = FT_HINTING_ADOBE;
> *
> *
> * FT_Init_FreeType(  );
> '''
> 
> As stated above in line 348: `FT_CFF_HINTING_ADOBE' is deprecated.

Please apply to git (without ChangeLog entry)!  BTW, no need to
contact `freetype-devel' for such trivial documentation fixes.


   Werner

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

[ft-devel] Tiny Docs Patch

2018-08-10 Thread armin

I suggest this tiny patch in the documentation of the driver properties:

```
diff --git a/include/freetype/ftdriver.h b/include/freetype/ftdriver.h
index 2384dc61..c893c545 100644
--- a/include/freetype/ftdriver.h
+++ b/include/freetype/ftdriver.h
@@ -383,7 +383,7 @@ FT_BEGIN_HEADER
*
*   {
* FT_Library  library;
-   * FT_UInt hinting_engine = FT_CFF_HINTING_ADOBE;
+   * FT_UInt hinting_engine = FT_HINTING_ADOBE;
*
*
* FT_Init_FreeType(  );
'''

As stated above in line 348: `FT_CFF_HINTING_ADOBE' is deprecated.


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

[ft-devel] Docwriter update: Docwriter 1.0 is out!

2018-08-10 Thread Nikhil Ramakrishnan

Hi all,

MkDocs 1.0 was just released and the directory structure was finally
fixed! This means that all links are now `docs/reference/page.html'
instead of `docs/reference/page/index.html'. With this, the docs are
now organized nicely in a single directory.

I've released docwriter 1.0 with the required changes to support MkDocs
>= 1.0. The changes are detailed at


https://github.com/freetype/docwriter/commit/195c25e8e786ca3957c6a3c30b0f9bedad45ad87

I've updated the demo site at

  https://nikramakrishnan.github.io/freetype-web-jekyll/docs/reference

We're also ready to convert the header files to markdown, and this will
be done within a few days!


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

Re: [ft-devel] (no subject)

2018-08-10 Thread Nikhil Ramakrishnan

> Ah, this is the result of Emacs's `adaptive fill mode' that
> automatically determines the fill prefix of paragraphs.  Setting the
> corresponding regexp explicitly fixes this.  Attached is a patch – it
> fixes some more places.
>

Great, this fixes it.

Meanwhile, I had a look at the complete diff, and I'm attaching the cases
that will need to be fixed manually, Other than these, I think we're now
ready to convert to markdown, and apply your code to normalize lines.


-- 
Nikhil


problems.diff
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] success?

2018-08-10 Thread Parth Wazurkar

>
> >> But, even after setting all the metric values and bitmap, it is not
> >> displaying a glyph in `ftview' and just displaying a blank output.
>
> Thanks to your new branch in `freetype2-demos' I can finally test the
> GF+TFM combo...
>
> Assuming that you are running a GNU/Linux box: Have you ever used
> `valgrind', as I've recommended to you a few times?
>

Yes I have :-), Also if you see the `cleaned' branch and debug it with
`valgrind'
you will find it completely error free. These errors by `valgrind' are
reported
after I changed the logic to load bitmaps on demand, and as reported by you
because of the double free in `tfm module'. Sorry for that, I'll fix it :-)

  FT2_DEBUG=any:7 valgrind ./ftview 20 cmr10.600gf &> cmr10.600gf.log
>
> Doing this you can immediately see in `cmr10.600gf.log' that there is
> a double free:
>
>   ...
>   TFM_Read_Metrics: TFM Metric Information:
> Check Sum  : 1274110073
> Design Size: 10
> Begin Char : 0
> End Char   : 127
> font_bbx_w : 10
> font_bbx_h : 10
> slant  : 0
>   Invalid read of size 8
>  at 0x412F6D: FT_Stream_Free (ftobjs.c:251)
>  by 0x41718E: FT_Attach_Stream (ftobjs.c:2711)
>  by 0x417089: FT_Attach_File (ftobjs.c:2672)
>  by 0x40A756: my_face_requester (ftcommon.c:267)
>  by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
>  by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
>  by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
>  by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
>  by 0x406FC4: event_font_change (ftview.c:1039)
>  by 0x408C10: main (ftview.c:1904)
>Address 0x79a80c8 is 56 bytes inside a block of size 80 free'd
>  at 0x4C2B35C: free (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
>  by 0x4DF876: ft_free (ftsystem.c:138)
>  by 0x42256C: ft_mem_free (ftutil.c:174)
>  by 0x4DDE84: tfm_close (tfmobjs.c:136)
>  by 0x47F8F1: TFM_Read_Metrics (gfdrivr.c:511)
>  by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
>  by 0x417089: FT_Attach_File (ftobjs.c:2672)
>  by 0x40A756: my_face_requester (ftcommon.c:267)
>  by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
>  by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
>  by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
>  by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
>Block was alloc'd at
>  at 0x4C2A110: malloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
>  by 0x4DF82B: ft_alloc (ftsystem.c:76)
>  by 0x42229F: ft_mem_qalloc (ftutil.c:76)
>  by 0x40: ft_mem_alloc (ftutil.c:55)
>  by 0x412E2C: FT_Stream_New (ftobjs.c:197)
>  by 0x41710B: FT_Attach_Stream (ftobjs.c:2698)
>  by 0x417089: FT_Attach_File (ftobjs.c:2672)
>  by 0x40A756: my_face_requester (ftcommon.c:267)
>  by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
>  by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
>  by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
>  by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
>
> `FT_Attach_Stream' frees the stream passed as an argument to
> `TFM_Read_Metrics' by itself.  While you have modeled your code after
> `afm_parser_init', you've missed that this function allocates a new
> stream but your code doesn't.  This means that in `tfm_close' you must
> not close the stream since this happens later on.


> Applying this fix
>
>   diff --git a/src/tfm/tfmobjs.c b/src/tfm/tfmobjs.c
>   index 8cd3b5bf5..c03873e7a 100644
>   --- a/src/tfm/tfmobjs.c
>   +++ b/src/tfm/tfmobjs.c
>   @@ -131,9 +131,10 @@
>  FT_LOCAL( void )
>  tfm_close( TFM_Parser  parser )
>  {
>   -FT_Memory  memory = parser->memory;
>   +FT_UNUSED( parser );
>
>   -FT_FREE( parser->stream );
>   +
>   +/* nothing */
>  }
>
> helps.
>

Done!


>
> Note that there are still memory leaks in your driver.
>
>   FT2_DEBUG=any:7 \
>   valgrind --leak-check=full \
>--show-leak-kinds=all \
>./ftview 20 cmr10.600gf
>
>   80 bytes in 1 blocks are definitely lost in loss record 42 of 73
>  at 0x4C2C240: calloc (in /usr/lib64/valgrind/vgpreload_
> memcheck-amd64-linux.so)
>  by 0x4DE498: tfm_parse_metrics (tfmobjs.c:282)
>  by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
>  by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
>  by 0x417089: FT_Attach_File (ftobjs.c:2672)
>  by 0x40A756: my_face_requester (ftcommon.c:267)
>  by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
>  by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
>  by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
>  by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
>  by 0x406FC4: event_font_change (ftview.c:1039)
>  by 0x408C10: main (ftview.c:1904)
>
>   128 bytes in 1 blocks are definitely lost in loss record 44 of 73
>  at 0x4C2C240: calloc (in

[ft-devel] processing TFM metric data

2018-08-10 Thread Werner LEMBERG


Parth,


now that parsing of TFM data works, you should do something with the
data: Please fill `slot->linearHoriAdvance' – the TFM data is not
specific to a pixel size, it thus makes sense to provide this field
(this has to be documented later on).  Similarly, the `slot->metric'
data should be updated to use the TFM values if they are present.


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

Re: [ft-devel] success?

2018-08-10 Thread Werner LEMBERG



>   FT2_DEBUG=any:7 valgrind ./ftview 20 cmr10.600gf &> cmr10.600gf.log

For other people reading this I forgot to mention that you need
`cmr10.tfm' in the same directory as `cmr10.600gf' to see the
problems.


Werner

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

Re: [ft-devel] success?

2018-08-10 Thread Werner LEMBERG


>> But, even after setting all the metric values and bitmap, it is not
>> displaying a glyph in `ftview' and just displaying a blank output.

Thanks to your new branch in `freetype2-demos' I can finally test the
GF+TFM combo...

Assuming that you are running a GNU/Linux box: Have you ever used
`valgrind', as I've recommended to you a few times?

  FT2_DEBUG=any:7 valgrind ./ftview 20 cmr10.600gf &> cmr10.600gf.log

Doing this you can immediately see in `cmr10.600gf.log' that there is
a double free:

  ...
  TFM_Read_Metrics: TFM Metric Information:
Check Sum  : 1274110073
Design Size: 10
Begin Char : 0
End Char   : 127
font_bbx_w : 10
font_bbx_h : 10
slant  : 0
  Invalid read of size 8
 at 0x412F6D: FT_Stream_Free (ftobjs.c:251)
 by 0x41718E: FT_Attach_Stream (ftobjs.c:2711)
 by 0x417089: FT_Attach_File (ftobjs.c:2672)
 by 0x40A756: my_face_requester (ftcommon.c:267)
 by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
 by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
 by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
 by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
 by 0x406FC4: event_font_change (ftview.c:1039)
 by 0x408C10: main (ftview.c:1904)
   Address 0x79a80c8 is 56 bytes inside a block of size 80 free'd
 at 0x4C2B35C: free (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 by 0x4DF876: ft_free (ftsystem.c:138)
 by 0x42256C: ft_mem_free (ftutil.c:174)
 by 0x4DDE84: tfm_close (tfmobjs.c:136)
 by 0x47F8F1: TFM_Read_Metrics (gfdrivr.c:511)
 by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
 by 0x417089: FT_Attach_File (ftobjs.c:2672)
 by 0x40A756: my_face_requester (ftcommon.c:267)
 by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
 by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
 by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
 by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
   Block was alloc'd at
 at 0x4C2A110: malloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 by 0x4DF82B: ft_alloc (ftsystem.c:76)
 by 0x42229F: ft_mem_qalloc (ftutil.c:76)
 by 0x40: ft_mem_alloc (ftutil.c:55)
 by 0x412E2C: FT_Stream_New (ftobjs.c:197)
 by 0x41710B: FT_Attach_Stream (ftobjs.c:2698)
 by 0x417089: FT_Attach_File (ftobjs.c:2672)
 by 0x40A756: my_face_requester (ftcommon.c:267)
 by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
 by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
 by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
 by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)

`FT_Attach_Stream' frees the stream passed as an argument to
`TFM_Read_Metrics' by itself.  While you have modeled your code after
`afm_parser_init', you've missed that this function allocates a new
stream but your code doesn't.  This means that in `tfm_close' you must
not close the stream since this happens later on.

Applying this fix

  diff --git a/src/tfm/tfmobjs.c b/src/tfm/tfmobjs.c
  index 8cd3b5bf5..c03873e7a 100644
  --- a/src/tfm/tfmobjs.c
  +++ b/src/tfm/tfmobjs.c
  @@ -131,9 +131,10 @@
 FT_LOCAL( void )
 tfm_close( TFM_Parser  parser )
 {
  -FT_Memory  memory = parser->memory;
  +FT_UNUSED( parser );
 
  -FT_FREE( parser->stream );
  +
  +/* nothing */
 }

helps.

Note that there are still memory leaks in your driver.

  FT2_DEBUG=any:7 \
  valgrind --leak-check=full \
   --show-leak-kinds=all \
   ./ftview 20 cmr10.600gf

  80 bytes in 1 blocks are definitely lost in loss record 42 of 73
 at 0x4C2C240: calloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 by 0x4DE498: tfm_parse_metrics (tfmobjs.c:282)
 by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
 by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
 by 0x417089: FT_Attach_File (ftobjs.c:2672)
 by 0x40A756: my_face_requester (ftcommon.c:267)
 by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
 by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
 by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
 by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
 by 0x406FC4: event_font_change (ftview.c:1039)
 by 0x408C10: main (ftview.c:1904)

  128 bytes in 1 blocks are definitely lost in loss record 44 of 73
 at 0x4C2C240: calloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 by 0x4DE480: tfm_parse_metrics (tfmobjs.c:281)
 by 0x47F85E: TFM_Read_Metrics (gfdrivr.c:497)
 by 0x417154: FT_Attach_Stream (ftobjs.c:2708)
 by 0x417089: FT_Attach_File (ftobjs.c:2672)
 by 0x40A756: my_face_requester (ftcommon.c:267)
 by 0x4BC018: ftc_face_node_init (ftcmanag.c:243)
 by 0x4BCD50: FTC_MruList_New (ftcmru.c:269)
 by 0x4BC201: FTC_Manager_LookupFace (ftcmanag.c:325)
 by 0x40B0FC: FTDemo_Set_Current_Font (ftcommon.c:551)
 by 0x406FC4:

Re: [ft-devel] Tiny Docs Patch

[ft-devel] Tiny Docs Patch

[ft-devel] Docwriter update: Docwriter 1.0 is out!

Re: [ft-devel] (no subject)

Re: [ft-devel] success?

[ft-devel] processing TFM metric data

Re: [ft-devel] success?

Re: [ft-devel] success?

8 matches

Site Navigation

Mail list logo

Footer information