Created attachment 105501 [details]
incorrectly rendered file
Build ID: 22.214.171.124-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: 126.96.36.199.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
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
Author: Bjoern Michaelsen <email@example.com>
Date: Wed May 2 19:15:24 2012 +0200
Author: Jesús Corrius <firstname.lastname@example.org>
AuthorDate: Wed Apr 25 17:46:26 2012 +0200
Commit: Jesús Corrius <email@example.com>
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 188.8.131.52 handles this document better, I'll change Version to 184.108.40.206 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 firstname.lastname@example.org; Any chance you could take a look at this? Thanks
Author: Luboš Luňák <email@example.com>
Date: Fri Apr 6 18:48:54 2012 +0200
don't use properties that aren't valid for paragraphs (part of bnc#751028)
Author: Adam Co <firstname.lastname@example.org>
Date: Wed Jul 10 19:12:45 2013 +0300
fdo#66781 : fix bullets with level 0
I was testing the Apache POI based DOCX export of my own software against LibreOffice Writer 220.127.116.11. 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!
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)
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!
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: 18.104.22.168.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
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 :)
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