In some occasions, Okular mangles some chars that are reproduced correctly by other PDF readers (e.g. acroread, masterpdfeditor) on the very same platform. Inkscape also imports the PDF correctly. Might be a poppler problem since xpdf has the same issue. The problem seems to be related to substitution rules for fonts that are not embedded in the PDF document nor available on the platform with exactly the same name. Reproducible: Always
Created attachment 100839 [details] Demo file A demo file to reproduce the problem
Created attachment 100840 [details] How okular shows the demo file
Created attachment 100841 [details] How other pdf readers show the file on the same platform
Confirmed on Qt: 4.8.7 KDE: 4.14.23 Okular: 0.25.0 poppler 0.44.0 Debian Testing
Still seen in kubuntu 17.04 with the KDE PPA, that is Okular 1.0.3 Framework 5.35 QT 5.7.1 Poppler 0.48.0 Please, mark as confirmed
Unless a developer confirms if the issue is caused by Okular code, poppler code, or just because of a font or configuration issue, it does not make sense to change the status.
Created attachment 116379 [details] The demo file rendered by okular (with arial font installed)
Can you please specify better on which platform you made the last screenshot? I am on kubuntu 18.04 and I still see the issue. The demo file is clearly *not embedding* its fonts and okular has to pick some fonts that it finds on the system for its rendering, which is the factor triggering the font mangling. However, the requested font is `TimesNewRomanPSMT`, so the fact that you have an *arial* font installed on the system should not make any difference and if it does, this looks like one more weirdness. Nonetheless, the font that is being substituted for the required `TimesNewRomanPSMT` is `dejavusans.ttf` on my system, which is a sans font, just like your arial so it looks like the system font machinery does not correctly match TimesNewRomanPSMT to a Times New Roman font. The document uses `TimesNewRomandPSMT` with two different encodings, one is `WinAnsi` and the other one is `Identity-H` with some internal mapping to unicode. It looks like it is this Identity-H encoding to be troublesome to Okular. Interestingly, also MasterPDFEditor recently mangles the fonts in the same way as okular.
Bug persists. I tested okular 1.6.3, inkscape 0.92.4, evince 3.32 and foxit pdf reader 2.4.4.0911 on Arch Linux. Only inkscape renders the attachment from comment 1 correctly. Operating System: Arch Linux KDE Plasma Version: 5.15.3 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.2
Firefox integrated PDF viewer based on pdf.js is also fine.
Created attachment 127886 [details] Bad Fonts selected
Created attachment 127887 [details] The actual selected fonts
I have similar problems, see "Bad Fonts selected" and "The actual selected fonts". I can provide you the PDF per email. I'm using Okular 1.10.0
Still an issue as of Okular 1.10.0 on Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-47-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz Memory: 15,3 GiB of RAM The PDF viewer in Firefox renders the demo file correctly, okular does not. The rendering is not as bad as in the attachment "how okular shows the demo file" right now.
Created attachment 149550 [details] Micro Character not shown correctly
Comment on attachment 149550 [details] Micro Character not shown correctly okular: Version 22.03.70 OS: Win10 https://res.cloudinary.com/openmicrolab/raw/upload/v1487645777/hs_usb_pdg_r1_0_zjnjtx.pdf
Created attachment 149551 [details] Page 8 of the Intel manual on Linux (In reply to Martin from comment #16) > Comment on attachment 149550 [details] > Micro Character not shown correctly > > okular: Version 22.03.70 > OS: Win10 > https://res.cloudinary.com/openmicrolab/raw/upload/v1487645777/ > hs_usb_pdg_r1_0_zjnjtx.pdf Cannot confirm on Linux (22.07.70, poppler 20.12.1).
OK also here: Linux with okular 22.04.1 and poppler 22.05.0 (from Manjaro packages).