Hi, Sorry for lated response.
On Mon, 4 Dec 2006 09:32:19 -0800 "Camp, TracyX E" <[EMAIL PROTECTED]> wrote: >I'm working on an effort to include the full 'font stack' in the LSB >(Linux Standards Base see: http://www.freestandards.org/). I appreciate Intel's interest in OSS font issues. >FreeType is obviously an important component of the de-facto 'font >stack' (along with Pango, fontconfig, Xft and XRender) on linux based >systems. Since LSB release 3.1, LSB has included fontconfig and Pango. >For the upcoming LSB 3.2 release we would like to include freetype, Xft >and XRender (XRender is complete). cairo will be included in LSB? >So a few questions: > >1) comments concerns, about putting FreeType's ABI into LSB? I have 3 questions. 1-a: I don't think LSB is defigned for pure OSS system. ------------------------------------------------------- Although I don't know actively-maintained project at present, there had ever been several attemps to provide commercial font rasterizers (or framework to work with commercial font rasterizers) onto Linux. For example, Bitstream had proposed btX2 (which supports some non-disclosured font formats), Sun had proposed STSF which can encapsule the detailed implementation of font rasterizer. Concrete definition of FreeType2 into LSB would distance such attempts from Linux. How do you think of? 1-b: FreeType2 is now modularized --------------------------------- Now FreeType2 is modularized and the developer can remove the font driver for the formats which they don't care, for example, PFR, WINFONT etc. In fact, it is possible to build FreeType2 without TrueType font driver. I wish if LSB "requires" the module checking method, and "propose" several font formats to be supported. 1-c: Softwares using builtin FreeType ------------------------------------- Now FreeType2 does not install the internal header files used in building libfreetype. These header files should not be included in building other softwares, but there are many softwares doing such. Turner researched and provided patches for many softwares: http://www.freetype.org/freetype2/patches/rogue-patches.html , there are many softwares which includes legacy freetype source code (or modified version of legacy freetype source code). Such software is simply out of scope? >2) Are there areas of the FreeType API that would be best left out? Does LSB mention about hinting, subpixel rendering for LCD? Current FreeType2 provides patent-free hinting system which enables life without patent issue, but a few CJK fonts cannot be displayed without genuine patented hinting. Some liberated GNU/Linux distributions want to disable patented hinting, but there are people who want libfreetype.so to include patented hinting by default (because there are a few commercial CJK fonts that cannot be displayed without patented hinting). I'm not familiar with patent for subpixel rendering, but I think the quality of subpixel rendering in FreeType2 is still under development for better quality. I'm not sure whether it is good idea to put it into "required" feature in LSB. >3) Are there any upcoming ABI breakage concerns? It might be out of LSB interest, the APIs defined in ftmac.h is not recommended (because it uses Carbon specific data types). -- I have another concern: at present, freetype-config, freetype2.pc and header files are configured for single architecture. Some distributions supporting dual architecture (e.g. amd64/i386) want to share such developer files. If dual architechture support is defined in LSB, I want to ask: 1. the location of runtime libraries for native and emulated architectures 2. the location of developer libraries for native and emulated architectures 3. the location of header files for native and emulated architectures 4. if the header files are shared for multiple architectures, there's any reliable cpp-conditional to specify an architecture? Regards, mpsuzuki _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel