Bug 60504 - Add to public API POIXMLDocumentPart.removeRelation(POIXMLDocumentPart part)
Summary: Add to public API POIXMLDocumentPart.removeRelation(POIXMLDocumentPart part)
Status: NEW
Alias: None
Product: POI
Classification: Unclassified
Component: XSLF (show other bugs)
Version: 3.16-dev
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-21 15:24 UTC by Aurélien
Modified: 2016-12-28 19:59 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aurélien 2016-12-21 15:24:25 UTC
Currently the method POIXMLDocumentPart.removeRelation(POIXMLDocumentPart part) is protected.
Would it be possible to change the visibility of this method to public?

Indeed the method POIXMLDocumentPart.addRelation(...) is already public, so it makes sense to also make available to possibility to remove a relation.

About my use case: I need to replace an image with another image. But I want to keep all the properties and the order of the original image in the replaced image. So what I am doing is replacing the blip embed attribute of the original image with the id of the new image. It works fine, but I also want to clean up the old image. So I need to remove the relation between the parent element and the blip id of the original image. That is where I need to call POIXMLDocumentPart.removeRelation(POIXMLDocumentPart part).
Comment 1 Greg Woolsey 2016-12-21 19:00:29 UTC
While we could make it public, that would also open the door to lots of ways to completely break a workbook.  I'd prefer to see a higher level API for replacing one image with another that would handle these details internally in a consistent manner, with lots of unit tests.

Patches are always welcome, as waiting for a volunteer to have the time and inclination to add a specific feature can take some time :)  Short of a patch, a robust discussion of what exactly an API improvement might look like, including test vectors, is still helpful.

For example, it may be that different document types need to handle image replacement differently.  I haven't dug in to how the different formats do it, but cell vs. slide vs. paragraph anchor references seem like one area that may be different.  Ideally there should be some consistency between document types for image replacement, and perhaps some checks as well if there are constraints or decisions needed when images differ in size, for example.

(In reply to Aurélien from comment #0)
> Currently the method POIXMLDocumentPart.removeRelation(POIXMLDocumentPart
> part) is protected.
> Would it be possible to change the visibility of this method to public?
>
Comment 2 Aurélien 2016-12-22 17:52:44 UTC
Thank you for your detailed reply.

About the containers in which an image can be, I counted only 2 containers:
- a XSLFSlide,
- a XSLFGroupShape.
There doesn't seem to be any way to put an image in a paragraph or in a table.

About the test vector, what do you have in mind?
I am actually working on the library https://github.com/Coreoz/PPT-Templates that is highly based on POI XSLF, but it difficult to write tests since it is often in PowerPoint that I can verify whether the image replacement is working, or if the PPT slide is corrupted.
Comment 3 Greg Woolsey 2016-12-22 18:54:42 UTC
(In reply to Aurélien from comment #2)

> About the containers in which an image can be, I counted only 2 containers:
> - a XSLFSlide,
> - a XSLFGroupShape.
> There doesn't seem to be any way to put an image in a paragraph or in a
> table.

I was thinking about Word and Excel files as well, not just PowerPoint.  Some of the graphics objects are common but handled independently, and perhaps that could/should be standardized in some respects.

> 
> About the test vector, what do you have in mind?
> I am actually working on the library https://github.com/Coreoz/PPT-Templates
> that is highly based on POI XSLF, but it difficult to write tests since it
> is often in PowerPoint that I can verify whether the image replacement is
> working, or if the PPT slide is corrupted.

Anything you can see as right/wrong in PowerPoint visually should be represented in the XML somehow, so it should be testable.  The key is ensuring the "expected" values are correct manually, possibly by viewing an "expected result" master file in PowerPoint, then building a test case around it.