Zettlr: Image resize

[demersn]

Any way to resize inserted images?

[nathanlesage]

It depends. You cannot crop or resize the images from within Zettlr. All it does is resize images that are too big to fit inside the width of the editor window.

What are you looking for specifically? A way to have basic image manipulation at your disposal? Or simply to have an option to enlarge too small images so that they fit the editor window?

[demersn]

Images that are too big fill the window and it's uncomfortable because it often fills the screen (ever worse for portrait orientation figures). Markdown does not seem to support this out of the box unless it's in html (correct me if i'm wrong), but drag and drop into zettlr makes it a MD link.

[nathanlesage]

That's correct; you could manually resize an image by using an <img>-tag and providing a width and height. But as for Markdown, it's not supported, because it belongs to the realm of styling, which is strictly separated from the writing process. But I see your point concerning portrait-oriented pictures.

After all, the automatic previewing is only thought of as a convenience so that you can directly see what that image would look like without having to open it manually.

I could add another restriction to the height of the images. The question is then: How high should portrait images be at maximum? (They would retain their aspect ratio but resized until they fulfill the height restriction). I would propose a maximum height of 50 percent of the window height (50vh), because this way, landscape oriented pictures won't be affected by that restriction.

[demersn]

Could html tags be previewed the same way md are? Then give the option to drag and drop images as html to allow customisation.

You could also put the option to choose the percentage of the restriction in the options menu, and 50% by default.

[nathanlesage]

I think I'll go for the menu option to manually restrict the height of images, because I feel like starting to begin previewing HTML elements en masse and accounting for all attributes and their different behaviour inside Zettlr vs. in the outer world would be an unreasonable effort.

[Jaifroid]

Should it not be a maximum width restriction, and make it optional? If we are maintaining aspect ratio, then setting the width would also control the height, and images should be centred if they only use a percentage of the width. Intuitively, the problem with portrait images is that they stretch to the full width of the window.

There is a markdown (extra?) syntax which allows adding CSS after an element like ![Image](image.jpg).{css_here} but I kind of agree that it could confuse things to start supporting custom styling.

[nathanlesage]

@Jaifroid

images should be centred if they only use a percentage of the width

Unfortunately, CodeMirror only supports inline widgets, which is why they are always left aligned, if they don't take up the whole space.

but I kind of agree that it could confuse things to start supporting custom styling

Yup.

After all, let us not forget that it is an image _preview_, not WYSIWYG. This is precisely the point of Markdown: Freeing you from the perceived need of formatting anything out of existence. I wouldn't bother so much with how or why images are placed, as long as they are displayed correctly and don't result in the 404-image. Concerning too big images, it's also obvious that there is a limit on _how_ big they should be, so the vertical constraint is understandable.

[517qf]

I just discovered this great markdown editor/note taking tool. For me setting the size (and not just size limites) of individual previews/images is very important.

I'd like this feature because I often have small drawings/sketches that - if they are stretched to full width - are too big = draw too much attention. This is especially relevant if I have a high res photo of a small drawing (and what would happen if I take a screenshot on a 4k 15'' notebook and later view it on a full-hd 27'' display). I also want some images to be pretty big - especially if it's a large table. Then a limit to 50% of the window height which is useful in many cases would be bad.

This feature might also be interesting because few other markdown software supports scaling of markdown images ...

But I can see that most people have different preferences ...

[nathanlesage]

@517qf There won't be any feature to individually scale image previews. And there is a good reason, why few editors support this: It tricks you into thinking the images would be the specific size on export, but Markdown actually doesn't support setting image sizes. And this has a good reason, because this way each exporting template may set the images as it sees fit. In most LaTeX-exports, images are typeset to the center and about 75 percent of the textwidth. Other Output format may choose different sizes, and this is by design.

Another reason why I will not implement individual resizing is of the database overhead this would generate. I'm rather proud that Zettlr manages to work with only exactly two "database" files: The config.json and the stats.json. This way it ensures that you don't rely on Zettlr for editing or viewing your files. You can even edit your Markdown files on computers that do not have Zettlr pre-installed (cross-platform portability).

Enabling individual resizing would jeopardise both fundamentals: First it would create a database that binds the image preview sizes to the computer on which they have been created, thereby threatening the portability of Markdown files directly. The second is that this would amount to a fundamental intrusion into the way Markdown files are rendered — if on one computer an image has the correct size for you, but not on others, this would render your files incompatible.

Let me instead offer you an alternative: A small program that you can load your image into, resize it until it fits on a Pixels/dpi basis, and then you're fine!

(But @Jaifroid @demersn don't worry, a global option for contraining the width and height will be coming)

[Jaifroid]

@517qf If you're using pandoc to convert your markdown to other formats, you can use a syntax like

![image](foo.jpg){#id .class width=30 height=20px}

to control the image size in the output. See http://pandoc.org/MANUAL.html#images . @nathanlesage , might this optional syntax be a compromise that avoids having a database, and uses a standard markdown extra syntax?

[nathanlesage]

@Jaifroid Yes, I see your point. Still, I'm hesitant, because I fear that Zettlr is becoming a second Word where you basically have WYSIWYG all the time 😕Maybe this is just me being paranoid …? But I don't want previews to foreclose our perception of what the rendered document will look like. And I fear that by supporting every syntax directly in the editor, Zettlr will just become another Typora, alienating people from the things they write.

[Jaifroid]

@nathanlesage I see the point. At least the syntax works for exporting with pandoc, so @517qf can achieve what they want, though not preview the result in Zettlr. Personally, I think supporting this very limited case of image resizing via CSS wouldn't turn Zettlr into Word, because you hide the image syntax ![image](foo.jpg) anyway, so the source code is already hidden. However, it's completely your call to decide if such a change would violate the Zettlr philosophy you've established.

[517qf]

Thanks for your quick and also explaining your reasoning. Even though a brief "no" would be perfectly fine (because it's free software) having an explanation feels much better.

[nathanlesage]

So, I finally managed to add two new preferences options that let you control the maximum size of the previewed images. If you select 100, no restriction applies to the height for the image. You can now find the options in the preferences under the "Display" tab!

[Jaifroid]

Many thanks!

[nathanlesage]

You're more than welcome!

[demersn]

Can't wait for the update!

[nathanlesage]

Update will be released on Friday -- it's the 1.0.0.-beta.1, e.g. now we're on the last mile! In any case, Zettlr Updater won't show that update because we'll be releasing it as a pre-release, and the Zettlr updater doesn't display pre-releases, so you'll have to manually download it!

But I'm looking forward for the last bug reports by you! :)

[Jaifroid]

@nathanlesage I've been testing the dev branch of this, and I wondered if you might possibly look into adding two things before you merge to master. One is that the spinners on Preferences -> Display don't tell you what number they're set to. There's some simple JS out there that allows you to set a field dynamically to show the value of the spinner as it is being dragged (it should change as you're dragging it). The field can be underneath or to the right of the spinner, but be careful it doesn't get covered by fingers for those using touchscreens on Windows, so right is perhaps best.

The second is either to centre the resized image horizontally (between the left-right margins) or to add a display option to make centring optional. Currently it aligns to the left, which looks odd when you have a wide screen and a small picture.

I don't know whether it's possible to reload automatically the currently open document after changing these settings, as currently I have to exit the document and reload it manually.

This is just the icing on the cake! No rush of course, it can be left for later, as part of beta testing.

[Jaifroid]

Further info:

Basically, for the spinners you want something like this (the oninput event doesn't have to be inline, it can be done programmatically with addEventListener in your code that sets up the page):

<label oninput="document.getElementById('spinnerVal').innerHTML = mySlider.value + '%';">
    <b>Description of slider:</b>
    <input type="range" name="mySlider" id="mySlider" min="0" max="100" step="1" value="100">
    Current value: <b><span id="spinnerVal">100%</span></b>
</label>

[nathanlesage]

@Jaifroid Hey, thanks for your quick reply. I know that it's not perfect by now. I just wanted to implement it so that I can close this issue, just for my own psychological wellbeing =D

The native sliders look rather ugly and don't fit into the design concept of the app, so I'll need to add some CSS before 1.0. Also, I wanted to flip the height-slider by 90 degree and add a mock-image, so that it's visually clear what you are regulating using the sliders.

The input is also something I already have on my list!

Concerning the reloading of the images: Could be done potentially, currently all text markers would've need to be updated manually, which is quite a hassle. The new options are immediately applied to newly created images, so instead of reloading the whole file you could click an image to destroy the <img>-tag, and then move out of the line to re-render it.

And concerning the horizontal alignment: I fear that is not possible, because CodeMirror requires inline-widgets, and I'm afraid to break things by circumventing this behaviour using margins (also these margins would require a lot of attention during window resizes etc.), so I'm not quite sure that's possible.

I'll dig into that, but can't promise anything.

[Jaifroid]

OK, great! No rush on anything.

Couldn't you just reload the document, like literally close it and reopen it, rather than attempt to re-render? Anyway, a simple option is to put a note on the dialogue box saying "Reload currently open document to see changes". Just so the user doesn't think it didn't work.

[nathanlesage]

Hah, even better idea: I'll just trash all preview elements whenever the settings change and trigger a manual reload. It's a little bit more resource intensive, but it's not as if one would change the preferences every second or so. And then I can reuse that function to use it also for when I implement the selective preview rendering (i.e. to choose which elements should be automatically previewed, and which not).

Wait for it, coming ... maybe on Friday evening in the first 1.0 beta, or in the next one :)