Download it now!
Bug 102011 - EDITING: Default wrap spacing to for images is not convenient
Summary: EDITING: Default wrap spacing to for images is not convenient
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 92746 (view as bug list)
Depends on:
Blocks: Anchor-and-Text-Wrap 87720
  Show dependency treegraph
 
Reported: 2016-09-09 07:39 UTC by Bryce
Modified: 2020-05-21 18:03 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bryce 2016-09-09 07:39:54 UTC
When wrapping text around an image, the text will touch or almost touch the image by default.  To add whitespace one must:

* Double click on the picture
* Click on "borders"
* Enable a border
* Set line style to something, if it's on none
* Set color to white (or your page background)
* Now, the "spacing to contents" box unghosts.  Check "syncronize" and dial all four numbers to zero.
* Now uncheck "syncronize" and distance to the direction you need (e.g. left or right depending on where the image is place).

This workaround has been good for many revisions of libreOffice.  Could it be made easier?  Having "spacing to contents" start out enabled would be a good start.
Comment 1 Cor Nouws 2016-09-09 09:01:16 UTC
Thanks Bryce,

IMO you are right.
Ideal, the spacing to contents should default depending on the wrapping chosen ;)

See also bug 92746
Comment 2 Yousuf Philips (jay) (retired) 2016-09-09 19:25:09 UTC
This likely can be considered a duplicate of bug 87720.
Comment 3 Bryce 2016-09-09 21:53:13 UTC
The goal with this bug report was to state the problem (and workaround for google searchers) clearly.
Comment 4 Cor Nouws 2016-09-10 07:25:27 UTC
(In reply to Yousuf Philips (jay) from comment #2)
> This likely can be considered a duplicate of bug 87720.

I argued there that maybe it's better to use that issue for anchoring and wrapping and this for spacing.
Comment 5 Heiko Tietze 2016-09-10 07:53:33 UTC
Definitely worth to discuss but please in bug 87720. I copy/paste the issue there.

*** This bug has been marked as a duplicate of bug 87720 ***
Comment 6 Cor Nouws 2016-09-10 08:22:51 UTC
So IMO it's more convenient to handle spacing here.
 - It can be solved fast and the anchoring / wrapping stuff needs much more research
 - Thus the principle One issue, One report is valid.

Let's see if this can be 'easyhacked'.
Comment 7 Yousuf Philips (jay) (retired) 2016-09-10 11:44:47 UTC
(In reply to Bryce from comment #3)
> The goal with this bug report was to state the problem (and workaround for
> google searchers) clearly.

I wouldnt call it defaulting to have no space as a problem/bug, it is just not a good default and the correct place to add the spacing is in the wrap tab and not the borders tab.

(In reply to Cor Nouws from comment #6)
> So IMO it's more convenient to handle spacing here.
>  - It can be solved fast and the anchoring / wrapping stuff needs much more
> research
>  - Thus the principle One issue, One report is valid.

All should be tackled at the same time, as all of them are set at the same time and affect each other's default.
Comment 8 Heiko Tietze 2016-09-12 09:12:22 UTC
Now I'm confused. What do we do with this ticket? Easyhack means we have a precise task and set the keywords accordingly.
Comment 9 Cor Nouws 2016-09-12 20:38:26 UTC
(In reply to Yousuf Philips (jay) from comment #7)

> I wouldnt call it defaulting to have no space as a problem/bug, it is just
> not a good default and the correct place to add the spacing is in the wrap
> tab and not the borders tab.

Sure - thanks for that correction.

> All should be tackled at the same time, as all of them are set at the same
> time and affect each other's default.

The improvement clearly should be: set spacing > 0 at the sides where the image is side by side with other content.

(In reply to Heiko Tietze from comment #8)
> Now I'm confused. What do we do with this ticket? Easyhack means we have a
> precise task and set the keywords accordingly.

Maybe with my explanation. But if that is easy? needsDevEval will help I hope.
Comment 10 Yousuf Philips (jay) (retired) 2016-09-12 21:56:46 UTC
(In reply to Heiko Tietze from comment #8)
> Now I'm confused. What do we do with this ticket? Easyhack means we have a
> precise task and set the keywords accordingly.

For me this is a duplicate of 87720 or blocks 87720.
Comment 11 Cor Nouws 2016-09-12 22:00:53 UTC
(In reply to Yousuf Philips (jay) from comment #10)

> For me this is a duplicate of 87720 or blocks 87720.

Blocking I can imagine indeed.
Comment 12 Cor Nouws 2016-09-12 22:02:47 UTC
*** Bug 92746 has been marked as a duplicate of this bug. ***
Comment 13 jani 2016-09-14 06:08:33 UTC
Setting NEEDINFO, missing code pointer and skill<foo>, difficulty<foo>

Removing needsDevEval, does not seem needed.
Comment 14 Xisco Faulí 2016-09-27 10:36:06 UTC Comment hidden (obsolete)
Comment 15 Justin L 2017-10-21 15:56:29 UTC
(In reply to Bryce from comment #0)
> * Click on "borders"
> * Enable a border
> * Set line style to something, if it's on none
> * Set color to white (or your page background)
...
> This workaround has been good for many revisions of libreOffice.  Could it
> be made easier?  Having "spacing to contents" start out enabled would be a
> good start.

This part of the workaround is no longer necessary as of LO 5.4. Bug 41542 addressed having "spacing to contents" always being enabled.
Comment 16 Xisco Faulí 2020-03-09 13:28:08 UTC
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Comment 17 Justin L 2020-03-14 18:49:09 UTC
The conclusion from UI in a duplicate report was:
Please apply the suggestion in bug 92746 comment 7 with 1/8" (3mm when converted to SI). [The sidebar dropdown is actually now 3.2mm - so probably alter the suggestion with that value. This refers to the "spacing to contents" on all 4 sides.]
("RID_SVXSTRARY_SPACING_CM", "Small (%1)"),        181,  32

The "Graphics" frame style is automatically applied to inserted images. (I tested this back to LO 5.0 - always worked.) That is the likely place to adjust the defaults (currently defaults to 0 in 7.0 master).

proposed fix at https://gerrit.libreoffice.org/c/core/+/90495
Comment 18 Justin L 2020-03-17 11:05:49 UTC
Changing the graphics style affects existing documents. I'm not going to stick my neck on the chopping block for this one...

That said, changing it at the graphics style DOES seem to be the right place to do it. You want the user to be able to give their own opinion on how graphics ought to be imported, and they can do that by changing the graphics frame-style.
Comment 19 Telesto 2020-05-17 18:58:09 UTC
Throwing it back at UX for a moment.. Reading .. graphics style similar to table style/frame/list style etc in the sidebar.. 

And let the default import style for what it is (for now).. making it easier to switch to a different layout is already quite helpful, IMHO

But not sure how much work it would be, or what the opinion of UX is..
Comment 20 Heiko Tietze 2020-05-18 08:44:39 UTC
(In reply to Justin L from comment #17)
> Please apply the suggestion in bug 92746 comment 7 with 1/8" (3mm when
> converted to SI)
> ...
> proposed fix at https://gerrit.libreoffice.org/c/core/+/90495

(In reply to Justin L from comment #18)
> Changing the graphics style affects existing documents. (abandoned the patch)

So the goal is clear, the way in principle as well. The missing piece is to set the value only for new documents to keep existing intact. 

Alternatively we could introduce another style "With Spacing" under the parent Graphic. And let the user switch.