Created attachment 54147 [details] Two slides: one containing images without a name, one containing images with a name When exporting ODP from Impress to the Microsoft PowerPoint format PPTX the title (a text alternative for accessibility) on images is lost. Steps to reproduced the issue: 1. Create a new presentation in Impress. 2. Add an image and give it only a title (right-click, choose "Description" from the context menu and fill in "Title"). 3. Add an image and give it only a description (right-click, choose "Description" and fill in "Description"). 4. Add an image and give it both a title and a description (right-click, choose "Description" and fill in both fields in the dialog window). 5. Save the file as "Microsoft PowerPoint 2007/2010 XML (.pptx)". 6. Open the PPTX file in Microsoft PowerPoint 2010 (or an older version that supports PPTX), right-click on each image, choose "Format picture", then "Alt text": the Title field is empty (while the Description field is preserved). Note: you can give images a name (so they become visible in the Navigator), but this does not make a difference. Desired behaviour: When exporting to PPTX, ODF's title and description should be mapped to DOCX's title and description.
While trying to confirm this bug in LibreOffice 3.5.0 RC1, it turned out that PPTX export loses the images: there are no images in the presentation when the exported PPTX is opened LibreOffice 3.4.3 or 3.5.0 RC1, or when opening the file in Microsoft Office 2010; Office 2010 reports that: "PowerPoint found a problem with the content in filename.pptx]. PowerPoint can attempt to repair the presentation. If you trust the source of this presentation, click Repair." (When unzipping the PPTX file to inspect the XML, there is no p:pic element for the image, nor a p:cNvPr element for the title or the description.) (See bug 41992.)
Confirmed with: LO 3.5.5.3 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Titles are missing. Second CC image on 1st page also. Checked with PowerPoint 2010.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.0.3 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-02-19
Reproduced with attachment 54147 [details]. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI
still valid a11y issue
Prioritizing: *Please do not adjust the priority without consulting QA on the mailing list or in the chat room http://webchat.freenode.net/?channels=libreoffice-qa Priorities are set per this chart: https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg Major - loss of data High - default seems appropriate, alternative text is not widely used but is quite important for those who do use it.
Migrating Whiteboard tags to Keywords: (a11y -> accessibility)
So in impress and writer, an exported image looses its title, while in impress a exported shape loses its name, title and description. So the correct export format should look like this. <p:cNvPr id="43" name="Image Name" title="Image Title" descr="Image Desc" /> This should be something easy to fix.
*** Bug 43546 has been marked as a duplicate of this bug. ***
wasn't it that Ms Word doesn't have names for images, or is that just tables?
(In reply to Cor Nouws from comment #10) > wasn't it that Ms Word doesn't have names for images, or is that just tables? They have title and description but no renaming the name (id) of the image. Same for tables.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I retested this in LibreOffice Impress 6.1.2.1 on Manjaro Linux; the issue is still present when exporting to PPTX. Both Title and Description are empty after exporting to PPTX ("PowerPoint 2007-2019") when I reopen the PPTX file in Impress. The only difference in the process is that you need to select 'Description' from the Format menu in order to access the Title and Description, instead of using the context menu.
The description for PPTX was imported in LO 6.3 starting with commit 52c81384e054a7953e21866394f5e473ea089358 by Author: Katarina Behrens on Date: Mon Feb 4 11:54:27 2019 +0100 Add PPTX import of shape description Reading and writing the name to PPTX already worked in 6.0. The description was already being written in 6.0 (since I can read it now in LO 6.4). So we remain with the title not being read or written. (In PowerPoint 2016, I can see a description, but no title using Picture Tools Format - Size - Alt Text.)
I have rechecked the issue in LibreOffice Impress 7.1.4.2 on Windows 10 and can confirm that the description is exported correctly to PPTX. (As far as I know, exporting the Title is less important for accessibility; it is more of a compatibility issue.)
Dear Christophe Strobbe, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug