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

Reply via email to