Hi, in general I think that this is a valid change. From how I understand the rendering in PDF Form, Text, Image and Pattern maintain their own matrix to map to user space which is then transformed by the CTM to device space so handling them specifically is fine and inline with the spec. I’d suggest that we make sure that the different ‚spaces‘ are defined properly within the code and refer to the PDF spec so that the code is easier to read if this is not already the case. With so many changes it’s a good opportunity to enhance the documentation within the source code. Some of the old code enjoys very little documentation.
I wouldn’t remove processStream and processSubStream but deprecate them and remove them in the next major release though as to keep the changes to a minimum. There are a number of very important changes in 2.0. The easier we can get people to use that version wo to many changes to their own code the better. For 2.0 removing the deprecated stuff of 1.x is fine. Removing not deprecated stuff should be avoided if possible. For the rendering what might have been missed is taking the UserUnit entry in the page dictionary into account which might change the default user space. This was introduced in PDF 1.6. A good opportunity to read that entry and make sure that we handle it appropriately. BR Maruan Sahyoun Am 18.03.2014 um 20:46 schrieb John Hewson <j...@jahewson.com>: > Hi All > > I’m still working on getting Tiling Patterns to render correctly, and need to > make some > changes to core PDFBox functionality in order to proceed. My problem is that > tiling > patterns are defined in their parent stream’s initial coordinate space, > rather than the > coordinate space defined by the CTM. However, in PDFBox there is no way to > access > the parent stream, so I can’t find out what it’s initial matrix is. The > manner in which the > initial coordinate space is determined is different for pages, forms, and > patterns > > What this means is that the parent stream’s initial coordinate space needs to > be passed > to processStream and processSubStream in PDFStreamEngine. This will > necessarily be > a breaking change, and it will affect all downstream subclasses of > PDFStreamEngine. > > Because this has to be a breaking change, I propose that we go all the way > and make > the new API bulletproof, 1) so that we won’t have to introduce breaking > changes in the > future if we encounter similar issues, 2) so that the caller of the method > can’t pass the > wrong data in the parameters. We would remove the two generic methods: > > public void processStream(PDResources resources, COSStream cosStream, > PDRectangle drawingSize, int rotation) > public void processSubStream(PDResources resources, COSStream cosStream) > > and replace them with four specific methods: > > public void processPage(PDPage page) > public void processForm(PDFormXObject form) > public void processTilingPattern(PDTilingPattern pattern) > public void processType3Font(PDType3Font font) > > This would mean that the various “procesXXXX” methods have access to their > parent > stream, and can read any of its public fields in the future without > introducing breaking > changes by altering the method’s parameters. > > What do you think? > > -- John >
