| Summary: | RTF Importer does not honor ansicpgN and cpgN control words -> fails to import some non-English documents properly | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Mike Kaganski <mikekaganski> |
| Component: | Writer | Assignee: | Miklos Vajna <vmiklos> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | bugs, jbfaure, tlundheim |
| Version: | 3.5.2 release | ||
| Hardware: | Other | ||
| OS: | Windows (All) | ||
| Whiteboard: | rtf_filter target:3.7.0 target:3.6.1 target:3.5.7 | ||
| i915 platform: | i915 features: | ||
| Attachments: |
Test file showing this behaviour
This is how it renders now - only one piece is shown correctly This is how it should be. |
||
|
Description
Mike Kaganski
2012-04-08 18:15:18 UTC
Also note that some RTF software stores font character set incorrectly as ANSI_CHARSET for some national fonts. At least, the standard Windows fonts ({Times New Roman|Arial|Courier New}[ CE| Cyr], Japanese, Chinese (Simplified and Traditional), Korean and Thai) should have that field corrected to ensure proper import. Same problem may exist for Arabic/Hebrew documents, which may contain legacy charset values.
Ideally there should be a way for user to provide a font mapping table to define a proper charset for custom fonts people could have used.
@Mike: please could you attach a pdf export of your test file which would show how it should look like when opened in LibreOffice ? Best regards. JBF Created attachment 61096 [details]
This is how it renders now - only one piece is shown correctly
Created attachment 61097 [details]
This is how it should be.
I'm not sure if assigning it to me is a right thing to do...
(In reply to comment #4) > Created attachment 61097 [details] > This is how it should be. Thank you very for the data Hi Miklos, another codepage problem in RTF import. Please, feel free to reassign if you can't handle this bug. Best regards. JBF Mike, Thanks for the detailed report. Funny, your test document in Word matches your "how it renders now" PDF, at least here, with an English UI. ;-) Since 3.5.2, we already implemented locale-dependent default (so your testdoc opens fine already if the locale is set to Russian), and also \ansicpg got implemented. And you're right: with the \cpg implementation, the LibreOffice result matches the "how it should be", even with English UI. I'll push that patch in a bit. Miklos Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f6a24ace5ad12e79f0cc90709a290a30e3758781 fdo#48446 implement RTF_CPG Resolved in master, -3-6 and -3-5 review requests: https://gerrit.libreoffice.org/386 https://gerrit.libreoffice.org/387 Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8054472f666c87d6437dcea064c3cef379916245&g=libreoffice-3-6 fdo#48446 implement RTF_CPG It will be available in LibreOffice 3.6.1. Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=98e895db332446b3fe2fc901a6cf9cff64d2b1b8&g=libreoffice-3-5 fdo#48446 implement RTF_CPG It will be available in LibreOffice 3.5.7. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.