Description: After selecting and copying the contents of a 'note' from within MacOS Notes, I tried to paste the contents into a new LibreOffice Writer document. Only the text appeared and the images were lost. Steps to Reproduce: 1. Open MacOS Notes and create a new note 2. Add both text and images into the note 3. Choose "Edit | Select All" in the note 4. Choose "Edit | Copy" 5. Open LibreOffice and create a new Writer document 6. Click in the new Writer document and select "Edit | Paste" 7. The cut & pasted text appears, but the images do not Actual Results: Only the text appears after the paste operation. The text appears properly formatted and has vertical space where the images should be, however, the images are not present. Expected Results: I would expect that both the copied text and images should have appeared in the Writer document. Reproducible: Always User Profile Reset: No Additional Info: I performed the same test with MS Word for Mac version 16.34 and the text and images were both present and appeared as they did in the MacOS Notes note. Also, I mentioned above that once pasted into the Writer doc, that the text appeared and vertical space appeared where the images should have been. I also tried to select the images and while there was vertical space, it did not appear that there were any images to be selected. I'm guessing the images were lost at some point even though some vertical space was allocated for them. I am experiencing these results in MacOS Catalina.
confirm in Version: 7.1.0.0.alpha0+ Build ID: 8c18cd6823ddf4ef5ba67801a84cee26c9b5a9a6 CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded
the same for 6.0 version in macOS
Same thing happens with LibreOffice Writer document, copying and pasting into an email. None of the pictures are included.
Dear Steve, 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
This bug is still present in: Version: 25.2.4.3 (AARCH64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 10; OS: macOS 15.3.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
So I can reproduce this bug so I added some debug code to see what data formats macOS Notes posted to the system pasteboard (see debug patch at the end of this comment. What I found is that when LibreOffice asks the system pasteboard what data flavors are avaialable (i.e. what was copied in Notes), I get the following data formats list: "com.apple.notes.richtext", "com.apple.flat-rtfd", "NeXT RTFD pasteboard type", "public.rtf", "NeXT Rich Text Format v1.0 pasteboard type", "public.utf8-plain-text", NSStringPboardType, "public.utf16-external-plain-text", "CorePasteboardFlavorType 0x75743136" Most are plain text or RTF. Neither of those formats support inline images. Don't know what "CorePasteboardFlavorType 0x75743136" is but I suspect that it is some internal Notes data format. That leaves only RTFD data formats. RTFD is a custom extension to RTF created by Apple to handle inline images. LibreOffice, however, does not understand the RTFD format (and neither do I) so it falls back to one of the text formats. So I really think the bug occurs because LibreOffice doesn't understand Apple's custom RTFD format but does understand the more common HTML format which supports incline images. This is why you can paste text and images from a web browser into LibreOffice: almost all browsers copy the HTML data format to the system pasteboard when copied. Hopefully, Apple will add HTML to its list of data formats that it posts to the system pasteboard. The other option is to change this bug into a feature request something like "support import and export of RTFD files and pasteboard data". Below is the debug patch that I used: diff --git a/vcl/osx/OSXTransferable.cxx b/vcl/osx/OSXTransferable.cxx index 725c56537a46..7f32bc041939 100644 --- a/vcl/osx/OSXTransferable.cxx +++ b/vcl/osx/OSXTransferable.cxx @@ -156,6 +156,7 @@ sal_Bool SAL_CALL OSXTransferable::isDataFlavorSupported(const DataFlavor& aFlav void OSXTransferable::initClipboardItemList() { NSArray* pboardFormats = [mPasteboard types]; +CFShow(pboardFormats); if (pboardFormats == nullptr) {