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

 
 

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

bug #29298: inconsistently dropping sub-pixel features

Submitter:  Kenneth Sharp <kens>
Submitted:  Mon 22 Mar 2010 09:17:57 AM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Planned Release:  None

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

 

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

Attached Files
file #20001:  main.c added by kens (9KiB - 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
  • -email is unavailable- added by kens (Submitted the item)
  • -email is unavailable- added by kens
  •  

    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
    2010-03-22 kens Attached File- Added main.c, #20001
        Attached File- Added ftmisc.h.diff, #20002
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code