Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Infinality



I wonder whether we should do the same for non-TrueType fonts.  I think
yes, but please comment!


Are there any known TTF fonts where the hinting is impacted (positively 
or negatively) by this change?  I had a version of Inconsolata Bold that 
looked like crap after this change, but it turns out it was a known 
hinting issue that was fixed in a more recent version of it.


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


Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Werner LEMBERG
 I wonder whether we should do the same for non-TrueType fonts.  I
 think yes, but please comment!
 
 Are there any known TTF fonts where the hinting is impacted
 (positively or negatively) by this change?

No, this change is not related to hinting at all.  It affects *all*
TrueType fonts regardless of hinting.


Werner

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


Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Werner LEMBERG

 I was just wondering if we have any examples of real-world, visual
 impact of the change, whether that's on hinting or something else.

Oops, it's not

  FT_Face-height

but

  FT_Face-size-metrics-height

which gets computed differently now.  Sorry for the confusion.

All programs which use this value are affected, for example ftview.


Werner

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


Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Infinality



I wonder whether we should do the same for non-TrueType fonts.  I
think yes, but please comment!

Are there any known TTF fonts where the hinting is impacted
(positively or negatively) by this change?

No, this change is not related to hinting at all.  It affects *all*
TrueType fonts regardless of hinting.


Understood...  I was just wondering if we have any examples of 
real-world, visual impact of the change, whether that's on hinting or 
something else.


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


Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread David Turner
2013/1/23 Werner LEMBERG w...@gnu.org


 Folks,


 just a heads-up which might influence applications: I've just fixed a
 bug in the TrueType handler to correctly compute the `height' value of
 the `FT_Face' structure.  Up to now, the following was done:

   ascender_int = round(ascender_26.6);
   descender_int = round(descender_26.6);
   height_int = round(height_26.6);

 This has been replaced with

   ascender_int = round(ascender_26.6);
   descender_int = round(descender_26.6);
   height_int = ascender_int - descender_int;


This seems to assume that height_26.6 was always ascender_26.6 + -
descender_26.6. I'm not sure this is always true. IIRC, there are fonts
where the line height is actually different from ascender - descender, they
would be affected by this patch in surprising ways.

Unless I'm missing something (which is entirely possible, and I've not
looked at the patch details yet).

If that so, maybe add some code to deal with this, e.g.:

  if (height_26.6 == ascender_26.6 - descender_26.6) {
height_int = ascender_int - descender_int;
  } else {
// something else, to be defined :-)
  }



 to be in sync with Windows.

 I wonder whether we should do the same for non-TrueType fonts.  I think
 yes, but please comment!


 Werner

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

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


Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Alexei Podtelezhnikov
On Wed, Jan 23, 2013 at 11:10 AM, David Turner da...@freetype.org wrote:
 Unless I'm missing something (which is entirely possible, and I've not
 looked at the patch details yet).

 If that so, maybe add some code to deal with this, e.g.:

   if (height_26.6 == ascender_26.6 - descender_26.6) {
 height_int = ascender_int - descender_int;
   } else {
 // something else, to be defined :-)
   }

 to be in sync with Windows.

Windows does that *regardless* of any condition!

Original metrics do not add up:
https://bugs.webkit.org/show_bug.cgi?id=102374#c29
Rounded metrics do: https://bugs.webkit.org/show_bug.cgi?id=102374#c31

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


Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Werner LEMBERG

 I wonder whether we should do the same for non-TrueType fonts.  I
 think yes, but please comment!
 
 With TrueType fonts, one expects Windows-like behavior.  With
 others, one does not.  That said, there is a virtue in consistency.
 Either way, man.

If you look at the code for a single glyph,
`ft_glyphslot_grid_fit_metrics' in `ftobjs.c', you can see that we
indeed add ceiled and floored values.  However, for the global size
metrics (in function `ft_recompute_scaled_metrics'), we don't do
that...

On the other hand, David is right: For some non-TrueType font formats,
`height' is not always `ascender - descender' (cf. cffobjs.c:752, for
example).

So probably the current behaviour is the right one, or we indeed add
the guard David has suggested.  Tricky, tricky.


Werner

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


Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Werner LEMBERG
 This has been replaced with

   ascender_int = round(ascender_26.6);
   descender_int = round(descender_26.6);
   height_int = ascender_int - descender_int;


 This seems to assume that height_26.6 was always ascender_26.6 + -
 descender_26.6.  I'm not sure this is always true.  IIRC, there are
 fonts where the line height is actually different from ascender -
 descender, they would be affected by this patch in surprising ways.

*blush* Uh, oh, I misunderstood what FreeType's `height' value is.
How embarassing.  As you correctly state it's *not* `ascender -
descender' but the baseline-to-baseline distance.

I'll undo the change (and add a comment).  Sorry for the noise.


Werner

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