bugThe FreeType Project - Bugs: bug #29298, inconsistently dropping sub-pixel...

 
 

bug #29298: inconsistently dropping sub-pixel features

Submitted by:  Kenneth Sharp <kens>
Submitted on:  Mon 22 Mar 2010 09:17:57 AM UTC  
 
Severity: 3 - NormalItem Group: None
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

Mon 22 Mar 2010 09:17:57 AM UTC, original submission:

As discussed already on ft-devel. Summary:

==============================================================
Background
===========
I've been interfacing Freetype with Ghostscript for some time. The project is going pretty well on the whole, but as you can imagine we have a large number of test files to run and there are still some outstanding issues which we are working our way through.

In this case the build with FreeType is dropping some glyphs at low resolution, which the regular Ghostscript build doesn't do, and I've been looking into why.

After some investigation it transpires that FreeType is dropping the glyph because it is very small. In this case its a 'underline' character, and at 72 dpi the glyph is 25 64ths of a pixel high. It seems that this is regarded as too small to render, and so the whole glyph gets elided.

I don't have an issue with that, at some point we obviously need to stop rendering very small features. However....

When rendering on a different device, at the same resolution, the glyph doesn't drop out. The only difference is the transformation that gets applied. In the second device we are drawing 'upside down', so we use FT_Set_Transform to 'flip' the glyph vertically.

Details
========
The glyph is, as noted, an underline and more than that it lies entirely below the baseline. (This is a PostScript font).

After interpretation the outline points are:

500 -125
500 -75
0 -75
0 -125

When using the regular transformation, in ftrend1.c, ft_raster1_render, the outline points become:

252 -64
252 -39
0 -39
0 -64

and the 'control box' is calculated as:

  1. -64 252 -39

Because the control box is below 0, FT_Outline_Translate moves the entire glyph 'up' sufficiently to make the lowest point has a y co-ordinate of 0.

So the final outline points are:

252 0
252 25
0 25
0 0

This renders as 4 'white' (unmarked) pixels.

Now, when the 'y flip' transformation is used we see that in ft_raster1_render the outline points are:

252 64
252 39
0 39
0 64

The control box is:

  1. 39 252 64

Because the minimum y co-ordinate is 0 FT_Translate_Outline does nothing and this is the outline we feed into raster_render.

This results in a line of 'black' (marked) pixels.

So why the difference ? I'm debugging my way through the rendering code to try and establish that precisely, but broadly its because of the position of the feature within the pixel.

By altering the outline points in the debugger (fortunately its a nice simple glyph) I can move the outline around and I see the following:

If the feature lies completely below one half pixel (ie yMax < 32) then the whole glyph is elided. If any part of the glyph lies above half the pixel (ie yMax >= 32) then the pixel is marked.

This is the point for discussion, it seems to me that the location of the feature within the pixel should not have any effect on whether the pixel is marked or not, that should only depend (In my opinion of course) on the size of the feature.

An example reason why the inconsistency is a problem is because we can be in a situation where alternate pages are 'flipped' vertically, for duplex printing. We don't want the presence/absence of very small features to depend on whether the page is recto or verso.

===============================================================

Attached is source for a small program which will exercise the rendering code (ftraster.c) when built STANDALONE. This draws four glyphs (ASCII characters), these are the outlines obtained by interpreting the type 1 underline glyph at 72 and 96 dpi, inverted and regular upright.

Also attached is a tiny diff to ftmisc.h. MSVC doesn't contain a definition of inttypes.h, and so fails to build when STANDALONE is defined. This patch simply defines FT_Int64 as __int64 when either _WIN32 or _WIN64 is defined.

Kenneth Sharp <kens>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #20001:  main.c added by kens (9kB - text/plain)
file #20002:  ftmisc.h.diff added by kens (426B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by kens (Submitted the item)
  • -unavailable- added by kens
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 22 Mar 2010 09:17:57 AM UTCkensAttached File-=>Added main.c, #20001
      Attached File-=>Added ftmisc.h.diff, #20002
      Carbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup