Bug 62176 - FILEOPEN: Draw/Impress text shapes: Negative indents in styles not loaded properly
Summary: FILEOPEN: Draw/Impress text shapes: Negative indents in styles not loaded pro...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha1
Hardware: All All
: highest major
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: BSA bibisected40 odf target:4.3.0 tar...
Keywords: regression
: 60620 63292 71476 (view as bug list)
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2013-03-11 15:04 UTC by Markus Michels
Modified: 2014-05-21 20:51 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Presentation File Showing Indentation Regression (15.90 KB, application/vnd.oasis.opendocument.presentation)
2013-05-02 17:24 UTC, Joel Madero
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Michels 2013-03-11 15:04:54 UTC
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
Comment 1 Joel Madero 2013-04-08 16:38:52 UTC
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
Comment 2 Jorendc 2013-04-09 08:50:22 UTC
*** Bug 63292 has been marked as a duplicate of this bug. ***
Comment 3 Jorendc 2013-04-09 08:52:51 UTC
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
Comment 4 Markus Michels 2013-04-11 04:46:33 UTC
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
Comment 5 Russell Schmitt 2013-04-25 02:47:43 UTC
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.
Comment 6 Joel Madero 2013-05-02 17:24:17 UTC
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
Comment 7 Joel Madero 2013-05-02 17:24:43 UTC
Created attachment 78788 [details]
Presentation File Showing Indentation Regression
Comment 8 Gene Kohlenberg 2013-05-27 21:52:19 UTC
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.
Comment 9 Markus Michels 2013-05-29 09:34:49 UTC
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
Comment 10 Joel Madero 2013-06-14 02:22:55 UTC
*** Bug 60620 has been marked as a duplicate of this bug. ***
Comment 11 drew 2013-08-12 01:20:18 UTC
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.
Comment 12 whoever 2013-08-23 07:33:25 UTC
Probably, this bug affects also the bug #68256 (https://www.libreoffice.org/bugzilla/show_bug.cgi?id=68256)
Comment 13 Robinson Tryon (qubit) 2013-10-19 00:08:51 UTC
Remove comma from whiteboard.
Comment 14 Cor Nouws 2013-11-25 21:12:44 UTC
*** Bug 71476 has been marked as a duplicate of this bug. ***
Comment 15 Markus Michels 2013-11-29 12:22:26 UTC
Bug still exists in LO 4.2.0 Beta 1, Linux x64
Comment 16 Björn Michaelsen 2014-01-17 00:43:43 UTC
(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
Comment 17 Cor Nouws 2014-02-07 12:12:58 UTC
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 ?)
Comment 18 Joel Madero 2014-02-07 13:43:49 UTC
@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
Comment 19 Cor Nouws 2014-02-07 14:37:39 UTC
(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.
Comment 20 stragu 2014-02-13 23:15:58 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 21 retired 2014-05-04 10:24:39 UTC
Does this persist with LO 4.2.3.3? If so, please move it to mab4.2, since 4.1 will be EOL soon.
Comment 22 whoever 2014-05-04 11:37:06 UTC
(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?)
Comment 23 Gene Kohlenberg 2014-05-04 20:34:26 UTC
This bug is also still in the Windows version LO 4.2.4.1.
Comment 24 Michael Stahl (CIB) 2014-05-07 20:30:34 UTC
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.
Comment 25 Commit Notification 2014-05-07 20:31:33 UTC
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.
Comment 26 Commit Notification 2014-05-08 07:36:16 UTC
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.
Comment 27 Gene Kohlenberg 2014-05-10 12:27:24 UTC
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.
Comment 28 Commit Notification 2014-05-20 14:49:31 UTC
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.
Comment 29 Michael Stahl (CIB) 2014-05-20 14:54:57 UTC
(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.
Comment 30 Commit Notification 2014-05-21 08:43:36 UTC
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.
Comment 31 Gene Kohlenberg 2014-05-21 20:51:57 UTC
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.