Bug 166239 - Export to PDF with password: Asian/Korean characters gone (become blank/spaces)
Summary: Export to PDF with password: Asian/Korean characters gone (become blank/spaces)
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
24.8.6.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-04-18 01:52 UTC by SR
Modified: 2025-04-30 15:23 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT file with latin chars (English) and hangul / Korean characters. (34.23 KB, application/vnd.oasis.opendocument.text)
2025-04-25 07:18 UTC, SR
Details
PDF file with a pswd (= 1234): open it and see that all Korean chars have gone. (218.47 KB, application/pdf)
2025-04-25 07:21 UTC, SR
Details
fonts comparison between a 'bad' and 'good' pdf (250.23 KB, image/png)
2025-04-29 17:35 UTC, Mateusz Wlazłowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description SR 2025-04-18 01:52:34 UTC
Hello,

Important: I use English text together with Korean hangul.
Export to PDF with password protection replaces the Korean characters by blank spaces.

Here is a rundown of my experience:

1) export to PDF WITH password.
Firefox, Chrome, Evince: all Korean characters become blank spaces.
LO draw: PDF looks good.

2) export to PDF WITHOUT password, and then set password with pdftk (version 3.3.3).
Firefox, Chrome, Evince: password protected PDF looks good.
LO draw has error: "Version Incompatibility. Incorrect file version".

3) export to PDF WITHOUT password.
Firefox, Chrome, Evince, LO draw: PDF looks good.

Password protection from within LO is buggy.
-S.R.

Version: 24.8.6.2 (X86_64)
Build ID: 480(Build:2)
CPU threads: 8; OS: Linux 6.13; UI render: default; VCL: gtk3
Locale: en-US (en_US.utf8); UI: en-US
Calc: threaded
Comment 1 Mateusz Wlazłowski 2025-04-24 15:18:54 UTC
Please provide us an odt file which we can use to export to pdf with a password
Comment 2 SR 2025-04-25 07:18:51 UTC
Created attachment 200505 [details]
ODT file with latin chars (English) and hangul / Korean characters.

This is an odt file which has latin alphabet (English) and Korean.

When creating a PDF with a password, then the Korean characters disappear when opening the PDF.
Comment 3 SR 2025-04-25 07:21:28 UTC
Created attachment 200506 [details]
PDF file with a pswd (= 1234): open it and see that all Korean chars have gone.

Open this PDF with the password 1234, and see that all Korean characters have gone!
Comment 4 SR 2025-04-25 07:25:38 UTC
Two files attached as examples to make my point regarding PDF with passwords & Korean characters.

The ODT file has latin chars and Korean hangul.
When saved with a password, the PDF has no Korean characters anymore; instead all Korean characters have become blank spaces.

The problem does NOT happen when creating a PDF without a password.

This happens with any of the programs in the LibreOffice Suite: Korean characters disappear when a PDF is created with a password protection.

-S.R.

PS: Is a general problem when using non-latin characters, such as Chinese, Japanese, or Thai?
Comment 5 Mateusz Wlazłowski 2025-04-25 16:58:31 UTC
> 2) export to PDF WITHOUT password, and 
> then set password with pdftk (version 3.3.3).


As this bug involves setting the password with another program, it is not the bug of LibreOffice, but pdftk
Comment 6 SR 2025-04-29 13:44:17 UTC
(In reply to Mateusz Wlazłowski from comment #5)
> > 2) export to PDF WITHOUT password, and 
> > then set password with pdftk (version 3.3.3).
> 
> 
> As this bug involves setting the password with another program, it is not
> the bug of LibreOffice, but pdftk

NO! You're missing the point!
I'm sorry that me adding an additional analysis with pdftk has the opposite effect....


When LO exports as PDF without password, and I set a password with pdftk, then all is fine: any external PDF reader can handle both versions: the one without password from LO, and the one WITH password from pdftk.

HOWEVER, when I let LO set the password, external PDF readers see only English (ascii?) characters, whereas all Korean (Asian?) characters are gone (i.e. have become blank spaces).

In conclusion: there is something fishy going on when LO sets a password for a PDF export. So I think something is wrong with LO and PDF export, when using Korean (and other Asian?) fonts.

S.R.
Comment 7 Mateusz Wlazłowski 2025-04-29 17:35:20 UTC
Created attachment 200605 [details]
fonts comparison between a 'bad' and 'good' pdf

Ok, my bad



I looked into the fonts, and the pdf with blanks has 'CJKkr-ExtraLight' (korean) fonts, whereas mine are 'CJKjp-Bold' (japan)

It's intriguing that a Japanese font works for displaying Korean characters. Maybe someone intertwined the names of the fonts?


Could you check in safe mode in Help > Safe Mode if the issue persists
Comment 8 SR 2025-04-30 15:23:09 UTC
Thank you.

I restarted LO in Safe mode, but the problem persists.

Still, what puzzles me is this:
why does this issue ONLY surface when exporting to PDF WITH a password?

When I export to PDF without a password, there is no problem at all....

Is something going wrong in LO during the password encryption / decryption?

Are fonts treated differently in plain PDFs than in password-protected PDFs?

Here is the result of pdffonts from poppler-utils on the PDF WITHOUT password and on the PDF WITH password:

$ pdffonts CreatePdfWithoutPswd.pdf  
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
BAAAAA+LiberationSerif               TrueType          WinAnsi          yes yes yes     70  0
CAAAAA+NotoSerifCJKkr-ExtraLight     Type 3            Custom           yes yes yes    151  0
DAAAAA+LiberationSerif-Bold          TrueType          WinAnsi          yes yes yes     65  0
EAAAAA+NotoSerifCJKkr-ExtraLight     Type 3            Custom           yes yes yes     73  0



$ pdffonts -opw 1234 -upw 1234 CreatePdfWithPswd.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
BAAAAA+LiberationSerif               TrueType          WinAnsi          yes yes yes     70  0
CAAAAA+NotoSerifCJKkr-ExtraLight     Type 3            Custom           yes yes yes    151  0
DAAAAA+LiberationSerif-Bold          TrueType          WinAnsi          yes yes yes     65  0
EAAAAA+NotoSerifCJKkr-ExtraLight     Type 3            Custom           yes yes yes     73  0


-S.R.