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