Re: [ft-devel] Need clarification on font cutoff

[Werner LEMBERG]

> We are using freetype-2.8.1.  When we try to print the text
> characters, sometimes little top portion of text characters got
> stripped off.  Pixel size passed to FT library is 30. No issue is
> seen with freetype-2.5.2.

Please give an example.  Which font, which character, which hinting
mode?

> It is seen, ascent value returned from font metrics is not returned
> properly from the ttdriver.c in recent versions of freetype.

Have you seen the following entry in the `CHANGES' file for
version 2.8?

  Global size metrics values in the `FT_Size_Metrics' structure can be
  different for TrueType fonts.  Reason is that in older FreeType
  versions the metrics were rounded differently to integer pixels
  compared to all other font formats, yielding an inconsistent
  behaviour if you used non-native hinting.  Starting with this
  version, global size metrics for TrueType fonts are handled the same
  as other font formats: `ascender' gets rounded up, `descender' gets
  rounded down, `height' gets normally rounded, and `max_advance' gets
  normally rounded, too.

  If you need more precise values of (global) ascender, descender,
  height, or `max_advance', please take the corresponding values from
  the `FT_Face' structure and scale them manually.

In version 2.9 I updated the documentation for `FT_Size_Metrics' as
follows.

   TrueType fonts with native bytecode hinting
   ---

   All applications that handle TrueType fonts with native hinting
   must be aware that TTFs expect different rounding of vertical font
   dimensions.  The application has to cater for this, especially if
   it wants to rely on a TTF's vertical data (for example, to properly
   align box characters vertically).

   Only the application knows _in_ _advance_ that it is going to use
   native hinting for TTFs!  FreeType, on the other hand, selects the
   hinting mode not at the time of creating an @FT_Size object but
   much later, namely while calling @FT_Load_Glyph.

   Here is some pseudo code that illustrates a possible solution.

 font_format = FT_Get_Font_Format( face );

 if ( !strcmp( font_format, "TrueType" ) &&
  do_native_bytecode_hinting ) 
 {
   ascender  = ROUND( FT_MulFix( face->ascender,
 size_metrics->y_scale ) );
   descender = ROUND( FT_MulFix( face->descender,
 size_metrics->y_scale ) );
 }
 else
 {   
   ascender  = size_metrics->ascender;
   descender = size_metrics->descender;
 }

 height  = size_metrics->height;
 max_advance = size_metrics->max_advance;


   Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Need clarification on font cutoff

[madana gopal]

Hi Team,

We are using freetype-2.8.1. When we try to print the text characters ,
sometimes little top portion of text characters got stripped off. Pixel
size passed to FT library is 30. No issue is seen with freetype-2.5.2.

It is seen, ascent value returned from font metrics is not returned
properly from the ttdriver.c in recent versions of freetype. Please find
the code part below:

*  static FT_Error*
*  tt_size_request( FT_Size  size,*
*   FT_Size_Request  req )*
*  {*
*...*
*if ( FT_IS_SCALABLE( size->face ) )*
*{*
*  error = tt_size_reset( ttsize, 0 ); //few metrics parameters like
ascent etc are changed locally in tt_size_reset() function, but not
updating the global size metrics. So, updates not getting reflected in
caller*
*  *
*}*
* }*

There is a line to update this in version 2.5.2.  It looks this removal
happened as part of commit *bcc74f4dafee25ea89f1d3144646cba7e30f9908*. Do
we have any specific reason for this removal?. Please clarify this.

Thanks.

Regards,
Madan
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Problems with gfdriver in ftview.

[Parth Wazurkar]

>
> >> Well, simply follow the documentation, i.e., set `pitch' to
> >>
> >>   w + 7) / 8) + 1) / 2) * 2
> >>
> >> (but with some better C code :-) and use this value for creating
> >> the bitmap.
> >
> > Ok, I did change the value of pitch (6) and tried to draw `a', it is
> > giving a wrong glyph, then I changed the value to previous value(5),
> > it drew a correct one.  I think that this might be the problem, that
> > gf uses odd pitch value to draw glyph and ftview requires a even
> > one?
>
> With `set the pitch' I mean of course that you also adjust the code to
> insert a trailing null byte each line *in the output buffer* if the
> number of input bytes per line is uneven...
>

Oh, I get it! Thanks.

Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel