Created attachment 67138 [details] Test file and screenshots When importing the attached RTF, the result is not quite identical to the MS Office products. This doesn't render the document unusable, so I used minor severity, but it still makes us do some work to restore formatting. If you open the screenshots in an editor, make one of them semi-transparent and align the paper corner, you may see that there are at least four inconsistencies here (I will describe the state in LO): 1. The table is shifted to the left about 2 mm 2. The borders are inconsistent (double borders are lost) 3. Some cells loose their central alignment 4. Text doesn't fit into some cells (which makes text in those cells to wrap and distorts the table). The fourth problem may be related to the general subtle difference in the text size that may be seen in header, too. But there it is unimportant, as it isn't very prominent. Another concern is rather long time needed to open the document. Yes, I understand that this is another issue, I just mention it here. And the speed is indeed MUCH better than in 3.5. If this issue will be resolved, the speed loss of RTF import compared to Apache OO (and LO 3.4) will be more than justified by overall accuracy (at least in our use cases :) ) Keep up your great work!
Thank you very much for your bug report and the additional screenshots to illustrate these bugs. For me it is partly reproducible with LO 4.0.0.3 (Win7 Home, 64bit). The mentioned bugs 2 and 3 I can already confirm. Regarding the other two bugs I cannot yet confirm, because the layout is even more worse in LO 4.0.0.3, because the table totally displaced. Therefore, I changed the importance to major. The speed seems to be ok for me.
The 4.0.1 seems to improve a bit over 4.0.0, but is still much worse than 3.6. Thus marking as "regression".
what exactly is a regression here? this bug was evidently filed against 3.6 and then retroactively extended to 4.0 in not quite obvious way. also the original description sounds like several distinct bugs already. it would be much better to file those aspects that are worse in 4.0 than in older versions as one (or several) _separate_ bug(s) to make this easier to handle for developers.
The regression is possibly the Bug 60644 (thus I won't fill a new bug, but instead will put a comment there and set the Regression keyword there). In the meanwhile I set this bug dependent on Bug 60644, and when it is resolved, will split it to separate bugs.
Now that the regression of Bug 66565 is fixed, I can return here to describe the inconsistencies left. The testcase in Attachment 67138 [details] is now (as of Version: 4.2.0.0.alpha0+ Build ID: 6a9aa432f53b53310ce56588508d151e15112b16) imported with column widths and font sizes that match MS Word Viewer more closely. Thank you! Now there's no annoying wrap of text in cells! But the alignment in cells is still left, not center. And the borders of table are single, not double, as they should be. I set it to unconfirmed, as it has not been confirmed yet in this state. The confirmation above was received when the regression took place. The affected version will be 4.1.1 (that have bug 66565 fixed).
(In reply to comment #5) > But the alignment in cells is still left, not center. Indeed, I'll have a look at that. > And the borders of > table are single, not double, as they should be. I can't see that. It might be a problem if the zoom is too small; but e.g. at zoom 200%, it's clearly a double border.
Miklos, thank you for looking into this! (In reply to comment #6) > > And the borders of > > table are single, not double, as they should be. > > I can't see that. It might be a problem if the zoom is too small; but e.g. > at zoom 200%, it's clearly a double border. I see now. You are quite right! But still, isn't it inconsistent, that the space between two lines of the border is imported different than original?
I guess the border problem is not RTF-specific. There is quite some Word vs Writer differences here: - Word (and thus RTF) says: \brdrdb\brdrw10, which means: double border style, width: 10 twips (== 18 mm/100) - Writer has a bit more properties here: InnerLineWidth, OuterLineWidth, LineDistance, LineStyle and LineWidth. The first 3 is set to 18 mm/100, style is double and LineWidth is set to 53 mm/100. 53 is about 3*18, so (apart from rounding problems) you typically do see a gap between the two lines. I guess it's due to rounding problems that it's not visible at zoom 100%. So, if you're unhappy with that, I would suggest dealing with that in a separate bug; feel free to refer to this attachment, but it's more like a Writer rendering problem than an RTF filter problem, which this bug is about. (And I'm not sure that is a regression.)
(In reply to comment #8) I have compared MS Word and LO at 500% scale and see that you are absolutely right. MS Word simply distorts the scale at 100% (maybe to inform user that this border is actually double when otherwise it would seem single, but this is just a cosmetic and something absolutely irrelevant to this issue). > (And I'm not sure that is a regression.) I never said it is; this keyword was set by mistake when Bug 66565 appeared. I remove it now. Thank you.
Set title to match the real problem
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=431853bfae7dccd139804caf7ac2505a7c283e63 fdo#54900 RTF import: support setting para align after text 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.
-4-1 review: https://gerrit.libreoffice.org/4913
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=49d3f271b0da11f1793135b067b9b5d4f48cf537&h=libreoffice-4-1 fdo#54900 RTF import: support setting para align after text It will be available in LibreOffice 4.1.1. 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.