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.
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
I can't reproduce this behavior using Version 3.6.5.2 (Build ID: 5b93205). Therefore I mark this as regression.
(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.
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
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.
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 ...
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 !
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.
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.
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.
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.
So closing fixed; thanks so much for the bibisect ! :-)
Modified Assignee due to facts to ease finding of experts via Bugzilla