| Summary: | Image gone after DOCX export (image frame anchored to Frame in Interactive frame) | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Telesto <telesto> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | aron.budea, jluth, stephane.guillou |
| Priority: | medium | Keywords: | filter:docx |
| Version: | Inherited From OOo | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=121508 https://bugs.documentfoundation.org/show_bug.cgi?id=40540 |
||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 104461, 120466 | ||
| Attachments: | Example file | ||
|
Description
Telesto
2020-08-21 09:52:15 UTC
Created attachment 164528 [details]
Example file
@Justin As I love to test the less common combinations.. I assume the export filter doesn't know/convert anchor to frame? I just tried it with adding another frame with a PNG inside and it exported that frame/image fine to docx (well, the image wasn't lost, but anchoring was wrong). So there must be something wrong with this particular frame and combination of settings. (I tried replacing the image with my image, and mine was lost too.) This is really an image in frame in frame. Cutting out one of the frames takes care of the problem. (But I was able to add a caption to my PNG and it still saved, so not sure what is really wrong here.) (In reply to Justin L from comment #3) Double checking./ Caption frame inside the interactive frame is anchored 'To Frame'. So simple inserting a caption frame inside a frame won't be enough. You need to change it 'to frame' Not sure in which cases 'to frame' being allowed (for reference at DOCX export). My initial idea for creating this was, maybe DOCX not having a 'to frame' emulation.. Longer reasoning: people tend to introduce new functions/ or make stuff more public forgetting they DOC/DOCX/RTF area (bit grumpy at the UX for introducing new Fontwork without checking DOCX comp-ability). Some times I which there were a kind of testing protocol/checklist. Or simply checking DOCX/DOC/RTF export by default if it's area which (hypothetically) could be affected too. (So say /shapes/anchoring/frames/fontwork/fields/footnotes/QR-code implementation). It's rather simple and reduces the number of bugs and would feel bit more coordinated. They QR-code function simply useless in DOCX format (blurry image). Doesn't need to be. And hard to promote LibreOffice as quality product. And they Calc jumbo sheets stuff shouldn't be mentioned in Release Notes; or somewhere hidden in a small caption with experimental written on it big time. Sorry for the off-topic part.. sometimes I only think, why, why, why. As it can be avoided without to much trouble Dear Telesto, 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 Sounds like a duplicate of bug 121508. *** This bug has been marked as a duplicate of bug 121508 *** As mentioned in bug 121508 comment 9, this issue is distinct: Telesto's example document has a picture anchored to paragraph inside a frame, which is itself anchored to a paragraph inside another frame. Setting back to New, but as Gabor said in bug 121508 comment 9, we might need to phase out this babushka doll feature because of the interoperability issues it creates... Difficult to say how to handle this. For simple shapes the anchoring is moved to character, meaning the shape is not lost, but positioned outside (and incorrectly compared to the original setting) of the frame. Another option would be anchoring inside the textbox as character, this kinda works for the usual caption objects, but for frame-in-frame objects, the outer one seems to overlap the inner one (I think I saw some docx export bug about this already). |