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
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 > 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
On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell 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
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
