I think we are taking the only reasonable route available w.r.t. complex script support, namely reading the OTF font directly to extract and use the advanced typographic tables. The same mechanisms can be used for the TTF AAT tables as well.
The inquiry that started this thread seems most interested in CFF support, and not complex scripts. However, I haven't looked into what is needed to add CFF support. G. On Wed, Jan 19, 2011 at 4:10 AM, Jeremias Maerki <d...@jeremias-maerki.ch>wrote: > I agree, native libraries would be a pain. BTW, interested parties could > take a look at Apache FontBox's CFF support. That's part of Apache > PDFBox. Maybe that could be used or adapted. > > On 19.01.2011 11:59:18 Craig Ringer wrote: > > On 19/01/11 16:35, Simon Pepping wrote: > > > I take this discussion to express my worries that FOP needs to create > > > its own support for fonts, among which Open Type Fonts. FOP's core > > > task is the layout and printing of FO files. If FOP could rely on good > > > font libraries, that would make our code base so much smaller and our > > > development tasks so much easier. > > > > > > If I am not mistaken, Firefox does a fairly good job at representing > > > Indic scripts. Do they use a generally available library? > > > > There are several libraries for "complex" scripts, including the > > commonly-used libbidi and pango libraries. All the widely used ones that > > I know of are C- or C++ libraries. > > > > While Java can use C and C++ libraries, a Java Native Interface (JNI) > > layer must be written. Further, JNI code and the libraries it uses must > > be compiled separately for each supported platform and architecture, > > making packaging and deployment of the Java code a ***PAIN*** unless all > > the native code parts are shipped as part of the JDK/JRE. > > > > Even allowing for the issues with complex/bidi libraries, Apache FOP > > must also handle the OpenType font format its self, including support > > for font subsetting and embedding. That's way outside the scope of > > complex script and bidi libraries. While library code exists to help > > with OpenType handling, I'm not aware of any even C or C++ libraries > > that provide useful, fairly abstracted facilities for subsetting and > > embedding without tying them in to related PDF libraries. > > > > While Java its self can use OpenType fonts, it doesn't expose the > > details of its OpenType parser etc to Java applications. In any case, it > > may use the platform's font support rather than bundling its own. Java > > apps need to provide their own OpenType format handling if they want to > > do more than just use the fonts with Graphics2D and the other Java > > rendering APIs, because there's no way to get to the "guts" of the fonts > > loaded by the JVM. > > > > > > Ideally, Apache FOP could be built on top of: > > > > - A low-level Java font format and parsing library that can identify > > fonts, enumerate tables and glyphs, detect features, etc. > > > > - A low-level Java PDF library that handles the PDF document structure, > > xref and indirect object management, PDF data structure representation, > > direct-to-disk streaming of big images into PDF object streams, etc etc. > > > > - A Java library that uses both of the above to provide features for PDF > > embedding of OpenType and TrueType fonts. > > > > > > Unfortunately, AFAIK *NONE* of them exist, or at least are used, at > > present. Fop seems to have its own PDF output code and own font handling > > code. I don't see any obviously advantagous 3rd party replacements for > > the font handling code, and most of the 3rd party PDF engines (like > > iText) appear to be a bit limited when you want to insert your own > > low-level PDF content stream data, objects, etc to implement features > > not supported directly by the PDF library you're using. > > > > I was looking into this a little myself while checking to see how hard > > it'd be to implement /DeviceCMYK and /ICCBased colour in FOP. Because of > > the way FOP stores and manages colour internally, the answer appears to > > be "very" at present, especially if you want to support PDF/X > > requirements and handle CMYK passthrough. > > > > -- > > System & Network Administrator > > POST Newspapers > > > > > Jeremias Maerki > >
