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
