[Okular-devel] Review Request 111829: Use DPI of current screen for PDF rendering

[Albert Astals Cid]

> On Oct. 1, 2013, 9:37 p.m., Albert Astals Cid wrote:
> > core/utils.cpp, line 116
> > <https://git.reviewboard.kde.org/r/111829/diff/6/?file=183816#file183816line116>
> >
> >     Hmmm, my libkscreen does not have sizeMm, what libkscreen version are you using?
> 
> Eugene Shalygin wrote:
>     The changes were accepted into master branch of libkscreen some time ago, and I do not know when they will be released
> 
> Albert Astals Cid wrote:
>     Ok, we'll have to wait until it gets released since otherwise the code is not compiling at the moment for people running released versions of stuff. It'd be cool if you can warn us once there's a released version of libkscreen we can use.
> 
> Eugene Shalygin wrote:
>     The change was commited on the next day after 1.0.1 tag. So, no problem, I'll ping here. Does it mean that you do not have any other objections? ;)
> 
> Albert Astals Cid wrote:
>     Can't tell if i have more objections until i can compile and run the stuff, i defenitely want to try how hard is to get away from using pixels and back to points, but i'll try that myself once i get this thing compiling properly.
> 
> Eugene Shalygin wrote:
>     Version 1.0.2 of libkscreen was released --- http://download.kde.org/stable/libkscreen/1.0.2/
> 
> Eugene Shalygin wrote:
>     ping?
> 
> Albert Astals Cid wrote:
>     on it sorry, been busy
> 
> Eugene Shalygin wrote:
>     OK. Do we have a chance to make it done for 4.13?

Yes, see http://techbase.kde.org/Schedules/KDE4/4.13_Release_Schedule


- Albert


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/111829/#review41080
-----------------------------------------------------------


On Aug. 21, 2013, 12:56 a.m., Eugene Shalygin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/111829/
> -----------------------------------------------------------
> 
> (Updated Aug. 21, 2013, 12:56 a.m.)
> 
> 
> Review request for Okular and Albert Astals Cid.
> 
> 
> Bugs: 268757
>     http://bugs.kde.org/show_bug.cgi?id=268757
> 
> 
> Repository: okular
> 
> 
> Description
> -------
> 
> This patch relies on master branch of LibKScreen.
> This patch does not solve the problem in bug completely, but makes Okular behaviour more correct (see below).
> 
> The problem (in the bug) is that Okular uses fixed DPI for PDF rendering (72.0 dots per inch) and therefore scale of rendered document becomes incorrect. With current mainline laptop screens having DPI easily twice larger than this constant (72), the problem shows itself quiet strongly.
> 
> Additional problems araise with multiscreen configuration, when 1) DPI of each individual screen may be different, and 2) there is no tools in Qt to detect DPI of individual screens in virtual desktop mode. Therefore XRandr has to be used for DPI detection. Raw XRandr is bad dependency for Okular and libkscreen is proposed instead.
> 
> This patch approach to the solution in the following way:
> 1. libkscreen detection staff is added to CMakeLists.txt and config.h
> 2. It changes Utils::realDpi() function to use libkscreen if present. With libkscreen the function looks for output that contains maximal part of given widget (suppose to be used for document rendering) and returns DPI of that screen.
> 3. Genenerator interface is extended by adding UtilizeDPI feature and setDPI() method, that is called by Document class right before calling loadXXX() if the generator supports this feature
> 4. Poppler generator is changed to support UtilizeDPI feature.
> 5. PageSizeMetric enum is extended with Pixels value to explicitly say that page size is defined in screen pixels (see my posts in the bug); Poppler generator uses this case.
> 
> 
> To completetly fix the bug, Document must invalidate generated pixmaps after the widget movements into another screen. I do not know how to track this without subclassing the main window class. Therefore I decided to publish this part of work to get your responce, especially regarding item 3 (Generator class changes).
> 
> In the current state, manual reloading of a document after moving Okular to another screen fixes the scale, that is, in my eyes, is quiet helpful already.
> 
> Even if we subclass the Okular main window, I do not know what to do when Okular is used as KPart. 
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 217337f 
>   config-okular.h.cmake 7217f8d 
>   core/document.cpp 3af92c8 
>   core/generator.h a5a971b 
>   core/generator.cpp 41beb92 
>   core/generator_p.h b59293a 
>   core/utils.h 8d5d5fc 
>   core/utils.cpp 5dd8448 
>   generators/poppler/generator_pdf.h 5d5853a 
>   generators/poppler/generator_pdf.cpp 1a44523 
> 
> Diff: https://git.reviewboard.kde.org/r/111829/diff/
> 
> 
> Testing
> -------
> 
> Manual. In all screens, that report correct physical size to XRandr, size of documents is correct
> 
> 
> Thanks,
> 
> Eugene Shalygin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20140113/354eb792/attachment.html>