Version: (using KDE KDE 3.4.0) Installed from: SuSE RPMs When viewing a PDF (at zoom 100%) with KPDF from KDE 3.4 RC1, the PDF is shown too small. It looks like KPDF assumes that the display has 72 dpi, which is just wrong for most displays and monitors. I have a 95dpi display (even "xdpyinfo |grep resolution" says that) but KPDF displays an A4 document with a width of only 15.7cm instead of 21cm. That makes it very hard to read text, especially for older people. OK, one cold zoom in every time one reads a PDF, but that's just a workaround.
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.