Yes, one of those regressions is to Tiling Patterns but this refactoring is needed to fix it, that’s why it’s taking so long.
-- John On 19 Mar 2014, at 10:49, Tilman Hausherr <thaush...@t-online.de> wrote: > I don't yet have a complete understanding of the projekt so I can't comment > much on the contents, but my three cents: > > - if the refactoring is based on the promise to solve problem XXX, then if > that problem XXX isn't solved after the refactoring, then it shouldn't be > done, or should be reversed > - there are still regressions from the previous refactorings. The longer you > wait, the less you'll remember what you did > > Nevertheless, at first sight, the refactorings seem to make sense. I always > like the idea of having access to information from above. > > Tilman > > Am 18.03.2014 20:46, schrieb John Hewson: >> 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 >> >> >
