bugThe FreeType Project - Bugs: bug #29335, scan conversion/rendering problem...

 
 

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

bug #29335: scan conversion/rendering problem with large glyphs

Submitter:  Kenneth Sharp <kens>
Submitted:  Thu 25 Mar 2010 01:24:03 PM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.3.13

Mon 05 Apr 2010 09:21:27 AM UTC, comment #4: 

Your arguments are convincing.  Pushed to the git repository, thanks.

Werner LEMBERG <wl>
Group administrator
Mon 05 Apr 2010 07:42:28 AM UTC, comment #3: 

We haven't done a performance comparison since making the change locally, so I can't really say yet if there is an impact. However the calculation is only performed once per line.

There's no hiding the fact that it will be slightly slower than before, but I don't think it likely to be significant, especially since without the change large outlines with diagonal lines are rendered as mostly blobs.

Ghostscript caches glyphs of course, so I don't think that we will see much difference, but we're fast approaching a finished solution using FreeType, and I do have timings from an earlier quality test run, so I'll compare them when we tidy up the last couple of problems.

Kenneth Sharp <kens>
Group Member
Mon 05 Apr 2010 05:57:18 AM UTC, comment #2: 

Thanks for the analysis and the fix.  Do you see any performance regression?

Regarding the other calculation I suggest that we wait until someone reports a problem.

Werner LEMBERG <wl>
Group administrator
Thu 01 Apr 2010 01:33:44 PM UTC, comment #1: 

The problem occurs in Line_Up in ftraster.c around line 1125 and 1131 where the x increments are calculated based on the delta values of x and y.

Effectively we calculate what distance is travelled in the x direction for every increment in the y direction, which allows us to quickly determine the x co-ordinate of the contour for each scan line.

The problem is that the calculation doesn't take account of arithmetic overflow. A similar calculation above has the comment:

      /* Take care: miny-y1 can be a very large value; we use     */
      /*            a slow MulDiv function to avoid clipping bugs */

The attached patch applies the same slow MulDiv function to the calculation of delta X. This resolves the issue in my test case, and around another 20 files exhibiting the same problem.

Werner, I'm not at all sure that the calculation ' ( ras.precision * -Dx ) % Dy' doesn't also need to be addressed. The simple patch works for me though.


(file #20085)

Kenneth Sharp <kens>
Group Member
Thu 25 Mar 2010 01:24:03 PM UTC, original submission:  

The attached main.c needs to be compiled with ftraster.c in STANDALONE mode. The outline is derived from a type 1 font at 122.73 point size, and comprises a forward slash rotated 90 degrees clockwise.

The program renders this outline twice, once at 72 dpi and then again at 300 dpi by scaling all the points by 300/72. It then dumps a text representation of the bitmpa rendered in each case.

The 72 dpi glyph looks correct, which is the reason for including it, but the 300 dpi version can only be described as broken. The glyph is mostly filled with marked pixels.

I have a number of examples of similar problems (at 300 dpi and large point size), but this is the simplest glyph outline that exhibits it. Although all the co-ordinates appear to be inside the 16:16 fixed point representation it is possible that the sheer size of the outline overwhelms a DDA or something similar. If this is the case, what (approximately) is the maximum co-ordinate which can be used ?


Kenneth Sharp <kens>
Group Member

 

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

Attached Files
file #20085:  ftraster.c.diff added by kens (555B - application/octet-stream)
file #20027:  main.c added by kens (6KiB - text/plain)

 

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 kens
  • -email is unavailable- added by kens (Submitted the item)
  •  

    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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-05 wl StatusNone Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.3.13
    2010-04-05 wl Assigned toNone wl
    2010-04-01 kens Attached File- Added ftraster.c.diff, #20085
    2010-03-25 kens Carbon-Copy- Added -email is unavailable-
    2010-03-25 kens Attached File- Added main.c, #20027

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code