RE: FT_Set_Char_Size() with TrueType fonts

[Jeff Chow]

Hi David and Yamano-Uchi,

Does this mean that eventually we will eventually be able to rasterize
truetype fonts into arbitrary bitmap sizes? We're using FreeType to generate
character glyphs in a fixed-sized cell format, and if the glyphs render
larger
than the bitmap dimensions, it's really no good for us..

Thanks again,
Jeff

> -----Original Message-----
> From: David Turner [mailto:address@hidden
> Sent: Tuesday, October 31, 2000 8:02 AM
> To: Yamano-uchi; Hidetoshi
> Cc: address@hidden
> Subject: Re: FT_Set_Char_Size() with TrueType fonts
> 
> 
> Hi Yamano-Uchi,
> 
>   I'm beginning to wonder wether I correctly understood you ?!
>   Could you tell me if the following is correct:
> 
>     - there is a difference between what is called the 
> "character size"
>       of scalable formats, and the "cell size" of most 
> bitmapped formats
> 
>       in one hand, the "character size" is the size of the EM square,
>       be it expressed in pixels, points, mm, etc.. it's not directly
>       related to the pixel dimensions of the bitmaps embedded in a
>       TrueType font.
> 
>       on the other hand, most bitmap formats use "cells" of constant
> height
>       to store glyph images. this "cell height" is normally the sum of
> the
>       ascent and descent metrics for a given "character size".
> 
>     - FT_Set_Char_Size and FT_Set_Pixel_Sizes are only used to set the
>       "character size" of fonts (specifying it either in points or
> pixels).
> 
>       the original reason why there are to distinct functions 
> to perform
> what
>       is basically the same thing, comes from small oddities that I
> won't
>       explain there (some stupid flag in the font header + some weird
> opcode
>       definned to retrieve the character size in _points_ and 
> push it on
> the
>       stack).
>     
>     - I now believe that you'd like a function that let's you select
>       bitmap strikes according to their "cell height", rather 
> than their
>       "character size".
> 
> If this is so, I propose to introduce a new function rather than
> modifying the
> existing one. Choosing a good name to avoid ambiguity being 
> important, I
> would
> propose something like:
> 
>   /*******************************************************************
>    *
>    * <Function> FT_Set_Bitmap_Cell_Size
>    *
>    * <Description>
>    *    chooses a given size for a face containing bitmaps,
>    *    based on the bitmap cell height.
>    *
>    * <Input>
>    *    face   :: handle to target face object
>    *    width  :: cell width in integer pixels. 0 means ignore
>    *    height :: cell height in integer pixels
>    *
>    * <Return>
>    *    Error code. non-0 if the face doesn't contain a bitmap strike
>    *    of the relevant cell height
>    *
>    * <Note>
>    *    this function can also be used on a scalable face, as long
>    *    as it provides embedded bitmaps for the relevant dimensions
>    */
>    FT_EXPORT_DEF( FT_Error )   FT_Set_Bitmap_Cell_Size( FT_Face  face,
>                                                         
> FT_UInt  width,
>                                                         
> FT_UInt  height
> );
> 
> there is also the problem of knowing what cell sizes are present in a
> font. By default, "face->available_sizes" returns a table of character
> sizes for scalable formats like TrueType, and of cell sizes for the
> "winfonts" driver.
> 
> Maybe we could change FT_Bitmap_Size to
> 
>   typedef struct FT_Bitmap_Size_
>   {
>      FT_UShort  height;       /* character height */
>      FT_UShort  width;        /* character width  */
>      FT_UShort  cell_height;  /* cell height      */
> 
>   } FT_Bitmap_Size;
> 
> for a bitmapped format, we would probably return "height == 
> cell_height"
> == cell_height"
> 
> I'd like your input on this topic ??
> 
> Cheers,
> 
> - David
> 
> 
> "Yamano-uchi, Hidetoshi ($@;3Fb(J address@hidden(J)" a écrit :
> > 
> > This problem is for embedded bitmaps(a.k.a. sbit) but not 
> for handling
> > collect "face (x-)height" as David said.
> > 
> > From: Werner LEMBERG <address@hidden>
> > Subject: Re: FT_Set_Char_Size() with TrueType fonts
> > Date: Tue, 31 Oct 2000 14:29:45 +0100 (CET)
> > Message-ID: <address@hidden>
> > 
> > > > or in the derivative SFNT-based format that only 
> contains embedded
> > > > bitmaps, that we now support thanks to Yamano-Uchi's excellent
> > > > work..?
> > >
> > > The former -- Hidetoshi has explained that he needs to 
> set the size of
> > > embedded bitmaps independently from the font's outlines.
> > 
> > But now, I think we should open other face like following style when
> > sbit's size does not depend on outline's size.  Because many
> > developpers may confuse the convention as I said.
> > 
> > FT_New_Face(library, &outline_face, same_filename);
> > FT_New_Face(library, &sbit_face, same_filename);
> > 
> > FT_Set_Char_Sizes(outline_face, outline_si
> ze,....);
> > // Set_Pixel_Sizes is not impremented yet.
> > FT_Set_Pixel_Sizes(sbit_face, sbit_size,....);
> > 
> > FT_Load_Glyph(outline_face, index1, FT_LOAD_NO_BITMAP);
> > FT_Load_Glyph(sbit_face, index2, FT_LOAD_NO_OUTLINE);
> > 
> > // synthesys double striked(i.e. psude-bolding) sbit.
> > .....
> > 
> > Oops, it is difficult for me.
> > 
> > ----- Yamano-uchi, Hidetoshi
>