Minor Fixes (Re: FT_Set_Char_Size() with TrueType fonts)

[YAMANO-UCHI Hidetoshi]

Hi David,

Thanks for your reply.

I read carefully the current code and your reply.
Finaly I think there are no reasons to add APIs like
FT_Set_Bitmap_Size.

* FT_Set_Pixel_Sizes may work fine on TTF without any fixes.
ftview now uses FT_Set_Pixel_Sizes and works fine.

* There are no resonable ways to calculate "cell size" for any
"proportional spacing" bitmapped font files.

* Even if we want to synthesize embedded bitmaps in TTF, it is the
problem on applications.  And we do not need providing any new APIs on
the problem.

From: David Turner <address@hidden>
Subject: Re: FT_Set_Char_Size() with TrueType fonts
Date: Tue, 31 Oct 2000 17:02:11 +0100
Message-ID: <address@hidden>

>     - 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).

I think so.

(snip)
>     - 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".

This convention is suitable for many "charcell" bitmapped font files
but not all bitmapped font files.  For example, it is not natural for
a following case.

-----
% xlsfonts -ll -fn "-adobe-times-medium-r-normal--24-240-75-75-p-124-iso8859-1"
  ascent:               20
  descent:              6
  font type:            Proportional (min and max widths not equal)
  bounds:               width left  right  asc  desc   attr   keysym
        min                6    -1     1    -3   -14  0x0000
        max               23     4    23    22     6  0x0000
  properties:           29
      PIXEL_SIZE            24
      POINT_SIZE            240
-----

In this case, "cell height" is 26 and "character height" is 24,
because it is a proportional spacing.  And "cell height" is not
suitable as "font size."

This example is a BDF font file. But some TTF font files with sbit
(e.g. MS-UI-Gothic) are proportional spacing.

Moreover, it is not good to use "cell height" on Unicode-encoded font
files having many scripts.

> 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;

I think there are no reason to change FT_Bitmap_Size.

> for a bitmapped format, we would probably return "height == cell_height"

Unfortunatly, I told the counter-example as above.

---- YAMANO-UCHI Hidetoshi

P.S.
Next part is minor fix for handling sbit.

sbit.diff
Description: Text document