Created attachment 74571 [details] Slide missing first line ident in 4.0 The latest release has a regression (compared to 3.6.5) opening an Impress document with a negative first line ident results in a setting of zero, for all styles. The attached document illustrates what I mean: if opened in 3.6.5, the first line has an indent of -0.6 cm, and the other lines have an ident of 0.6 cm, for both Outline 1 and Outline 2 styles. However, in 4.0.0, only the 0.6 cm setting for all lines appears, and the first line ident is 0.0 cm for all styles. This appears to be loading problem, because if I set the ident back to -0.6 in 4.0.0 and save, then re-open in 3.6.5, the setting is correct (i.e., 4.0.0 can use and set the setting). However, opening again in 4.0.0 results in the 0.0 cm indent (i.e., 4.0.0 ignores the setting when the file is opened). Possibly related is that if I set Outline 1 to have the correct first line ident in 4.0.0, the setting does not carry through to the other (linked) styles, whereas it does if I change that setting in 3.6.5. The upshot is that I have numerous presentations that now have a slight shift in ident and consequently occasional unexpected (new) line wrapping, and this effectively makes 4.0.0 worthless for me unless I completely redesign thousands of slides. In the event it is relevant, I'm using the Debian packages currently in experimental.
Indeed, I see the regression. Version 4.1.0.0.alpha0+ (Build ID: 9601a571d42b0199bdccf2256fc8be82e14af8a Date: Mon Feb 18 23:22:17 2013 +0100 Bodhi Linux 2.2 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ New (confirmed) Major (loss of data) Highest (regression + major bug) regression bibisectrequest
Bibisected: source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 # 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
With bibisect make sure to include both the output after your last git bisect good/bad as well as the output of git bisect log :-D Thanks for bisecting this one!
This bug persists in 4.0.3.3. Specifically, I have narrowed it down to the fact that styles convert all negative first line indents to zero when the file is loaded. This is true only of styles; negative first line indents applied directly to a block of text remains upon save and load. And positive first line indents in styles also are unaffected. This can all be tested with a completely new file, simply by adding some text to a textbox and changing the formatting directly or via the default style, saving, and reloading.
good catch - duplicate of another bug. other bug has a bit more info and input so marking this one as a dupe even though this one was reported first. Thanks bchemnet *** This bug has been marked as a duplicate of bug 62176 ***