Problem description: Negative indents in style definitions are not retained after closing a document Steps to reproduce: 1. Create a new style in Impress to achieve a hanging indent 2. Modify style and go to indents tab 3. Set space before text to 10mm 4. Set first line indent to -10mm (to achieve the "hang" in first line indent) 5. Create a textboxt, add some lines of blind text, apply style 6. Applied formatting works perfectly, producing a hanging indent 7. Save document, close Impress 8. Reopen document 9. Text in box is no longer a hanging indent 10. Check style settings under indent tab unveils that first line indent has been set to 0 (negative value omitted) Current behavior: See above - negative indents as part of style definitions are not properly saved. This seems to affect only custom styles, when using the default style things seem to be okay... Also if a hanging indent format will be used to create a new style from, the negative indent will be lost right away... Expected behavior: Defined values (also negative indents) should be kept. Operating System: Ubuntu Version: 4.0.1.2 release
Thank you for reporting this issue! I have been able to confirm the issue on: Version 4.1.0.0.alpha0+ (Build ID: 9a46e5614f5a0e0bdce3c497f81ca529da8fb5c) Date: Mon Mar 18 18:59:09 2013 +0100 Platform: Bodhi Linux 2.2 x64 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm this problem I am marking as: New (confirmed) Major - Data loss (formatting loss = data loss) Highest - regression, changed from default (high) to highest Keywords - regression (no problem in 3.6.5.2) Whiteboard Status - bibisectrequest + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage and join us on freenode at #libreoffice-qa There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
*** Bug 63292 has been marked as a duplicate of this bug. ***
See Bug 63292. Report the same behavior in Draw. Quite obvious, because draw and impress share a lot (all?) of code. Therefore I mark this bug as component 'LibreOffice' and set platform to all. Kind regards, Joren
Thanks for confirming this. Please also have a look at the previous bug I reported (62175). This is also connected to formatting loss (= data loss as you described it) with "some" relation to the default style. May be these two bugs share common roots and should be addressed together? Thanks again and regards, Markus
The inability to save a hanging indent is very frustrating. I might not have the know-how to eliminate the bug, but I would enjoy trying if someone would assist me in starting.
Definitely an import error - the file itself has the info to indent but releases since Version 4.0.0.0.alpha1 (updating version) have ignored the value. Bibisect below along with an attached document where you can open with 3.6 series and it's good, in 4.0+ it's wrong. 817bfd5393346f13e384678ae34710b46e91fa02 is the first bad commit commit 817bfd5393346f13e384678ae34710b46e91fa02 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun Dec 9 17:30:58 2012 +0000 source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 commit 47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 Author: Daniel Bankston <daniel.e.bankston@gmail.com> AuthorDate: Mon Jun 11 02:42:30 2012 -0500 Commit: Fridrich Štrba <fridrich.strba@bluewin.ch> CommitDate: Fri Jun 15 15:20:01 2012 +0200 Extend current database range unit test to also check xls and xlsx Since Excel doesn't support named database ranges, I also added tests for unnamed database ranges for ods, xls, and xlsx. Change-Id: I491324883c95cf2edb13c0561e975a13d13ba7d7 :100644 100644 f3050e05432fb8b9624ca76ff6025d190f12ef05 5af276938ba298fec7eaa06d3f236ad82b750ff0 M autogen.log :100644 100644 1b878dc8fb39668c78cbc584ab0666a4e2b32e04 ee55db580d376ce694e7185a4a061a4bca36cdd8 M ccache.log :100644 100644 db544f3790eabdd62ccb357b2db5244d00eb8804 ee1b400e961e7c449e8dfb9633a24ec9c9572b62 M commitmsg :100644 100644 91f7df69bee46893556862ca2b27dda5795a3614 709655bb46e0e76e1f2ff0230a77374d823ecf16 M dev-install.log :100644 100644 d393b955ae6f0b2d3715f32ee5a8b17690783497 4ffb69cf2df545b413704acb4227edc92b8c8132 M make.log :040000 040000 60ec76053315a06969fa1b47213433a65e80eb77 1a12da6aa4191683cbe51d96555409ada2a36782 M opt # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # bad: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect bad f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # bad: [5bf3b624cdeb593e55402f44c730209f12813961] source-hash-4b4ca8030285bd66526ff5bb2b6ea5a75a6c6bc7 git bisect bad 5bf3b624cdeb593e55402f44c730209f12813961 # bad: [fbd64ab02c3b611eb2161132a98d2a24ccf109ad] source-hash-77987eacff20dec40caf29aae61d262239d441e9 git bisect bad fbd64ab02c3b611eb2161132a98d2a24ccf109ad # good: [b8013cdf546a6319d5cd43746b74e35f177a5544] source-hash-699e7d9e4081942bb0ad73e9be73f90a26d0c2f7 git bisect good b8013cdf546a6319d5cd43746b74e35f177a5544 # bad: [778045e259d6c6cdd39e55feea1646e95eab8537] source-hash-6aeeca56daa9065f607cc7056e7d86d237c84a99 git bisect bad 778045e259d6c6cdd39e55feea1646e95eab8537 # good: [5d495e9d278412d3719fe3d18b429d2b34831241] source-hash-4f5c523b97542bdbfe69fb7695bcb9699c66f89f git bisect good 5d495e9d278412d3719fe3d18b429d2b34831241 # bad: [817bfd5393346f13e384678ae34710b46e91fa02] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 git bisect bad 817bfd5393346f13e384678ae34710b46e91fa02
Created attachment 78788 [details] Presentation File Showing Indentation Regression
I use hanging indents in our weekly church service presentations. They are prepared on a Windows 7 machine and are presented using a Windows Vista machine. Until this bug is fixed, I have to load the presentation before the service and go to each style that uses hanging indents and reset the negative first line values. A fix to this bug will be greatly appreciated. I see that LiO 4.1.0.0 is still afflicted.
Sorry for cross-referencing this again. It seems that the entire style management has a few issues that might be interconnected somehow in the background. Referring to bug 62175 where custom styles revert to default in some circumstances. This is very bad if one tries to reuse existing charts in another presentation because after saving and reopening your copied slides might be crippled. It would be good if these issues could be addressed all together with high priority and a fix be released very soon. These functional drawbacks really prevent LibreOffice from standing up to its main rivals in the market. This is sad because I do like LibreOffice a lot and promote it like hell in private and business spaces... Thanks and regards, Markus Michels
*** Bug 60620 has been marked as a duplicate of this bug. ***
LO does not export this negative indent correctly to .ppt format, which I'm going to guess is a side effect of this bug. I am going to have to switch to OpenOffice 4.1 until this thing is fixed. Unfortunately, I'll have to redo the font settings in OO, but... I MUST be able to export reliably to PowerPoint (in order to work with the presentation software our church uses) and OO provides that currently while LO does not. Going back from OO to LO seems to load in the correct font settings, at least.
Probably, this bug affects also the bug #68256 (https://www.libreoffice.org/bugzilla/show_bug.cgi?id=68256)
Remove comma from whiteboard.
*** Bug 71476 has been marked as a duplicate of this bug. ***
Bug still exists in LO 4.2.0 Beta 1, Linux x64
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
as per comment #6: FILEOPEN issue @joren: I tend to set component to Impress - is less general (vague) then LibreOffice .. Importance = medium (I thought that it is still up to devs to use that to set their priority ?)
@Cor - we set priorities now as a guide for some devs and in preparation when we have our own bugtracker. I think quite a few are using the flowchart located here: https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg and any bug that goes on MAB list should be set to HIGHEST so that we can slowly but surely move away from the MAB list and just use priority field
(In reply to comment #18) > @Cor - we set priorities now as a guide for some devs and in preparation > when we have our own bugtracker. I think quite a few are using the flowchart > located here: > https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg thanks - recorgnise some of that from years back ;) > and any bug that goes on MAB list should be set to HIGHEST so that we can > slowly but surely move away from the MAB list and just use priority field Ok, good to know. Changing that now.
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
Does this persist with LO 4.2.3.3? If so, please move it to mab4.2, since 4.1 will be EOL soon.
(In reply to comment #21) > Does this persist with LO 4.2.3.3? If so, please move it to mab4.2, since > 4.1 will be EOL soon. Yes - the bug is still existing in 4.2.3.3 (tested with Ubuntu 14.04). I changed now to mab4.2 (I hope I did it correct?)
This bug is also still in the Windows version LO 4.2.4.1.
looks like this was explicitly disabled by: commit 0f8f92a5b6fcba1fef456539bb929819a9162a85 Author: Muthu Subramanian <sumuthu@suse.com> AuthorDate: Fri Jun 15 17:20:20 2012 +0530 n757419: Hidden/Non-wrapping text. Negative values for left-margin plays havoc with the text in this case. bugdoc has: <style:style style:name="test1" style:family="graphic" style:parent-style-name="title1"> <style:paragraph-properties fo:margin-left="5.08cm" fo:margin-right="0cm" fo:text-indent="-5.08cm"/> </style:style> from the ODF spec version 1.2: 20.218 fo:text-indent The fo:text-indent attribute specifies a positive or negative indent for the first line of a paragraph. See §7.15.11 of [XSL]. The attribute value is a length. If the attribute is contained in a common style, the attribute value may be also a percentage that refers to the corresponding text indent of a parent style. => negative first-line indent is explicitly allowed by ODF, and disabling it is not an option to fix whatever problem may occur on other documents. guess the only option is to revert the above commit. fixed on master.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3b566ca82ebbe754902c1837e11da5fba1e6c93d fdo#62176: Revert "n757419: Hidden/Non-wrapping text." 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0500ac6f276f7e0a5522e1ecdbd3688462ee4533&h=libreoffice-4-2 fdo#62176: Revert "n757419: Hidden/Non-wrapping text." It will be available in LibreOffice 4.2.5. 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 tested libo-42~2014-05-09_01.06.23_LibreOfficeDev_4.2.5.0.0_Win_x86.msi and hanging indents now work properly. However, once the negative first-line number is entered, it is replaced with a 0.00 the next time Indents & Spacings is opened. The hanging indent still works properly; however, there is no indication that a hanging indent was set.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=35199df7b7af9d9dd3e98eb5f1b24ac1d407345c (related: fdo#62176) Revert "reset min/max values in paragraph ... 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.
(In reply to comment #27) > However, once the negative > first-line number is entered, it is replaced with a 0.00 the next time > Indents & Spacings is opened. this is a separate bug, but i was too lazy to file a new bug, it's now fixed on master.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a989b693f6836a17fba4b60b5f06d5117bdb67c4&h=libreoffice-4-2 (related: fdo#62176) Revert "reset min/max values in paragraph ... It will be available in LibreOffice 4.2.5. 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 tested Version: 4.3.0.0.alpha1+ Build ID: 19979ae27055cb910bfc368bfc2899d211f56be1 TinderBox: Win-x86@39, Branch:master, Time: 2014-05-21_00:29:23 using Windows 7, and find that the First Line Indent negative number is still visible when Indents & Spacings is reopened. The problem seems to be resolved. Thank you. I use this feature weekly.