Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing monospace text in PDF file #194

Open
ssokolow opened this issue Aug 19, 2022 · 5 comments
Open

Missing monospace text in PDF file #194

ssokolow opened this issue Aug 19, 2022 · 5 comments

Comments

@ssokolow
Copy link

ssokolow commented Aug 19, 2022

When running under Flatpak, Okular renders pages 4 through 16 of 17 of this copy of SFF-8501 (i.e. EIA-741, the spec for the dimensions and mounting hole positions for 5.25" drives) as completely blank.

(More specifically, it appears to be failing to find a mapping for whatever monospace font is the only content on those pages.)

For help tracking down the cause, I should note that the same problem comes into being when I take a working system install of Okular on Kubuntu 20.04 LTS and run it through the default Firejail profile.

  • /usr/bin/okular ~/reference/SFF-8501.PDF: Works perfectly
  • firejail /usr/bin/okular ~/reference/SFF-8501.PDF: Missing monospace text
  • flatpak run org.kde.okular ~/reference/SFF-8501.PDF: Missing monospace text

Since I'd really prefer to be running Okular sandboxed, I've taken to using Firefox's built-in PDF reader when I need to read that particular file.

@travier
Copy link
Member

travier commented Aug 19, 2022

Hum, maybe we are missing some fonts. Is there anything in the logs?

@ssokolow
Copy link
Author

ssokolow commented Aug 19, 2022

Which logs do you want me to check?

There's nothing relevant on stdout/stderr. (I say "relevant" because there's always an error about how, because libgtk3-nocsd.so.0 doesn't exist in the Flatpak runtimes, that LD_PRELOAD will be ignored.)

@tsdgeos
Copy link
Collaborator

tsdgeos commented Aug 19, 2022

please attach the screenshots of the contents of file/properties/fonts both when it works and when it doesn't

@ssokolow
Copy link
Author

ssokolow commented Aug 20, 2022

Working with system package:
working

Broken with system package under Firejail (default Kubuntu 20.04 LTS Firejail profile):
broken_firejail

Broken with Flatpak:
broken

Looking at that, my best hypothesis to test is that sandboxing breaks use of non-embedded Type 1 fonts.

@tsdgeos
Copy link
Collaborator

tsdgeos commented Aug 20, 2022

Super weird that you have two CourierNew that get substittuted to diffferent fonts. Needs investigation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants