Created attachment 121130 [details] Result in Okular I have some PDFs in which I cannot see correctly the document in okular, in Plasma 5.16.1, framework 5.59, archlinux. If I open them with foxit in linux i can see the missing characters. I attach jpgs and the affected pdf.
Created attachment 121131 [details] Result using Foxit in Windows
Created attachment 121132 [details] Affected PDF
You can see the greek letter theta missing in the drawing and also in the middle equations, and also pi is missing
Can you please report the content of the Fonts tab under File menu -> Properties ? From the past experience, 99% this is a font replacement issue which happens outside Okular.
Created attachment 121133 [details] Using firefox PDF viewer works too
Created attachment 121134 [details] Properties -> Fonts
(In reply to Luigi Toscano from comment #4) > Can you please report the content of the Fonts tab under File menu -> > Properties ? > > From the past experience, 99% this is a font replacement issue which happens > outside Okular. I don't really mind there are problems like this, the only thing I don't like is not having any kind of warning about this kind of problems because i take for granted (I don't know if I should but I always do) that PDF will render perfectly, like a jpg, and I usually print PDFs without inspecting them to see if everything is in order... I don't know, could a warning be designed or something like that?
Try to remove those fonts in the gsfonts folder (you can expand the window to see the full path) and see if improves. I suspect it's not easy to find out whether the right font is used for replacement. Or better, how to find out whether the chosen character is the right one. If I remember the previous discussions about this, the PDFs where the fonts are not embedded are known for being not good.
Info provided (but it would be useful to have the screenshot with the full path and the name of the fonts)
(In reply to Luigi Toscano from comment #9) > Info provided (but it would be useful to have the screenshot with the full > path and the name of the fonts) Oh sorry about this
Created attachment 121136 [details] Fonts
Created attachment 121137 [details] Fonts, again...
(In reply to Luigi Toscano from comment #8) > Try to remove those fonts in the gsfonts folder (you can expand the window > to see the full path) and see if improves. > > I suspect it's not easy to find out whether the right font is used for > replacement. Or better, how to find out whether the chosen character is the > right one. If I remember the previous discussions about this, the PDFs where > the fonts are not embedded are known for being not good. Now is worse hahaha
Created attachment 121138 [details] After removing the gsfonts
Looks like a fontconfig issue. For me, blacklisting all the fonts before "Symbol" "Regular" in the output of fc-match -s Symbol like this (should be put in the <fontconfig> section of ~/.config/fontconfig/fonts.conf): <selectfont> <rejectfont> <glob>/usr/share/fonts/drakfont/tmp/tmp/*</glob> </rejectfont> <rejectfont> <pattern> <patelt name="family" > <string>Standard Symbols PS</string> </patelt> </pattern> </rejectfont> </selectfont> solves the rendering problem (symbol.ttf should be installed for sure). Anyway, it is a good practice to embed or subset all the non-standard fonts in PDF (cf. the other embedded part of Symbol in this slide).
Not really our bug, the font is not provided by the pdf so we have to guess, you need to configure your system so that the guessing works. Anyhow even if this was a bug because you said "it should guess better", the guessing is done by poppler, so also not our bug.