I take screenshots using Greenshot.
I can paste the image from clipboard in Impress and Draw.
But if I paste the clipboard content into Writer, the image is missing: It shows only a placeholder.
I traced the problem: The root cause is that the URI contains three FORWARD slashes, not BACK-slashes as required in Windows.
Here is a sample URI: file:///C:Users\njaras\AppDataLocal\Temp\gfukOrcd.1lk.png
If I manually correct the slashes, the image gets inserted normally.
Steps to do this:
1. Double-clicking on the placeholder
2. A "Picture" window pops up. Click on its "Picture" tab.
3. In the "Link" section, the URI of the temporary file is listed.
4. Edit the URI and replace /// with \\\
5. Press OK. The image is inserted in the file now.
Conclusion: Both Impress and Draw create the URI correctly.
Please correct the URI format in Writer.
I simply deleted the protocol specifier part at the beginning (file:///).
This was sufficient to correct the problem.
That means the "file:///" is actually redundant, and can be removed altogether.
(There is no need to correct /// to \\\ at all.)
so do you think that was a LibO bug or an issue about Greenshot or the way you pasted the URI?
So where is that faulte URL coming from? Greenshot? I agree with tommy27, that in that case it isn't a LO bug.
Setting to NEEDINFO until more detail is provided.
After providing the requested info, please reset this bug to UNCONFIRMED. Thanks :)
Well, I have already stated that the image does get inserted in Impress and Draw with the EXACT SAME steps.
So how do you conclude that the URI may be faulty?
Even assuming that the incoming URI is faulty, How come it can be handled by Impress and Draw; but not by Writer?? Obviously, the logic used in Impress and Draw seems to be more robust, and should be reused in the Writer too.
Also, the code for pasting clipboard contents is different in Writer. WHY?? Shouldn't a common code be reused across all LibreOffice apps?
I have Greenshot too, so I can test.
please provide complete step-by-step instruction how to reproduce the bug and specifically how do you copy and paste it from Greenshot to Writer.
I tried this in PC at home, and found that I am able to paste the image.
1. If I try to check the URI in LibreOffice (by double-clicking on the image, and in the dialog box that pops up, clicking on the "Image" tab), I cannot see any URI at all.
2. I checked the Edit>Links menu option, which is grayed out.
That means the image is fully pasted in the document (and not linked from the temp folder).
In comparison, at work, the placeholder shows the URI in wrong format (as described earlier), and when this format is corrected, the image is LINKED from the temporary folder (I have to break the link by using the Edit>Link menu).
Both PCs are running on 32-bit Windows 7.
But the home PC has Home premium version, and the work PC has Professional version.
I used the same installers to install LibreOffice (22.214.171.124 RC1) and GreenShot (v1.1.7 Build 17) in both PCs.
I restarted both PCs, and the behavior (good/bad) is consistent in both PCs.
p.s. I reflected this bug at GreenShot, but they feel that this may be a bug with LibreOffice, because the URI is correct according to specifications RFC 1738.
Narayanaras: All that's needed is "please provide complete step-by-step instruction how to reproduce the bug and specifically how do you copy and paste it from Greenshot to Writer."
Please provide that info - otherwise it is impossible for tommy27 to try and reproduce.
From your initial description the steps are fuzzy e.g. "1. Double-clicking on the placeholder" in which software?
Maybe a small screencast would be the best way to show what is exactly going on.
Created attachment 91413 [details]
Shows problem in Win 7 Professional (pause video as required)
Enclosed in a video that shows the problem.
I have inserted call outs to place a running commentary about what's happening, and what steps I take.
Notice that the link inserted in wrong: It has "File:///" instead of "File:\\\".
As soon as the URI is corrected, the image appears. Note that this image is LINKED (not INSERTED in the document).
Created attachment 91414 [details]
The image is LINKED (not INSERTED)
This video shows how the image that appears after correction of link is linked to a TEMPORARY folder.
Note that if I don't break the link, the image will be lost soon, because the actual image is in a TEMPORARY folder.
In contrast, when I repeat the experiment in Win7 Premium at home, the image is inserted (not LINKED). I don't have to worry about breaking the link to make it permanent.
I have Greeenshot 1.1.7 buid 17 64-bit version
I use LibO 126.96.36.199 under Win7 Pro 64bit
it's not clear to me from your video how exactly you do the "copy & paste" from Greenshot.
in my PC I select "capture region" in Greenshot then take the screenshot, then a pop-up menu comes out and I can choose among other options "Copy to clipboard".
then I Ctrl+V to paste the captured screenshot in Writer and the image is fully pasted in the document, not linked outside.
I suspect you have a different configuration of Greenshot that automatically saves the "capture region" to a temp folder and this triggers the bug.
can you confirm this? check Greenshot "fast preferences" right clicking on the traybar icon, you should see something like: has Greenshot such "Image destination" (I have Italian UI so translation may differ). Actually I have "select destination dinamically"
Yes, GreenShot offers a list of destinations if you select "dynamically".
In my case I have set identical settings for both PCs:
1. Destination (select Preferences > Destination tab) : "Copy to clipboard"
2. Storage location(select Preferences > Output tab): "D:\Data\Downloads"
So When I capture a screenshot, the image is automatically placed on clipboard.
All I have to do is to switch to the target app (in this case LibreOffice Writer), and press CTRL+V.
As mentioned, I can paste the image in Impress and Draw. But not in Writer.
In fact, I conducted two additional experiments:
I opened one odt file and one odp file. Then I took a screenshot and switched to odt first, and pressed CTRL+V. It gave a placeholder. Then I switched to odp and pressed CTRL+V again (that means the clipboard contents are still the same). This time I am seeing the image.
That means there is nothing wrong in the clipboard content.
I selected the image in Impress and pressed CTRL+C, switched to Writer and pressed CTRL+V. This time the image is pasted normally.
Again, this means the clipboard contents are OK.
BTW I also observed a strange effect: Both Impress and Draw seem to treat the image differently (as compared to Writer). If I double-click on the pasted image in Impress/Draw, it only allows me to type text (as if the pasted image is a text box). But if I double-click on the corrected image in Writer, a complete "Picture" dialog box opens up, with a lot of tabs (Type/Options/Wrap/ Hyperlink/Picture/Crop/Borders/Background/Macro).
In the experiment-2 above, the image copied from Impress and pasted in Writer behaves as it behaves in Impress (a double-click on it only allows me to type text only; and does not show me "picture" properties).
Created attachment 91448 [details]
How the image behaves in Writer
The "Image in Writer" video shows that-
1. When pasted, only a placeholder shows up.
2. When it is double-clicked, the "Picture" dialog is triggered.
3. In this dialog, switch to "Picture" tab and correct the URI (from /// to \\\)
4. Now the actual image appears (only LINKED, not INSERTED)
5. A double-click on the image triggers the same "Picture" dialog.
Contrast this with the corresponding video for Impress.
Created attachment 91449 [details]
How the image behaves in Impress
How the image behaves in Impress
The first half of this video shows the Writer again (for reference).
In the second half, I switched to Impress and pasted the SAME clipboard contents.
The latter half of the "Image in Impress" video shows that-
1. When pasted, the image shows up.
2. When it is double-clicked, the "Picture" dialog is NOT triggered.
Instead, I am allowed to type text there.
(the pasted image behaves like background for this "text box")
Contrast this with the corresponding video for Writer.
sorry I still not reproduce your issue even on 188.8.131.52rc
Greenshot captures saved to the clipboard can be pasted without any issue in Writer. I do not see that placeholder you talk about.
did you try resetting your user profile?
oops- I forgot to mention that part:
Yes, I deleted the "4" folder from this path:
And then restarted the PC. Yet the problem is still there.
BTW as I pointed out, this problem is not there in my home PC (running 32-bit Win 7 Home Premium). So this issue could be specific to a 32-bit Win7 Professional.
so you are saying that the bug you report affects only a Win7 Pro 32bit PC and doesn't affects a Win7 Home 32bit PC?
No my point was that the fact that I am able to paste the image in Win 7 Home Premium, shows that the problem is not universal. So if you are unable to replicate it in another type of OS, I won't be surprised.
So any observation in other types of OSs should NOT lead to a "WorksForMe" closure.
Created attachment 91454 [details]
Path shows "/", instead of "\" in Windows 7 Professional
I discovered this by chance: When I hover over a file's thumbnail in the Start Center, the tooltip shows the path of the file with "/", instead of "\" in Windows 7 Professional.
Since the tooltip path is not used anywhere, this won't create any problem.
But this does prove that in some parts of the code, the wrong type of slashes are used (it is compatible with Linux, but not compatible with Windows file system).
To conclude, by removing the "File:///" part, the problem can be resolved.
(Or change the "File:///" to "File:\\\".)
(In reply to comment #20)
> Created attachment 91454 [details]
> Path shows "/", instead of "\" in Windows 7 Professional
> I discovered this by chance: When I hover over a file's thumbnail in the
> Start Center, the tooltip shows the path of the file with "/", instead of
> "\" in Windows 7 Professional.
interestingly when I hover on it I don't see the path of the file but just the filename. tested under LibO 184.108.40.206rc under Win7 Pro 64bit.
*** This bug has been marked as a duplicate of bug 59236 ***
*** This bug has been marked as a duplicate of bug 35176 ***