我正在尝试使用FreeType v2.6.3在C＃中工作。除了渲染部分，我得到了一切工作。
Font.cs（FreeType.Render_Glyph）
FreeType.Load_Glyph(facePtr, index, FreeType.FT_LOAD_DEFAULT | FreeType.FT_LOAD_TARGET_NORMAL);
FaceRec faceRec = (FaceRec)Marshal.PtrToStructure(facePtr, typeof(FaceRec));
FreeType.Render_Glyph(faceRec.glyph, FreeType.FT_RENDER_MODE_NORMAL);
GlyphSlotRec glyphRec = (GlyphSlotRec)Marshal.PtrToStructure(faceRec.glyph, typeof(GlyphSlotRec));
这会调用DllImport FreeType.cs
public static int Render_Glyph(IntPtr slot, int render_mode)
{
return FT_Render_Glyph(slot, render_mode);
}
[DllImport("freetype263.dll", CallingConvention = CallingConvention.Cdecl)]
private static extern int FT_Render_Glyph(IntPtr slot, int render_mode);
C代码freetype.h
/*************************************************************************/
/* */
/* <Function> */
/* FT_Render_Glyph */
/* */
/* <Description> */
/* Convert a given glyph image to a bitmap. It does so by inspecting */
/* the glyph image format, finding the relevant renderer, and */
/* invoking it. */
/* */
/* <InOut> */
/* slot :: A handle to the glyph slot containing the image to */
/* convert. */
/* */
/* <Input> */
/* render_mode :: This is the render mode used to render the glyph */
/* image into a bitmap. See @FT_Render_Mode for a */
/* list of possible values. */
/* */
/* <Return> */
/* FreeType error code. 0~means success. */
/* */
/* <Note> */
/* To get meaningful results, font scaling values must be set with */
/* functions like @FT_Set_Char_Size before calling FT_Render_Glyph. */
/* */
/* When FreeType outputs a bitmap of a glyph, it really outputs an */
/* alpha coverage map. If a pixel is completely covered by a */
/* filled-in outline, the bitmap contains 0xFF at that pixel, meaning */
/* that 0xFF/0xFF fraction of that pixel is covered, meaning the */
/* pixel is 100% black (or 0% bright). If a pixel is only 50% */
/* covered (value 0x80), the pixel is made 50% black (50% bright or a */
/* middle shade of grey). 0% covered means 0% black (100% bright or */
/* white). */
/* */
/* On high-DPI screens like on smartphones and tablets, the pixels */
/* are so small that their chance of being completely covered and */
/* therefore completely black are fairly good. On the low-DPI */
/* screens, however, the situation is different. The pixels are too */
/* large for most of the details of a glyph and shades of gray are */
/* the norm rather than the exception. */
/* */
/* This is relevant because all our screens have a second problem: */
/* they are not linear. 1~+~1 is not~2. Twice the value does not */
/* result in twice the brightness. When a pixel is only 50% covered, */
/* the coverage map says 50% black, and this translates to a pixel */
/* value of 128 when you use 8~bits per channel (0-255). However, */
/* this does not translate to 50% brightness for that pixel on our */
/* sRGB and gamma~2.2 screens. Due to their non-linearity, they */
/* dwell longer in the darks and only a pixel value of about 186 */
/* results in 50% brightness – 128 ends up too dark on both bright */
/* and dark backgrounds. The net result is that dark text looks */
/* burnt-out, pixely and blotchy on bright background, bright text */
/* too frail on dark backgrounds, and colored text on colored */
/* background (for example, red on green) seems to have dark halos or */
/* `dirt' around it. The situation is especially ugly for diagonal */
/* stems like in `w' glyph shapes where the quality of FreeType's */
/* anti-aliasing depends on the correct display of grays. On */
/* high-DPI screens where smaller, fully black pixels reign supreme, */
/* this doesn't matter, but on our low-DPI screens with all the gray */
/* shades, it does. 0% and 100% brightness are the same things in */
/* linear and non-linear space, just all the shades in-between */
/* aren't. */
/* */
/* The blending function for placing text over a background is */
/* */
/* { */
/* dst = alpha * src + (1 - alpha) * dst , */
/* } */
/* */
/* which is known as the OVER operator. */
/* */
/* To correctly composite an antialiased pixel of a glyph onto a */
/* surface, */
/* */
/* 1. take the foreground and background colors (e.g., in sRGB space) */
/* and apply gamma to get them in a linear space, */
/* */
/* 2. use OVER to blend the two linear colors using the glyph pixel */
/* as the alpha value (remember, the glyph bitmap is an alpha */
/* coverage bitmap), and */
/* */
/* 3. apply inverse gamma to the blended pixel and write it back to */
/* the image. */
/* */
/* Internal testing at Adobe found that a target inverse gamma of~1.8 */
/* for step~3 gives good results across a wide range of displays with */
/* an sRGB gamma curve or a similar one. */
/* */
/* This process can cost performance. There is an approximation that */
/* does not need to know about the background color; see */
/* https://bel.fi/alankila/lcd/ and */
/* https://bel.fi/alankila/lcd/alpcor.html for details. */
/* */
/* *ATTENTION*: Linear blending is even more important when dealing */
/* with subpixel-rendered glyphs to prevent color-fringing! A */
/* subpixel-rendered glyph must first be filtered with a filter that */
/* gives equal weight to the three color primaries and does not */
/* exceed a sum of 0x100, see section @lcd_filtering. Then the */
/* only difference to gray linear blending is that subpixel-rendered */
/* linear blending is done 3~times per pixel: red foreground subpixel */
/* to red background subpixel and so on for green and blue. */
/* */
FT_EXPORT( FT_Error )
FT_Render_Glyph( FT_GlyphSlot slot,
FT_Render_Mode render_mode );
有没有人知道我做错了什么？