The following construct allows to scale an image in a Markdown document, while still using the original Markdown image command. No further css is needed. It turns out that a critical element is the empty line between the div statement and the image command (that’s why I missed this a long time ago). Use margin: auto; to center the image horizontally, without that it will be left aligned. This is to my knowledge the easiest, least intrusive way of achieving this with minimal HTML cluttering up the markdown.
If you associate a css sheet with Markdown in DT, you can further fine tune the global appearance of figures by customizing the figure environment, e.g to have the caption in somewhat smaller font and e.g. italics, set the background color, add a frame.
This hack depends sensitively on the ability to use md commands inside a HTML environment, so it’s potentially fragile. It could stop working with a future update of the md engine.
Important: No one is forced to use this. I have a good case for myself, and I figured (pun intended) that it would be worth sharing with those that also see some value in scaling and centering images in md.
Note: This writeup replaces the original method, that was much more cumbersome. Some of the discussion below refer to that old version.
Why not use CSS in an external stylesheet for that? It would keep the md document a lot cleaner.
I just noticed your usage of 10pt for font size. I’d discourage that: Absolute sizes for anything (except maybe one pixel borders) are not a good idea in these times of widely varying display sizes. Something like 0.9em (or any relative unit) would be a lot more flexible.
And: If you want a figure in HTML, use a figure element. It is there for exactly this case, and brings its own capture child. More semantics, better accessibility. And why use display:table for a div if you introduce your caption with a br anyway?
Thanks, @chrillek and @cgrunenberg for the feedback. I wholeheartedly agree that the bulky html block for the scaled images is annoying. But in order to fine-tune the environment for each figure, all the parameters would have to show up there, and can’t be in a css file. Having said that, in most cases the user probably only wants to adjust the width, and maybe the left/center/right alignment on a per-image basis. Everything else should probably go into a css, as you suggest.
use a figure element.
@chrillek: Well, that would have worked if I had not been stuck in HTML3 world. I didn’t know about the figure environment in HTML5. I now also realize that it is this very figure environment that shapes the appearance of the Markdown image environment. That explains a lot. I was wondering what css elements I would have to manipulate to e.g. format the caption. And all your other remarks about my html code are of course true. I’m essentially hacking this stuff by throwing things together, playing with it until it works, and then I stop . And then hope for forum feedback to make improvements. Standing on the shoulders of DT giants.
Looking into all this again this morning, I suddenly found a method that allows to scale md images (and format other aspects) with leaving the md image command intact! In fact, I had tried this a long time ago and it did not work, and it turns out a single extra linefeed makes the difference. I’ll post that later today.
One question about putting things in a css file: Of course, any formatting that can be punted into a css-file should be, to keep the md clean. The natural place would be the css template that can be specified in the DT prefs. However, to my knowledge this template is not available in DTTG, so to me this path is a no-go. I only see two other paths:
The css sits at a publicly available URL; this will not work in offline mode.
The css is located at as file in DT and is referenced on the first line of the md file as css:x-devonthink-item://04126D5E..., which mucks up the md source right at the top, but otherwise works reliably on DTTG as well.
The best solution would be to add the ability to specify a css template in DTTG. We need to convince Eric.
Wow. Did you fall down a wormhole? HTML 3 – what kind of environment is that? This version appeared in 1997 and was superseeded in the same year by HTML 4. Which also went out of fashion about 10 years ago.
Do you think that that’s necessary? I’d understand the requirement if you were publishing art books, for example. Otherwise, I do not think that it’s even a good idea to “fine tune” the style for every figure. Readers like consistency (I suppose). I’d go for a maximum of three widths (and leave the rest of the parameters the same for all figures): 98% of the container’s width (to allow for some white space left and right), 48% of the container’s width to allow for two images side by side, and 48% of the container’s width to allow for an image to the left of the text (i.e. the text flows “around” it at its right side). Of course, if you’re using a 3- or 4-column layout (are you?), 1, 2, 3, and 4 column wide images would perhaps be needed.
Even if the idea of having special styles for every image were more appealing, it has one important disadvantage: You have to change every single image definition if you (for example) want them to be 30% or 50% wide. That’s a bit like foregoing “styles” (is that the term?) in Word - if you decide that your second level heading has to be 14 instead of 16 points, you’d have to change every single one of them by hand. Instead of changing the style.
But: What are we really talking about here: A high-end web site that has to be mega attractive to millions of people – or rendering some technical stuff as fast possible, sufficiently “nice” and in a way that conveys the information as well as possible? The less special cases you take into account, the easier the task is becoming. And if it’s only you and some colleagues who’ll ever be looking at your rendered MD … maybe less is more.
I think so, too. However, this approach has one drawback: The global CSS overwrites all styles predefined by DT. So a global stylesheet has to provide for everything. I find that a bit disappointing. And then there’s of course
I’m with @chrillek on this… unless there’s some particular requirement for formatting and presentation, why not settle on a comfortable middle ground of “That’s pretty good” that applies to all images?
And while I’m less of a Markdown purist like @cgrunenberg or @chrillek since I do a ton of tinkering, I do agree that including raw HTML in Markdown should be much more limited than what you’re proposing. However, “different strokes”, yeah? (And not the dreadful TV show I used to watch )
Well, I’m a subatomic physicist for my day job, and I wield whatever computer stuff is necessary. Typically as far as I need to get the job done, but not further, as my to-do list is already too long. For my own research webpage, I’ve had for 15 years now an instance of PmWiki, so no html involved there. Other than that, I fiddle with html for things like fudging the appearance of Markdown documents Using <b>, <em>, <img>, and <h1,2,3> goes a long way. Today I added <figure> to my repertoire, and I’m also stoked about <details> and <summary>!
As I wrote in my previous post: no it’s not. As you suggest, I only use the md docs as internal working documents, so they need to be utilitarian in the first place, but when they are too rough, it bugs me. So I put a bit of work in.
Currently (and that’s where my burst of activity on Markdown is coming from) I’m making a growing number of flashcards for my DT-internal spaced repetition practice system. Someone on this forum had mentioned how one can use <details> and <summary> to make nice cards where you expand the answer. That together with LaTeX formulae and nice images makes for excellent cards written in markdown. I like those cards to look nice when I go through them. So yes, I spend a bit of effort on formatting.
Perhaps a MD template for that would be helpful? It could also contain a style element at its top that defines different styles for these flashcards (if that is desired). It could also predefine the details and summary sections (less typing when filling in the flashcards).