Re: [ft-devel] controlling FreeType modules
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 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Fri, Sep 7, 2012 at 11:53 PM, suzuki toshiya mpsuz...@hiroshima-u.ac.jp wrote: Tagoh-san, could you describe more about the advantage to put full CFR support into FreeType? I think, the significant advantage is the minimized cost of the migration from concrete TrueType/OpenType with 64k glyph limitation to the CFR without such limitation. If FreeType supports CFR fully, with builtin fontconfig client etc, just upgrading the older FreeType library to new one would be sufficient. It's very happy scenario. That's true and what I'm mainly concerned. I'm not that familiar with FreeType API though, I guess it's not feasible to apply the modified fonts metrics etc so far, right? this is why I'm requesting some changes according to FreeType3 discussion too. And the point that I think it would be better support CFR in FreeType is, CFR itself could be a font file. even though it's a virtual font that doesn't contain any outline nor bitmap data for glyphs. So it shouldn't break the usage of the existing APIs. In fact, it is not rare to see the posts to freetype (or freetype-devel) mailing list asking a question like why Microsoft Windows can show every Unicode characters by Arial font, but FreeType2 cannot do such?. Often I reply as what you specify on Microsoft Windows is not arial.ttf, it is ..., but I don' think the people asking the question can get any pragmatic solution from my reply (and I guess they may feel as if they are forced to give it up what they wanted to do originally). If FreeType supports CFR directly and fully, I can post the solution for them. It's very happy scenario. Sure. if FreeType has any solution for that, that would be nice and hope it may helps in case we may see in pure Xft-based applications too. but I'm not expecting on this discussion to change the behavior on the existing APIs too. rather I don't think it's needed. However, as I've investigated the the number of applications/libraries assuming as they access concrete font files is not negligible. To support CFR fully without asking some change in these applications/libraries, some fake concrete fonts should be synthesized. I'm afraid that debugging such layer would not be so easy, and it is difficult for FreeType developers to guarantee the faked fonts are safe/stable for current FT2 clients. That's why I proposed to support CFR with another layer, at the beginning. Aha. interesting. well, I'm not at the position to recommend using CFR strongly. so if CFR support can be implemented outside FreeType without missing compatibility to FreeType APIs, I don't have any objections. but just trying to find out if there are any easier way to do it from the POV of application developers. -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Fri, Sep 7, 2012 at 1:40 PM, Werner LEMBERG w...@gnu.org wrote: Not necessarily. It shouldn't be too difficult to provide the necessary hooks so that a small library for handling composite font objects on top of FreeType can reuse FreeType's code. Sure. that sounds reasonable and I didn't mean to have all-in-one. having said, if FreeType allows us to do FT_New_Face(foo.cfr...) instead of having another library with FreeType's hooks, that would be easier to support in applications though. I was presuming to have the sort of callback APIs in FreeType and set it in other library or applications, but anyway. -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Chris Liddell wrote: On 07/09/12 03:34, Akira TAGOH wrote: On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell chris.lidd...@artifex.com wrote: 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. But it's what one has to be done for CFR. otherwise someone needs to write another library to support CFR, which may has a lot of duplicate code to FreeType. I don't see that being the case at all. As Werner mentioned, it could better be implemented as a layer over Freetype. Tagoh-san, could you describe more about the advantage to put full CFR support into FreeType? I think, the significant advantage is the minimized cost of the migration from concrete TrueType/OpenType with 64k glyph limitation to the CFR without such limitation. If FreeType supports CFR fully, with builtin fontconfig client etc, just upgrading the older FreeType library to new one would be sufficient. It's very happy scenario. In fact, it is not rare to see the posts to freetype (or freetype-devel) mailing list asking a question like why Microsoft Windows can show every Unicode characters by Arial font, but FreeType2 cannot do such?. Often I reply as what you specify on Microsoft Windows is not arial.ttf, it is ..., but I don' think the people asking the question can get any pragmatic solution from my reply (and I guess they may feel as if they are forced to give it up what they wanted to do originally). If FreeType supports CFR directly and fully, I can post the solution for them. It's very happy scenario. However, as I've investigated the the number of applications/libraries assuming as they access concrete font files is not negligible. To support CFR fully without asking some change in these applications/libraries, some fake concrete fonts should be synthesized. I'm afraid that debugging such layer would not be so easy, and it is difficult for FreeType developers to guarantee the faked fonts are safe/stable for current FT2 clients. That's why I proposed to support CFR with another layer, at the beginning. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Another example that I recently stumbled across (and haven't yet investigated fully) is the rendering of notdef glyphs. For Truetype, Freetype is (correctly) using the TTF notdef glyph (the empty rectangle), but for Postscript/PDF/PCL/PXL, the notdef is a non-marking glyph. So, in the event that we're using a TTF in a PS/PDF/PCL/PXL context, we'll need a way to influence that behaviour. This sounds like a good candidate for a property of the truetype module... My preference is to have a dual level API: where you might have a simple high level interface, which includes the very simplest use cases and hides the vast majority of the details of what the library is doing from the calling app, and users need very little knowledge to use it. Then you have a low level API, where users need a lot more knowledge of what they're doing, but they then have the ability to access and influence a lot more of the behaviour of the library. But this doesn't solve the problem of exposing internal structures to the public... Also, a note on the fontconfig interaction mentioned: I'm not clear on what that proposal involves, but I would urge against Freetype interacting directly with fontconfig. I feel Freetype should continue to be purely a font scaling/rendering library, and shouldn't get involved in font management, or other peripheral functionality. Basically, I agree. However, the border between font objects and font management is fuzzy. For example, do you consider composite fonts like Windows 7's `CompositeFont' objects or PostScript's `FontType 0' fonts as something FreeType should handle? I think it doesn't really belong to FontConfig. Instead, I can imagine a layer on top of FreeType which handles such formats. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On 06/09/12 07:05, Werner LEMBERG wrote: Another example that I recently stumbled across (and haven't yet investigated fully) is the rendering of notdef glyphs. For Truetype, Freetype is (correctly) using the TTF notdef glyph (the empty rectangle), but for Postscript/PDF/PCL/PXL, the notdef is a non-marking glyph. So, in the event that we're using a TTF in a PS/PDF/PCL/PXL context, we'll need a way to influence that behaviour. 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. I need to look more closely at how the Truetype module sets all this up, but it would probably be moderately easy to have GID 0 setup as a whitespace glyph. My preference is to have a dual level API: where you might have a simple high level interface, which includes the very simplest use cases and hides the vast majority of the details of what the library is doing from the calling app, and users need very little knowledge to use it. Then you have a low level API, where users need a lot more knowledge of what they're doing, but they then have the ability to access and influence a lot more of the behaviour of the library. 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. It's very much a compromise, but I don't think there is a right answer which doesn't end up reducing flexibility and increasing the change of the code being forked. 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). Then we can change the internal representations any way we want, and just modify the accessor function to suit. We can also make additional information available through the accessor as required without superficially changing the API. Also, a note on the fontconfig interaction mentioned: I'm not clear on what that proposal involves, but I would urge against Freetype interacting directly with fontconfig. I feel Freetype should continue to be purely a font scaling/rendering library, and shouldn't get involved in font management, or other peripheral functionality. Basically, I agree. However, the border between font objects and font management is fuzzy. For example, do you consider composite fonts like Windows 7's `CompositeFont' objects or PostScript's `FontType 0' fonts as something FreeType should handle? I think it doesn't really belong to FontConfig. Instead, I can imagine a layer on top of FreeType which handles such formats. Hmmm, I haven't really looked into the Windows 7 CompositeFont things (I probably will have to at some point). By Postscript Type 0, I assume you mean a CIDFont which has been composed with a CMap? 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 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. Chris ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell chris.lidd...@artifex.com wrote: 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. But it's what one has to be done for CFR. otherwise someone needs to write another library to support CFR, which may has a lot of duplicate code to FreeType. -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Loading a font face by its name is too platform dependent problem (some platform may have multiple font management systems and their registries are often left with no synchronization), putting everything for CFR into FreeType2 would be slightly difficult. My concern is that the system maintainer will have to install multiple FreeType2 libraries configured for different font managements. # A portable solution would be a standardization of the file format # packing a CFR and its component font files into single container. # I've ever posted such to SC29/WG11/font AHG, and one expert had # commented it's tolerable idea. Unfortunately, other SC29/WG11/font # AHG people gave no response - I'm looking for appropriate route to # standardize it via JTC1. And, some FreeType2 APIs (mainly getting the indepth content of the font file, like, FT_Load_Sfnt_Table()) cannot be applied to CFR directly. Also the consideration of FT_Get_Name_Index(), FT_Get_Char_Index() would be needed. Considering these issues, I think some thin wrapper library is expected to support CFR really; it should provide a subset of FreeType2 APIs and most of them are just passing the arguments to FreeType2 (after the translation of CFR face object to appropriate font object). The API syntax is expected to be same with FreeType2, to minimize the cost to rewrite the application using FT2 directly. -- BTW, another issue would be the Unicode layout features of CFR. I guess the design of CFR assumes that the CFR object is dealt over the layer of the text layout and does not assume that the user of CFR reads OpenType (or AAT) layout tables from a CFR object. It would be possible for CFR supporting library to identify which layout table of which component font should be used, but returning its raw content would be useless, because its glyph index is not unique number in CFR object. It would be possible to translate the raw glyph index to the fake glyph index for CFR, but as far as the OpenType supporting code request the memory image of OpenType layout tables, the 64k glyph limitation is still existing. I'm not sure if CFR supporting library should provide the APIs to access OpenType layout table content. # IMHO, the stake holders of OpenType layout tables and the breakage of # 64k glyph limitation would be slightly different. Regards, mpsuzuki Akira TAGOH wrote: On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell chris.lidd...@artifex.com wrote: 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. But it's what one has to be done for CFR. otherwise someone needs to write another library to support CFR, which may has a lot of duplicate code to FreeType. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
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 it's what one has to be done for CFR. otherwise someone needs to write another library to support CFR, which may has a lot of duplicate code to FreeType. Not necessarily. It shouldn't be too difficult to provide the necessary hooks so that a small library for handling composite font objects on top of FreeType can reuse FreeType's code. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Wed, Aug 29, 2012 at 11:45 AM, Werner LEMBERG w...@gnu.org wrote: Any plans for Freetype3? It's been 12 years. Is it time yet for a spring cleaning? Since I'm very bad at API design, I won't start such a project, but you are very welcome to discuss potential improvements, and it's very cheap to start a new branch in the git repository. Can we ask FreeType users what do they want to have and have simplified in API? What do they not need too? By users I mostly mean: - Cairo and Pango (Behdad ?) - Qt - fontconfig - ghostscript (Ken Sharp ?) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
At 10:26 30/08/2012 -0400, Alexei Podtelezhnikov wrote: Can we ask FreeType users what do they want to have and have simplified in API? What do they not need too? By users I mostly mean: - Cairo and Pango (Behdad ?) - Qt - fontconfig - ghostscript (Ken Sharp ?) Should be Chris Liddell for Ghostscript now, though (obviously) I'm still lurking and still interested :-) Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Thu, Aug 30, 2012 at 11:26 PM, Alexei Podtelezhnikov apodt...@gmail.com wrote: By users I mostly mean: - Cairo and Pango (Behdad ?) - Qt - fontconfig Since there are a discussion to support the Composite Font Representation in fontconfig, I'd like to see some APIs that fontconfig let FreeType know what real fonts they may requires or what's the better font if missing because CFR doesn't alllow to have the file path for an real font but PostScript font naming. This would gives us an opportunity to open CFR with FreeType directly and less changes in applications to support it. TIA, -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Indeed, I think FreeType3 should have some distinction of APIs between the APIs bound to real single font file, and APIs not bound to. Maybe I should investigate the existing software and make a list of referred APIs and their popularity. Regards, mpsuzuki Akira TAGOH wrote: On Thu, Aug 30, 2012 at 11:26 PM, Alexei Podtelezhnikov apodt...@gmail.com wrote: By users I mostly mean: - Cairo and Pango (Behdad ?) - Qt - fontconfig Since there are a discussion to support the Composite Font Representation in fontconfig, I'd like to see some APIs that fontconfig let FreeType know what real fonts they may requires or what's the better font if missing because CFR doesn't alllow to have the file path for an real font but PostScript font naming. This would gives us an opportunity to open CFR with FreeType directly and less changes in applications to support it. TIA, ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
I think FreeType3 should have some distinction of APIs between the APIs bound to real single font file, and APIs not bound to. Maybe I should investigate the existing software and make a list of referred APIs and their popularity. Please do so! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Is this because we ran out of FT_LOAD_XXX space? We used to control Freetype with flags, now it is this API. Potentially this is more flexible Freetype3 material. Any plans for Freetype3? It's been 12 years. Is it time yet for a spring cleaning? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On 08/29/2012 09:58 AM, Alexei Podtelezhnikov wrote: Any plans for Freetype3? I'm been thinking about that... ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Is this because we ran out of FT_LOAD_XXX space? This is one of the reasons, yes. Another one is that controlling modules with FT_LOAD_XXX simply doesn't feel right, since modules belong to FT_Library objects and not to FT_Face. Any plans for Freetype3? It's been 12 years. Is it time yet for a spring cleaning? Since I'm very bad at API design, I won't start such a project, but you are very welcome to discuss potential improvements, and it's very cheap to start a new branch in the git repository. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
The intended API looks like this now
FT_Error
FT_Property_Set( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Property_Get( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void**avalue );
which I'm going to implement the next few days.
And here it is. FT_Property_Get is slightly different now, namely
FT_Error
FT_Property_Get( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* value )
A first property for the auto-hinter, `glyph-to-script-map' (without
documentation yet), is implemented too. An application would do
something like the following:
/* the format of this structure is specific */
/* to the `glyph-to-script-map' property*/
typedef struct map_property_
{
FT_Face face;
FT_Byte* map;
} map_property;
map_property prop;
FT_Init_FreeType(library);
FT_New_Face(library, foo.ttf, 0, face);
prop.face = face;
error = FT_Property_Get(library, autofitter,
glyph-to-script-map, prop);
/* now use OpenType features to fix the glyph to script mapping */
/* returned in prop.map array */
FT_Done_FreeType(library);
I think that the interface is stable now. Please comment.
Werner
diff --git a/include/freetype/fterrdef.h b/include/freetype/fterrdef.h
index fb4b53b..bb06d79 100644
--- a/include/freetype/fterrdef.h
+++ b/include/freetype/fterrdef.h
@@ -4,7 +4,7 @@
/* */
/*FreeType error codes (specification).*/
/* */
-/* Copyright 2002, 2004, 2006, 2007, 2010-2011 by */
+/* Copyright 2002, 2004, 2006, 2007, 2010-2012 by */
/* David Turner, Robert Wilhelm, and Werner Lemberg. */
/* */
/* This file is part of the FreeType project, and may only be used, */
@@ -56,6 +56,8 @@
array allocation size too large )
FT_ERRORDEF_( Missing_Module, 0x0B, \
missing module )
+ FT_ERRORDEF_( Missing_Property,0x0C, \
+missing property )
/* glyph/character errors */
diff --git a/include/freetype/ftmodapi.h b/include/freetype/ftmodapi.h
index 4cb089d..b0dc113 100644
--- a/include/freetype/ftmodapi.h
+++ b/include/freetype/ftmodapi.h
@@ -42,14 +42,15 @@ FT_BEGIN_HEADER
/*Module Management */
/* */
/* Abstract*/
- /*How to add, upgrade, and remove modules from FreeType. */
+ /*How to add, upgrade, remove, and control modules from FreeType.*/
/* */
/* Description */
/*The definitions below are used to manage modules within FreeType. */
/*Modules can be added, upgraded, and removed at runtime.*/
+ /*Additionally, some module properties can be controlled also. */
/* */
- /*Here is a list of module names (the possible values of the */
- /*`module_name' field in the @FT_Module_Class structure).*/
+ /*Here is a list of possible values of the `module_name' field in*/
+ /*the @FT_Module_Class structure.*/
/* */
/*{ */
/* autofitter */
@@ -72,6 +73,7 @@ FT_BEGIN_HEADER
/* winfonts */
/*} */
/* */
+ /*Note that the FreeType Cache sub-system is not a FreeType module. */
/* */
/*/
@@ -274,6 +276,130 @@ FT_BEGIN_HEADER
FT_Module module );
+
Re: [ft-devel] controlling FreeType modules
Werner,
I know I'm fairly opinionated when it comes to library design, but thought
share my thoughts anyway. Personally I think FreeType's public API is largely
over-engineered, and the proposed property service is a big step in that
direction. As a user of the library, I don't care about modules,
services, or generic properties infrastructures. Just give me an enum for
the parameters that make sense, and a setter/getter. No need to reinvent a
property system in C.
My 0.02CAD,
behdad
On 07/28/2012 01:51 AM, Werner LEMBERG wrote:
Toshiya-san and I have met in Osaka, and we have enjoyed a great time
visiting the private museums of Motoya and Morizawa, two big font
companies in Japan.
While having a nice lunch, we've discussed how to control modules in
FreeType. In FreeType's `autohinter-properties' branch, I've posted a
first draft of how an interface might look like. However, this is far
from sufficient, and it is special to the auto-hinter only, while we
need a more generic solution to control any module.
So here is another proposal for an interface.
Property service
Properties get accessed with FreeType services. For example, to
make the module `foo' listen to property changes, add a
`foo-properties' service to the module, with two functions to get
and set values.
Default properties
--
Internally, we use an `FT_Property' structure to collect all
properties in a linked list:
typedef FT_Property_
{
FT_String*module_name;
FT_String*property_name;
void* value;
FT_Property* next;
} FT_Property;
The list is located in the `FT_Library' object:
FT_Property* properties;
Allocation and deallocation of `properties' is handled by FreeType.
As soon as a new `FT_Face' object gets created, the corresponding
modules check the `properties' list and use it for initialization.
There might be properties which are not suitable for global
initialization; such cases are to be ignored (with a debugging
warning probably).
Already existing `FT_Face' objects are not affected.
FT_Error
FT_Library_SetProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Library_RemoveProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name );
FT_Error
FT_Library_GetProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* avalue );
The generic pointer `value' gets typecast to a pointer of the real
value variable or structure. Maybe not the most convenient, it
guarantees flexibility and extensibility, however.
Local properties
These are located in an FT_Face object. Existing values for
properties get overwritten.
FT_Error
FT_Face_SetProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Face_RemoveProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name );
FT_Error
FT_Face_GetProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name,
void* avalue );
Examples
/***/
/* Set property `bar' in module `foo' to value 1. */
FT_UInt bar;
bar = 1;
FT_Face_SetProperty( face, foo, bar, bar );
/***/
/* Get property `baz', which consists of a minimum and maximum */
/* value. */
typedef range_
{
FT_Int32 min;
FT_Int32 max;
} range;
range baz;
FT_Face_GetProperty( face, foo, baz, baz );
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
I know I'm fairly opinionated when it comes to library design, but thought share my thoughts anyway. Personally I think FreeType's public API is largely over-engineered, well... This is definitely not my fault :-) and the proposed property service is a big step in that direction. As soon as you are up to date with reading the FreeType email list postings, you will have seen my other email. Now there are only two functions, FT_Property_Set and FT_Property_Get. As a user of the library, I don't care about modules, services, or generic properties infrastructures. You don't have to. Services is something internal to FreeType, not visible by the application. The module API already exists, and it is central to FreeType, so I will continue with addressing properties using module names. Just give me an enum for the parameters that make sense, and a setter/getter. Hmm. Instead of an enum like FT_AUTOFITTER_DO_THIS_AND_THAT you will have to use two arguments, autofitter and do-this-and-that, so I don't see a big difference, neither in understanding nor typing. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
What are the void* pointers typically expected to point to...?
Property data structures.
As I suppose these void* values are often pointers to some malloced
memory in many cases, how is it expected that resource management of
that memory is done...? I.e., when the a list gets destroyed
because a FT library is destroyed, who's responsible for cleaning up
the pointed-to property data?
FreeType. If there is ever a need to pass a new string to the library
(for which I currently don't have a use case), the data will be
copied.
property tends to bring to mind simple things like numeric or
string settings. Strings could I suppose passed directly; how about
numbers?
Here's a typical example. Let's say I want to control the range where
the auto-hinter rounds the hinted size more easily to larger integers.
typedef range_
{
FT_Int32 min;
FT_Int32 max;
} range;
range increase_x_height = { 6, 22 };
FT_Property_Set( library, autofitter, increase-x-height, range );
Another example is to get a pointer to the auto-hinter's internal
`glyph_script' array which holds a map between glyph indices and its
assigned scripts. The idea is to fix entries which need OpenType
support (for example, small caps or superscripts which are normally
not visible in the cmap).
typedef glyph_idx_to_script_
{
FT_Long count;
FT_Byte* scripts;
} glyph_idx_to_script;
void* v;
glyph_idx_to_script* map;
FT_Long idx;
FT_Property_Get( library, autofitter, glyph-to-script-map, v );
map = (glyph_idx_to_script*)v;
/* change an entry */
idx = 12;
if ( idx map-count )
map-scripts[idx] = AF_SCRIPT_LATIN;
Structures like `range' or `glyph_idx_to_script' are predefined.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Werner LEMBERG w...@gnu.org writes: What are the void* pointers typically expected to point to...? Property data structures. As I suppose these void* values are often pointers to some malloced memory in many cases, how is it expected that resource management of that memory is done...? I.e., when the a list gets destroyed because a FT library is destroyed, who's responsible for cleaning up the pointed-to property data? FreeType. If there is ever a need to pass a new string to the library (for which I currently don't have a use case), the data will be copied. Wait how does that work? That suggests that freetype will copy any structure passed in into malloced memory or something; otherwise, one couldn't pass in any dynamically calculated values. But since (AFAICT) the property mechanism is generic, the type of the data structure wouldn't be known except to the eventual caller of FT_Property_Get. Given this, how can FT_Property_Set know the size of the data structure passed in, to malloc/copy it? Thanks, -miles -- Love is the difficult realization that something other than oneself is real. [Iris Murdoch] ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
FreeType. If there is ever a need to pass a new string to the
library (for which I currently don't have a use case), the data
will be copied.
Wait how does that work?
That suggests that freetype will copy any structure passed in into
malloced memory or something; otherwise, one couldn't pass in any
dynamically calculated values.
Yes.
But since (AFAICT) the property mechanism is generic, the type of
the data structure wouldn't be known except to the eventual caller
of FT_Property_Get. Given this, how can FT_Property_Set know the
size of the data structure passed in, to malloc/copy it?
The property mechanism has a generic interface to accept any data
structures so that it stays extensible, but the data structures
themselves aren't generic; they are always controlled by FreeType.
For example, to pass a string of arbitrary length, a possible
structure might be
struct foo
{
intlen;
char* str;
}
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
2012/8/22 Werner LEMBERG w...@gnu.org: But since (AFAICT) the property mechanism is generic, the type of the data structure wouldn't be known except to the eventual caller of FT_Property_Get. Given this, how can FT_Property_Set know the size of the data structure passed in, to malloc/copy it? The property mechanism has a generic interface to accept any data structures so that it stays extensible, but the data structures themselves aren't generic; they are always controlled by FreeType. Sure. I'm just confused how FT_Property_Set figures out the length, presuming it's FT_Property_Set that does the copying (I'm guessing it would have to be, as the caller of FT_Property_Set is outside of freetype, and the actual point of use of the data structure, which obviously would know the type, is too late). Thanks, -miles -- Cat is power. Cat is peace. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
What are the void* pointers typically expected to point to...? As I suppose these void* values are often pointers to some malloced memory in many cases, how is it expected that resource management of that memory is done...? I.e., when the a list gets destroyed because a FT library is destroyed, who's responsible for cleaning up the pointed-to property data? property tends to bring to mind simple things like numeric or string settings. Strings could I suppose passed directly; how about numbers? -Miles -- 97% of everything is grunge ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Folks, it's embarassing, but I've screwed up my property proposal. The reason is quite simple: While designing and discussing the interface, I haven't looked closely enough at the source code, and only now I have discovered the discrepancy between my faulty memory and the reality... However, not everything is wrong. This one Property service Properties get accessed with FreeType services. For example, to make the module `foo' listen to property changes, add a `foo-properties' service to the module, with two functions to get and set values. stays the same, while this Default properties -- Internally, we use an `FT_Property' structure to collect all properties in a linked list: [...] doesn't work. Fact is that modules can only be controlled at the FT_Library level; FT_Face objects simply use pointers into an FT_Library's module list. This has two consequences: (1) The suggested API is much simpler. (2) Changes to modules have an immediate effect to *all* FT_Face objects, including the ones already created. If you want to have FT_Face objects with different module settings, simply use another FT_Library object. If memory is a concern it is possible to only load selected modules into this new FT_Library object instead of the default ones, as discussed in the FreeType documentation. The intended API looks like this now FT_Error FT_Property_Set( FT_Librarylibrary, const FT_String* module_name, const FT_String* property_name, void* value ); FT_Error FT_Property_Get( FT_Librarylibrary, const FT_String* module_name, const FT_String* property_name, void**avalue ); which I'm going to implement the next few days. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Hello Toshiya-san! Sorry for the late response. At present, FTC_Manager instance is allocated with FT_Library's allocator, FT_Library object itself does not have a (list of) FTC_Manager, so, it could be slightly difficult for set- property functions to invoke the cache flusher. There might be 2 ways: A) set-property function does not invoke the cache flusher, but sets some internal flags in FT_Library or FT_Face to indicate the change of the properties. when the cache is accessed, the cache manager checks the flag and flush if needed. B) put a list of FTC_Manager instance(s list) into FT_Library. if set-property functions are used, FT_Library instances invoke the cache flusher of the listed FTC_Manager instance(s). Which is better? What about C) If an application uses FreeType's cache system, it should call `FTC_Manager_Reset' to flush the cache. ? This sounds rather straightforward to me, and it fully avoids any internal hassles. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] controlling FreeType modules
Toshiya-san and I have met in Osaka, and we have enjoyed a great time
visiting the private museums of Motoya and Morizawa, two big font
companies in Japan.
While having a nice lunch, we've discussed how to control modules in
FreeType. In FreeType's `autohinter-properties' branch, I've posted a
first draft of how an interface might look like. However, this is far
from sufficient, and it is special to the auto-hinter only, while we
need a more generic solution to control any module.
So here is another proposal for an interface.
Property service
Properties get accessed with FreeType services. For example, to
make the module `foo' listen to property changes, add a
`foo-properties' service to the module, with two functions to get
and set values.
Default properties
--
Internally, we use an `FT_Property' structure to collect all
properties in a linked list:
typedef FT_Property_
{
FT_String*module_name;
FT_String*property_name;
void* value;
FT_Property* next;
} FT_Property;
The list is located in the `FT_Library' object:
FT_Property* properties;
Allocation and deallocation of `properties' is handled by FreeType.
As soon as a new `FT_Face' object gets created, the corresponding
modules check the `properties' list and use it for initialization.
There might be properties which are not suitable for global
initialization; such cases are to be ignored (with a debugging
warning probably).
Already existing `FT_Face' objects are not affected.
FT_Error
FT_Library_SetProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Library_RemoveProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name );
FT_Error
FT_Library_GetProperty( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* avalue );
The generic pointer `value' gets typecast to a pointer of the real
value variable or structure. Maybe not the most convenient, it
guarantees flexibility and extensibility, however.
Local properties
These are located in an FT_Face object. Existing values for
properties get overwritten.
FT_Error
FT_Face_SetProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Face_RemoveProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name );
FT_Error
FT_Face_GetProperty( FT_Face face,
const FT_String* module_name,
const FT_String* property_name,
void* avalue );
Examples
/***/
/* Set property `bar' in module `foo' to value 1. */
FT_UInt bar;
bar = 1;
FT_Face_SetProperty( face, foo, bar, bar );
/***/
/* Get property `baz', which consists of a minimum and maximum */
/* value. */
typedef range_
{
FT_Int32 min;
FT_Int32 max;
} range;
range baz;
FT_Face_GetProperty( face, foo, baz, baz );
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
