According to recent commit 244cd56 pandoc 1.16 will add basic support for image sizes.

I would like to specify image sizes for GitHub Flavour Markdown (GFM) and GitHub Pages rendered with Jekyll, using the output from pandoc.

Apparently GitHub briefly supported their own syntax for image sizes in GFM, but now an HTML snippet is required - see http://stackoverflow.com/questions/24383700/resize-image-in-the-wiki-of-github-using-markdown or https://gist.github.com/uupaa/f77d2bcf4dc7a294d109

i.e. If the image has no size information, continue to produce a classic markdown image. However, if the height or width is specified, in order to get a useful image displayed via GitHub, substitute the HTML snippet.

A few examples using the GFM as implemented in the GitHub issue tracker (close to but not identical to GitHub Pages rendered with Jekyll).

No scaling, use a standard markdown image ![test](https://github.com/favicon.ico)

Defunct GFM, ![test](https://github.com/favicon.ico | width=48)

Another Markdown variant's style which does not work with GFM, ![test](https://github.com/favicon.ico =24x48)

Sadly this kramdown variant does not work with GFM, ![test](https://github.com/favicon.ico){:height="24px" width="48px"}

{:height="24px" width="48px"}

No scaling, with HTML <img src="https://github.com/favicon.ico">

Setting width to 48, with HTML <img src="https://github.com/favicon.ico" width="48">

Setting height to 24, with HTML <img src="https://github.com/favicon.ico" height="24">

Setting height to 24, and width to 48, with HTML <img src="https://github.com/favicon.ico" height="24" width="48">

markdown_github is defined as a bunch of extensions that are enabled (see the README). The width and height (and other) image attributes are enabled in the link_attributes extension (not enabled for markdown_github, so they are dropped).

So to support the requested feature, we'd have to create a new extension called github_images or so and change the Markdown writer accordingly.

Thanks for your architectural insights - this sounds non-trivial then.

Right, of course. I didn't think of the raw_html extension...

Lovely - thanks!