Calculating the intersection of two Area can take a lot of time. However, depending on the Graphics2D that is used for rendering, it may not be necessary to actually perform this operation.

For instance, when generating an SVG, the individual clipping paths can be serialized individually, and the intersection is then calculated at runtime, when the SVG file is rendered.

The idea of this PR is to replace PDGraphicsState.clippingPath with a list of GeneralPaths, which is lazily evaluated, truncated & cached when getCurrentClippingPath() is called (effectively leaving the current behaviour of PdfBox unchanged, and it should also not have any significant impact on the performance).

Additionally, a new method protected void transferClip(PDGraphicsState graphicsState, Graphics2D graphics) is added to PageDrawer. By default, this method makes use of getCurrentClippingPath() to call graphics.setClip(...), which again is what PdfBox currently does.

However, classes that extend PageDrawer can override this method, and directly access the individual clipping paths, without any need to calculate their intersection.

In some cases (shading fills & transparency groups), it is still necessary to calculate the intersection.

Less data copy operations over all. Linewise bulk copy instead of per pixel.

The softMask / matte calculation might need to be checked. I have only found one PDF in https://issues.apache.org/jira/browse/PDFBOX-4267

There was a severe performance issue with really big masks if the image needs to be scaled to it (i.e. 10000*10000 pixels). Scaling bicubic can take 6-10 seconds. This patch tries to switch to bilinear resizing for these cases, although the threshold might have to be fine tuned, still.

There was also a double allocation for the final masked image when we can simply use the image since applyMask() is always fed with a newly created one. Reference hogging and needless allocation have been removed.

Additionally the alpha blending routines were very slow, working on pixels. There is now a staggered approach by:

• direct byte masking which is very fast even for big images (right now does not work with padded buffers),
• exploiting data buffer's sample system to merge the alpha component into the ARGB image, letting the sample model do the bit masking,
• slow pixel expansion to reverse premultiply matte values (but using fixed point integer arithmetics).

Additionally also using the interpolation flag of the mask to decide if the mask should be interpolated.

Implemented proper rendering of Indian languages, which need extensive Glyph substitution. The GSUB table has been read and used effectively to replace some compound words with their respective Glyphs. All tests are passing. I have tested this for the Bengali font. Please review these changes and let me know if it makes sense to incorporate these.

Thanks, Palash.

This PR adds a GitHub workflow to enable checks from all JDKs from version 8 to 15.

The output of GitHub actions is better integrated in GitHub. Furthermore, the errors are highlighted better:

I want to propose the following update of the CCITT decoder.

We had a few fixes since the version from 2016. Futher I later helped to use the decoder in ICEpdf and did some changes for the EncodedByteAlign-Flag.

This PR fixes the potential flaky test in PDFObjectStreamParserTest.java file.

In the test testOffsetParsing(), we convert the keys of objectNumbers to the array and assign this array to numbers.

class PDFObjectStreamParserTest
{
    @Test
    void testOffsetParsing() throws IOException
    {
        COSStream stream = new COSStream();
        stream.setItem(COSName.N, COSInteger.TWO);
        stream.setItem(COSName.FIRST, COSInteger.get(8));
        OutputStream outputStream = stream.createOutputStream();
        outputStream.write("1 0 2 5 true false".getBytes());
        outputStream.close();
        PDFObjectStreamParser objectStreamParser = new PDFObjectStreamParser(stream, null);
        Map<Long, Integer> objectNumbers = objectStreamParser.readObjectNumbers();
        assertEquals(2, objectNumbers.size());
        Long[] numbers = objectNumbers.keySet().toArray(new Long[0]); // <<<<<<<<<<<<<<<< LINE: 48
        objectStreamParser = new PDFObjectStreamParser(stream, null);
        assertEquals(COSBoolean.TRUE, objectStreamParser.parseObject(numbers[0]));
        objectStreamParser = new PDFObjectStreamParser(stream, null);
        assertEquals(COSBoolean.FALSE, objectStreamParser.parseObject(numbers[1]));
    }
}

However, as the objectNumbers is initialized as a HashMap, it is not guaranteed that the order will remain constant over time according to the Java documentation.

This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time.

Such indeterministic characteristic of HashMap will cause this test to fail in some platforms or specific machines that adopt a different iteration order.

To fix it, I looked over our codebase and thought it was doable to initialize our objectNumbers as a LinkedHashMap rather than HashMap. In this way, the line 48 (variable numbers) in PDFObjectStreamParserTest.java file will always be deterministic.

This function writes bytes as ascii characters directly to the page.

For use cases where only ascii text needs to be written, this solves a few problems:

1. Avoids the "No glyph for X" issue (eg https://stackoverflow.com/questions/42228567/remove-illegal-characters-from-string-with-pdfbox).
2. While it's possible to pre-process text before using showText(), this means the data will be looped through at least twice since PDFont.encode() loops the text.
3. Preforms better. Everything can be kept as bytes without having to go to text

Benchmarks vs showText(): 2000 page pdf: showText(): 579ms / writeAscii(): 419ms 1000 page pdf: showText(): 283ms / writeAscii(): 193ms

This fixes an issue with a missed logged error + loop breaking if an erroneous read falls onto a skipped row.

It also improves the speed at least by factor twice (due to sign test instead of bit masking and boolean flag for subsampling). It will be even faster with regions, as there was a poor design choice of full inner loop computations even if x was below startX.

(The method wasn't very slow to begin with, though.)

• Add final
• Unnecessary semicolon ';'
• Remove Unnecessary interface modifier
• Remove Unnecessary semicolon
• Remove Unused import
• Use Standard Charset Object
• Change License to Text Plain

Hi,

I ran JaCoCo over the pdfbox module, and found a few functions that were missing unit test coverage.

I've written some tests for these functions, with the help of Diffblue Cover.

Hopefully these tests should help you detect regressions caused by future code changes.

Based on https://github.com/danfickle/pdfbox See examples/src/main/java/org/apache/pdfbox/examples/pdmodel/AdvancedTextLayoutSequencesDin91379.java

Glyph layout looks good with NotoSans-Regular. Combinations with two diacritics work after reordering glyphs, using the patch for FOP-2969 and setting gdef in GlyphPositioningTable.

Output of test is now: TestDin91379AdvancedLayout-NotoSans-Regular.ttf-20.0.pdf

Finalizers (method finalize()) are going to be deprecated for removal with JDK 18. See https://openjdk.java.net/jeps/421 for details.

The best way to replace the finalize() methods is by using the JDK 9 java.lang.ref.Cleaner. As PDFBox 3 targets JDK 8 this can not be used directly.

The attached patch implements a Cleaner using finalizers for JDK <= 8 and using java.lang.ref.Cleaner by reflection for JDK 9+.

The two remaining finalize() implementing classes are migrated to the new Cleaner.

I’m not really happy with the name and package org.apache.fontbox.util.PdfBoxInternalCleaner of the cleaner. Maybe you have an idea for a better place and name.

In theory this patch could be back ported to PDFBox 2, but I’m not sure if this is worth the risk.

Jira

• PDFBOX-5284

Description

Replace test class PDFTabulaTextStripper by spying object and improve test design

Motivation

• Decouple test class PDFTabulaTextStripper from production class PDFTextStripper.
• Remove the redundant test child class PDFTabulaTextStripper
• Remove the redundant constructor.

Key changed/added classes in this PR

• Created spying object to replace test subclass PDFTabulaTextStripper, decoupled test from production code.
• Created method that return the mocking object for code reuse.

The XMP box library is nice, but out in the wild are PDF files that fail parsing. For example dc.create is a Bag instead of a Seq.

Ideally the parser would have a mode where it tries to read as many properties as possible by simply discarding unreadable ones. This is not good if you want to write back a PDF but if you just want to extract Metadata, such a mode would be nice. In this case this invalid dc.creator value would be dropped. This would require doing some more work.

I've seen that there is a non strict parsing mode, which I don't think should be confused with this proposed lenient mode, but as the name suggests it should be less strict. So in this mode Sequences could be read fom Bags and vice versa. I left Alt cardinality as an error because it doesn't really fit in.

Maybe in one of the modes an element that should be an array but isn't could automagically be wrapped into one...

(I also believe that a Bag could always be read from a Sequence...)