Created attachment 105501 [details] incorrectly rendered file Fedora 20 Build ID: 4.2.6.2-1.fc20 Document renders incorrectly (running off to next line, showing some strange rectangles); looks much better in google docs
Please provide a pdf of what it should look like (ie. from MS Office). Marking as NEEDINFO. FWIW this bug report isn't very actionable. I'll confirm it if you provide a pdf but saying "make this document look right" isn't nearly as good as identifying and reporting SEPARATELY every particular problem you see. Also the title of the bug isn't very informative - so if you want to help a bit you can report separate bugs with clear titles that are particular to a single issue. Else you can just provide the pdf and I'll mark as NEW but developers are less inclined to just take a bug report that's "this file looks wrong." Marking as NEEDINFO - once you provide a pdf please set to UNCONFIRMED. Thanks
Created attachment 105696 [details] google docs rendering I don't have MS Office, here's google docs rendering (looks a lot more reasonable)
The font rendering seems to take more space in LibO. The date field doesn't display the time. I don't see any strange rectangles, though. Set to NEW and tweaked severity per https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg Win 7 64-bit Version: 4.5.0.0.alpha0+ Build ID: b144f0ac8695dd62a2053b4e88212d0b109c9a41 TinderBox: Win-x86@51-TDF, Branch:MASTER, Time: 2014-11-25_00:14:54
3.3.0 looks quite ok, the date field only displays time. 3.5.0 has an extra blank page after pg 1 and the date field displays the date only. I guess someone could do a bibisect and see, when this runs to a second line (bad): Participant Name/Belt Size(Print) Parent/Guardian Signature So I'll mark this as a regression and request a bibisect. Ubuntu 14.10 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Created attachment 112174 [details] Comparison of PDF vs LO, lots of filter problems for sure.
What I am seeing is that something in the front of each line is being viewed as a tab stop which is bumping the text out into the tab position. Older versions of LO seem to handle this document better. Newer versions of LO seem to get worse and worse in regards to this specific document. I am closing in on a bibisect.
13312242b4c33dfbbf82238d6e47bbefdaf22f32 is the first bad commit commit 13312242b4c33dfbbf82238d6e47bbefdaf22f32 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed May 2 19:15:24 2012 +0200 source-hash-33f5acad371bcf838011b3629450e6dcd405a4e9 commit 33f5acad371bcf838011b3629450e6dcd405a4e9 Author: Jesús Corrius <jesus@softcatala.org> AuthorDate: Wed Apr 25 17:46:26 2012 +0200 Commit: Jesús Corrius <jesus@softcatala.org> CommitDate: Wed Apr 25 17:46:26 2012 +0200 Remove blank space introduced in previous patch :100644 100644 660cb56bf1c16bfd2cabae508e0d417af16ee735 4b364d22d5fdd945ff74a38b14b10507b6cc7bef M ccache.log :100644 100644 66eeda0541e4612f2c10b5589373632d18282168 c8fa6358af0799d993b059b1bcddb303235dd53c M commitmsg :100644 100644 444e480fc8394f56fdfae6917f0661407b0247b8 2b0ae781a4dfeaa9676195700c004b78fb4717d6 M dev-install.log :100644 100644 9328f48a3231d91f50da06112b6a3abc05587f52 88f62105dad7c2c7c1603c19e3f5645273271293 M make.log :040000 040000 8a8d95fd0367932826c728a26fec3c639782548a 71e9fb5a6916a6eacd5d42ba99d35f21bea2a69e M opt :100644 100644 fae9744eac2d90d2474d2491a5475d1ab5a74ecf 5918afbd72326bd1187716203ebdb3f2a36639c6 M patch.log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect good 369369915d3582924b3d01c9b01167268ed38f3b # bad: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 git bisect bad 6fce03a944bf50e90cd31e2d559fe8705ccc993e # bad: [8a39227e344637eb7154a10ac825d211e64d584c] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf git bisect bad 8a39227e344637eb7154a10ac825d211e64d584c # good: [e8bc60acad752e284db73fc4d8ad383ac055361c] source-hash-7e6e16ba6de2d3ef2b130d1ad5ffeabfdb37918e git bisect good e8bc60acad752e284db73fc4d8ad383ac055361c # good: [e1ec404400a4c6531a5d49d89631d1acc599071d] source-hash-5708f2bfa70db0479ddbf9b454329cd81e0f509d git bisect good e1ec404400a4c6531a5d49d89631d1acc599071d # bad: [09b0c68ed3c0cb7a96ac98146a67e9540df994c8] source-hash-d50f02bec4a70bd26a518e4e76f4a876454ab937 git bisect bad 09b0c68ed3c0cb7a96ac98146a67e9540df994c8 # bad: [a0225eee14bbecc662d5e82894b0f7738c75ff23] source-hash-1aa91a2d8e7db5cebff5b47f3005f1acff64d25e git bisect bad a0225eee14bbecc662d5e82894b0f7738c75ff23 # bad: [13312242b4c33dfbbf82238d6e47bbefdaf22f32] source-hash-33f5acad371bcf838011b3629450e6dcd405a4e9 git bisect bad 13312242b4c33dfbbf82238d6e47bbefdaf22f32
Created attachment 112194 [details] Screenshot from 4.5 master Unfortunately this is in one of those mysterious ranges that don't work for me at all - either in bibisect or built from source. However, I also don't see the random start-of-line characters in current 4.5 (see attached screenshot) If there's any problem left here it's possibly the indentation, but we'd need a rendering from Office to compare to in order to determine that.
Created attachment 112195 [details] PDF generated from Office for Mac 2011 This suggests LO is getting the indentation wrong
Created attachment 112196 [details] Screenshot from Office for Mac 2011 There's also some funky on-screen formatting that LO seems to know nothing about (this is from a Chinese edition of Office, so there is some localised Chinese text that's irrelevant to the actual document)
(In reply to Beluga from comment #3) > Set to NEW and tweaked severity Please do not confirm reports with multiple problems such as "file displayed incorrectly". Each problem should be reported separately. I suggest this bug be only for indentation/tab stops (with title updated) and other problems searched and reported separately. (In reply to Dave Richards from comment #6) > What I am seeing is that something in the front of each line is being viewed > as a tab stop which is bumping the text out into the tab position. Older > versions of LO seem to handle this document better. Newer versions of LO > seem to get worse and worse in regards to this specific document. I am > closing in on a bibisect. Since 3.5.7.2 handles this document better, I'll change Version to 3.6.0.4 because tab stops started there.
(Better luck building this on the second try) A follow up source bisect revealed the following. After commit a9e16b168c7eb046c62d6d7d2669bdea944da279, the text paragraph indentation was wrong, and there were unwanted bullet points on each paragraph. Commit 71e1927c78e3873c377d87feb64b33286138756b later fixed the problem with the bullet points, but the issue with the indentation remains. Adding Cc: to l.lunak@collabora.com; Any chance you could take a look at this? Thanks commit a9e16b168c7eb046c62d6d7d2669bdea944da279 Author: Luboš Luňák <l.lunak@suse.cz> Date: Fri Apr 6 18:48:54 2012 +0200 don't use properties that aren't valid for paragraphs (part of bnc#751028) commit 71e1927c78e3873c377d87feb64b33286138756b Author: Adam Co <rattles2013@gmail.com> Date: Wed Jul 10 19:12:45 2013 +0300 fdo#66781 : fix bullets with level 0 Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport.cxx Change-Id: I14b0ce9ae096eae4759793a49865eefe16ec1afd Reviewed-on: https://gerrit.libreoffice.org/4818
I was testing the Apache POI based DOCX export of my own software against LibreOffice Writer 4.4.4.3. I thought I was doing something wrong with exporting global styles, since LibreOffice was not picking up indentation or tab-stops of global styles at all. I confirmed that I stored the indentation and tab-stop information exactly like LibreOffice itself is storing this information in word/styles.xml when exporting to DOCX (OOXML). Then I discovered, that LibreOffice Writer *itself* does not restore the indentation and tab-stops from global styles in documents that it has exported itself! To reproduce: 1) In a fresh document in LibreOffice Writer, create a custom root style, not based on any other style. 2) Open format templates, edit this custom style and define an indentation (first, left, right). Define some tab-stops. 3) Observe that a paragraph set to this style in the text shows the expected indentation and tab-stop positions. 4) Export as .docx and close the document. 5) Re-open/import the file exported in step 4. 6) Observe that the indentation and tab-stop information is not restored on the global style. Notice that the text formatted with this style is now formatted differently (with default indentation and tab-stops).
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Created attachment 126461 [details] incorrectly rendered file compared in MSO and LO
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro in 6.2+.
This interestingly designed document is using a style that has numbering enabled, but doesn't actually use numbering. LO doesn't emulate Word's numbering well.
Still exists in version: Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
This still exists, but as per comment 18 this is a very niche document using a not very common feature As such I don't see the reason to have this as highest priority, the default would be medium. At least it hasn't been prioritized for 5+ years :) Version: 6.4.0.0.alpha1+ Build ID: 80109586e6cb6d3e2e0a53a9079c3125ec9b8368 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Still confirmed Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: bfbf745470cb6f99532523fdeffca061b37d8393 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 31 May 2020
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d2e428d1abb9f2907c0b87d55830e8742f8209b9 tdf#83309: docx import: allow for lists tabstop at zero position It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/a380a06c1872091e8fa8c810e95a8e1d5dfe1820 tdf#83309: docx import: allow for lists tabstop at zero position It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/219b122861b1a65f48c9c363c20970f307134ba6 tdf#83309: docx import: allow for lists tabstop at zero position It will be available in 6.4.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 162062 [details] How it looks in LibreOffice 7.1
Hi Vasily, The list still has an incorrect indent in Version: 7.1.0.0.alpha0+ Build ID: 11d21b3c1f7754b5d13ae9ea88da562ec74366ff CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded See attached screenshot
Xisco, I can't repro this situation. Everything is ok on my machines. Tested with: Version: 7.1.0.0.alpha0+ (x64) Build ID: cec1d2cb8eb17a28bf418625ea6ea522d6c1c580 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: en-US (C); UI: en-US Calc: threaded At the same time I see, that for some strange reasons zero width spaces used as a kinda bullets in this doc are displayed as rectangles. Incomplete or corrupted font? Some platform specifics?
(In reply to Vasily Melenchuk (CIB) from comment #27) > At the same time I see, that for some strange reasons zero width spaces used > as a kinda bullets in this doc are displayed as rectangles. Incomplete or > corrupted font? Some platform specifics? Indeed: the rectangles say they use the Cambria font. I don't have this font available on Linux and thus I still get the bad result, where the underlines run to a second line. On Windows everything looks fine. In my view this can be closed as fixed.
Created attachment 162106 [details] Screenshot of the document in current Writer Does not look better for me in: Version: 7.1.0.0.alpha0+ (x86) Build ID: a3c8ea5e644ca2fc04de9f01ba9f8ace47f520f0 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL
Sorry to reopen, but I see the same on Win 8.1 as Xisco. Tab of the numbering is much larger than in Word (pulls in to the U of SIGNUP, insted of to the I), although its position is now imported correctly as 0.
Created attachment 162111 [details] Example file with different tabulator positions My experimenting shows that it is possible to set small values for the Tab stop at, about until 0.3 cm and it will take effect. But set it to 0.25 cm or below and then it does not take effect - tabulator size visually resets to 1.27 cm, despite that the dialog says 0.25. The tabulator and bullet symbol would be then so close they would overlap and it seems that Writer just cannot do that.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5ed96c798679a1613b058a11b30cce4ba0ffd920 tdf#83309: sw: do not create bullet with no char It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "libreoffice-6-4-5": https://git.libreoffice.org/core/commit/3c09eb16f4e0dea47839adbef66584a6e7bbca63 fix tdf#83309 tdf#120394 tdf#132754: squashed fix backport It will be available in 6.4.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/0453702ea9cf48fc5764bb7d2d6685e0234e09cb tdf#83309: sw: do not create bullet with no char It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.1.0.0.alpha0+ Build ID: 63f3485b57904de4e77c04f5759e6563fcce6748 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Vasily, thanks for fixing this issue!!
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/dcd3375233714c52c693bbf3a32d380f75d08fac tdf#83309: sw: do not create bullet with no char It will be available in 6.4.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9169202e7217d24a108d97d1af7b4ef2d2dc4ac5 CppunitTest_sw_ooxmlexport14: replace Verdana with Noto Sans in tdf83309.docx It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.