freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] Apple Color Emoji Invalid size handle revisited.


From: Hin-Tak Leung
Subject: [ft-devel] Apple Color Emoji Invalid size handle revisited.
Date: Sun, 7 May 2017 02:57:44 +0000 (UTC)

Hi Werner,

I have a better look at the glyph 0 Invalid size handle issue with Apple Color 
Emoji .

I think the size handle is invalid (with both x scale/y scale zero):

===
FT_Request_Size (font driver's `request_size'):
  x scale: 0 (0.000000)
  y scale: 0 (0.000000)
  ascender: 160.000000
  descender: -50.000000
  height: 210.000000
  max advance: 160.000000
  x ppem: 160
  y ppem: 160
===

but somehow it does not matter with FT_LOAD_COLOR and a valid glyph id.

Here is the sequence of events:

for valid glyph id,  TT_Load_Glyph() runs load_sbit_image() ( 
src/truetype/ttgload.c line 2625 or there abouts)
which returns success, so 'return FT_Err_Ok;' happens around line 2650.

but for glyph id 0,  load_sbit_image() returns failure, so it drops down to the 
next part:

===
    if ( !( load_flags & FT_LOAD_NO_SCALE ) && !size->ttmetrics.valid )
    {
      error = FT_THROW( Invalid_Size_Handle );
      goto Exit;
    }
===

which is what returns Invalid_Size_Handle . 

It is invalid size, but it does not matter if load_sbit_image() is successful.


I tried loading NotoColorEmoji.ttf with an invalid char, so it also loads glyph 
0. The requested size isn't as obviously wrong, but it is also invalid size 
handle:

===
FT_Request_Size (font driver's `request_size'):
  x scale: 223232 (3.406250)
  y scale: 223232 (3.406250)
  ascender: 101.000000
  descender: -27.000000
  height: 128.000000
  max advance: 147.000000
  x ppem: 109
  y ppem: 109
===

Is there a better way of handling this? Invalid size handle just seems 
misleading; it is rather  that load_sbit_image() failed and also that one 
shouldn't try everything else.

How about something like this (the  else clause):

===
error = load_sbit_image( size, glyph, glyph_index, load_flags );
if ( !error )
{
...
  return FT_Err_Ok;
}
else
{
if ( load_flags & FT_LOAD_COLOR)
   {
    /* return error now and don't try loading outline */
      error = FT_THROW( Invalid_Argument );
      goto Exit;

    }
}
===

I think in most cases one wants to continue to try loading outlines (and get to 
the invalid size handle check), but for FT_LOAD_COLOR, and perhaps some "other 
bitmap-only" or "I-don't-want-outlines" flag too, it is obvious the client 
program does not want to continue if  load_sbit_image() fails?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]