https://bugs.documentfoundation.org/show_bug.cgi?id=171340
Bug ID: 171340
Summary: afdko fails with profile path having non-Latin-1
characters on Windows
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
On Windows:
1. Open attachment 142643 [details] from bug 118105 in a debug build, using
LO_IMPORT_USE_PDFIUM, and a profile path including some non-Latin-1 characters
(e.g., 'LO_IMPORT_USE_PDFIUM=1 soffice
path/to/3-collabora_online_slide_deck.pdf
-env:UserInstallation=file:///C:/абв').
2. In Draw, Right-click the PDF object, and Break it.
3. In your file manager (e.g., Windows Explorer), navigate to
C:\абв\user\temp\embeddedfonts\fromdocs, to inspect its contents.
=> it only has TTF files. The expected contents include OTF files (converted by
ofdko).
If you monitor system IO using tools like Sysinternals' Procmon, you may see
failures like
> ... CreateFile
> C:\абв\user\temp\embeddedfonts\fromdocs\898299879936Carlito0.ttf PATH NOT
> FOUND ...
Compare with the same procedure, but using profile directory C:\abc instead of
C:\абв (and file:///C:/abc instead of file:///C:/абв).
The problem is using UTF-8 (which, by default, is not the charset used in file
functions taking 8-bit strings as filenames on Windows); see commit
e20bf4d9dfeaf7370f9adce4c2428e4e08100fe3. The afdko library unfortunately uses
8-bit-filenames API internally.
Note that using thread encoding would allow for characters existing in the
system charset - but still fail with paths like C:\abcабвαβγ.
Note also, that this will fail not only on Windows, but also on Linux using
locale with non-UTF-8 encoding, e.g. KOI8 flavors.
--
You are receiving this mail because:
You are the assignee for the bug.
