bugThe FreeType Project - Bugs: bug #19976, rendering problem in ftdiff

 
 

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

bug #19976: rendering problem in ftdiff

Submitter:  None
Submitted:  Sun 27 May 2007 07:57:47 AM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Invalid Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  None

Jump to the original submission

Fri 09 Jul 2010 02:37:26 PM UTC, comment #6: 

Forgotten to close it...

Werner LEMBERG <wl>
Group administrator
Tue 06 Jan 2009 11:13:03 PM UTC, comment #5: 

I'm now rather convinced that there is no bug.  I've attached
a small PDF file which uses uagk8a.pfb as in the two
multiLineText images, displaying the two letter `S' and `e'.
I've also attached an image of acroread 7.0.8 (on GNU/Linux),
rendering the small document so that the glyphs have
approximately the same size.  It looks (almost) the same as with
FreeType 2.3.7 -- considering acroread as one of the reference
implementations for rendering PS fonts natively, I doubt that
this result can be improved.

Have I missed something?  If there are no objections I'm going
to close this bug report.

file #17216)

Werner LEMBERG <wl>
Group administrator
Fri 26 Dec 2008 07:25:48 AM UTC, comment #4: 

I need input for ftview so that I can debug this further.
Anyway, I've reopened it.

Werner LEMBERG <wl>
Group administrator
Fri 26 Dec 2008 05:13:52 AM UTC, comment #3: 

I have determined that it was the fix for this bug that causes several unit tests in VTK to fail when switching from freetype 2.3.5 to 2.3.6.  The VTK bug entry is:

http://www.vtk.org/Bug/view.php?id=7199

Sean


Anonymous
Sun 18 May 2008 09:49:53 PM UTC, comment #2: 

Fixed in the CVS.  Please test.

Werner LEMBERG <wl>
Group administrator
Mon 28 May 2007 05:58:59 AM UTC, comment #1: 

I can confirm the problem at 25pt/96dpi even with ftview
in the current CVS.

However, this font isn't a TT based OTF, so there can't be
bytecode instructions.  I don't think that it is related to
the interpretation of the CFF strings because the effect of
getting thinner and thinner glyphs can be easily shifted
with the -f option of ftview so that the effect starts at a
different glyph.

I suspect that the global data of this font somehow causes
a lacking initialization of the rendering state so that
repeated calls of FT_Load_Glyph reduce the character width
instead of computing it anew.

Werner LEMBERG <wl>
Group administrator
Sun 27 May 2007 07:57:47 AM UTC, original submission:  

I've discovered a strange rendering problem in ftdiff at 12.5 pt and 96 dpi with the Aurulent Sans font.  A screenshot is attached.  The command run was:
ftdiff -r 96 -s 12.5 AurulentSans-Regular.otf

The problem also appears at 25pt with 96 dpi.  However, I've only seen the problem for this font.  It also only appears for the bytecode hinting.  Other OTF-CFF fonts, or TTF or PFB, never showed a problem.  There is also no problem with ftview.

Is this a problem with the font, freetype2, or ftdiff?  I used freetype2-2.3.4 and ft2demos-2.3.4.

By the way, ftdiff is a fantastic tool!

Thanks!
Stephen Hartke
lastname at gmail dot com

Anonymous

 

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

Attached Files
file #17215:  Se.png added by wl (23KiB - image/png)
file #17216:  Se.pdf added by wl (3KiB - application/pdf)
file #17194:  multiLineText2.3.5.png added by None (16KiB - image/png - VTK unit test results with FT 2.3.5 vs 2.3.7.)
file #17195:  multiLineText2.3.7.png added by None (15KiB - image/png - VTK unit test results with FT 2.3.5 vs 2.3.7.)
file #12874:  AurulentSans-Regular.otf added by None (37KiB - application/octet-stream)
file #12875:  ftdiff.png added by None (86KiB - image/png)

 

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)
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-09 wl StatusNeed Info Invalid
        Open/ClosedOpen Closed
        Planned Release2.3.8 None
    2009-01-06 wl Attached File- Added Se.png, #17215
        Attached File- Added Se.pdf, #17216
    2009-01-02 None Attached File- Added multiLineText2.3.5.png, #17194
        Attached File- Added multiLineText2.3.7.png, #17195
    2008-12-26 wl StatusFixed Need Info
        Open/ClosedClosed Open
        Planned Release2.3.6 2.3.8
    2008-05-18 wl StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.3.6
    2007-05-28 wl StatusNone Confirmed
        Assigned toNone wl
        Carbon-Copy- Added freetype
    2007-05-27 None Attached File- Added AurulentSans-Regular.otf, #12874
        Attached File- Added ftdiff.png, #12875

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code