Defect #10189

Inline image does not work with spaces in file name

Added by Jason Palmer almost 6 years ago. Updated about 1 year ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Text formatting
Target version:-
Resolution: Affected version:1.3.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).

Sample Image.png (10.6 KB) Jason Palmer, 2012-02-09 21:37

SampleImage2.png (10 KB) Jason Palmer, 2012-02-09 21:37

space_in_inline_image_filename.patch Magnifier (777 Bytes) Dicky Hadiyuwono, 2012-11-19 03:34

unescape_inline_attachment_filename.patch Magnifier (465 Bytes) Jeff Fendley, 2013-12-03 23:56

images_with_space.patch Magnifier - Please test and feedback. No changes to Redmine syntax (909 Bytes) Paulo Neves, 2013-12-15 14:12


Related issues

Related to Redmine - Defect #10182: UTF and Attachments New
Related to Redmine - Feature #26071: Generate markup for uploaded image dropped into wiki-edit... Closed
Duplicated by Redmine - Defect #17679: Attached inline image not working Closed
Duplicated by Redmine - Defect #13375: Inline Image formatting does not allow a file name with s... Closed

History

#1 Updated by Jason Palmer almost 6 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

#2 Updated by Vitaly Klimov almost 6 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

#3 Updated by Etienne Massip almost 6 years ago

  • Description updated (diff)

#4 Updated by fangzheng (方正) almost 6 years ago

Really important issue.
Watch it and wait for developer's feedback.

#5 Updated by Mirko Geissler over 5 years ago

Still present in 1.4.0 it seems!

#6 Updated by Jean-Philippe Lang over 5 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.

#7 Updated by Jason Palmer over 5 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?

#8 Updated by Dicky Hadiyuwono about 5 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!

#9 Updated by Jason Palmer about 5 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)}}

#10 Updated by Philipp erpel about 5 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.

#11 Updated by Jeff Fendley about 4 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)!

#12 Updated by Paulo Neves about 4 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.

#13 Updated by Steffen Hartmann almost 4 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).

#14 Updated by Paulo Neves almost 4 years ago

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.

#15 Updated by T Leish over 3 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."

Redmine jsToolbar Images Extension

#16 Updated by Jānis Elmeris over 3 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.

#17 Updated by T Leish over 3 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.

#18 Updated by Toshi MARUYAMA over 3 years ago

  • Duplicated by Defect #17679: Attached inline image not working added

#19 Updated by Toshi MARUYAMA about 3 years ago

#20 Updated by Toshi MARUYAMA about 3 years ago

  • Duplicated by Defect #13375: Inline Image formatting does not allow a file name with spaces added

#21 Updated by Laurent Girard about 2 years ago

+1

#22 Updated by Inese Ez over 1 year ago

+1

#23 Updated by Fernando Hartmann over 1 year ago

+1

#24 Updated by Toshi MARUYAMA over 1 year ago

  • Category changed from Wiki to Text formatting

#25 Updated by Stephane Lapie about 1 year ago

+1

#27 Updated by Toshi MARUYAMA 6 months ago

  • Related to Feature #26071: Generate markup for uploaded image dropped into wiki-edit textarea added

Also available in: Atom PDF