[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Minor Fixes (Re: FT_Set_Char_Size() with TrueType fonts)
From: |
David Turner |
Subject: |
Re: Minor Fixes (Re: FT_Set_Char_Size() with TrueType fonts) |
Date: |
Mon, 06 Nov 2000 19:12:53 +0100 |
Hi Yamano-Ucih,
I'm really happy we're finally understanding each one's point of view..
>
> (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.
>
>
> I think there are no reason to change FT_Bitmap_Size.
>
All right, thanks a lot for the examples. I think however that some
applications will need to access the "cell height" (for example, when
implementing an emulator).
I'm pretty certain that this won't come for the 2.0 release :-) But
what would be, in your opinion, a good API, to select it ?? It'd be
interesting to see some comments regarding this "feature" on this
list..
> > for a bitmapped format, we would probably return "height == cell_height"
>
> Unfortunatly, I told the counter-example as above.
>
OK :-)
>
> P.S.
> Next part is minor fix for handling sbit.
>
Thanks a lot for the fix, I've applied it to the source tree, though it
has been a bit hard due to our latest reformatting changes. I'd like to
point out a few changes I've performed:
- You introduced a new field named "driver" in the public "FT_SizeRec"
structure. I have move it to the private "TT_SizeRec" under the name
"strike_metrics", since I couldn't understand why you needed it in
the public part of the API (under an opaque pointer).
by the way, I've introduced changes lately to the public classes
FT_FaceRec, FT_SizeRec and FT_GlyphSlotRec, in order to add a new
public field named "internal". It's an opaque pointer to a block
of private data for the object. For example, the following FT_FaceRec
fields have moved to "internal":
max_points, max_contours, transform_matrix, transform_offset,
etc..
The idea is that the content of "internal" can change between releases
of FreeType without risking breaking binary compatibility with client
applications or font modules (the latter wouldn't be possible if we
had moved the "internal" fields to a sub-class of FT_FaceRec)
- I have somewhat changed the fields of TT_SizeRec related to embedded
bitmaps, there is now "strike_index", which defaults to 0xFFFF to indicate
"no selected strike", and "strike_metrics", which contains your old
"driver".
I have only tested the changes with TrueType fonts containing embedded
bitmaps. I'm sorry I'm missing the time to check that it works well with
sfnt-based sbit fonts. Could you please test it ??
And again, a great thanks for your work,
- David
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------
> Name: sbit.diff
> sbit.diff Type: Plain Text (Text/Plain)
> Encoding: 7bit