PPSpliT 1.26 changes alternative text for pictures

[tomash87]

Hello, PPSpliT 1.26 when run using either PowerPoint 2013 and Windows 10 or PowerPoint 2019 and macOS 11.6 changes the alternative text for (some) pictures in a presentation. Steps to reproduce:

1. Create a slide with a JPG picture.
2. Add the alternative text for the picture.
3. Add an animation to the slide.
4. Execute the "Split animations" command.

Result: the alternative text for pictures changes to some number (in MWE below to " 5"). Expected result: the alternative text remains unaffected.

MWE: The attached presentation consists of two slides, each having a JPG picture and some simple animation. Run "Split animations" on this presentation and consult the alternative text (In PP2013 for Windows: Format picture -> Size & Properties -> Alt Text; in PP2019 for Mac: Right-click the picture -> Edit alt text). W01 - ppsplit bug.pptx

[maxonthegit]

Hi @tomash87,

thank you very much for your interest in the add-in and for reporting this observed behavior.

Although there are no obvious reasons why alternative texts should be affected by the split process, some internal functions of PPspliT (e.g., copyShapeIds, findShape as well as others) indeed alter their contents. The underlying reason is that shapes often need to be copied among slides during the split process, with all their attributes retained. Even if copy-pasting is the sole and most effective way to achieve this (and also the reason why the clipboard should not be touched by the user while splitting), there are few properties that are still not retained and require being separately restored (e.g., the Z-order, namely which shape overlaps which). This, as well other processing steps, require recognizing different copies of the same shape appearing in different slides which, unfortunately, cannot be accomplished by using shape identifiers since they are regenerated for each copy of the same shape. Given that it is not possible to define custom attributes for a shape, I chose to use the alternative text as a safe placeholder to store a copy of the shape ids that is not altered in any way by PowerPoint, thus recovering the ability to match different copies of the same shape.

That said, I was not able to find any relevant shortcomings in overwriting the alternative text in this way. Considering the final goal of PPspliT, I see no reasons why a split presentation should be subsequently stored in native PPspliT format (with altered alternative texts) as opposed to exporting it to some other redistributable format like PDF (with alternative texts removed altogether).

Thank you again for point this out. Unless other reasons exist to consider changing this behavior, I am going to close this as "not an issue".

[tomash87]

Hello @maxonthegit,

In fact, it is an issue for me, since I am requested to provide accessible slides in PDF. By "accessible" it is meant to fulfill the WCAG 2.1 standard. One of the requirements is to provide an alternative text for pictures, graphics, images, etc. PowerPoint for Windows exports the alternative text for pictures (not for other objects) into PDF (although only some PDF viewers can read it). PowerPoint for Mac (as of v2019) does not support exporting the alternative text.

I understand your point about storing extra information in the alternative text. This is actually what I thought when saw these numeric values replacing the alternative text. A possible solution is to temporarily store a "serialized" object (e.g., JSON) in the alternative text that holds all missing properties, including the original alternative text. Once the splitting process is done, the original alternative can be easily restored.

I know that serializing an object in VBA is not directly possible, but there are workarounds, e.g., https://github.com/VBA-tools/VBA-JSON

[maxonthegit]

Issue addressed in release 1.27, which has just been published.

Instead of encoding AlternativeTexts in a way to preserve their original contents and store shape IDs at the same time (which might also have been implemented with a simpler encoding than full JSON) I chose to use Tags: they provide programmers with a more flexible way to store object-specific name-value pairs and, as far as I know, are not exposed in the user interface in any ways, thus being safe from overriding user data.

Thank you again for highlighting this issue, which I hope this change helps you overcome.

[tomash87]

Thank you, Massimo. The alternative text works great now.