The FreeType Project - Bugs: bug #43075, FT_Outline: use unsigned instead...
You are not allowed to post comments on this tracker with your current authentication level.
bug #43075: FT_Outline: use unsigned instead of short?
Submitter: | rcombs <rcombs> | ||
Submitted: | Tue 26 Aug 2014 12:35:37 AM UTC | ||
Severity: | 3 - Normal | Item Group: | Wishlist |
Status: | Postponed | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Planned Release: | None |
Jump to the original submission
Wed 27 Aug 2014 07:15:44 PM UTC, comment #8: |
rcombs <rcombs> |
Wed 27 Aug 2014 06:49:27 PM UTC, comment #7: I think that a new, generalized API will probably come with FreeType 3.0, but this is far, far in the future. Given that FreeType is a font library, there is no urgent need to increase the maximum number of points. Consequently, you should use your own structure if FT_Outline isn't sufficient.
|
Werner LEMBERG <wl> |
Wed 27 Aug 2014 05:47:49 PM UTC, comment #6: While there are a few specific cases where the extra bit would mean we had enough available points, there are also plenty of cases (both existing and possible) where it wouldn't. So, if the FT_Outline API can't be changed at all, then the question is: do we consider this sort of functionality to be generally useful enough to add a new type to the FreeType API, or should libass just switch to using its own structs (with larger integer sizes) internally and drop support for FreeType's rasterizer?
|
rcombs <rcombs> |
Wed 27 Aug 2014 02:57:22 PM UTC, comment #5: Ah, now I understand the issue! Sorry for being dense...
|
Werner LEMBERG <wl> |
Wed 27 Aug 2014 06:51:03 AM UTC, comment #4: Actually, we're defaulting to using our own anti-aliasing rasterizer by default in libass now (it has SIMD optimizations, and focuses on speed; you can imagine why that'd be necessary in this sort of situation) and are using FreeType for both font management and as another rasterizer option (which can be enabled at configure-time). The core issue here is that we use the FT_Outline struct to store both font and vector drawing data in all cases, and the `n_points` and `n_contours` members are both too small to hold the respective counts in very large drawings. Which rasterizer ends up consuming the struct is irrelevant.
|
rcombs <rcombs> |
Wed 27 Aug 2014 06:36:03 AM UTC, comment #3: Thanks, but this doesn't directly help. I presume that you are mainly interested in the anti-aliasing rasterizer to display vector graphics on the screen, right? In other words, you are completely bypassing the font functionality of FreeType.
|
Werner LEMBERG <wl> |
Wed 27 Aug 2014 05:55:10 AM UTC, comment #2: Here's a file with a very large (>2^15 points) vector drawing (WARNING: 3MB text file): https://gist.githubusercontent.com/torque/68c27381fca098b34445/raw/the%20future%20of%20typesetting.ass
|
rcombs <rcombs> |
Wed 27 Aug 2014 04:37:57 AM UTC, comment #1: This needs investigation, so I'm marking it as `postponed'. It would help a lot if you could provide such a vector drawing for reference.
|
Werner LEMBERG <wl> |
Tue 26 Aug 2014 12:35:37 AM UTC, original submission:
We've seen some cases with libass where content authors produce vector drawings with more than 2^15 points or contours, which previously caused crashes (and now just causes rendering failures). I'm not sure what the ABI-compatibility implications of changing the types on the "n_contours" and "n_points" properties would be, nor whether or not it would be possible to work around this issue in some other way (e.g. add an "extended_n_points" property that's used if `n_points == -1`?), but it'd be great from our perspective if an improvement could be made in this area. |
rcombs <rcombs> |
No files currently attached
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2014-10-08 | wl | Item Group | None | Wishlist | |
2014-08-27 | wl | Status | None | Postponed | |
2014-08-26 | rcombs | Carbon-Copy | - | Added rcombs |
Powered by Savane 3.13-cf05.
Corresponding source code
Ah, I didn't think of it being used as a struct member. That makes sense.
Well, I'll go ahead with creating our own structs with integer members and copying data out of ones provided by FreeType, then. Thanks a lot for discussing this!