[ft-devel] inconsistently dropping sub-pixel features

[Ken Sharp]

Hi all,

This may or may not be regarded as a bug, so I thought I'd put it up for 
discussion before potentially raising it as an issue.

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:

0 -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:

0 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.


Thanks for your time reading this rather lengthy post, I'd welcome any 
thoughts or other opinions.


                                                        Ken
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TASK: Shoot yourself in the foot.
C: You shoot yourself in the foot.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -