bugThe 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: 

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!

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.

We can't add new fields to FT_OUtline to stay binary compatible with older FreeType DLLs: FT_Outline is a member of the FT_GlyphSlotRec structure; if we increased the size of FT_Outline, offsets to fields after FT_Outline in FT_GlyphSlotRec would have wrong offsets.

Werner LEMBERG <wl>
Group administrator
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?

Also, out of curiosity: what prevents additional fields from being added to the existing struct?

rcombs <rcombs>
Wed 27 Aug 2014 02:57:22 PM UTC, comment #5: 

Ah, now I understand the issue!  Sorry for being dense...

Of course, I don't need an example at all to tell you that I can't change the interface of FT_Outline, sorry.  Unfortunately, it's also not possible to simply extend the structure by appending fields at the end.

A simple solution for you might be to define another value for the `flags' field in FT_Outline, say, FT_OUTLINE_UNSIGNED, which makes your library apply `unsigned short' casts to `n_contours', `n_points', and `contours'.  This would double the available number of points.  If this isn't sufficient, we had to define new structures and a new API.

Werner LEMBERG <wl>
Group administrator
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.

I can make a modified version of that example file that creates a contour with a very large number of automatically-generated points; would you prefer for it to deliberately overflow `n_points` (e.g. create 2^17), or to do something else? The crashes we see in libass usually happen when the drawing code tries to create points after the short wraps around, or when the rasterizer tries to handle a very large negative number of points.

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.

Please prepare a C file similar to http://freetype.org/freetype2/docs/tutorial/example3.cpp (but using the AA rasterizer instead) so that this can be tested directly with FreeType, avoiding any dependency on another library.  It's easiest to embed the vector drawing data into the C file, I guess, but make the program read from a text file is fine also :-)

Werner LEMBERG <wl>
Group administrator
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
This file was generated from an Adobe Illustrator document, here rendered as a PNG: https://www.dropbox.com/s/uol8c3le5or5aj2/Screenshot%202014-08-26%2022.46.20.png
The example isn't really a reasonable use-case for this method (creating a single large vector shape out of a large number of actual glyphs), but you could see how it could be reasonable if the content author intended to do some other processing of the shape, such as twisting it or applying some other effect.
You can test it using mpv ( http://mpv.io ) using `mpv --demuxer=rawvideo /dev/zero --sub-file <path to .ass file>`
Most mpv builds will crash on it rather quickly (because there was no check for an overflow); if you happen to have a very new trunk build of libass installed, it will either fail to draw anything, or draw only part of the shape (depending on your configure-time rasterizer settings). The relevant libass code is available here: https://github.com/libass/libass/blob/master/libass/ass_drawing.c#L35

Feel free to ask for anything else you might find useful for this.

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>
Group administrator
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>

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by rcombs (Submitted the item)
  • -email is unavailable- added by rcombs
  •  

    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 GroupNone Wishlist
    2014-08-27 wl StatusNone Postponed
    2014-08-26 rcombs Carbon-Copy- Added rcombs

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code