Defect #10189
openInline image does not work with spaces in file name
Added by Jason Palmer almost 13 years ago. Updated over 1 year ago.
0%
Description
Now that Redmine does not replaced special characters in attachment filenames, you cannot display an image attachment inline when the attachment name has spaces in it.
e.g.:
!Sample Image.png! will not, as it does not recognise this as a complete image reference
!Sample Image.png!
!Sample_Image.png! will not work, as there is no attachment with this name
!"Sample Image.png"! will not work, it doesn't seem to respect the quotes to enclose the filename
!"Sample Image.png"!
If you rename the file so that it does not containe spaces it does work
!SampleImage2.png! will work
I know it is best practice to name files without spaces, but the users have been used to working with the underscores for a couple of years now. What is the best way to reference the attachment (containing spaces in the name) or revert to the previous file handling (less preferable).
Files
Sample Image.png (10.6 KB) Sample Image.png | Jason Palmer, 2012-02-09 21:37 | ||
SampleImage2.png (10 KB) SampleImage2.png | Jason Palmer, 2012-02-09 21:37 | ||
space_in_inline_image_filename.patch (777 Bytes) space_in_inline_image_filename.patch | Dicky Hadiyuwono, 2012-11-19 03:34 | ||
unescape_inline_attachment_filename.patch (465 Bytes) unescape_inline_attachment_filename.patch | Jeff Fendley, 2013-12-03 23:56 | ||
images_with_space.patch (909 Bytes) images_with_space.patch | Please test and feedback. No changes to Redmine syntax | Paulo Neves, 2013-12-15 14:12 |
Related issues
Updated by Jason Palmer almost 13 years ago
Sorry, I missed a slash on one of the pre tags
!Sample Image.png! will not, as it does not recognise this as a complete image reference
!Sample Image.png!
!Sample_Image.png! will not work, as there is no attachment with this name
!"Sample Image.png"! will not work, it doesn't seem to respect the quotes to enclose the filename
!"Sample Image.png"!
If you rename the file so that it does not containe spaces it does work
!SampleImage2.png! will work
Updated by Vitaly Klimov over 12 years ago
It also concerns filenames with parentheses in name, because redcloth parser uses text in parentheses inside image tag as an image title. So i guess one should patch redcloth or fall back to the old file naming rules
Updated by fangzheng (方正) over 12 years ago
Really important issue.
Watch it and wait for developer's feedback.
Updated by Jean-Philippe Lang over 12 years ago
Textile syntax does not support spaces in image names. If you want to display your image inline, don't use spaces in its name.
Updated by Jason Palmer over 12 years ago
I figured that textile did not support spaces in the filenames - I was unable to find out how to wrap the filename to ensure it was parsed correctly to display the inline image. This is one effect of the system no longer renaming file attachments to replace unsupported characters with a (predictable) close approximation of the original name. The bulk of our attachments are now a stored as a hash of the original file name.
That being said, I do appreciate the system preserving the original file name. Perhaps best practice for us moving forward is just to ensure that files are named appropriately prior to being attached, until someone can find a method of passing the attachment name to the inline image function (or other function that does not support files with spaces). Is it possible to lookup and pass the hashed filename to the inline image function if the original filename containing spaces is entered?
e.g. entering
!Sample Image.png!
becomes
!53616d706c6520496d616765.png!
automatically, and the image is displayed?
Updated by Dicky Hadiyuwono about 12 years ago
This prove to be crucial with our workflow since Skitch uses space in its output file.
I've made a workaround by simply substituting space with %20.
eg. !Photo Skitch Document.png!
-> !Photo%20Skitch%20Document.png!
Updated by Jason Palmer about 12 years ago
In the newer releases of Redmine, I have noticed that the thumbnail feature seems to be able to deal with the spaces in attachment names (either that or one of the Redmine admins at our site toggled a switch to prevent the renaming). Thumbnails are usually better for our use, though we do still need to actually embed the full-sized images from time to time.
{{Sample Image.png, size=150, title=Thumbnail)}}
{{Sample Image.png, size=150, title=Thumbnail)}}
Updated by Philipp erpel almost 12 years ago
Here's another workaround:
Just use a url starting from root:
!/attachments/download/7187/Sample%20Image.png!
It would also work with http://www.redmine.org/attachments/download/7187/Sample%20Image.png but then you have the host part permanently in your content and that might not be so cool.
Updated by Jeff Fendley almost 11 years ago
Dicky Hadiyuwono wrote:
This prove to be crucial with our workflow since Skitch uses space in its output file.
I've made a workaround by simply substituting space with %20.eg.
!Photo Skitch Document.png!
->!Photo%20Skitch%20Document.png!
I'm migrating another wiki to Redmine and this solution works great. It doesn't require changes to the Textile parser or your filenames, it just makes escaping work properly. I suggest using CGI.unescape, though, since that would fix the parentheses problem, e.g. for
<img src="rex(dog).jpg" alt="My dog, Rex" />
write
!rex%28dog%29.jpg(My dog, Rex)!
Updated by Paulo Neves almost 11 years ago
Hi this Issue is so important. I was going in circles trying to find why my images were not showing up. It seems that they all had spaces. Why the hell is this not a major bug?
Jeff: Your patch only corrects what is newly attached, not the already existing attached images, am i correct? Also I find asking a user to mess around with %20s and the like a bit out of line for non techie people. I am currently looking into the textile regex, but if I am correct the problem was with Redmine abusing the inline image system.
Thank you for your patches in the mean time.
Updated by Steffen Hartmann almost 11 years ago
Philipp erpel wrote:
Here's another workaround:
Just use a url starting from root:
[...]It would also work with http://www.redmine.org/attachments/download/7187/Sample%20Image.png but then you have the host part permanently in your content and that might not be so cool.
This works for me too with redmine 2.3.3 but it's hard to find out the file number 7187 before actually uploading (i.e. for preview).
Updated by Paulo Neves almost 11 years ago
- File images_with_space.patch images_with_space.patch added
I have taken a different approach that tries not to break the existing images with space, as well as the new ones.
I haven't run Redmine tests with it but I think they should pass.
The way the patch works is by adding additional processing to the parse_inline_attachments
. This method is originally responsible for detecting inlined images that exist as attachments. This function is responsible for overriding the normal functionality of Redcloth. Redcloth intends the mechanism ! !
to be used with fully qualified image urls or images with relative names. This function basically processes wrong <img src>
generated by redcloth and corrects it to point to the attachment.
My patch tries to find ! !
which were not processed at all by Redcloth because they had unsupported syntax (like having space inside the block). This patch makes a last effort to catch the unparsed ! !
without requiring any change to both Redcloth nor Redmine image syntax.
I have found this regression on redcloth but it hasn't been corrected since 2009 and the mantainer seems to have given up. I think the problem is in the way the attributes of the images are separated from the source by a space. To allow for both images with spaces in them and space separated attributes is almost impossible, at least without any complicated logic that figures out if a part of the string are attributes or a filename of an image. Below is the regular expression used by Redcloth:
IMAGE_RE = / (>|\s|^) # start of line? \! # opening (\<|\=|\>)? # optional alignment atts (#{C}) # optional style,class atts (?:\. )? # optional dot-space ([^\s(!]+?) # presume this is the src \s? # optional space (?:\(((?:[^\(\)]|\([^\)]+\))+?)\))? # optional title \! # closing (?::#{ HYPERLINK })? # optional href /x
I hope it helps.
Updated by T Leish over 10 years ago
Added an image menu plugin that helps with this issue:
"The image menu button detects if there are spaces and inserts a modified path to support spaces file name."
Updated by Jānis Elmeris over 10 years ago
Dicky Hadiyuwono wrote:
This prove to be crucial with our workflow since Skitch uses space in its output file.
I've made a workaround by simply substituting space with %20.eg.
!Photo Skitch Document.png!
->!Photo%20Skitch%20Document.png!
Still doesn't work (in 2.3.4). Also, the space replaced with '%20' doesn't work, the path is not resolved to where the image is located.
Updated by T Leish over 10 years ago
My experience with image space names and Redmine is:
Doesn't work¶
!Photo Skitch Document.png!
Doesn't work¶
!Photo%20Skitch%20Document.png!
Works¶
!/attachments/download/12345/Photo%20Skitch%20Document.png!
To get this last example to work, you need to grab the full url from the uploaded image, which is why I created the Redmine jsToolbar Images Extension to figure this out automatically.
Updated by Toshi MARUYAMA about 10 years ago
- Has duplicate Defect #17679: Attached inline image not working added
Updated by Toshi MARUYAMA about 10 years ago
- Related to Defect #10182: UTF and Attachments added
Updated by Toshi MARUYAMA about 10 years ago
- Has duplicate Defect #13375: Inline Image formatting does not allow a file name with spaces added
Updated by Toshi MARUYAMA over 8 years ago
- Category changed from Wiki to Text formatting
Updated by Toshi MARUYAMA over 7 years ago
- Related to Feature #26071: Generate markup for uploaded image dropped into wiki-edit textarea added
Updated by Mischka Lebensland over 2 years ago
Updated by Andreas Baumgärtner over 1 year ago
+1
redmine 5.0.0
not working yet
!some helpful picture.png!
workaround confirmed
!some%20helpful%20picture.png!