Created attachment 141972 [details] comparison MSO 2010 and LibreOffice 6.1 Steps to reproduce: 1. Open attachment 90710 [details] from bug 66401 -> See the field characters. They're much smaller than before. See the attached image Reproduced in Version: 6.1.0.0.alpha1+ Build ID: 1e2afc9bd3062cfba6b65b45c17a08f298014239 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group [Bug found by office-interoperability-tools]
Regression introduced by: author Luke Deller <luke@deller.id.au> 2018-03-05 00:14:28 +1100 committer Miklos Vajna <vmiklos@collabora.co.uk> 2018-03-05 10:26:47 +0100 commit 18cbb8fe699131a234355e1d00fa917fede6ac46 (patch) tree 0642ae0059b821ed52228bde8bb526c15e2ec285 parent 60ac7418747530a006894a7941c67c5006d6158c (diff) tdf#107035 Fix field character style DOCX import Reinstate a call to DontExpandFormat which was removed from appendTextContent in commit 232ad2f2588beff50cb5c1f3b689c581ba317583 This ensures that direct character formatting which ended immediately before the insertion point will not be expanded to cover the inserted content. Bisected with: bibisect/bibisect-linux64-6.1 Adding Cc: to Luke Deller
The same commit makes attachment 114395 [details] from bug 50774 to displayed a random '2' on the document
Created attachment 141996 [details] The number '2' introduced by the same commit
Thanks you for finding this with your office-interoperability-tools work Xisco! I think the underlying issue in attachment 90710 [details] existed prior to commit 18cbb8fe699131a234355e1d00fa917fede6ac46. This is about an old equation editing feature in Word described here: https://blogs.msdn.microsoft.com/murrays/2018/01/23/microsoft-word-eq-field/ This example document uses such an "equation" to draw a superscript "x " superimposed upon a subscript " a". While LibreOffice does not in general handle this old equation syntax, it does have a special case which can handle this example. It imports it as a "Combine characters" field, a field intended for use with Asian languaes where several character are arranged in a grid occupying the space of a single character. This handling existed in the ww8(doc) filter inherited from StarOffice at the beginning of our git history, and it was reused in the docx import for bug 66400 in commit 5342cd7533a51fd488de85565674ee01649ddcbc The problem is that a "Combine characters" field containing 4 characters will show each character at half of its normal height/width (quarter of the area). However the Word equation does not reduce the size of the letters at all. This problem was hidden in the example here, because there was direct formatting placed upon the text prior to the field to double the font size. This direct formatting was *not* applied to the field itself in Word, however due to bug tdf#107035 this direct formatting was wrongly applied to the field in LibreOffice. This resulted in the field's font size being doubled, which exactly compensated for the problem I described in the previous paragraph. Now that tdf#107035 is fixed, the problem in the equation import is no longer hidden.
Created attachment 142054 [details] First example with formatting removed Here is the first example edited in Word 2016 to remove the direct formatting. This example demonstrates the underlying problem which is independent of commit 18cbb8fe699131a234355e1d00fa917fede6ac46: the letters in the fields are smaller in LibreOffice than in Word, with or without that commit.
Dear Xisco Faulí, 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
Still reproducible in Version: 6.3.0.0.alpha0+ Build ID: 630db80d17616d635cf2e5f1d5a0852428b794a3 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Removing 6.1 regression as per comment 5. Support for this was introduced in 4.2 via commit 5342cd7533a51fd488de85565674ee01649ddcbc Author: Caolán McNamara on Wed Sep 25 22:40:23 2013 +0200 Resolves: fdo#66400 import combined characters from docx move .doc combined character parser stuff from sw to filter for reuse in .docx and fix bad length problem when nSavPtr == -1 after String->OUString conversion. Thanks for the pasta CloudOn.
Created attachment 170552 [details] tdf117501-fmtcleared_42_72.pdf: same in LO 4.2 and 7.2. No regression.
Dear Xisco Faulí, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug