Created attachment 32443 [details] demonstration of possible fix for posted bug The patch has been implemented as a static 'fix-up' to allow easy testing without touching the original sources. However, I think that it would make more sense to have the OPCPackage.getPartsByName() with a comparator, so that the indices are properly sorted to start with. Then there would only be the need to deal 0-based vs. 1-based.
Might be worth posting to the dev list - I seem to recall that a few months ago someone was talking about fixing up some problem with opc relations that was going to need some moderately major internal changes to do things cleanly. You might find this helps with that, or you can otherwise assist with the refactor :)
Created attachment 32573 [details] patch (generated with git format-patch against trunk) Should I following up on a dev-list? I have a few more ideas for fixes (pptx handling), but I don't want to be coding in vain.
I see that your code introduces a sorting in combination with a comparing interface, but I don't understand what problem it solves. Is sorting necessary to suffice the M1.12 rule? Why is the old code wrong, which just compares case-insensitive? Please give an example as to when addPicture() finds the incorrect image, i.e. adding a sample pptx and a test case (failing in the old code/working with the new code) would be good.
Hi Andreas, It'll take some time for me to put together a test pptx, but the problem/solution are fairly quickly explained. When adding a picture, the code examines the chksum of the existing pictures to decide if a new entry is needed or an existing media can be reused. With the current code, the media will be listed in lexical order (eg, image1.png, image10.png, image11.png, image2.png, image20.png, image3.png, ...). If the picture to be added already exists, the 0-based index in the list is returned and (later) changed to a 1-based index for the referencing. This results in total rubbish. For the small example, the original image10.png is found as index 2 in the list (0-based), which becomes index 3 (1-based) for the slide reference. The slide will thus now reference /media/image3.png !! The current code will only work properly if you have a maximum of 9 images. The patch introduces a (case-insensitive) alpha-numerical comparator so that the list is ordered as (image1.png, image2.png, ... image10.png, image11.png ...) which re-establishes the proper connection between the indices. /mark
Errata: The original image10.png is found as index 1 in the list (0-based), which becomes index 2 (1-based) for the slide reference. The slide will thus now reference /media/image2.png !!
I think I've been able to write a unit test to show this, starting from a blank slideshow. See commit r1676810 / TestXSLFBugs.test57552() If someone (mark.o perhaps?) could confirm if the logic in that test is sane + it's triggering the same bug, then I can have a go at applying the patch
Do we really need to work with indices? How about changing the return type of addPicture to something like a abstract PictureData class which encapsulate the PackagePart (XSLF) or EscherBSERecord (HSLF)? Need image files always conform to the pattern /ppt/media/image<num>.<ext>? [1] [1] http://web.mit.edu/~stevenj/www/ECMA-376-new-merged.pdf (see 15.2.13 Image Part)
Some sort of helpful wrapper class would seem a cleaner fix to me, though with the small disadvantage of breaking some existing code. However, with the common SL code coming soon, people will need to tweak things anyway, so maybe we just roll this change into that?
(In reply to Nick Burch from comment #7) > I think I've been able to write a unit test to show this, starting from a > blank slideshow. See commit r1676810 / TestXSLFBugs.test57552() > > If someone (mark.o perhaps?) could confirm if the logic in that test is sane > + it's triggering the same bug, then I can have a go at applying the patch The unit test looks plausible - I'll see if I get time in the next days to test and give confirmation.
(In reply to Nick Burch from comment #9) > Some sort of helpful wrapper class would seem a cleaner fix to me, though > with the small disadvantage of breaking some existing code. However, with > the common SL code coming soon, people will need to tweak things anyway, so > maybe we just roll this change into that? I found the use of plain integers slightly fragile (or weird) too. A wrapper class would definitely be an improvement, even if the first incarnation is nothing better than a wrapped integer. In the longer term, I had figured it would be even more convenient to have an addPicture() method on the slide class (I think I've seen something similar in the ppt or the docx code). The user could then simply add a picture to the slide directly without worrying about any of the internal bookkeeping. In the background the method would do the 'if-exists-or-add-new' logic on the slide show. With this approach, it would be fairly easy to add a wrapper-class without immediately breaking any existing code. We could also provide extra XMLSlideShow.addPicture() methods that conveniently takes other parameters (eg,InputStream, File, etc) and returns the new wrapper-class. This would also provide an easy way to move forward without breaking existing code. The PictureDataXXX class could also be slightly extended to include its CRC and (for plain image data) its original dimensions. The would still be fairly lean but would make the existence lookups much easier. Retaining information about the original dimensions makes it easier to handle some other functionality that I've already started to code. Eg, /** Resize this picture into target rectangle, while maintaining its aspect ratio */ XSLFPictureShape.resize(Rectangle2D target, RectAlign align); I'm using this type of method to fit pictures to the placeholder dimensions.
> The unit test looks plausible - I'll see if I get time in the next days to > test and give confirmation. Before: test57552 failed expected: <5> but was: <11> at line 356 After patch: test57552 passed Looks OK.
Thanks for this, applied in r1677373. If you're happy, I'd suggest we close this bug now, and open a new enhancement one to track the improvements to addPicture discussed here
(In reply to Nick Burch from comment #13) > Thanks for this, applied in r1677373. > > If you're happy, I'd suggest we close this bug now, and open a new > enhancement one to track the improvements to addPicture discussed here Thanks. We can close the bug and follow up with an enhancement.