Feature: image sizes about markwon

[noties]

Hello @liweijian ,

there are multiple options to support images sizes now.

For example commonmark-java currently has an extension to specify width and height for an image - via ![alt](#){width=10 height=19} syntax. They had it implemented as a delimiter processor, but unfortunately these attributes are available for HTML rendering only. We could adopt similar solution.

Then, currently commonmark allows specifying title for an image with ![alt](# "title") syntax. So, for example ![IMAGE](quiver-image-url/CE441C33AC43C93AA252DD42A1E73DB9.jpg "=618x164") would be a relatively easy addition. Not sure if it is a good application for title, but still it is a possibility.

And finally, a custom inline processor could be implemented. It would require quite a few changes. You can inspect code in CloseBracketInlineProcessor class. I would not modify it directly as it would diverge Markwon and commonmark-java code bases, which is not a very welcome thing at this point. Anyway, if you feel like it, you can fork this class and adjust to your needs.

PS I should also mention that there is another way for specifying image size - HTML. markwon-html artifact supports width and height attributes from day 1

[liweijian]

Just wondering if maybe we could support the Quiver-like syntax as: ![IMAGE](quiver-image-url/CE441C33AC43C93AA252DD42A1E73DB9.jpg =618x164) in the future?

[ubuntudroid]

HTML has one problem: it seems to be applied after the whole image loading process. Meaning that e.g. transformations like rounded corners result in even the corners being scaled up/down together with the image to match the desired size.

So if you have

<img src="https://picsum.photos/id/237/1024/800" width="100%" height="auto">

and in e.g. your CoilImagesPlugin you define

CoilImagesPlugin.create(
    object : CoilImagesPlugin.CoilStore {
        override fun load(drawable: AsyncDrawable): LoadRequest {
            return LoadRequest.Builder(app)
                .transformations(RoundedCornersTransformation(14))
                .data(drawable.destination)
                .build()
        }

        override fun cancel(disposable: RequestDisposable) {
            disposable.dispose()
        }

    },
    ImageLoader.Builder(app)
        .okHttpClient(okHttpClient)
        .build()
)

you will end up with huge corners as everything (including the corners) is scaled up after the image has been loaded:

As you can see the corners are much bigger than 14px.

So whatever the solution, it should be applied before actually passing the request on to the image loader.

[ubuntudroid]

Ah, and I have to correct myself / clarify: this only happens when using width="100%". Corners are properly sized for fixed sizes.

[noties]

Hello @ubuntudroid ,

I can confirm that this happens. Image loader would be asked to prepare image resource and after that ImageSizeResolver would do a final post processing. For example, when width=100% then it would scale the image (up or down depending on its original size). Another use-case is when image exceeds available width and will be scaled down to fit. A possible fix is to do resizing inside image loader itself (maybe the only one given the current state of things)