Created attachment 103969 [details] Word 2013 VS Libo 4.3.1 When testing the RTF file in attachment 103764 [details] for bug 81978, if its loaded into LibO, the number 2014 should be centered but instead in on the left and that it only shows as 201 in master. Tested in 3.6.7, 4.1.6, 4.2.7, 4.3.1 and master on Linux. Regression as it worked correctly in 3.3.0 (old RTF importer).
Confirmed on Ubuntu 14.04 x86_64: * Version: 4.4.0.0.alpha0+ * Build ID: 8cb75e905cef50a2d8a423443d3dcef5f1899027 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-07-30_04:47:13 status -> new block -> bug 81234 (meta bug for rtf filter)
This issue is fixed after commit d4b96b45727314585d02394bb5a084393b647729
Migrating Whiteboard tags to Keywords: (filter:rtf) Remove redundant rtf_filter. [NinjaEdit]
(In reply to Xisco Faulí from comment #2) > This issue is fixed after commit d4b96b45727314585d02394bb5a084393b647729 I tested 4.3.7.2, 4.4.7.2, and master and this issue hasnt been resolved. Version: 6.0.0.0.alpha1+ Build ID: 60a03d97bc35c02cb1eff0e4a02b6f37fd1a6a34 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 137390 [details] smaller sample
Yes, you're right. I've just tested with d4b96b45727314585d02394bb5a084393b647729 and the problem is not fixed in that commit. Honestly, I dunno why i wrote that comment. Sorry for that. I was young and foolish
** 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
2014 is now centered in the original rtf attachment 103764 [details], but not in the minimised attachment 137390 [details]. Not sure what to do or believe. Original problem seen already in 3.5.0. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 2c7b0030b40de00e8c9ab997bdfe83631861968a CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 1 January 2019
(In reply to Buovjaga from comment #8) > 2014 is now centered in the original rtf attachment 103764 [details], but > not in the minimised attachment 137390 [details]. Not sure what to do or > believe. Well, in MSO, "2014" is centered in the minimised example, so let's keep this open. In LibO it is justified.
Created attachment 173517 [details] test_rtf - small sample_msword2003.pdf: As seen in MS Word 2003. \qc is the code for centred, and \qj is the code for justify. \s26 and \s28 8 designate the paragraph styles The RTF contains "2014" in: \pard\plain \ltrpar\s26\qc \li0\ri0\sb2760\widctlpar\wrapdefault\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0\pararsid12470261 \rtlch\fcs1 \af0\afs24\alang1025 \ltrch\fcs0 \f1\fs24\lang1049\langfe1049\cgrid\langnp1049\langfenp1049 {\rtlch\fcs1 \af0 \ltrch\fcs0 \insrsid16197105 20} {\rtlch\fcs1 \af0 \ltrch\fcs0 \insrsid6190013 14} but it seems to be affect by the last paragraph (defined after the header) \pard\plain \ltrpar\s28\qj Yup - 2014 is on the wrong paragraph and has the wrong paragraph style. It should be style _Титул_Год создания. There should be a page break AFTER 2014, not before it. There should be an empty, justified paragraph using paragraph style _Содержание as the last item in the document. It seems to be confused because there is no \par adding a Carriage Return after 2014. It immediately jumps to the \sect page break. Adding a CR before the page break fixes this document.
proposed fix at https://gerrit.libreoffice.org/c/core/+/118819
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fce76110e02409b67ad977ae0077adf55ca58065 tdf#82111 rtf import: ensure CR before section break It will be available in 7.3.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.
*** Bug 112413 has been marked as a duplicate of this bug. ***