tatsy / markdown-it-imsize

markdown-it plugin for size-specified image markups.
46 stars 93 forks source link

Support specifying a single dimension #9

Open sloria opened 6 years ago

sloria commented 6 years ago

Users should be allowed to pass a single dimension, which is assumed to be the width. We let the browser maintain the aspect ratio for the height.

![test1](image.png =100)
![test2](image2.png =50%)
<p><img src="image.png" alt="test1" width="100" ></p>
<p><img src="image2.png" alt="test2" width="50%" ></p>
tatsy commented 6 years ago

Hi @sloria,

Actually, your request is already supported. You can specify the size only for width or height by:

![test1](image.png =100x)
![test2](image.png =x100)

They will be rendered as:

<img src="image.png" alt="test1" width="100"/>
<img src="image2.png" alt="test2" height="100"/>
sloria commented 6 years ago

@tatsy Ah, didn't realize you could leave out a dimension like that.

I still think that =100 is more intuitive than =100x. Would you be willing to support that? My colleague @Johnetordoff has already implemented it, so if you're up for it, a PR is on its way!

tatsy commented 6 years ago

Hi @sloria,

I think the specification =100 is not supported either official Markdown nor GitHub flavored Markdown. If it is supported either of them, please let me provide a link to the document.

This plugin is designed to follow the GitHub-flavored Markdown, therefore, the functions, which are not supported by it, should not be included in this plugin.

sloria commented 6 years ago

@tatsy Ah, I didn't realize this plugin's syntax was following a specification. Which specification does this project follow?

GitHub-flavored Markdown does not support this syntax. As of this writing, the only way to size images in GFM is to use an img tag.

sloria commented 6 years ago

The image sizing syntax is listed in one of the Deployed Extensions for Commonmark, but it doesn't specify how to define a single dimension.

The syntax I'm proposing was also proposed in the Commonmark forum here: https://talk.commonmark.org/t/support-for-image-dimensions/148/7 .

tatsy commented 6 years ago

Hi @sloria,

Thank you for sharing the links. But these links indicate that people proposed the new syntax but it is not officially supported. I think this is because the syntax ![test](image.png =100) is ambiguous. It is unclear that the number 100 specifies width or height.

Accordingly, GitHub-flavored Markdown supports the syntax only ![test](image.png =100x) to specify only width.

sloria commented 6 years ago

The proposed syntax is especially convenient when using percentages.

![test](image.png =50%)

I understand it's more ambiguous when using pixels, but as a user, I would assume =100 means "100px for width and scale height accordingly". This is is consistent with other programs such as ImageMagick (e.g. mogrify -resize 100 image.png).

Btw, I haven't been able to get ![test](image.png =100x) (or any other variant) working anywhere on GitHub. I've tried comments, README.md, Wiki, and Gist; what am I missing?

tatsy commented 6 years ago

Hi @sloria,

I am sorry for my misunderstanding. You're right. The GitHub-flavored Markdown does not support the above features.

The syntax ![test](image.png =640x480) is supported by the MacOS editors Mou, Marked2 and Ruby-based Markdown parser RDiscount.

I remembered that I adopted this syntax because this one is simple and intuitive, also it was easy to support. For example, Pandoc supports the syntax like ![test](image.png){width=640px, height=480px}, but this one is rather hard to parse appropriately with the simple codes.

Despite the fact that the many Markdown parsers do not support the syntax that this plugin supports, I am still against to support the syntax ![test](image.png =100) because, as I mentioned before, this is ambiguous and hard to distinguish the size "100" is for width or height. Also, the syntax ![test](image.png =100x) is acceptable because just type a character "x" is not so laborious.

In conclusion, I think there is not enough justification to support the syntax that you have proposed. However, I am still open to your opinion. Please feel free to tell me your further opinion.

Thank you.