Bug 61256 - Saving particular odg file resets font formatting
Summary: Saving particular odg file resets font formatting
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: high normal
Assignee: Michael Meeks
URL:
Whiteboard: bibisected40 target:4.1.0 target:4.0.2
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-02-22 00:43 UTC by Ryszard
Modified: 2013-04-10 05:45 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
sample file for showing saving font formating problem (39.94 KB, application/vnd.oasis.opendocument.graphics)
2013-02-22 00:43 UTC, Ryszard
Details
edited diff between flat odf exports (133.55 KB, text/plain)
2013-03-13 14:02 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryszard 2013-02-22 00:43:36 UTC
Created attachment 75280 [details]
sample file for showing saving font formating problem

Saving file under new libreoffice 4.0 removing text formatting (in my case in flowchart symbols), so reopened file always has font Arial size 18.
Attached file was created in different version, so will open correctly in 4.0, but saving it and reopening(in any version) should show the problem.
Comment 1 Jorendc 2013-02-25 22:34:01 UTC
I can confirm this behavior using Mac OSX 10.8.2 and LibreOffice Version 4.1.0.0.alpha0+ (Build ID: 80f57172833ec720a2bc0d7d9c8f82f8bc5fc70)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2013-02-24_11:53:07

You have some step by step guide how to reproduce this behavior from scratch? I tried to reproduce it on my own, but I can't. With which version did you create this odp?

Kind regards,
Joren
Comment 2 Jorendc 2013-02-25 22:36:06 UTC
I can't reproduce this behavior using Version 3.6.5.2 (Build ID: 5b93205). Therefore I mark this as regression.
Comment 3 Ryszard 2013-02-26 03:40:27 UTC
(In reply to comment #1)
> I can confirm this behavior using Mac OSX 10.8.2 and LibreOffice Version
> 4.1.0.0.alpha0+ (Build ID: 80f57172833ec720a2bc0d7d9c8f82f8bc5fc70)
> TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time:
> 2013-02-24_11:53:07
> 
> You have some step by step guide how to reproduce this behavior from
> scratch? I tried to reproduce it on my own, but I can't. With which version
> did you create this odp?
> 
> Kind regards,
> Joren

The file was created about 8 months ago, I do not really remember what was the office version than, but this was already rework from older version that was created few years back, probably using openoffice.
From this what I see the problem is that each object is not saved with changes made individually to it, and always apply all properties from style that is assigned to it(in my case default). So as workaround for libreoffice version 4.0, after opening file you may bring style and formatting window, select object and update style, or create style by selection and apply to object using same formatting. Problem is that I have quite a few files like this.
Comment 4 Joel Madero 2013-02-28 19:40:33 UTC
Bibisect 
 baa679e0fdc379e107b231ae025b54356846c207 is the first bad commit
commit baa679e0fdc379e107b231ae025b54356846c207
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon Dec 10 07:58:17 2012 +0000

    source-hash-4662df8a7561ce71ba00accbb5170e10818d6008
    
    commit 4662df8a7561ce71ba00accbb5170e10818d6008
    Author:     Matúš Kukan <matus.kukan@gmail.com>
    AuthorDate: Thu Aug 16 10:53:35 2012 +0200
    Commit:     Matúš Kukan <matus.kukan@gmail.com>
    CommitDate: Thu Aug 16 11:41:52 2012 +0200
    
        tubes: simplify and make more readable, I believe
    
        Change-Id: I83a4332d9947d03382b10ea050f26bf3ed544299

:100644 100644 06d3b00c8f2cd8f1f644a95ae857e72bcb9ca877 b716fff249ef76de0787d2a8319c2f7070d38e42 M	autogen.log
:100644 100644 9574689f4920cfb25e6fe9ae3791e83507352024 d5cd0596d367951df92d05f577e3847bde477733 M	ccache.log
:100644 100644 06a1a64175f01d774eb31ef226d6a5578d222afc 53577b741827fef73674a1c0aaa1d0560dcd664c M	commitmsg
:100644 100644 a97c14a33fd554535fe699b02c61f5bdd356d097 bacae80c7411d67901c4c9adc72d319e9e573e12 M	dev-install.log
:100644 100644 9bb59cf51c5bb8efacdf338951d522ecf2adcc64 0c0655ade12ef70098f9b245d5f335386c04f1e7 M	make.log
:040000 040000 bd9883b909ea19b137e5742e4d7d7d5f53b75262 7ffb4e08414500e61817e4ae252957e056603388 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
# good: [5bf3b624cdeb593e55402f44c730209f12813961] source-hash-4b4ca8030285bd66526ff5bb2b6ea5a75a6c6bc7
git bisect good 5bf3b624cdeb593e55402f44c730209f12813961
# good: [70771b69f427dcd3ace8caea819338f104b88c43] source-hash-83837d6514217c82ebe8d56dddf89fa34f4b5435
git bisect good 70771b69f427dcd3ace8caea819338f104b88c43
# good: [3959ee48f25552210657c68840918bc9d0d3b310] source-hash-57c3b583f1f69edd32b2a54253850e1b3b202255
git bisect good 3959ee48f25552210657c68840918bc9d0d3b310
# bad: [baa679e0fdc379e107b231ae025b54356846c207] source-hash-4662df8a7561ce71ba00accbb5170e10818d6008
git bisect bad baa679e0fdc379e107b231ae025b54356846c207
# good: [adcdd01db66917de374031eccbb13356826d1dc5] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good adcdd01db66917de374031eccbb13356826d1dc5
# good: [2e1f79f59bdf45eb6e08eafe8ca2b165cd94d8be] source-hash-62f5fc1d2f14f8164c3dd6eca5494a8c1b01301b
git bisect good 2e1f79f59bdf45eb6e08eafe8ca2b165cd94d8be
Comment 5 Michael Meeks 2013-03-13 14:02:53 UTC
Created attachment 76475 [details]
edited diff between flat odf exports


So - a great technique with this kind of bug is to save as flat-odf, then you can diff -u -w between versions to see what exactly changed.

I attach such a sample diff; things like:

   </style:style>
   <style:style style:name="P1" style:family="paragraph">
-   <style:text-properties fo:font-size="9pt" style:font-size-asian="18pt" style:font-size-complex="18pt"/>
-  </style:style>
-  <style:style style:name="T1" style:family="text">
-   <style:text-properties fo:font-size="9pt" style:font-size-asian="18pt" style:font-size-complex="18pt"/>
+   <style:chart-properties/>
   </style:style>
+  <style:style style:name="T1" style:family="text"/>
   <text:list-style style:name="L1">
    <text:list-level-style-bullet text:level="1" text:bullet-char="●">
     <style:list-level-properties/>

Look rather suspicious - this is from before -> after.

Why are T1 and P1 much empty styles, missing fo:font-size="9" in this new export ? - most odd.

Manually editing them back into the fodg fixes the font sizing problem.
Comment 6 Michael Meeks 2013-03-13 21:26:48 UTC
Interestingly, it is the presence of the OLE objects that causes the grief; that (it seems) clobbers the PropertyMap used for serializing the text objects: which is most odd.

Still digging ...
Comment 7 Michael Meeks 2013-03-15 17:39:00 UTC
It seems that the root cause of the problem is that the property mappers no longer happen to match up for charts and text paragraphs - which really badly screws up properties on export.

I've got a big re-factoring of all that style export magic on origin/feature/autostyle - review appreciated.

I'd be interested if that branch works better for calc import/export around styles when there are charts/OLE objects embedded (do we know of other bugs there ?)

Thanks !
Comment 8 Michael Meeks 2013-03-18 10:41:15 UTC
git log 62f5fc1d2f14f8164c3dd6eca5494a8c1b01301b..4662df8a7561ce71ba00accbb5170e10818d6008 -- xmloff

I thought the bisection was to a re-base commit; but looking at it again - if the above is correct, it suggests a much more minimal fix.
Comment 9 Commit Notification 2013-03-18 11:02:52 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=64595f591cdeebc389deee37adbc68e14f9a6286

fdo#61256 - the Get.*Export methods also create and register styles



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 10 Commit Notification 2013-03-18 11:48:49 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b4a1cd7e3cc476bcdc143ba3964c6211e007186&h=libreoffice-4-0

fdo#61256 - the Get.*Export methods also create and register styles


It will be available in LibreOffice 4.0.3.

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 11 Commit Notification 2013-03-18 14:23:09 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-0-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ced7d3008c15643a3e35b8d0bc8391e847476a62&h=libreoffice-4-0-2

fdo#61256 - the Get.*Export methods also create and register styles


It will be available already in LibreOffice 4.0.2.

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 12 Michael Meeks 2013-03-18 15:14:36 UTC
So closing fixed; thanks so much for the bibisect ! :-)
Comment 13 Rainer Bielefeld Retired 2013-04-10 05:45:02 UTC
Modified Assignee due to facts to ease finding of experts via Bugzilla