Created attachment 77263 [details] Rtf file it is garbled. In the RTF file that was created using the ApacheFOP, some Japanese are garbled. Occurred in 3.5 and later versions of events. When you save in another application MSWord, WordPad, etc., you will be able to open it without garbled. Please tell me the cause.
(In reply to comment #0) > Created attachment 77263 [details] > Rtf file it is garbled. > > In the RTF file that was created using the ApacheFOP, some Japanese are > garbled. > Occurred in 3.5 and later versions of events. > > When you save in another application MSWord, WordPad, etc., you will be able > to open it without garbled. > > Please tell me the cause.
mimimimizk, I am running version 4.0.2.2 of LibreOffice Writer on Debian Linux (Testing) and opening the .rtf file the Japanese text appears fine. Please provide information about your Operating System type and version and what Japanese font you're using. It may well be an issue with your system's Japanese font. I had similar problems with Japanese text in the past on Linux and had to install a new font to resolve the problem. The font I had to install was "ttf-vlgothic".
Could you attach a PDF file with this document displayed correctly? I can see several ?'s opening this in WordPad, for example.
Created attachment 78048 [details] RTF file garbled I will replace it with a smaller RTF files.
Created attachment 78049 [details] Display example Libreoffrce, word, word pad (screen shot)
Created attachment 78050 [details] Xsl-fo file before converting in AppacheFOP
I've uploaded a new RTF file and xsl-fo files before conversion rtf. Also, I've uploaded a screen shot opens with the normal state and garbled. The operating system you are using WindowsXP Professional Sp3. I have to specify the Mincho "MS" to the type of font. I have installed the fonts ttf-vlgothic, did not change the situation. Thanks for the advice.
The reason for ?'s are due to Unicode character values as unsigned decimals, instead of signed as required by RTF. @Reporter: Fonts should look better if the font table will be containing charset value: \fcharset128 You can ensure your XML source generates it or add it manually to RTF file immediately after each "\f1", "\f2", etc. within "{\fonttbl..." section.
where the unicode value has changed to a negative character that is more than 32767, garbled was solved. (For example, \u34920 > \u-30616) However, it is saved with a value of more than 32767 When you save in LibreOffice. Is it to look for another way? ※ 15 page "Rich Text Format (RTF) Specification Version 1.9.1" on MicroSoft There has been described to be written in unicode negative number more than 32767. I tried to append \fcharset128 and \ansicpg932, but it did not resolve.
Probably due to check in core/writerfilter/source/rtftok/rtfdocumentimpl.cxx:3064
caolanm->vmiklos: Is this still relevant ?
Yes, it is. Actually it seems Word accepts values between SAL_MAX_INT16 and SAL_MAX_UINT16 for \u, and maps them to SAL_MIN_INT16..0, doing the same in writerfilter makes sense. Will do that in a bit.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4a816a816e8b4e213394898bd0e307dd90fcbb64 fdo#62977 allow SAL_MAX_INT16..SAL_MAX_UINT16 when importing RTF_U 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-0 review: https://gerrit.libreoffice.org/3913
As a result of tested on version4.1.0.0.alpha1+ of the master, the problem has been corrected. Thank you very much.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=53d40e18515c78e59583f1f8fadc82ffa2ab9e32&h=libreoffice-4-0 fdo#62977 allow SAL_MAX_INT16..SAL_MAX_UINT16 when importing RTF_U It will be available in LibreOffice 4.0.4. 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.