Created attachment 156750 [details] sample document Steps to reproduce: 1. Open attached document 2. Save it as .RTF 3. Open the new created document -> Font size and bold is no longer preserved Reproduced in Version: 6.5.0.0.alpha0+ Build ID: dee81fb2e1df5091702b3c8b0e4a3f2b58e89291 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 [Bug found by office-interoperability-tools]
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=fd95fb975b754d71d3750e85431a4e596a40e659 author Serge Krot <Serge.Krot@cib.de> 2019-05-30 15:33:29 +0200 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2019-06-06 14:20:44 +0200 commit fd95fb975b754d71d3750e85431a4e596a40e659 (patch) tree ae0e9afd2016a6e95c8a6190403f6cee7592a647 parent 50696615fa8698ba18f9afc05202acd0a5a24cf8 (diff) tdf#125719 sw: rtf: refactor associated character properties Bisected with: bibisect-linux64-6.4 Adding Cc: to Serge Krot
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
Still reproducible in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 57ad86fec9e5b4981332392bdb5c5a1f5e468bfe CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
@Justin, I thought you might be interested in this issue
Font size seems to be preserved. It is 24 in both original and in the RTF. Bold is lost (for Latin/Asian). However, it is there in MS Word 2016, so this should be FILEOPEN?
@Mark recently made alterations in this area. This looks like it is related to \dbch. The document is Asian.
Almost certainly the same thing that Mark changed earlier for _sz, where DBCH was considered to be a CS. - nSprm = (m_aStates.top().getIsRightToLeft() - || m_aStates.top().getRunType() == RTFParserState::RunType::HICH) - ? NS_ooxml::LN_EG_RPrBase_iCs - : NS_ooxml::LN_EG_RPrBase_i; So in this case DBCH would have been _i but now it is _iCs.
(In reply to Justin L from comment #5) > Font size seems to be preserved. It is 24 in both original and in the RTF. This was fixed in 7.2 (backport to 7.1.0) by the code change I saw earlier. author Mark Hung on 2020-11-25 commit f97af19460fbd7483a0e1c1d0137e814f5390e69 tdf#137894 separate associated character properties In all cases, the export code seems pretty much unrelated to the import(writerfilter) changes, so this just looks like a simple regression to me, and I'll go ahead and make a fix.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9d50307b2e1fd26d415539d3ed8624c7a449e45b tdf#129578 rtfimport: CJK char properties are not CS It will be available in 7.4.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/0d3d6e1eba9b10bc334a769c275312a828b82a00 tdf#129578 rtfimport: CJK char properties are not CS It will be available in 7.3.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.