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

PDF content not rendered when specifying a PDF on command line #72

Open
jmozd opened this issue Sep 25, 2024 · 3 comments
Open

PDF content not rendered when specifying a PDF on command line #72

jmozd opened this issue Sep 25, 2024 · 3 comments

Comments

@jmozd
Copy link

jmozd commented Sep 25, 2024

Using Quba-Viewer-1.4.0 on Linux, opening the application including a PDF file name will not render the PDF content, but produce a content warning instead.

If the PDF contains structured content, the PDF display on the left reports the error, while the structured content pane is displayed with proper content from the PDF's structured data.

Opening the same PDFs via d&d or Ctrl-O works properly

The detailed error message reveals that Quba-Viewer is trying to render the PDF using a container-based path, instead of the host file system:

user@host:~> bin/Quba-1.4.0.AppImage somedir/somefile.pdf

PDF.js Version 2.9.359 (build: e667c8cbc)
Nachricht: Missing PDF "file:///tmp/.mount_Quba-1zAq2sf/resources/app.asar/dist/lib/pdfjs/web/somedir/somefile.pdf".

@jstaerk
Copy link
Contributor

jstaerk commented Oct 3, 2024

on windows it works, might confirm on linux

@jmozd
Copy link
Author

jmozd commented Oct 3, 2024

on windows it works, might confirm on linux

assuming that AppImage packaging is only used on Linux, it is expected that the error won't show on Windows :)

Additional info: This only happens with relative file names - which is likely the reason why other methods of opening the file do work. AFAIR, even opening files via "Desktop" operations will hand the absolute file name (with leading "/") to the application.

@jstaerk
Copy link
Contributor

jstaerk commented Oct 14, 2024

on windows it works, might confirm on linux

assuming that AppImage packaging is only used on Linux, it is expected that the error won't show on Windows :)

the code is the same for win , mac and linux and in that particular part of the functionality there is not distinction

Additional info: This only happens with relative file names - which is likely the reason why other methods of opening the file do work. AFAIR, even opening files via "Desktop" operations will hand the absolute file name (with leading "/") to the application.

And that I actually could reproduce on windows if there is a manual we will include it #58 . Background is probably that it had been requested to be able to be the default software assigned with file types and the OS

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

2 participants