Apache FOP is a print formatter driven by XSL formatting objects

It used to be possible to provide default page dimensions on a per-UA basis. This was useful because the needed page dimensions may change for different runs (Fop instances) in the same application (same FopFactory instance). An application of mine needs this: the page dimensions are set to whatever the user previously entered in the Page Setup dialog.

Since FOP 2.0, however, this is no longer possible, because there is no public or protected constructor to the FOUserAgent class. In my use case, that means there is no way to override the getPageWidth and getPageHeight methods.

This PR makes FOUserAgent's constructor protected and take only a FopFactory parameter (so the resolver is still taken from the FopFactory). Applications needing to customize FOUserAgent's behavior can now do so.

This is the same as the patch attached to FOP-2729.

The XSL processor attempts to reach out to the internet to resolve URIs in XSLT source files. This happens because the URIResolver is not registered on the TransformerFactory when it creates a Transformer instance for a given XSLT source.

This fix assigns the URIResolver to the TransformerFactory (which then gets assigned to any Transformer created from that factory) rather than on the Transformer. This change allows the processor to resolve URIs in the XSLT source when the source is being loaded.

This patch also registers the InputHandler as an ErrorListener for the TransformerFactory so that any errors that occur while loading the XSLT are logged consistently.

This applies the patch brought forward by Neil Smeby in https://issues.apache.org/jira/browse/FOP-2704. In short, it works around the UnsupportedOperationException: coverage set class table not yet supported exception when trying to use Google's Roboto font (updated 2017).

Maven ${version} placeholders are replaced with plain versions to work around a potential issue in Jitpack.io.

See https://jitpack.io/#webfactory/fop/da392ffca how you can easily give this patch a try with your preferred build system.

java.awt.image.BufferedImage.getAlphRaster() return null if an IndexColorModel is used. This resulted in those PNGs missing the SMask and had broken transparency effects.

PNG images with indexed color palette featuring tRNS transparency encoding had potentially wrong PDF Mask. If image contained transparency but no fully transparent pixel, then the default implementation of PDFImageXObject still generates a Mask entry with three color components. PDF Specification expects the index when using a palette based color model. Thus Acrobat Reader does not process this image and shows error message. In general ImageRenderedAdapter would overwrite this Mask, but since AbstractImageAdapter.getIndexOfFirstTransparentColorInPalette() does return null if image does not contain fully transparent pixels the more general implementation of PDFImageXObject leaks to the output.

I removed avalon (a project that is dead for over a decade now) from the code base. For this to happen, I've written a clean-room (i.e. I didn't looked at the avalon code) implementation of the few bits of avalon that are still in use by FOP. After that I fixed the tests.

Apart from some minor stuff that is only used for testing, the main thing of avalon that was still in use was the Configuration stuff.

I also renamed the packages name of the (now embeded) avalon stuff like this:

• org.apache.avalon.framework.configuration moved to org.apache.fop.configuration
• org.apache.avalon.framework.activity moved to org.apache.fop.activity
• org.apache.avalon.framework.containeralso moved to org.apache.fop.activity

This rename is completely optional, i.e. if there are concerns against it, I will update my change request and keep the original package names.

I would be glad if you could consider my patch for merge into the trunk branch.

Kind regards,

aanno

References https://issues.apache.org/jira/browse/FOP-2815.

• Replaces deprecated SimpleLog with LogFactory. The LogFactory gets set when the logger is null. The logging level is also set to INFO (value: 800).
• Bumped the parent pom to 2.4.1-SNAPSHOT.

The method just returns one field "params" of the current class, thus method name "getParams" should be better than "build".

ApacheFOP treats surrogates pairs as 2 different codepoints. Most of the methods accepts/returns a single char (Eg Typeface.mapChar(char c)) which mean they can deal only with BMP characters (<= 0xFFFF).

In order to correctly handle the non-BMP characters (Eg: Emoji, Mathematical symbols, ancient scripts, CJK extensions) ApacheFOP should deal with int rather then char. It is possible to represent the whole Unicode range using a single int while it is not possible with a single UTF-16 char.

These are the 3 main aspects of this modification:

1. Read the non-BMP glyphs from the font
2. Make the API to use int instead of char
3. Convert surrogate pairs to a single int
4. Adapt the renderer

Read the non-BMP glyphs from the font

The glyph information are stored in one of the font CMAPs tables. The implemented one is:

• PlatformID: 3 (Microsoft)
• EncodingID: 10 (Unicode UCS-4)
• CMAP format: 12 (Formats 8, 10, and 12, 13, and 14 are used for mixed 16/32-bit and pure 32-bit mappings. This supports text encoded with surrogates in Unicode 2.0 and later)

Apple TrueType Reference Manual: (https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html)

Make the API to use int instead of char

Such modification would mainly affects the Font classes hierarchy. The Typeface class is one of the base classes of the Font Hierarchy and is one of the classes that should be modified. It has though (as of September 2016) approximately 27 subclasses/implementations which would make the scope of the modification pretty huge.

Since not all the font classes are supposed to deal with non-BMP codepoints it is possible to narrow down the the scope of the modification to a lower number of classes. This is supposed to be just a step that allow to have at least a working path to handle surrogate pairs.

The class identified as good point to start is CIDFont as a CID Fonts has been designed to handle huge character sets. From Adobe documentation: "CID fonts are a new format of composite (multibyte) Type 1 fonts that better address the requirements of Far East markets. Adobe developed the CID-keyed font file format to support large character set fonts..." (src: http://www.adobe.com/products/postscript/pdfs/cid.pdf).

FontMetrics
    Typeface
        SystemFontMetricsMapper
        LazyFont
        AFPFont
            RasterFont
            AbstractOutlineFont
                DoubleByteFont
                OutlineFont
                    AFPTrueTypeFont in AFPFontConfig
        Base14Font
            Helvetica
            Symbol
            HelveticaBoldOblique
            HelveticaOblique
            HelveticaBold
            ZapfDingbats
            Courier
            CourierBold
            TimesBold
            TimesBoldItalic
            TimesItalic
            TimesRoman
            CourierOblique
            CourierBoldOblique
        CustomFontMetricsMapper
        CustomFont
            SingleByteFont                + hasCodePoint(int):boolean
            CIDFont   <------------------ + mapCodePoint(int):int
                MultiByteFont

                                         ~ getUnicode(int):char -> getUnicode(int):int
CIDSet (Used by CIDFont) <-------------- + mapCodePoint(int, int):int
    CIDSubset
    CIDFull
                                          + hasCodePoint(int):boolean
Font <----------------------------------- + mapCodePoint(int):int

getUnicode(): is defined in CIDSet (is not a property of the Typeface class or one of its subclasses). I changed the firm of this method to handle int instead of char because it is semantically incorrect to represent unicode with a single UTF-16 char. As you can see from the CIDSet hierarchy the change affect only 3 classes.

getUnicodeFromGID(): this method is defined in CustomFont and CIDSet. It never get called from the MultiByteFont path, probably because getUnicode is used instead. That is why I'm down casting the return value from int to char in CIDFull and CIDSubset. Probably the best thing to do would be to get rid of this method or make it handle int, but again the change would affect more classes then the ones in the scope.

Convert surrogate pairs to a single int

The data arrives as String and non-BMP characters are represented as surrogate pairs. Every time some operation is performed on the data (eg. Font.mapCodePoint(int)) surrogate pairs should be converted to the corresponding code point.

The current implementation make this conversion inside the for loops used to deal with the data:

for (int i = 0, i < text.length(); i++) {
    int cp = text.charAt(i);

    if (CharUtilities.containsSurrogatePairAt(text, i)) { // Throw an exception if it is an ill-formed surrogate pair
        c = Character.toCodePoint((char) c, text.charAt(++i));
    }
    [...]
}

or

for (int i = 0, i < text.length(); i++) {
    int cp = text.codePointAt(i); // Java API, do NOT throw error if it is an ill-formed surrogate pair

    i += CharUtilities.incrementIfNonBMP(orgChar);
    [...]
}

The best thing to do in future is implement something like the Java8 API String.codepoints() which allow you to directly iterate through a stream/array of codepoints avoiding boilerplate code.

Adapt the Renderer

Every ApacheFOIP output format has it's own way to represent data which means that each renderer need to be adapted to handle non-BMP codepoints.

The adapted Renderer/Painters are:

PDFPainter PSPainter Java2DPainter Java2DRenderer

…ages in PDF export

java.awt.image.BufferedImage.getAlphRaster() return null if an IndexColorModel is used. This resulted in those PNGs missing the SMask and had broken transparency effects.

PNG images with indexed color palette featuring tRNS transparency encoding had potentially wrong PDF Mask. If image contained transparency but no fully transparent pixel, then the default implementation of PDFImageXObject still generates a Mask entry with three color components. PDF Specification expects the index when using a palette based color model. Thus Acrobat Reader does not process this image and shows an error message. In general ImageRenderedAdapter would overwrite this Mask, but since AbstractImageAdapter.getIndexOfFirstTransparentColorInPalette() does return null if image does not contain fully transparent pixels the more general implementation of PDFImageXObject leaks to the output. This has been fixed.

Beforehand, the SVGDocumentHandler could not be used directly and had to be overwritten in the way, how the getConfigurator() method is over- written. Also fonts could not be embedded without the configurator.

The foUserAgent can now be modified in the way: foUserAgent.setRendererOverride(new SVGRenderer(foUserAgent)); foUserAgent.setDocumentHandlerOverride(new SVGDocumentHandler(IFContext context);

After that, the FopFactory.newFop(..) can be called and the transformation can be done.

This prevents

<4>Batik not in class path
<4>java.lang.NoClassDefFoundError: org/w3c/dom/svg/SVGDocument
<4>    at java.base/java.lang.ClassLoader.defineClass1(Native Method)
<4>    at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
<4>    at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)

This method seems to find a "Property" related to the fo.getNameId(). Hence, the new name "getNameId" should be better than "make".

Allow to override build date with SOURCE_DATE_EPOCH in order to make builds reproducible. See https://reproducible-builds.org/ for why this is good and https://reproducible-builds.org/specs/source-date-epoch/ for the definition of this variable.

This patch was done while working on reproducible builds for openSUSE.

Note: probably only a partial fix towards reproducible pdf output / https://issues.apache.org/jira/browse/FOP-2854

As described here https://issues.apache.org/jira/browse/FOP-2858?filter=-2, this patch fixes the font name localization problem, which prevents guessWeight/Style methods from working as they are based on english keywords.

This is a re-post of #59 which was apparently closed by an automatic process and/or due to a force-push on the fop-2_3 branch?

It applies the patch brought forward by Neil Smeby in https://issues.apache.org/jira/browse/FOP-2704. In short, it works around the UnsupportedOperationException: coverage set class table not yet supported exception when trying to use Google's Roboto font (updated 2017).

See https://jitpack.io/#webfactory/fop/48e0a1567 how you can easily give this patch a try with your preferred build system.