Just a small feature request: Writer currently does not allow to set an inner spacing between the edge of a text frame and its actual text content unless the respective edge has a visible line. I suggest to allow that. Steps to reproduce: 1. Create a text frame with "Insert/Frame..." 2. Right-click the frame and select "Frame..." 3. In the "Borders" tab, switch off the visible line at any edge of the text frame ("Line arrangement"). 4. Enter a "Spacing to contents" value for any edge that does not have a line. 5. Press OK => The entered spacing is ignored and set to zero. 6. Re-open the dialog => The respective setting is grayed out. Current behavior: For all edges that do not have a visible line, the respective "Spacing to contents" value is ignored and set to zero. When re-opening the Dialog, the respective edit "Spacing to contents" fields are grayed out. Wanted behavior: Always allow (and use) the "Spacing to contents" settings for all edges regardless of if they have a visible line or not. Pros: + More flexibility (when I do not want an inner spacing; I can still set it to zero myself) + That's how Word does it (=> more compatible import of Word documents, easier conversion to ODF)
- Reported with Bug Submission Assistant -
reproduced in LibO 3.3.4. and 3.6.0 master on Fedora 64 bit my be it is error? I can not understand for what it is done. @ Lenge Meanwhile use White color for border instead of no border or use Text Frame (on Drawing toolbar) if appropriate > - Reported with Bug Submission Assistant - What it was?
Is this the same as https://bugs.freedesktop.org/show_bug.cgi?id=32257 ? That bug report is marked as fixed, but it doesn't seem to be fixed in 3.5.5
Explanation from there: What's the need to have spacing to content when there is no border? I you want to have space between the text outside the frame and the text inside the frame, then you need to adjust the Spacing values in the Wrap tab. IMHO it sounds reasonable: no borders - no space And we still have 3 workarounds: Wrap options, white color of borders, paragraph options
<cite>Explanation from there: [...]</cite> Reply to that: See "Pros" section of my original report. ;) <cite>IMHO it sounds reasonable: no borders - no space</cite> I respectfully disagree; I see no reason to disallow the spacing in these cases. In fact, as the spacing GUI does NOT immediately gray out when a certain border is unset, the current behavior is both less flexible and misleading. (As already said: If you want zero space, you are free to enter just that - an explicit "0".) <cite>And we still have 3 workarounds:</cite> Yet still, none of these workarounds is applied when importing a Word document (how could it, as there is no 1:1 substitute for the missing feature). All in all, I think that allowing this feature wouldn't break any existing conception of LibreOffice, add more flexibility, ease the import of Word documents, and shouldn't be too hard to implement. So I'd like to stick with my request.
> Yet still, none of these workarounds is applied when importing a Word document Serious argument! Thanks! I hope it will be fixed
I would argue that at least .DOC (and thus likely DOCX) formatted documents *should* honor the borderless spacing since this is how it is handled in Word. It is a compatibility issue. Generally speaking, LO is still in the "early" stages of adoption. Ultimately, I agree that it would be best to leave "spacing to contents" active all the time for ALL document types, even if it could break some existing LO-authored/formatted documents. I don't forsee problems with turning on the "honoring" of any existing spacing settings since it looks like LO discards the "spacing to contents" settings IF borders are disabled. Thus any LO authored documents will not have existing spacing settings defined and so won't have compatibility issues if spacing is now always enabled. The only time I forsee a problem is if the document was authored in Word, and then reformated/resized in LO (without changing the border/spacing settings). In that case, the spacing settings will still be defined in the document and enabling them will change the formatting. I consider this a very acceptable "regression" since it increases compatibility with the original Word-authored document - removing the need to reformat/resize in the first place. I don't really see the benefit of LO's current behaviour of resetting spacing to zero when borders are turned off, so changing this behaviour shouldn't cause big problems. The only thing it does is save manually changing one setting by hand (since all four sides are sync'd by default). So I'm adding this comment to agree with Lenge and cast my vote for greater .DOC compatibility here.
This might be a minor issue using Writer as a word processor but when using it to create labels (New -> Labels) it becomes important (& aggravating). By default, the frames in a 'label document' have no borders, hence no padding. It's both ugly and hard to read label text printed directly against the left edge; further, many labels have rounded corners and it's possible to clip parts of letters off. There's no legitimate reason to bar spacing to contents when borders aren't in use. It's not like the frame doesn't have an edge to enforce spacing against -- it's just not a visible edge. ...a workaround is not the same as a solution.
I completely agree with this request, but it should probably be marked as an enhancement request, so I'll do so. Also, this is probably worthy of being put up on the vote for enhancement wiki page (https://wiki.documentfoundation.org/Vote_for_Enhancement).
Created attachment 127075 [details] textboxMargins.doc: varied margins with no border
Created attachment 127077 [details] screenshot from Word showing settings and how it should look sw/layout/frmtool.cxx:m_rBox.CalcLineSpace(SvxBoxItemLine::BOTTOM, /*bIgnoreLineStatus=*/true); This is a good place to start dev work. Forcing the existing bIgnoreLineStatus option to be true imports with textbox margins (and no border).
Created attachment 127114 [details] textboxMargins.docx: varied margins with no border in DOCX format see bug 84678 for .docx textbox spacing. Although this bug report is for all of LibreOffice, I've submitted patches that only apply to .doc files. I don't intend to try to change the default behaviour of Writer, but am simply trying to address the compatibility issue. https://gerrit.libreoffice.org/28601 SpacingWithoutBorders compatibility setting affecting .doc, allowing proper visual display and enabling round-tripping of .doc. https://gerrit.libreoffice.org/28602 SpacingWithoutBorders: allow UI changes without borders for .doc files only.
(In reply to Justin L from comment #12) > Although this bug report is for all of LibreOffice, I've submitted patches > that only apply to .doc files. I don't intend to try to change the default > behaviour of Writer, but am simply trying to address the compatibility issue. Pleas don't. Personally, I couldn't care less about DOC/DOCX formats, but I am strongly interested in native ODT being able to do what Word has been capable of for decades. Even besides the pure compatibility issue, there is enough reason to enable Writer to natively add the missing feature (see original description or comment 8 for example). And still, if you don't want the border spacing on a specific edge, you'll always be able to explicitly set it to zero (which has always been the default setting anyway).
I have just learned that this bug is closely related to bug 33041 (see comments 26, 30, 31 of bug 33041). Despite the different topics, the technical origin of both bugs is practically the same. So maybe the two bugs could/should be handled together?
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=52b29c60801cf75364fd8275a22e812797cb184d tdf#76349 SpacingWithoutBorders: enable .doc RT It will be available in 5.3.0.
Marking as needsUXEval - someone from UI can determine whether all of the work done to hide border settings was worthless. Likely the *need* for extra space (in labels for example) can be solved with other paragraph style settings like Indents and spacing.
(In reply to Justin L from comment #16) > Marking as needsUXEval - someone from UI can determine whether all of the > work done to hide border settings was worthless. 1.) I cannot judge if it was that much work, and I wouldn't call it "worthless" anyway, but it definitely made things more complicated by unnecessarily taking away some of the creative freedom without any obvious reason for the restriction. 2.) Allowing the spacing also without borders would add more flexibility, strengthen compatibility with other office suites and document formats, and last not least also resolve bug 33041. 3.) I don't like the idea of introducing artificial differences in handling different document formats such as ODT and DOC(X) where it isn't absolutely necessary for technical reason. 4.) Finally, why look for workarounds when both bugs (33041 and 41542) can be directly resolved at their common root cause?
(In reply to Justin L from comment #16) > Marking as needsUXEval - someone from UI can determine whether all of the > work done to hide border settings was worthless. > > Likely the *need* for extra space (in labels for example) can be solved with > other paragraph style settings like Indents and spacing. We discussed the question in the last design hangout. Following ODF 1.2 margin-border-padding is applicable to <style:graphic-properties>, <style:header-footer-properties>, <style:page-layout-properties>, <style:paragraph-properties>, and <style:table-cell-properties>, without restriction to a border style. So please have these options always enabled. And please rename the caption to "Margins" (see also bug 103275). The change will affect not only paragraph style but also the page and images, for example. That should be verified.
*** Bug 94279 has been marked as a duplicate of this bug. ***
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb615bc1462e5a48c368b51b0250138558882845 tdf#41542 rename variable to match LO5.4 terminology It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Changed description to match the decision to implement borderless-padding for textboxes/frames, pages, headers, paragraphs, ?characters?, images. (Tables already worked that way.) Waiting for LO 5.4 codebase to start before implementing the complete fix. There will be a lot of verification required, as well as compatibility changes for exporting to other formats. Questions: -clarify what "rename the caption to margins" means. I hope that doesn't mean change the tab name from "borders" to "margins". That would be a bad idea. -confirm that character properties should also support this. -is there anything that uses SVXPAGE_BORDER that should NOT allow borderless-padding? (I didn't see anything else.)
(In reply to Justin L from comment #21) > Questions: > -clarify what "rename the caption to margins" means. I hope that doesn't > mean change the tab name from "borders" to "margins". That would be a bad > idea. "Border" is fine. > -confirm that character properties should also support this. confirmed, same for the Page dialog As stated in bug 103275 'Use "padding" for space inside boxes and "margin" for outside distances.' I wonder how we call the spacing between columns. Would say this is a true _spacing_. @Regina? > -is there anything that uses SVXPAGE_BORDER that should NOT allow > borderless-padding? (I didn't see anything else.) No idea
@Heiko: Columns are difficult. Case tables: There exists the ODF style attribute 'table:border-model' with value 'collapsing' and 'separating'. A similar -but not referenced- attribute in CSS and XSL is 'border-collapse' with values 'separate' and 'collapse'. In case of 'separate', the attribute 'border-spacing' in CSS (and perhaps 'border-separation' in XSL) determines the length of the gap. But a similar attribute does not exist in ODF. Therefore there is never a gap between the borders of adjacent table cells in ODF, and we need not think about a name. Case page-layout, section, and frame: If there exists no single <style:column> elements, the attribute 'fo:column-gap' of <style:columns> can be used. If there exists <style:column> elements to make settings for each column, then the distance is set by the attributes 'fo:start-indent' and 'fo:end-indent' of <style:column>. These attributes are based on the corresponding attributes in XSL. The attributes 'fo:start-indent' of the first column and 'fo:end-indent' of the last column work, although there exist no UI to set them. And there is no UI for an unequal distribution of the total gap, but such work too. The implementation in LibreOffice seems to be wrong, as it used 'fo:column-gap' although <style:column> elements exist. The attributes 'fo:space-before' and 'fo:space-after' (for the vertical direction) are defined in ODF, but not implemented in LibreOffice. In regard to the name: It should not be 'padding' or 'margin' because those exist in addition for page-layout, section, and frame and have different meanings. 'start-indent' and 'end-indent' would be fine, if there are plans to allow different values left and right. 'start'/'end' and not 'left'/'right', because it depends on the writing direction. If we stay with the current UI, then 'gap' might be suitable, but it does not correspond to the file format, in case e.g. three columns with different 'gap'-values are used, which needs to result in single 'indent' values. The current word 'Spacing' as a generic term is not bad. So I suggest do not change it for columns, as long as there are no changes in the UI.
Created attachment 128375 [details] padding_demo.pdf: page show page/frame/paragraph/character/header/image borderless padding proposed patch: https://gerrit.libreoffice.org/30434 tdf41542 globally allow padding without borders: layout With this patch, I'm suggesting that in LO5.3 we allow the layout of borderless padding, but leaving the UI component for 5.4 (see Comment 21). This patch allows the layout demonstrated in padding_demo.pdf
Created attachment 128377 [details] padding_demo.odt
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f013d4a1f4073cda735befd6e446bee35f3db65c tdf#41542 PaddingWithoutBorders: allow UI changes if... It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9130627e21dd7c52c5eee1acc4b71f86eb9f3118 tdf#41542 globally allow padding without borders: layout It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=67e385ac8dfd804015c8b6199865b71ab6e927b4 tdf#41542 MSWordExport: accommodate page's borderless padding It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8eff1decd91cbfb10094c25d4cf1d2b434a4da72 tdf#41542 MSWordExport: accommodate image's borderless padding It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a34ff14f18da0df261ae8f1ca3f23de157706a1 tdf#41542 globally allow padding without borders: UI It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I forgot to update the bugzilla script. So the last commits are for 5.4.0 and not for 5.3.0 unless they get pushed to the 5-3 branch.
Marking this bug as fixed in LibreOffice 5.4 (see comment 30 and comment 31). To summarize the changes for 5.4 -user interface allows borderless padding in any format (odt/doc/docx etc.) for Pages, Paragraphs, Characters, Headers, Frames, Images. Summarized changes for 5.3 -layout displays borderless padding in any format (odt/doc/docx etc.) -user interface allows borderless padding for FRAMES only in doc/docx only. -any import/export issues identified were fixed for doc/docx.
*** Bug 78090 has been marked as a duplicate of this bug. ***
For a long time (at least since version 3.6) LibreOffice has reset the padding values to zero when borders were removed, but some older documents may still have padding values despite having no border - and thus may now render differently as the padding is activated. To remove the unwanted padding in LO <= 5.3, first add and apply a border, and then remove it again.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8f30759a540c0b323b2fb6d873abd67f37da2ca2 tdf#41542 sw cleanup: m_bBorderDist was always true It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.