[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] controlling FreeType modules
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] controlling FreeType modules |
Date: |
Tue, 11 Sep 2012 08:44:37 +0200 (CEST) |
>> This sounds like a good candidate for a property of the truetype
>> module...
>
> I think I have a workaround for now, but it would certainly be
> easier if it were supported in the library.
OK. I'm still exploring how to introduce global properties in modules
(and, most of all, where to add structures for storing those things).
>> But this doesn't solve the problem of exposing internal structures
>> to the public...
>
> The reality is that it means that the "low level" API will likely
> extend over time - as folks identify new aspects they want to
> interrogate or influence, we add functions to handle those to the
> API.
Correct. However, `extending' a low-level API means that I no longer
can *change* it...
> Alternatively, we could go a bit object oriented, so (almost?) every
> internal structure includes an accessor function pointer (I'd make
> the accessor the first entry in every relevant structure).
Hmm.
> Then we can change the internal representations any way we want, and
> just modify the accessor function to suit.
Doing it this way may be something for FreeType 3.
> By Postscript Type 0, I assume you mean a CIDFont which has been
> composed with a CMap?
Whatever. I'm referring to fonts with a FontType of 0, as described
in section 5.10 of the PostScript Language Reference Manual.
> From a Ghostscript point of view, we handle all the Type 0 font
> stuff ourselves, so Freetype only ever sees the descendant fonts,
> but in general, I would consider combining the CIDFont with the CMap
> to be part of loading a font for use, so within Freetype's remit.
>
> Having said that, given that you need a Postscript interpreter to
> really handle CIDFont/CMap combinations in the general case, I can't
> imagine there being much demand for it, so that may well be moot.
I can imagine to provide hooks into FreeType to handle that.
> I just think that Freetype should remain an engine which takes a
> font from some source, and uses it to to create outline or bitmap
> glyphs. I would not like to see Freetype getting sucked into
> loading fonts by name (even if that was done by punting off the
> fontconfig), or gaining any kind of layout capabilities.
Yes. But unfortunately the reality doesn't always allow to draw a
clean border. As mentioned previously, I prefer a (thin) layer on top
of FreeType.
Werner