[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FT_Set_Char_Size() with TrueType fonts
From: |
Jeff Chow |
Subject: |
RE: FT_Set_Char_Size() with TrueType fonts |
Date: |
Tue, 31 Oct 2000 17:44:18 -0800 |
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
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE: FT_Set_Char_Size() with TrueType fonts,
Jeff Chow <=