Summary: | Wrong dpi used for page view | ||
---|---|---|---|
Product: | [Applications] kpdf | Reporter: | Matthias Wieser <mwieser> |
Component: | general | Assignee: | Albert Astals Cid <aacid> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | minor | CC: | dev, fongpwf, rafael.rodriguez.tf |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Test patch |
Description
Matthias Wieser
2005-03-14 00:08:07 UTC
Confirmed, KDE 3.4.0. I have just opened an A4 document, and 100% zoom showed a page with 14,7 cm width. Considering my resolution is 101 dpi, (14.7*101) / 21 = 70.7, or within an error margin for 72 dpi. Created attachment 10118 [details]
Test patch
Can you verify 2 things?
- That patch fixes the size issue
- That patch gives you blurry rendering
Thanks for the reply! I will try as soon as possible. Why is that patch so large? Isn't it enough to replace "72.0" by the actual dpi to have the right size without blurry rendering? Something like (I am no C programmer) - double fakeDpiX = request->width * 72.0 / page->width(), - fakeDpiY = request->height * 72.0 / page->height(); + double fakeDpiX = (double)request->width * (double)request->dpiX / (double)page->width(), + fakeDpiY = (double)request->height * (double)request->dpiY / (double)page->height(); // setup kpdf output device: text page is generated only if we are at 72dpi. // since we can pre-generate the TextPage at the right res.. why not? @@ -870,8 +870,8 @@ KPDFPage * page = d->currentRequest->page; int width = d->currentRequest->width, height = d->currentRequest->height; - double fakeDpiX = width * 72.0 / page->width(), - fakeDpiY = height * 72.0 / page->height(); + double fakeDpiX = (double)width * (double)d->currentRequest->dpiX / (double)page->width(), + fakeDpiY = (double)height * (double)d->currentRequest->dpiY / (double)page->height(); Well this is exactly what the patch does, but request did not have dpiX and dpiY inside so all places in code that use it must be changed to pass the dpi. Please not that 72 is a magic number, many things will get out of place by only changing what Matthias suggested (links, search highlights.. just to name some). Need some deep focused work & refactor. *** Bug 108889 has been marked as a duplicate of this bug. *** I just wanted to report the same issue when I stumpled onto this report. I'm using kpdf 3.5.5. I'd appreciate a fix as well. Regards Sebastian Any progress here? Will it be resolved for KDE4? Anyway, KPDF is one of my favourite and most used apps, thank you for making it so good!! *** Bug 144999 has been marked as a duplicate of this bug. *** I don't know what the problem with fixing this is? Kpdf can do zooming to any factor but it cannot "zoom" to the right DPI value? If you do not want to change the "magic number" 72 (hit Apple for this!), can't you just redefine what 100% zoom means for a specific document? Albert, any news on this bug? If you don't have the time can't you reassign this bug to someone else who does? Regards Sebastian It's assigned to me because i'm default kpdf bug owner, anyone is free to work on fixing it. Still happens to me with KPDF in KDE 3.5.9, and oKular in KDE 4.1.2 as well... Closing this wish. kpdf is no longer under development and the okular team has already implemented it. If you have some problem with the okular feature please open a separate bug. |