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

Reply via email to