Bug 140587 - LibreOffice Draw doesn't render string with Chinese characters in pdf correctly.
Summary: LibreOffice Draw doesn't render string with Chinese characters in pdf correctly.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Import-Draw
  Show dependency treegraph
 
Reported: 2021-02-22 01:38 UTC by yiheso
Modified: 2022-01-12 14:34 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
pdf contains Chinese wasn't rendered correctly. (2.80 KB, application/pdf)
2021-02-22 01:39 UTC, yiheso
Details
screenshot of libreoffice draw open the pdf. (41.53 KB, image/png)
2021-02-23 06:52 UTC, yiheso
Details

Note You need to log in before you can comment on or make changes to this bug.
Description yiheso 2021-02-22 01:38:38 UTC
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.
Comment 1 yiheso 2021-02-22 01:39:56 UTC
Created attachment 169952 [details]
pdf contains Chinese wasn't rendered correctly.
Comment 2 Ming Hua 2021-02-22 06:42:16 UTC
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.
Comment 3 yiheso 2021-02-22 13:35:27 UTC
(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.
Comment 4 Ming Hua 2021-02-23 00:18:07 UTC
(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.
Comment 5 yiheso 2021-02-23 06:50:44 UTC
(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.
Comment 6 yiheso 2021-02-23 06:52:01 UTC
Created attachment 169982 [details]
screenshot of libreoffice draw open the pdf.
Comment 7 Ming Hua 2021-02-23 07:20:06 UTC
(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.
Comment 8 yiheso 2021-03-02 07:45:57 UTC
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.
Comment 9 Michael Warner 2021-06-23 04:02:44 UTC
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.
Comment 10 Kevin Suo 2021-07-15 01:39:12 UTC
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.
Comment 11 Ming Hua 2021-07-15 02:36:19 UTC
(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.
Comment 12 QA Administrators 2022-01-12 03:42:24 UTC Comment hidden (obsolete)
Comment 13 Kevin Suo 2022-01-12 04:27:18 UTC
@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.
Comment 14 V Stuart Foote 2022-01-12 14:34:31 UTC
(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.