The 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: |
Alexei Podtelezhnikov <podtelez> |
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.
|
Werner LEMBERG <wl> |
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.
|
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.
|
Werner LEMBERG <wl> |
Mon 27 Jun 2016 06:34:26 PM UTC, comment #4: updating with correct main.c... |
Anonymous |
Mon 27 Jun 2016 06:27:31 PM UTC, comment #3: Including example file main.c
|
Anonymous |
Mon 27 Jun 2016 04:59:06 PM UTC, comment #2: Thank you for your quick response!
|
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.
|
Werner LEMBERG <wl> |
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
|
Anonymous |
Depends on the following items: None found
Items that depend on this one: None found
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 | Status | Works For Me | Invalid | |
Open/Closed | Open | Closed | |||
2016-06-28 | podtelez | Status | Invalid | Works For Me | |
Open/Closed | Closed | Open | |||
2016-06-28 | wl | Status | Works For Me | Invalid | |
Open/Closed | Open | Closed | |||
2016-06-28 | wl | Status | Need 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 | Status | None | Need Info | |
Assigned to | None | wl |
Powered by Savane 3.13-3230.
Corresponding source code
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!