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!
|
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.
|
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?
|
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.
|
Mon 27 Jun 2016 06:34:26 PM UTC, comment #4:
updating with correct main.c...
(file #37602)
|
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)
|
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)
|
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.
|
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;
}
|