Saved image expand to include annotations out of border.

[vaunchag]

Not always the annotations fit into the captured region. The GUI allows to do these "out of border" annotations:

But they are cut without notice when saving (only seen when opening externally the saved file, possibly too late):

Making things even worse, when working with a custom area that has white background, one does not know where the croped image really ends and the "limit" where we should fit our annotations:

Results in a dificult to predict cut:

Proposal: it would be nice that when saving, the canvas is automatically augmented to cover whatever has been annotated. By default with white color? or transparent?

This does not only apply to captured small areas, but also in general: not always the annotations fit into the captured region, and in any case readability suffers with an uncontrolled background of the image (it's convenient to annotate "externally").

Ideally, it would be nice to also permitting the user:

• Manually expanding the canvas to decide the size of the "margins" beyond the detected annotations (or to configure the size of these margins somehow).
• Permit the user to choose the color/transparency used for the filled borders background.

These two things could be made when saving, by asking the user when annotations outside of the border are detected, or maybe as some preventive way of configuring that (that visually shows what the resulting saved image will look like).

If not possible to implement the main request (or not for now), at least show a visual clue (border?) on where the actual canvas is ending (needed for the case where the capture has white areas in the borders)... Or least, not showing a "promising" white margin that cannot be used indeed.

I take the opportunity to congratulate for the great application. It fills very nicely this "gap": a multiplatform (and even FOSS) screenshot tool, for easily and lightly getting uniform annotation across systems.

[DamirPorobic]

I run into this issue myself and was thinking about fixing it. I think export what is covered by annotation + Background image should not be that complex to implement. Background will be white probably though I need to check what can be done. Later on we can think about the other stuff that you have proposed, but this might be a bit more complex to implement, certainly when saving.

Thanks for the nice feedback :)

[vaunchag]

Thanks a lot to you!

Indeed, the first fix that you propose would do the key part of the improvement.

Now I see for the "canvas size" issue: currently the window size set by the user, when bigger than the image, may be already quite implicitly "defining" that extra area... Could do the trick for not very big images: one increases the window size, giving room for the white border margin, and draws there.

For bigger images (filling the screen), a workaround (in Linux) would be Alt+dragging the window, then resizing beyond the screen size... Not handy. A better way could be allowing zooming (ksnip/ksnip#180, a quite useful feature, independently of this).

Also implementing #8 would be a complementary way to getting the extra area (I did not see #8 before submitting my issue, it looks quite related).

For small (details) captures, the application forces a quite big white border (minimum window size due to the toolbar)... So, when saving, for the moment it is clearly better fit to the annotation elements + background as you propose (and not to the "drawn white area", that would be excessive on small detail captures).

Also possible interference of all this with #21?

As a side note, I see clearly now that (when implemented) the config of the color/transparency of the "extra border" would deserve a config option (and not waiting when saving). Surely the option placed in the preferences (not cluttering the main interface).

Thanks again.

[DamirPorobic]

I've pushed a commit that changes the behavior. Can you give it a try an let me know what you think.

[vaunchag]

It works great! Needless to say (but has to be said!) that I'm absolutely stunned by the speed of the fix.

As expected, not leaving any extra margin doesn't look quite nice, but the annotations are now respected: it is a wonderful improvement. And I still think that adding an arbitrary "extra margin" is not a really better globally solution (and even if margin size is made configurable).

Thinking about the way to explicitly specify the "canvas" (to cover that issue), maybe an intuitive way could be with the already available "Crop" button: it only permits currently to reduce... It could allow to freely expand beyond the image.... For discoverability, it's name could be changed to "Crop/enlarge" or something like this. What do you think?

The other point is that I see that finally the filling color is white. Wasn't it easy to make it transparent? I'm not sure on this, but I tend to think that transparent would be more "neutral" as the default decision.

In any case, making this filling color configurable (and visualized consecuently in the GUI), remains as a FR.

Should I close now this #90 issue (after your feedback on the detail of transparency), and open the other stuff as separate ones?

[DamirPorobic]

Yeah, I'm not thrilled about single side extension too but for now that will have to do until we figure out a better solution. Best would be to have a permanent border around the screenshot and been able to drag (extend) it only. Reading this last sentence it does sound like crop with limitation. Maybe we leave the current implementation for a quick "cover all my stuff" solution and if you want additional margin, go to the crop/extend tool.

Transparent was actually the default but in the saved image you see the tiles which looked a bit strange so I changed it to white, what kind of the default is for drawing application, like working on white paper. We can of course make it configurable.

Yeas, please close this one and open for the remaining stuff new issues so we can better track the stuff.

[vaunchag]

Great! I close this one and open for the other stuff.

Default color:
I understand what you say... transparence may be shown oddly depending on the image viewer (tiles, white, black, ...). White color, even if less neutral (assumtions on the image and final place where it will be inserted) has a predictable appearance, so it is more user friendly (less intimidating). You convinced me :-)