Add Image rendering callback

[andreasrosdal]

A OpenPDF user has requested support for an Image rendering callback function.

"I've been trying to migrate from iText v5.5.11(License version) library to OpenPDF v1.2.8(Open Source) library.I think that both are having similar functionalities. But,the renderImage function from iText library is missing in OpenPDF library and I'm in need of an alternative function in OpenPDF library" Source: https://stackoverflow.com/questions/54408620/itextpdf-to-openpdf-integration

What is the use-case? what does this user want to do, which is currently not possible in OpenPDF?

[Kindrat]

There is note in iText we don't call invokeOperator for embedded images - this is one area of the PDF spec that is particularly nasty and inconsistent. For inline images they do not call operator to draw, rather this callback only.

I think that is a major change to existing pdf processing, as it differs much from what is in iText. How much can we copy/move from their codebase?

com.itextpdf.text.pdf.parser

try {
            PRTokeniser tokeniser = new PRTokeniser(new RandomAccessFileOrArray(new RandomAccessSourceFactory().createSource(contentBytes)));
            PdfContentParser ps = new PdfContentParser(tokeniser);
            ArrayList<PdfObject> operands = new ArrayList<PdfObject>();
            while (ps.parse(operands).size() > 0){
                PdfLiteral operator = (PdfLiteral)operands.get(operands.size()-1);
                if ("BI".equals(operator.toString())){
                    // we don't call invokeOperator for embedded images - this is one area of the PDF spec that is particularly nasty and inconsistent
                    PdfDictionary colorSpaceDic = resources != null ? resources.getAsDict(PdfName.COLORSPACE) : null;
                    handleInlineImage(InlineImageUtils.parseInlineImage(ps, colorSpaceDic), colorSpaceDic);
                } else {
                    invokeOperator(operator, operands);
                }
            }

        }

While in OpenPdf it is in PdfContentByte#addImage

[Kindrat]

Ok, actually we cam mimic same behaviour by changing only private class Do implements ContentOperator in PdfContentStreamHandler.

[andreasrosdal]

@Kindrat Thanks for looking at this. Remember, all contributions to OpenPDF must be developed independently, and must not be copied from other projects.

[Kindrat]

yeah, but in this case entrypoint would be exactly the same, however processing and callback signature would be different as in iText they introduced lots of new entities to work with these callbacks.

we can expose similar callback with same info but different representation

[andreasrosdal]

Good plan. Pull requests welcome

[testn]

Where are we with this?

[andreasrosdal]

Pull requests welcome, still :)

[testn]

@andreasrosdal are you ok with api exactly the same as itextpdf?

[andreasrosdal]

The idea is that we make an API which solves the problem reported by this user. The API doesn't have to be exactly like anything else. There could be something different with a different name, and we could tell users of OpenPDF to use this instead.

@testn @Kindrat

[asturio]

Pull requests are welcome!