Re: [ft] Stray pixel from FT_Outline_Get_Bitmap()?

[Ian Britten]

On 04/08/10 09:54 AM, Werner LEMBERG wrote:

> > I believe I'm seeing a regression between 2.3.9 and 2.3.11 when
> > rendering monochrome text, resulting in a stray pixel being rendered
> > - See the attached screenshots.
>
> Just for reference: Have you tested 2.4.1 also?  I don't expect any
> improvement, but...

No, I haven't.  I confess that being on an RPM-based system, I
usually just use the system-provided RPMs, and I don't see anyone
packaging 2.4.x by default (yet).
If it becomes crucial, I can explore trying to upgrade...

> > Unfortunately, I'm not able to give out this custom font nor view it
> > in ftview, so I'm at a bit of a loss as to how to best pass this
> > problem over to someone for further investigation - Suggestions
> > welcome!
>
> You can't view it in ftview...  Interesting.  Can you elaborate for
> curious people like me?

Sorry, I knew what I meant, but didn't convey it well...  :P

I actually have a custom (Legacy) font file format that I'm
supporting, using a custom (Non-sanctioned) FT_Driver (Yep, it's
me again! :)  This C++ driver uses our framework, ICU, etc, so it
wouldn't be possible to redistribute it.

FWIW, I'm reasonably confident that it's not the cause of this
particular problem, as it works in all cases to date (AA rendering,
FT_Outline_Decompose(), etc).  It seems to just be this one
glyph, when rendered with no AA, that seems problematic (So far).


> > Meanwhile, I can provide the raw geometry of the problematic diamond
> > shape (from the font file), in the hopes that it can be used
> > somehow:
> >
> >       -35, 368   (LL)
> >      -111, 444   (UL)
> >       -22, 444   (UR)
> >        54, 368   (LR)
> >       -35, 368   (LL)
> This helps, but it is not complete: Is this font units?  If yes, how
> many font units are per em?  1000 (as in Type 1 or CFF fonts) or 2048
> (as in most TTFs)?

Sorry, I wasn't sure if just the Cartesian geometry would be enough...

- Our EM is 8000 (for some historical reason - the comments suggest
  its related to preventing overflow).
- Those points I gave are an integral/scaled mm size.  We take the
  [floating point] mm size and scale it fit into the EM box.
- For this face, the root.bbox ends up being (-4265,-4000), (4265,4000)
- In my "slot load CB", based on these inputs:
       face->scale = 521.4579965583772
       size->metrics.x_scale = 18579
    I return these values for the points:
       -131, 1382
       -417, 1667
        -83, 1667
        203, 1382

I'm not sure if that's clear, or if it's enough info.  If not, please
let me know, and I'll dig further.  Similarly, if there's something
specific I could look at or try, please let me know...

Many thanks for your help!
Ian