some freetype 2 questions (and a patch)

[Toby J Sargeant]

Hi,

I'm playing around with decomposing outline into spans, and I've come across
some issues which it would be good to have clarified.

Firstly, is there any difference between the outline member stored in
the glyph slot, and the outline stored in a glyph retrieved with
FT_Get_Glyph() on that outline? I ask, because the following python code:

ft_face.loadGlyph(glyph).glyph.outline.decompose(ft_lib)
ft_face.loadGlyph(glyph).glyph.getGlyph().outline.decompose(ft_lib)

which i would have expected would do the same thing twice, appears to
have different results. when i dump the outline, as it's decomposed, i get
the following:

outline at 0x808fc18:
1 contours, 55 points, flags: 00000000
points:  155,-64 [19] 125,-64 [00] 85,-64 [11] 12,-64 [19] 16,-53 [00] 39,-14 
[00] 44,-3 [01] 68,58 [00] 84,109 [01] 90,130 [00] 103,171 [09] 103,192 [19] 
83,192 [11] 79,192 [00] 67,188 [01] 50,184 [00] 45,175 [01] 43,168 [00] 41,160 
[01] 38,152 [00] 24,149 [19] 24,173 [09] 24,173 [00] 32,198 [00] 32,215 [09] 
32,221 [00] 30,238 [00] 30,243 [09] 30,244 [00] 34,256 [11] 57,256 [11] 100,256 
[00] 148,256 [19] 143,240 [00] 129,213 [01] 114,184 [00] 108,170 [01] 93,131 
[00] 79,86 [01] 56,18 [00] 57,0 [19] 96,0 [11] 111,0 [00] 120,9 [01] 128,19 
[00] 128,30 [09] 128,39 [09] 127,56 [00] 139,66 [11] 150,66 [19] 150,52 [09] 
150,49 [00] 143,17 [00] 143,2 [09] 143,-18 [00]
contours:  54
cbox: 0 -64 192 256
SPAN: 0 - 3 spans
SPAN: 1 - 3 spans
SPAN: 2 - 2 spans
SPAN: 3 - 2 spans
SPAN: 4 - 3 spans

outline at 0x80a0158:
1 contours, 55 points, flags: 00000001
points:  155,-64 [50] 125,-64 [ec] 85,-64 [18] 12,-64 [40] 16,-53 [50] 39,-14 
[ec] 44,-3 [18] 68,58 [40] 84,109 [01] 90,130 [00] 103,171 [09] 103,192 [19] 
83,192 [11] 79,192 [00] 67,188 [01] 50,184 [00] 45,175 [01] 43,168 [00] 41,160 
[01] 38,152 [00] 24,149 [19] 24,173 [09] 24,173 [00] 32,198 [00] 32,215 [09] 
32,221 [00] 30,238 [00] 30,243 [09] 30,244 [00] 34,256 [11] 57,256 [11] 100,256 
[00] 148,256 [19] 143,240 [00] 129,213 [01] 114,184 [00] 108,170 [01] 93,131 
[00] 79,86 [01] 56,18 [00] 57,0 [19] 96,0 [11] 111,0 [00] 120,9 [01] 128,19 
[00] 128,30 [09] 128,39 [09] 127,56 [00] 139,66 [11] 150,66 [19] 150,52 [09] 
150,49 [00] 143,17 [00] 143,2 [09] 143,-18 [00]
contours:  -26928
cbox: 0 -64 192 256
Traceback (innermost last):
  File "decompose.py", line 21, in ?
    ft_face.loadGlyph(glyph).glyph.getGlyph().outline.decompose(ft_lib)
ft2_interface.error: (20, 'invalid outline')

For a bit of context, loadGlyph calls FT_Load_Glyph and returns the
face object. so, ft_face.loadGlyph(glyph).glyph.outline loads the glyph,
and returns the outline member of the face glyph slot. decompose()
calls FT_Outline_Render() after setting up render params to render into
a span buffer rather than a bitmap.

getGlyph() is an equivalent to FT_Get_Glyph(), and it returns an
FT_Glyph object, so getGlyph().outline should be the glyph outline.

also, would it be possible to make FT_Outline_Render ignore the bitmap.buffer
member when rendering direct? I only use the bitmap to pass dummy size
information, but I have to do the following:

  bmp.buffer=(unsigned char *)1;
  //bmp.buffer=NULL;

In order to stop FT_Outline_Render() returning FT_Invalid_Outline(!).

Toby.

lastly, here's a patch for fterror.h. I use fterror.h in a rather nonstandard
way to build a case statement that converts from ft error code to ft error
string, and also to expose the ft errors to python.
The extern "C" {} stuff gets in the way when I do this. I appreciate that
there are cases where it's needed, but I think that for the non default
case it should be the responsibility of the includer, rather than the include
file itself. thus:

diff -w -B -u -r1.10 fterrors.h
--- fterrors.h  2000/09/15 22:50:57     1.10
+++ fterrors.h  2000/09/26 23:10:48
@@ -44,10 +44,8 @@
 #define FTERRORS_H
 
 
-#ifdef __cplusplus
-  extern "C" {
-#endif
 
+#undef NEED_CLOSE_EXTERN__
 
 #ifndef FT_ERRORDEF
 
@@ -55,6 +53,11 @@
 #define FT_ERROR_START_LIST     enum {
 #define FT_ERROR_END_LIST       FT_Err_Max };
 
+
+#ifdef __cplusplus
+#define NEED_CLOSE_EXTERN__
+  extern "C" {
+#endif
 #endif /* !FT_ERRORDEF */
 
 
@@ -184,7 +187,7 @@
 #undef FT_ERRORDEF
 
 
-#ifdef __cplusplus
+#ifdef NEED_CLOSE_EXTERN__
   }
 #endif