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

[David Turner]

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