bugThe FreeType Project - Bugs: bug #48309, Cannot get CFF Font to Load

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #48309: Cannot get CFF Font to Load

Submitter:  None
Submitted:  Sat 25 Jun 2016 12:09:52 AM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Invalid Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  None

Jump to the original submission

Tue 28 Jun 2016 06:44:03 PM UTC, comment #8: 

You actually found the problem: for you,
FT_DivFix( 131072000, 65536000 ) returns 0.
Debug here!!!

I cannot reproduce this with 2.6.3. I get correct value of 131072 and I tried a lot of things. Please debug your FT_DivFix.

On 64-bit platform, like you claim, this function is a straightforward 64-bit division. It is a more complex if you do not have FT_LONG64 defined.

Good luck!

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 28 Jun 2016 05:53:46 PM UTC, comment #7: 

I have absolutely no idea.  While the internals of FreeType continually change, the code sequence you use in your snippet should work just fine.

Note, however, that since version 2.5.0 a new CFF rendering engine (contributed from Adobe) is used by default.  I guess that this is causing your problems, but I can't even guess what exactly is your issue.

I'm closing this now as `invalid'.  Please reopen if necessary.

Werner LEMBERG <wl>
Group administrator
Tue 28 Jun 2016 04:27:17 PM UTC, comment #6: 

Thank you for your help. Sorry about the filename - I pulled the code from a few different places and mistakenly added the incorrect extension.

It is as I fear then, my porting tool is causing some error past FreeType v2.4.4

More information can be found here: https://github.com/kripken/emscripten/issues/4262

Any idea why this would be the case / what would have changed?

Anonymous
Tue 28 Jun 2016 04:29:08 AM UTC, comment #5: 

Thanks for the demo program.  Running your program with both 2.6.3 and the current git version of FreeType, it works just fine after I've changed the string 'Incosolata.TTF' to 'Inconsolata.otf' in the call to `load_font` – the font gets loaded at 16px, as expected.

Obviously the problem is somewhere else, and I fear I can't help you further.  Please run a debugger by yourself to find out more details.

Werner LEMBERG <wl>
Group administrator
Mon 27 Jun 2016 06:34:26 PM UTC, comment #4: 

updating with correct main.c...

(file #37602)

Anonymous
Mon 27 Jun 2016 06:27:31 PM UTC, comment #3: 

Including example file main.c

Needs to be compiled with freetype and ran in same directory as font previously attached

To produce error:
gcc main.c -o main
./main

(file #37601)

Anonymous
Mon 27 Jun 2016 04:59:06 PM UTC, comment #2: 

Thank you for your quick response!

Was the glyph not being loaded at em size in the code below? I checked the API but didn't see any calls to specify how to load the glyph like that. I didn't do any scaling/filling until later with different code to drive the drawing.

Some more context: This error occurs at all sizes. I was testing with a char size of 16x16 which seems small for this error.

I simply loaded a cff file (attatched) into the library and called the function (get_bitmap) below. Are there function calls I am missing? If needed, I can post the whole driver file. I am guessing, by your previous response, there is just a loading error somewhere.

(file #37600)

Anonymous
Sat 25 Jun 2016 06:09:26 AM UTC, comment #1: 

This is not a bug.  The new CFF engine prevents internal overflow by refusing rasterization at too large sizes.  If you receive an `FT_Err_Glyph_Too_Big' error, you should load the glyph at em size, then scaling it manually and filling it as a graphics operation.

Of course, this happens at really large sizes where hinting is completely meaningless.  So: What sizes are we talking about?

In case I shall debug something, I need a standalone snippet working at the command line that exhibits the problem.

Werner LEMBERG <wl>
Group administrator
Sat 25 Jun 2016 12:09:52 AM UTC, original submission:  

When calling FT_Load_Char on a .otf (CFF) font, I always get error 164 (Glyph too big for hinting). This worked previously on 2.5

Code snippet from(https://github.com/metafloor/freetype-js/blob/master/main.c):
unsigned char* get_bitmap(int font, int ch, int width, int height) {
FT_Error error;
FT_Face face;

face   = faces[font];
width  = (width mults[font] 64) / 100;
height = (height mults[font] 64) / 100;


/* 1pt == 1px == 72dpi */
error = FT_Set_Char_Size(face, width, height, 72, 0 );
if (error) {
printf("Set_Char_Size Error! %d\n", error);
return 0;
}
slot = face->glyph;

error = FT_Load_Char(face, ch, FT_LOAD_RENDER);
if (error) {
printf("Load_Char Error! %d\n", error);
return 0;
}

return slot->bitmap.buffer;
}

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #37602:  main.c added by None (3KiB - text/x-csrc - updating with correct main.c file)
file #37601:  main.c added by None (3KiB - text/x-csrc)
file #37600:  Inconsolata.otf added by None (57KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-25 podtelez StatusWorks For Me Invalid
        Open/ClosedOpen Closed
    2016-06-28 podtelez StatusInvalid Works For Me
        Open/ClosedClosed Open
    2016-06-28 wl StatusWorks For Me Invalid
        Open/ClosedOpen Closed
    2016-06-28 wl StatusNeed Info Works For Me
    2016-06-27 None Attached File- Added main.c, #37602
    2016-06-27 None Attached File- Added main.c, #37601
    2016-06-27 None Attached File- Added Inconsolata.otf, #37600
    2016-06-25 wl StatusNone Need Info
        Assigned toNone wl

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code