Re: [ft-devel] Roadmap for supporting external Drivers?

[Ian Britten]

David Turner wrote:
> I don't think we want to publicly export the FT_Driver internals at all. 
> doing so would require just too much work
> for so little benefits. on the other hand, we can foresee the definition 
> of a public FT_UserFontDriver structure
> that could be filled up by client libraries and apps to implement some 
> level of user-level font support.
>
> this structure would be much simpler than FT_Driver and only expose a 
> minimal number of features.
> we need to find a good balance between what most user-font providers 
> need and what we can support..
> if you want a full blown font driver; it should be part of FreeType, or 
> you should deal with the changes in
> internals, period.
>
> which is why I was asking Ian what kind of "features" he wants to see 
> supported.
> "exposing the internal font driver" is a no-go, but something like
> "overriding the shapes of certain characters" could make it.
>
> so again, what are you using this custom font driver for precisely ?

Sorry if I haven't been clear.
FWIW, I hope I haven't come across as saying "You must expose the font
driver", as I realize that's a painful/expensive change.  I'm just
looking for a way to continue to support our custom font files
(somehow).  A Driver would seem to be the natural approach, but I'd be
open to other ways too, if there are any...

We have a [legacy, internal] font file format, which contains vector
fonts (Lines and/or Polygons).  It's actually a multiple-master file
(eg: Numerous faces in the same file), but that's probably not
relevant to this discussion.

There's also the font stuff other than the actual vectors:  Kerning
information (which we propagate to ICU), codepage/encoding handling,
EM sizing, etc.  Currently, our driver implements the following
callbacks:
    - FT_Face_InitFunc
    - FT_Face_DoneFunc
    - FT_Slot_LoadFunc
    - FT_Face_GetKerningFunc

Years ago, we would have to maintain two completely separate code
paths and techniques in our code to support these fonts:  One for
'normal' fonts, and one for 'our' fonts.  While moving to use FT,
we were happy to discover that we could make a Driver for our old
format.  Thus, in our startup code, we dynamically add the Driver
to FT.  We simply use a naming convention for our fonts, such
that retrieving "Arial" gets us the usual TT font, but retrieving
"Custom #1" ends up retrieving our font (via our Driver), and thus
we can access any font seamlessly in our code, which greatly
simplifies the code.

Our Driver ended up being C++, and makes entensive use of our
classes and ICU.  Because of this (And the internal nature of it),
adding it to FT is not an option.


Given all this, I don't see how "overriding the shapes of certain
characters" could be done, but maybe you have some thoughts?  Since
it's our Driver that's reading our file and returning the points to
FT when requested (Via its FT_Slot_LoadFunc callback), I'm not sure
how this 'override' would work.  Maybe you could elaborate?

Stated another way:  Given that the character 'A' of one of our
fonts contains a particular set of lines/polygons, how would I
integrate that information into FT, if not via the Driver?

Currently, it's a "pull" approach, where our driver returns
whatever is requested, if/when requested.  I'm not familiar with
any other approach that can be used with FT, but maybe you can
point me to something?
Or are you suggesting that this 'other approach' might be what
you would develop/add to eliminate our need for a driver?

As always, many thanks for your thoughts, and any suggestions!
Ian