freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ian Britten
Subject: Re: [ft-devel] Roadmap for supporting external Drivers?
Date: Wed, 25 Jun 2008 09:35:35 -0300
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050322)

Werner LEMBERG wrote:

I've played a bit around with your font driver skeleton.  And indeed,
as you've already pointed out, many internal structures (besides the
stuff in ftdriver.h) had to be exposed to the public, which is bad.  I
don't have the time (and, admittedly, the skills) to redesign the
driver interface so that dependencies on internal header files can be
avoided.

My sincere thanks for taking the time to look at it, and also for
confirming that the problem is real (As opposed to me just
misunderstanding/overlooking something!)

The excercise is clear: Redesign the API given in ftdriver.h so that
it can be lifted to the public level, relying only on opaque pointers
(cf. the FT_Xxx_Internal typedefs in freetype.h) if really necessary.
Such an API should be extensible so that new font driver capabilities
could be added -- something like `FT_Driver_Add_Function' comes to my
mind, but maybe other solutions are possible too.

No comment.
In all honesty, I have no clear idea/plan how you'd like to do this,
and I'll leave it up to you (And/Or the FT team) to address.  As long
as I can access my fonts via some supported technique, I'll be happy!
[ Hopefully not requiring a radical rewrite though, if possible! ;) ]

Actually, given that I'm probably a rare user (Having a custom font
format), I'd even be open to any sort of hybrid solution which might
be easier for you.  Admittedly, exposing any sort of 'partially
internal' stuff could put you back into the situation you worked so
hard to get out of, so you might not want to go there.  I'd just
hate to see you spending a lot of time on redesigning/exposing
something that very few users need.

Basically, if I can:
  - Install a stock version of FT (ie: No customization)
  - Build our code against it (ie: No hacks, copies of header files)
I'd be happy.
ABI compatibility between versions is probably not much of a concern
for us on Windows.  Since there's no preinstalled version of FT on
Windows, and we'd probably just build+ship our executables with
whatever version of FT we need/choose.
Building+Deploying on Linux would obviously be trickier though,
since FT is a 'system' library and not under our control.  We could
probably impose some restrictions between build and deployment
distributions though in this case.

Until this happens, you probably should simply continue to use the
internal header files in your project, tracking changes of its
contents as soon as new versions of the FreeType library appear.  This
is not as complicated as it may sound since changes are not too
frequent; George Williams, for example, does the same for FontForge,
providing a great interface for TrueType bytecode debugging.

Ya, for the time being, I had already realized I was going to have
to do this.  Even if 2.3.7 has your proposed changes, I don't want
to delay our FT upgrade until then.  FT is used by so many other
tools (eg: Cairo) that we simply *must* upgrade, due to conflicting
dependencies.
I'll classify this as a 'duct-tape' solution - Good enough for now! ;)

Thanks again!
Ian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]