MultiMarkdown-6 icon indicating copy to clipboard operation
MultiMarkdown-6 copied to clipboard

LaTeX: leave image size as is?

Open hosewiejacke opened this issue 8 years ago • 6 comments

Currently, if neither width nor height is given the image will scale to texwidth x 0.75% textheight:

\includegraphics[keepaspectratio,width=\textwidth,height=0.75\textheight]{/path/to/image.png}

That's good for big images. On the other hand, small images scale up.

Suggestion: if the image has no size given leave it as is.

hosewiejacke avatar Sep 15 '17 12:09 hosewiejacke

The problem is that then large images don't work properly. With the current approach, all images work, even if small images have been scaled up.

If there's a better approach that works for all images, I'll look at it. If I have to choose one or the other, then I'll leave it the way it is.

fletcher avatar Sep 15 '17 12:09 fletcher

I think small images are much more common (at least in context of LaTeX) than big ones. And keeping the original size feels like the expected behavior when no size is given.

If there's a better approach that works for all images, I'll look at it.

Unfortunately, nothing I know of.

But I see your point. Feel free to close the issue if I couldn't change your mind :-)

hosewiejacke avatar Sep 16 '17 06:09 hosewiejacke

I'll leave open for now and see if anyone else has some ideas.

fletcher avatar Sep 16 '17 15:09 fletcher

I haven't tested it (outside of double-checking that the example code works), but perhaps something like answer №7 on this StackExchange question could suffice for a general-purpose solution?

The idea is to use the adjustwidth package with the export option, so that the "max width" key can be used in \includegraphics, like so:

\includegraphics[max width=\textwidth]{/path/to/images.png}

ghost avatar Mar 04 '18 16:03 ghost

I worry that this is complicating something that should be simple (either through more custom demands, or through more required packages). It's best practice for HTML to specify image dimensions, and if using MMD that means they are specified for all formats (assuming valid units).

The other issue is that the "natural" size of an image doesn't really mean much. Assuming a pixel based format (e.g. JPG, GIF, etc.) the only thing we really know is the number of pixels. Which is only loosely correlated to anything else -- are we using a high pixel density display (retina display, smart phone, etc)? Are we creating a PDF for reading on a monitor, or for printing with a high resolution printer? Does the image specify it's own resolution and therefore expected final dimensions?

In all formats, but for LaTeX especially, being explicit about requiring image sizes seems to be a good thing.

I'm leaving this open for now, but I'm less and less convinced I should do anything about it at this point.

fletcher avatar Mar 04 '18 16:03 fletcher

That's certainly the way I approach it. Well, I should say that's the way Scrivener approaches it, so for most of the MMD I produce there are fully defined image dimensions. I size the original image precisely as I need it to be sized and they come out looking right in the end. Scrivener does handle the sticky issue of resolution vs pixels by defining output size in points. That is also incidentally the best way to force high resolution display in HTML. If you need 144 DPI for Retina, then double your pixels but set the hard display width to half the literal pixels.

But back to the point, and setting aside the fact that being specific is surely best practices all around, as a fallback from best practices, it seems to me that an assumption that limits the width of the image to the \textwidth (avoiding unwanted clipping) and otherwise leaves assumptions to the image (which might be well designed), is less of an assumption than one that sets all images to 3/4 width the line no matter what. Even though it hasn't impacted me much, that is something I've always wondered about: what is the utility in having all images one width no matter their underlying size?

Hmm, well it is a fallback I suppose, maybe it's okay for fallbacks to be potentially suboptimal.

ghost avatar Mar 04 '18 21:03 ghost