Summary: | System DPI ignored for PDF files | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | zfr77 |
Component: | PDF backend | Assignee: | Okular developers <okular-devel> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | nate, oliver.sander, zfr77 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Mint (Ubuntu based) | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
zfr77
2021-03-19 09:25:07 UTC
We get the DPI from Qt; I don't think it realistic for us to work around Qt by getting it from somewhere else. :/ What we do have, however, is if (qAbs(res.width() - res.height()) / qMin(res.height(), res.width()) < 0.05) { return res; } else { qCDebug(OkularCoreDebug) << "QScreen calculation returned a non square dpi." << res << ". Falling back"; } in method Utils::realDpi, file utils.cpp. In other words, unequal dpi values for x and y are actively ignored by Okular. I am not sure whether that is a bug or a feature. Probably both. And I understand Qt gets its DPI from EDID? Is there any way to work around wrong monitor EDID then? Is it possible to add a an option in Okular's .config that lets the user override the DPI used. Incorrect EDIDs are not that uncommon. |