Created attachment 103881 [details] LibO 4.1.6 VS 4.3.1 Steps: 1) Open attachment 103815 [details] in Word 2013 and convert to RTF, else open < https://drive.google.com/file/d/0B6qJrVIa0SAlbHNZaDRsYlVpQkU/edit?usp=sharing > 2) scroll to page 3 3) look at attached screenshot Tested in 4.3.1. Regression that begin in 4.2.x. 4.2.5 doesnt display the TOC, while 4.2.7 displays it with the correct stlye (font name, size), except that the text is shown as hyperlinks (blue with underline).
Created attachment 103882 [details] how TOC looks in 4.2.7
Tested 4.3.1 on Windows and it looks similar to the 4.2.7 screenshot except that all the text is in Times New Roman.
Checked this issue on 4.4 on Linux and here is now it looks (basically the same as 3.2.1) - attachment 103946 [details]. Seems linux is more broken than windows on this issue, but both arent perfect.
The fixing of the font in the last few days has fixed half of the issue now. Now the only remaining issue is that 4.3.1 looks like the 4.2.7 screenshot (text is in blue with underline).
Bodhi Linux 2.4 running E17 LibreOffice 4.4 built August 7, 2014 Confirmed: New - confirmed Normal - can prevent high quality/professional work High - regression Bibisect - JUST FOR FONT COLOR AND UNDERLINE (this was a separate issue than the other one that was resolved already) 4850941efe43ae800be5c76e1102ab80ac2c085d is the first bad commit commit 4850941efe43ae800be5c76e1102ab80ac2c085d Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sat May 10 23:51:39 2014 +0000 source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b commit 980a6e552502f02f12c15bfb1c9f8e6269499f4b Author: Julien Nabet <serval2412@yahoo.fr> AuthorDate: Sat Jan 4 12:21:09 2014 +0100 Commit: Julien Nabet <serval2412@yahoo.fr> CommitDate: Sat Jan 4 12:46:59 2014 +0100 cppcheck: Clarify expression with parentheses Change-Id: I71333af38adba1d916138835e28419bb62cd1db4 :100644 100644 0bbbdc4f0bf92d9f129a9da63934e49f60e9f86f 711777e12295c5972db7458ed3b6adca03616717 M ccache.log :100644 100644 09c19033d1fcb3eac30b479caee49891254a1012 e932875a94f8ee2c1d0fdedc9b0a87929dbecfdd M commitmsg :100644 100644 29b66fc8e0226662b8e568089d4ebbfde4fc63f5 b46aa9736656e7a84a76c2088aeb76edbe56251d M make.log :040000 040000 ba7d095ae893c586c96d42d52058c62f9e976ca1 0134398ee8a546fe917806c9490bda13e9b0c704 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d # skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681 git bisect skip a043626b542eb8314218d7439534dce2fc325304 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # good: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 git bisect good c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31 # good: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 git bisect good c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31 # good: [30cde618212ecaf5725321372bd1b8339f8e2b9f] source-hash-137f872aa8e6e598e7c7ed1ffa4d21e580e22bdb git bisect good 30cde618212ecaf5725321372bd1b8339f8e2b9f # good: [30cde618212ecaf5725321372bd1b8339f8e2b9f] source-hash-137f872aa8e6e598e7c7ed1ffa4d21e580e22bdb git bisect good 30cde618212ecaf5725321372bd1b8339f8e2b9f # good: [306d62ec4b911895f08f2bb8efefebed7ac795f0] source-hash-735bd120c9ee2d9bb3514907936c27efb75d7282 git bisect good 306d62ec4b911895f08f2bb8efefebed7ac795f0 # skip: [18ee045c7e35e5ae98cffaafd56fb6fb37d7afcf] source-hash-fe506f34f2dccb6562935fe4dfbc1fe6d609dec8 git bisect skip 18ee045c7e35e5ae98cffaafd56fb6fb37d7afcf # good: [2a3d9160aa946746b49f306e4f8cc5ddcd27d922] source-hash-cff891fc44adcca745bcaa9ae95483bd63aa05ae git bisect good 2a3d9160aa946746b49f306e4f8cc5ddcd27d922 # good: [33ac6698e6d90d84f99d784b9553ee87eec27d6a] source-hash-732c0f929fc0229b6da37d4ec4b6de8994fcea46 git bisect good 33ac6698e6d90d84f99d784b9553ee87eec27d6a # good: [9fe7b44f1975d64e3009c31341187c53c8e3a2b8] source-hash-7f5494f3c4bf14209a119c6b21c02e10075503ae git bisect good 9fe7b44f1975d64e3009c31341187c53c8e3a2b8 # good: [6f7541cf54e32992fe5e0cee84f9a7b17c378b76] source-hash-e11a80d0be9db1e8cc1054d166638a99e89defea git bisect good 6f7541cf54e32992fe5e0cee84f9a7b17c378b76 # good: [e0ab078ed43a5f7fde83c2a310e7d75c861d02c9] source-hash-53745911a7055cab0ddcfc4ac221ecfaccb04902 git bisect good e0ab078ed43a5f7fde83c2a310e7d75c861d02c9
There are 15 writer commits in the range 53745911a7055cab0ddcfc4ac221ecfaccb04902..980a6e552502f02f12c15bfb1c9f8e6269499f4b. Of those, this one: commit 9679e9c23216decb5f9f25f85b04cb3f25211111 Author: Vinaya Mandke <vinaya.mandke@synerzip.com> Date: Mon Dec 30 16:22:30 2013 +0530 fdo#69649 Fix for pre-rendered Table Of Contents Added Import and Export Uts for the same Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport.cxx Reviewed on: https://gerrit.libreoffice.org/7207 Change-Id: I966b3d268dd407aa05823e29fe1da4d097091265 Looks somewhat suspicious as it handles TOCs, CC'ing author.
The problem is that the table of contents has a character style and also has direct character formatting. For contents inside the table of content field result, Word seems to ignore the character style and only handles direct formatting, and in case of DOCX, we do the same. The situation is a bit more complicated for RTF, as in every RTF file Writer or Word produce, in case a character style is used, the contents of the character style is duplicated after the character style usage, to support old readers, not handling character styles. This means that on import, we have to find out what direct formatting is just a duplication of the character style and what is real direct formatting. We do this already to help import performance, but in this case it also affects correctness. So the question is why the underlining is not detected as a duplicated direct formatting. If that's fixed, the underlining will go away from the TOC.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=75d0cbb2e8f737e4c1721285a172618a1af78135
Thanks for the patch !!! (In reply to Miklos Vajna from comment #8) > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=75d0cbb2e8f737e4c1721285a172618a1af78135
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
Migrating Whiteboard tags to Keywords: (bibisected filter:rtf) Remove redundant 'rtf_filter'. [NinjaEdit]