Re: [ft-devel] FT_Slot_LoadFunc load_flags info?

[Ian Britten]

Werner LEMBERG wrote:
> > - It's cover is [(-800, -1000), (800, 1000)], as an example.
>
> This is quite unusual for a glyph...

> > Since my origin is in the centre of the glyph,
>
> This is unusual, too.  Normally, the origin is left of the glyph (or
> above the glyph in case for vertical typesetting).

Ya, no kidding ...  :P
These 'fonts' are an old, home-grown solution dating back before
TT/FT/etc, and violate lots of conventions/assumptions:  Arbitrary
origins, open path strokes, variable line thicknesses, etc... :(

[ Aside ] I'm just (really) happy that I can generally hide most of
the details/discrepancies within a single custom FT driver, and
keep most of the calling code in all our applications clean and
simple!  Thanks!  :)

> > these are basically half the width/height, right?
>
> Yes.  Look at the attached image (from the tutorial); note that
> horiBearingX is negative for your glyph dimensions.

Ya, thanks.  That's what I was working from.  I was just hesitant
since the accompanying docs say: "It is positive for horizontal
layouts..." and I wasn't sure whether my negative value would work.

> > > The horizontal advance is the amount you have to move the cursor to
> > > the right (or down for vertical layouts);
> > This is where I start to scratch my head ...
> > - Should this be the width of my glyph?
>
> This value is completely independent from the actual glyph!  It's up
> to you how much whitespace you want to have between your glyphs.
> Basically, it's a design decision; of course, in most cases the
> advance width is larger than the glyph's width.
>
> To summarize: The advance width gives the distance from the origin of
> a glyph to the origin of the next glyph.

Hmmm, so if I set the advance equal to the glyph width, they should
be packed tight together?

I wonder if we have crossed some wires/concepts in our higher-level
layout code?  I know we have "pair kerning", and I return some info
from these fonts in response to that request.

However, our (font-agnostic) layout code works correctly with TT
fonts, which is why I keep suspecting something in this driver...

> > - Or should it be zero?  Zero seems to work in _some_ cases...
>
> This surprises me.  Zero should make all glyphs positioned at the same
> place, overwriting each other.

Until I opened this rats-nest, it seems we were always returning
zero, and maybe our layout handles advancing itself?  We do lots of
wacky text rendering, including text-along-curves, track-kerning,
block/HTML-like text, etc.

When I change the advance to be the glyph width, one of the
problematic Cairo cases seems better.  However, that makes little
sense to be, since we only ever draw text one glyph at a time, with
our layout determining the position/size/angle/etc of each glyph.

The mystery deepens ...  :/
[ Again though, the more confidence I have that my driver is
returning the correct information, the more chance I can unravel
this ... ]

> > I also seem to be getting a FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH
> > flag?
>
> Uh, how comes?  You should never need this flag.

Don't ask me - I'm just a font driver!  :)

Seriously though, when we load glyphs (either via FT or Cairo),
we only use NO_HINTING (And IGNORE_TRANSFORM it seems, in one case).
All the other flags my driver receives, including
IGNORE_GLOBAL_ADVANCE_WIDTH, are being turned on by FT/Cairo.

In this particular case though, _cairo_ft_scaled_glyph_init()
(src/cairo-ft-font.c) contains this line:
    /* Ignore global advance unconditionally */
    load_flags |= FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH;
I don't know why ...

This gets back to the root of my original question though - Which
FT_LOAD_ flags does my driver need to handle, and which ones are
just being turned on due to higher-level processing (But which my
driver can ignore)...

Anyways, this thread has given me a lot to digest so far.  I'm
going to try and incorporate the definitive information you've
provided, review our layout/advance stuff, and see where I stand
after that.
As always, many thanks!
Ian