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


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

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

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


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

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

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project Member


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

Attach Files:

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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    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 chris.liddell@artifex.com
    2010-03-25 kens Attached File- => Added main.c, #20027

    Back to the top

    Powered by Savane 3.5