Description: LibreOffice draw can handle Chinese characters, When we create text node, It displays correctly, and for some pdf with Chinese characters, It works fine too. But not the attached pdf, With attached pdf, It seems string with Chinese characters are ignored, and not rendered at all on libreoffice draw side. Please take a look. Steps to Reproduce: 1. Open the attached products.pdf 2. Try to select the text with Chinese characters 3. The text with Chinese characters are not rendered at all in libreoffice draw. Actual Results: The text with Chinese characters are not rendered at all in libreoffice draw. Expected Results: We should be able to select text with Chinese characters just as we create the text on the pdf. With inkscape, When we import the pdf, We can have text correctly rendered, and selected. Reproducible: Always User Profile Reset: No Additional Info: inkscape imports pdf fine on process the same pdf.
Created attachment 169952 [details] pdf contains Chinese wasn't rendered correctly.
With 7.1.0 on Windows 10 I can't open the attached file: Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded Draw just displays "The PDF file is encrypted and can't be opened." Sumatra PDF reader can open it and (likely) correctly display the Chinese characters.
(In reply to Ming Hua from comment #2) > With 7.1.0 on Windows 10 I can't open the attached file: > Version: 7.1.0.3 (x64) / LibreOffice Community > Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c > CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: > win > Locale: zh-CN (zh_CN); UI: zh-CN > Calc: threaded > Draw just displays "The PDF file is encrypted and can't be opened." > > Sumatra PDF reader can open it and (likely) correctly display the Chinese > characters. Hi, Can you open the pdf with chrome? BTW, My system is in windows 10 English, with Chinese support. Not the Chinese version of windows 10. Thanks.
(In reply to yiheso from comment #3) > (In reply to Ming Hua from comment #2) > > With 7.1.0 on Windows 10 I can't open the attached file: > > Version: 7.1.0.3 (x64) / LibreOffice Community > > Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c > > CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: > > win > > Locale: zh-CN (zh_CN); UI: zh-CN > > Calc: threaded > > Draw just displays "The PDF file is encrypted and can't be opened." > > > > Sumatra PDF reader can open it and (likely) correctly display the Chinese > > characters. > > Hi, Can you open the pdf with chrome? I don't have Chrome to test. But why does it matter? The attached file can be opened by SumatraPDF for me so presumably it's a good file. It's LibreOffice's import filter's problem if it can not open it. What matters is: can you open it on your system with LibreOffice Draw, and when opened does Draw render the barcode and English text OK, but the Chinese text is not correctly rendered? If so, it would be helpful if you can attach a screenshot showing how it looks like in Draw. > BTW, My system is in windows 10 English, with Chinese support. > Not the Chinese version of windows 10. That shouldn't make any difference. > Thanks.
(In reply to Ming Hua from comment #4) > > BTW, My system is in windows 10 English, with Chinese support. > > Not the Chinese version of windows 10. > That shouldn't make any difference. It does make difference, I noticed, that recent version of windows now uses utf8 file for txt files, and the old version of windows when we use gbk. And I'll attach the screenshot of opened pdf, The bar code displays ok.
Created attachment 169982 [details] screenshot of libreoffice draw open the pdf.
(In reply to yiheso from comment #5) > (In reply to Ming Hua from comment #4) > > > > BTW, My system is in windows 10 English, with Chinese support. > > > Not the Chinese version of windows 10. > > That shouldn't make any difference. > > It does make difference, I noticed, that recent version of windows now uses > utf8 file for txt files, and the old version of windows when we use gbk. Not true. Windows 10 still uses GBK (code page 936), not UTF-8. It's just that recently (around 2019, I think?) notepad.exe was upgraded to handle UTF-8 files gracefully, instead of displaying scrambled characters. > And I'll attach the screenshot of opened pdf, The bar code displays ok. Thanks. I've tested both 7.1.0 (in comment #2) and 7.0.4 on my system: Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded ...and both give me the same error message about encryption and not being able to open the PDF. So hopefully some other QA person can have a look and reproduce the problem.
Hi, yesterday, I tried it on libreoffice on debian bullseye/sid, Found it works. So I think it's windows only issue. Hope this can help dev to narrow down the issue. Thanks.
I was able to reproduce this problem in: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: e3086b58eb5427d520b86c185f9d911bb6f7a3a0 CPU threads: 12; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-21_15:37:11 Calc: threaded I was not able to reproduce in a branch of master with my fix for bug 141709 applied, this may be a duplicate. However, I am testing on Linux and this report is for Windows, so I won't change the status.
The patch as mentioned by Michael Warner was backported to 7.2 branch. So, either use a daily master or 7.2 branch build to test, or wait until 7.2.0 beta2 to test. Set to NEEDINFO.
(In reply to Kevin Suo from comment #10) > wait until 7.2.0 beta2 to test. I assume Kevin meant 7.2.0 RC2 here.
Dear yiheso, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
@Michael Warner: This issue was fixed by your commit: 648e4106cc002ff5b8184a8c104f93cb06e4b540 on master (so it works ok in 7.3 and current master). However, I tested the current 7.2 branch, but this bug is still there in version 7.2.4.1. Opening attachment 169952 [details] still loses Chinese characters. I do see that commit was cherry-picked to 7.2. Do you know what is going on? Was the backported commit different than the master commit? But anyway, since this now works OK in 7.3 and master, let's mark it as RESOLVED FIXED.
(In reply to Kevin Suo from comment #13) > However, I tested the current 7.2 branch, but this bug is still there in > version 7.2.4.1. Opening attachment 169952 [details] still loses Chinese > characters. I do see that commit was cherry-picked to 7.2. Do you know what > is going on? Was the backported commit different than the master commit? > See trailing comments of bug 141709 regards registering the poppler data directory, didn't make it into 7.2.4 hotfix, won't be fully functional until the 7.2.5 release build.