[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minor Fixes (Re: FT_Set_Char_Size() with TrueType fonts)
From: |
YAMANO-UCHI Hidetoshi |
Subject: |
Minor Fixes (Re: FT_Set_Char_Size() with TrueType fonts) |
Date: |
Sun, 05 Nov 2000 14:03:30 +0900 |
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
- Minor Fixes (Re: FT_Set_Char_Size() with TrueType fonts),
YAMANO-UCHI Hidetoshi <=