Conversion from Markdown to docx produces images of fixed size

[ben]

I'm having an issue where images included from markdown aren't sized appropriately; they appear to all be pinned to 1.67" square. This is easily reproducible:

$ pandoc -t docx -o test.docx
![Caption](a_400x100_image.jpg

Expected output: a document with an embedded image that, if too wide, is clamped to the margin area, but honors its original aspect ratio.

Actual output: a document that looks like this (screenshot from Word for Mac 2011):

Here's the image that's being included. It's 400x100 at 72dpi.

Is there some flag I can pass to bypass this behavior? It also happens if I round-trip to LaTeX, and the LaTeX output doesn't look like it's embedding any size information:

$ pandoc -f markdown -t latex
![Caption](a_400x100_image.jpg)

The output:

\begin{figure}[htbp]
\centering
\includegraphics{a_400x100_image.jpg}
\caption{Caption}
\end{figure}

[ben]

I should mention this is version 1.11.1:

$ pandoc --version
pandoc 1.11.1
Compiled with citeproc-hs 0.3.8, texmath 0.6.1.3, highlighting-kate 0.5.3.8.
Syntax highlighting is supported for the following languages:
    actionscript, ada, apache, asn1, asp, awk, bash, bibtex, boo, c, changelog,
    clojure, cmake, coffee, coldfusion, commonlisp, cpp, cs, css, curry, d,
    diff, djangotemplate, doxygen, doxygenlua, dtd, eiffel, email, erlang,
    fortran, fsharp, gnuassembler, go, haskell, haxe, html, ini, java, javadoc,
    javascript, json, jsp, julia, latex, lex, literatecurry, literatehaskell,
    lua, makefile, mandoc, matlab, maxima, metafont, mips, modula2, modula3,
    monobasic, nasm, noweb, objectivec, objectivecpp, ocaml, octave, pascal,
    perl, php, pike, postscript, prolog, python, r, relaxngcompact, rhtml, ruby,
    rust, scala, scheme, sci, sed, sgml, sql, sqlmysql, sqlpostgresql, tcl,
    texinfo, verilog, vhdl, xml, xorg, xslt, xul, yacc, yaml
Default user data directory: /Users/ben/.pandoc
Copyright (C) 2006-2013 John MacFarlane
Web:  http://johnmacfarlane.net/pandoc
This is free software; see the source for copying conditions.  There is no
warranty, not even for merchantability or fitness for a particular purpose.

[jgm]

Confirmed the issue on my mac (with latest dev version of pandoc).

Confirmed that imageSize from Text/Pandoc/ImageSize.hs is returning
Nothing for your file -- meaning that it cannot determine the image
size. Most likely this is a problem with my algorithm for finding
a JPEG's size. My algorithm works fine on tests/lalune.jpg in the
pandoc distribution, which 'file' lists as

tests/lalune.jpg: JPEG image data, JFIF standard 1.01

but not on yours, which 'file' lists as

976.jpg:          JPEG image data, EXIF standard

So perhaps (it has been a while since I worked on it), my algorithm
only correctly handles JFIF, not EXIF.

Presumably this wouldn't be hard to fix. But for a workaround you might
try resaving your image with a program that writes JFIF.

[ben]

I'm using both Skitch and Photoshop to generate JPGs, and images from both sources have problems, so I'd expect this to be rather common. For a workaround, it looks like PNGs generated from both Skitch and Photoshop have no issues. Thanks! 😀

[sowiso]

We have the same issue on ubuntu 12.04.
As a current workaround we pre-convert images to .png, but a fix would be nice.

[jgm]

Here's a description of the EXIF format:
http://www.media.mit.edu/pia/Research/deepview/exif.html

[jgm]

Reopening -- the patch above will only work with some EXIF headers. Working on something more robust.