Does it support Chinese?

[zhangkmsjtu]

Does it support Chinese?

[dannyedel]

Yes and no:

• Yes, it should™ support LaTeX documents containing chinese characters, as long as the fonts are embedded in the PDF file. If this doesn't work, please create a demonstation pdf and I'll investigate.
• No, the user interface is not yet translated.
  • If you want to add a translation, you will need to add your new translation file in two places: cmake/filelists.cmake and dspdfviewer.qrc
  • Then configure with cmake -DUpdateTranslations=ON and it should™ generate the translation file.

[zhangkmsjtu]

\documentclass{beamer} \usepackage{pgfpages} \setbeameroption{show notes on second screen} %\usepackage[timeinterval=1]{tdclock}%dspdfviewer不支持tdclock宏包 \usepackage[UTF8,scheme=plain]{ctex}

\usetheme{Madrid}

\title{中文标题Chinese Title} \author{中文名Chinese name} \date{\today} \institute{sjtu单位}

\begin{document}

\maketitle

\section{Introduction}

\begin{frame} \frametitle{Introduction} \begin{itemize} \item 测试 \note{笔记} \item 这里显示中文 \item 这里也显示中文 \end{itemize} \end{frame}

\end{document}

[zhangkmsjtu]

Beamer_Chinese.zip

[zhangkmsjtu]

The Chinese fonts cannot be displayed on a dspdfviewer.

[dannyedel]

Thanks for the document upload. I'll look into the issue and report back.

[dannyedel]

Hi @zhangkmsjtu I tried to view the PDF you supplied in the zip with dspdfviewer (current master from source, and additionally checked the Debian stretch and Debian sid binaries), and it displayed the following on the helper monitor:

To me, this looks like it worked. To figure out why it doesn't for you, please provide the following information:

• What platform (Operating System and Desktop Environment) are you using
• What version of dspdfviewer are you running (output of dspdfviewer --version or check the F1 help box when its running)
• Did you install from a binary (if yes, where from) or compile yourself from source (if yes, against which Qt and Poppler version)

Also, a quick search on the web suggests that sometimes, the package package poppler-data was not installed which is needed to render Chinese documents.

According to pdffonts, the file you uploaded has the fonts embedded so this is not an issue here.

[zhangkmsjtu]

Specific infromation: windows 7, v1.14

I don't know why?

[dannyedel]

Thank you for the detailed information! This should™ be all the info needed to reproduce and debug this.

windows 7, v1.14

I will CC @projekter on this, since he's the windows expert. In the meantime, I will try to reproduce this in a windows 7 VM and see if I can improve on the situation.

[zhangkmsjtu]

Thank you very much for everything you do.

[dannyedel]

Progress report: This is definitely the missing poppler-data package.

I can reproduce the problem on a Linux host by removing the poppler-data package, I get the exact same result (chinese glyphs don't get rendered at all).

I will try to figure out where to copy the files on a windows machine.

[projekter]

Yes, I had to build poppler without the data package. But the reason for this was that I could not figure out where to put this package and how to configure poppler so that it actually uses it. So any hints will be appreciated, I'm sure this can be fixed easily.

[dannyedel]

@projekter: On a Linux host the poppler-data gets installed into /usr/share/poppler/ and /var/lib/ghostscript, see debian listing for example.

When running on Debian with strace -e open -f dspdfviewer, I don't see any attempt to load files from the "ghostscript" directory, so I'm not sure if that part is really needed.

I think it should™ be possible to tell poppler at the cmake time which directory name to embed in the library as a search path to poppler-data; Setting the variable POPPLER_DATADIR at poppler cmake time might™ work.

---

If you have a tool that can print out which files a windows program tries to load, its output might help a lot in figuring out where to place the files (without recompiling). Example strace output without poppler-data installed:

Failed to load qt translations for locale "C"
Failed to load dspdfviewer translation for current locale "C"
[pid 23588] open("/home/danny/.config/dspdfviewer.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 23588] open("/home/danny/tmp/dsp-ticket163/Beamer_Chinese.pdf", O_RDONLY|O_CLOEXEC) = 7
[pid 23588] open("/usr/share/poppler/nameToUnicode", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 23588] open("/usr/share/poppler/cidToUnicode", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 23588] open("/usr/share/poppler/unicodeMap", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 23588] open("/usr/share/poppler/cMap", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

After installing poppler-data to /usr/share/poppler (with correct output):

Failed to load qt translations for locale "C"
Failed to load dspdfviewer translation for current locale "C"
[pid 23635] open("/home/danny/.config/dspdfviewer.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 23635] open("/home/danny/tmp/dsp-ticket163/Beamer_Chinese.pdf", O_RDONLY|O_CLOEXEC) = 7
[pid 23635] open("/usr/share/poppler/nameToUnicode", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 8
[pid 23635] open("/usr/share/poppler/nameToUnicode/Thai", O_RDONLY) = 9
[pid 23635] open("/usr/share/poppler/nameToUnicode/Greek", O_RDONLY) = 9
[pid 23635] open("/usr/share/poppler/nameToUnicode/Bulgarian", O_RDONLY) = 9
[pid 23635] open("/usr/share/poppler/cidToUnicode", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 8
[pid 23635] open("/usr/share/poppler/unicodeMap", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 8
[pid 23635] open("/usr/share/poppler/cMap", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 8

(...)

[pid 23638] open("/usr/share/poppler/cidToUnicode/Adobe-GB1", O_RDONLY) = 10
[pid 23638] open("/usr/share/poppler/cMap/Adobe-GB1/Identity-H", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 23638] open("/usr/share/poppler/ColorProfiles/display.icc", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 23638] open("/usr/share/poppler/ColorProfiles/RGB.icc", O_RDONLY) = -1 ENOENT (No such file or directory)

So in this case, it seems to be the Adobe-GB1 file that it needs to load.

[projekter]

So poppler-data is kind of a standalone, that does not need to be compiled into poppler? That's interesting. The problem I had is that in all instructions you are told to extract poppler-data to /usr/share/poppler. As this is not a valid path on Windows, I tried to figure out where to change it, but I could not figure out a cmd switch, and I remember I found a statement that this path is hardcoded into poppler. As everything worked without poppler-data, I did not investigate further, but now I'll do so.

[dannyedel]

@projekter: The path /usr/share apparently gets mapped to C:/dspdf/ by default. I got this by running https://live.sysinternals.com/Procmon.exe against "Program Name is dspdfviewer.exe, Operation is CreateFile" -- which is a bit misleading, but apparently CreateFile also captures "open existing file" attempts.

---

@zhangkmsjtu As a temporary workaround, you can download the poppler-data-0.4.7.tar.gz file from https://poppler.freedesktop.org/ and extract the contents into c:/dspdf/poppler, so that the Directories C:/dspdf/poppler/nameToUnicode and so on exist. You may need to install 7zip or similar, since Windows cannot by default read .tar.gz.

Result:

[projekter]

Just a minute too late. That's what I just wanted to say. I don't know whether there is a way to embed the encodings into the executable; I don't think so. But it should be no problem to change the poppler sources such that they will look for those encodings in the current application directory. I think this would be the most convenient way. Btw., @zhangkmsjtu: I tried to compile the code you gave in your second comment with XeLaTeX and this pdf can be display without the need for the encodings. The only apparent difference I could find is that my XeLaTeX uses MicrosoftYaHei (TrueType) while yours does FandolHei-Regular (Type1).

[dannyedel]

they will look for those encodings in the current application directory. I think this would be the most convenient way.

Agreed. The only thing to watch out for is probably that the directory can have different names depending on the language and bits of the windows -- I've seen c:/program files/dspdfviewer, c:/program files (x86)/dspdfviewer, and c:/programme/dspdfviewer so far. I don't know if these are really all mapped to the same thing (for example, when I open a german windows' drive on Linux, c:/Benutzer is really called c:/users) or if one has to actually figure out the path at runtime.

[zhangkmsjtu]

1. That's normal when the code is compiled with TeX Live 2015. Texlive2015_Beamer_Chinese:
2. It cannot be displayed correctly as the code is compiled with ShareLaTeX (https://www.sharelatex.com). Sharelatex_Beamer_Chinese:

pdf files: pdf_TexLive2015_ShareLaTeX.zip

[projekter]

Yes, of course. I am just updating poppler to the most recent version (if I have to edit its sources, this is a good moment) and will then post a new release. And the folders are very different, not just aliases, so I'll need runtime-behavior. At the moment, poppler uses a constant for the path. I just changed this /usr/... constant to C:/dspdf in order to make it at least possible for Windows users to use the encodings.

[projekter]

Ha, this looks promising. The new poppler version has some flags in its cmake called "poppler_data_static". Perhaps that's what I looked for.

[projekter]

Please have a look at the latest release, for me this fixes the problem. As there was no way to do it statically, but poppler already provides means to search relative to the current application, I used the original poppler implementation of its most recent version and included a directory structure in the setup that conforms to that. As a result, dspdfviewer is now 11MB larger (but only 2MB for the setup).

[zhangkmsjtu]

GOOD JOB. It's ok now.