Re: [Okular-devel] Dt. 28th August - status
On Thu, Aug 29, 2013 at 2:41 AM, Fabio D'Urso fabiodu...@hotmail.it wrote: On Thursday, August 29, 2013 01:23:48 AM Jaydeep Solanki wrote: On Wed, Aug 28, 2013 at 2:00 AM, Jaydeep Solanki jayd...@gmail.com wrote: Hi, I noticed that the (movie) annotation version actually works, it's just that it takes a few seconds to start. Current status is I can hear the video playing but no visual. I have visual now, working on playing video using raw data, and fixing position of video widget, currently it's displayed at (0,0). Hi, In case it's relevant for your work, there's an interesting comment about playing from QByteArray in core/movie.cpp Yeah, I saw it, but according to the comment, it should be fixed. No ? Also in generators/epub/epubdocument.cpp::loadResource(..) when I load video, I get data = and size = the size of the video file in bits. Result, is the video doesn't get played. :/ Fabio To debug this, I turned off a lot of features like drawingContent (because the video player is not drawn using converter), turned off the textpages, etc. Now what I see are random lines, which I guess was supposed to be the video. Plus, the audio doesn't play when loading movie from QByteArray, but works when using a file from other location (which I used to test). Seems to be a minor bug, will be easy to fix once I get at least something working. Note : if you want to try out what I'm seeing, a patch is attached, and if you might have seen something similar it would be helpful. Epub link https://epub-samples.googlecode.com/files/cc-shared-culture-20120130 .epubto test. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 204709] find: whole words only
https://bugs.kde.org/show_bug.cgi?id=204709 ssameer+b...@gmail.com changed: What|Removed |Added CC||ssameer+b...@gmail.com --- Comment #2 from ssameer+b...@gmail.com --- I am using Okular 0.17.0 in KDE SC 4.11.00 (OpenSuse). This feature is essential for searching documents. More examples: search for vision yields division, revision, etc. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111829: Use DPI of current screen for PDF rendering
On Aug. 25, 2013, 4:13 p.m., Albert Astals Cid wrote: Ok, the code looks sane but there are two things that still make me unsure about this whole thing: * Why you need Pixels? In the bug you say Points, but actually it is pixels, DIVIDED by 72. That is not true, the page size of a PDF is defined in points (well it's actually defined in UserUnits but that defaults to the Point value) Why do you say it's pixels DIVIDED by 72? I'd be happier if we could still have the PDF backend return stuff in points and have all the dpi conversion magic in the layers above it * I'm still undecided as of why we need the widget realDpi. Reasons: As far as I know (though my knowledge may not be very good :D) all the systems force you to have the same DPI in all the monitors, so having to pass the widget seems nice it's going to do magic when I move it to another monitor, but that's really not happening no? Or at least if there was a system in which you could have different screens with different monitors, we miss something so that when you move it from one monitor to another the dpi gets recalculated no? I know this may sound like I'm stalling the patch, but it is really not, I just want to make sure we end up with a patch that we're all happy and convinced with. Eugene Shalygin wrote: * Why you need Pixels? Regarding the pixels divided... I'm not sure now :). The story had been started with aim to get correct scale on screen, as you certainly remember. To my understanding, Page::width() and Page::height() are in screen pixels (at least it seems to me like this from reading of e.g. PageView::updateItemSize()). If this is correct, PageView class should handle screen DPI, and all generators should set page size in points (or in something, that has a dimension). Will we go this way? * I'm still undecided as of why we need the widget realDpi. I'm afraid I do not understand your comment completetly. I'll answwer on question that I understood. 1. The system can not force us to have the same DPI in all monitors, since the system can not change physical DPI of the screen (at least in the Universe #3 :D). 2. We use widget object to get the monitor in which the display the pages (and its current DPI). I'm going to be on holiday most of september, so unless someone else takes care of this review you'll have to wait until I come back. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111829/#review38556 --- On Aug. 21, 2013, 12:56 a.m., Eugene Shalygin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111829/ --- (Updated Aug. 21, 2013, 12:56 a.m.) Review request for Okular and Albert Astals Cid. 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
Re: [Okular-devel] Review Request 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111410/#review38896 --- I'm going to be on holiday most of september, so unless someone else takes care of this review you'll have to wait until I come back. - Albert Astals Cid On Aug. 27, 2013, 8:11 p.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111410/ --- (Updated Aug. 27, 2013, 8:11 p.m.) Review request for Okular. Description --- This patch implements the feature request of bug 321350: if a PDF file is viewed, the selection tool offers the new extraction method vector which allows to save to a file (PDF, SVG, EPS, PostScript). The crop operation is performed by calling pdftocairo with matching arguments. The resulting file contains the original PDF file's content without rendering it to a pixmap. I am not sure if calling an external program is an acceptable solution for this problem. However, it is tested if the program is available before showing the new option. Alternatively, the code of pdftocairo (as part of poppler) would had to be copied and integrated into Okular increasing the solution's complexity. I am not aware of a similar solution available using poppler-qt4 only. Maybe using a QPrinter printing to PDF would have been an alternative, but again this seemed to be too complex. Diffs - core/document.h fe296e0 core/document.cpp 3af92c8 core/generator.h a5a971b core/generator.cpp 41beb92 generators/poppler/generator_pdf.h 5d5853a generators/poppler/generator_pdf.cpp 1a44523 ui/pageview.cpp 0d6c567 Diff: http://git.reviewboard.kde.org/r/111410/diff/ Testing --- Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 110914: Tabbed interface
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110914/#review38895 --- I'm going to be on holiday most of september, so unless someone else takes care of this review you'll have to wait until I come back. - Albert Astals Cid On Aug. 23, 2013, 8:06 p.m., Jonathan Doman wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110914/ --- (Updated Aug. 23, 2013, 8:06 p.m.) Review request for Okular. Description --- This patch adds support for a tabbed interface (multiple documents in one window). The core work just adds a tab bar that switches between multiple embedded okularparts, but there are many other considerations: - Tab context menu allows for duplicating or detaching (detached tabs start in new okular process) - `okular file.pdf` will open file in existing window if possible, unless --new flag is used. It also selects the most recently raised/activated window to use. This mirrors behavior I expect from browsers and other tabbed interfaces. - Warns when closing window with multiple tabs - No warning is given when opening an already open file. This is the behavior I strongly prefer (and observe in other programs), but will change if there is consensus otherwise. When selecting different tools in one part, the tool selection propagates to all parts, but the GUI does not reflect that. This bug is present in other programs (e.g. multiple okularparts in Konqueror), so I made no attempt to diagnose or fix. One menu item was added for the multiple tab warning option. When testing this, I noticed that items in the Settings menu seem to move around when switching tabs, and I cannot diagnose or fix this. It seems to be related to XMLGUI bug #64754. My development branch is also hosted at https://github.com/jrmrjnck/okular-tabbed This addresses bug 155515. http://bugs.kde.org/show_bug.cgi?id=155515 Diffs - part.h 4b3aafdb637080ae81eb0e45742f53a34738984d part.cpp 71c3d0f5d908969ffcf18aba327297ccd2e1c8e1 shell/main.cpp e0ca587ba167c4020d5af5bd33a2dc1b4923cac4 shell/shell.h c065c560fb4ddfcf181601cf35e9ca14581731f6 shell/shell.cpp 1708501daaef817a1ce35fa5d96701a66ab66983 shell/shell.rc 93fbc417588312792bab39b693c65e5d414c87c6 Diff: http://git.reviewboard.kde.org/r/110914/diff/ Testing --- Thanks, Jonathan Doman ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111829: Use DPI of current screen for PDF rendering
On Aug. 25, 2013, 6:13 p.m., Albert Astals Cid wrote: Ok, the code looks sane but there are two things that still make me unsure about this whole thing: * Why you need Pixels? In the bug you say Points, but actually it is pixels, DIVIDED by 72. That is not true, the page size of a PDF is defined in points (well it's actually defined in UserUnits but that defaults to the Point value) Why do you say it's pixels DIVIDED by 72? I'd be happier if we could still have the PDF backend return stuff in points and have all the dpi conversion magic in the layers above it * I'm still undecided as of why we need the widget realDpi. Reasons: As far as I know (though my knowledge may not be very good :D) all the systems force you to have the same DPI in all the monitors, so having to pass the widget seems nice it's going to do magic when I move it to another monitor, but that's really not happening no? Or at least if there was a system in which you could have different screens with different monitors, we miss something so that when you move it from one monitor to another the dpi gets recalculated no? I know this may sound like I'm stalling the patch, but it is really not, I just want to make sure we end up with a patch that we're all happy and convinced with. Eugene Shalygin wrote: * Why you need Pixels? Regarding the pixels divided... I'm not sure now :). The story had been started with aim to get correct scale on screen, as you certainly remember. To my understanding, Page::width() and Page::height() are in screen pixels (at least it seems to me like this from reading of e.g. PageView::updateItemSize()). If this is correct, PageView class should handle screen DPI, and all generators should set page size in points (or in something, that has a dimension). Will we go this way? * I'm still undecided as of why we need the widget realDpi. I'm afraid I do not understand your comment completetly. I'll answwer on question that I understood. 1. The system can not force us to have the same DPI in all monitors, since the system can not change physical DPI of the screen (at least in the Universe #3 :D). 2. We use widget object to get the monitor in which the display the pages (and its current DPI). Albert Astals Cid wrote: I'm going to be on holiday most of september, so unless someone else takes care of this review you'll have to wait until I come back. Well, then just commit it right now ;) Could you please then try to answer my question before going on holiday? - Eugene --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111829/#review38556 --- On Aug. 21, 2013, 2:56 a.m., Eugene Shalygin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111829/ --- (Updated Aug. 21, 2013, 2:56 a.m.) Review request for Okular and Albert Astals Cid. 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
[Okular-devel] [okular] [Bug 249364] PATCH: Fit best (best-fit) zoom
https://bugs.kde.org/show_bug.cgi?id=249364 --- Comment #12 from Christoph Feck christ...@maxiom.de --- Albert, Version-Fixed-In == 4.12, or do you want to use the Okular version now? -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 322127] Okular crashes on CHM files
https://bugs.kde.org/show_bug.cgi?id=322127 Christoph Feck christ...@maxiom.de changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |INVALID --- Comment #4 from Christoph Feck christ...@maxiom.de --- No response, changing status. Please reopen, if you have more information. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 322407] Okular does not properly display some gradients
https://bugs.kde.org/show_bug.cgi?id=322407 --- Comment #3 from Christoph Feck christ...@maxiom.de --- To further investigate this issue, KDE developers need the information requested in comment #2. If you can provide it, or need help with finding that information, please add a comment. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 322357] PDF Annotations in certain pages crash Okular
https://bugs.kde.org/show_bug.cgi?id=322357 --- Comment #3 from Christoph Feck christ...@maxiom.de --- To further investigate this issue, KDE developers need the information requested in comment #1. If you can provide it, or need help with finding that information, please add a comment. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 323391] Impossible to reduce the width of documents with portrait and landscape pages
https://bugs.kde.org/show_bug.cgi?id=323391 --- Comment #10 from Christoph Feck christ...@maxiom.de --- So should this bug be reassigned to Kile developers? -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 249364] PATCH: Fit best (best-fit) zoom
https://bugs.kde.org/show_bug.cgi?id=249364 --- Comment #13 from Albert Astals Cid aa...@kde.org --- 4.12 or 4.12.0 is both fine -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 322993] Okular always prints in duplex mode
https://bugs.kde.org/show_bug.cgi?id=322993 --- Comment #11 from Christoph Feck christ...@maxiom.de --- You could check if this also shows with pure Qt applications, for example qpdfview. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111829: Use DPI of current screen for PDF rendering
On Aug. 25, 2013, 4:13 p.m., Albert Astals Cid wrote: Ok, the code looks sane but there are two things that still make me unsure about this whole thing: * Why you need Pixels? In the bug you say Points, but actually it is pixels, DIVIDED by 72. That is not true, the page size of a PDF is defined in points (well it's actually defined in UserUnits but that defaults to the Point value) Why do you say it's pixels DIVIDED by 72? I'd be happier if we could still have the PDF backend return stuff in points and have all the dpi conversion magic in the layers above it * I'm still undecided as of why we need the widget realDpi. Reasons: As far as I know (though my knowledge may not be very good :D) all the systems force you to have the same DPI in all the monitors, so having to pass the widget seems nice it's going to do magic when I move it to another monitor, but that's really not happening no? Or at least if there was a system in which you could have different screens with different monitors, we miss something so that when you move it from one monitor to another the dpi gets recalculated no? I know this may sound like I'm stalling the patch, but it is really not, I just want to make sure we end up with a patch that we're all happy and convinced with. Eugene Shalygin wrote: * Why you need Pixels? Regarding the pixels divided... I'm not sure now :). The story had been started with aim to get correct scale on screen, as you certainly remember. To my understanding, Page::width() and Page::height() are in screen pixels (at least it seems to me like this from reading of e.g. PageView::updateItemSize()). If this is correct, PageView class should handle screen DPI, and all generators should set page size in points (or in something, that has a dimension). Will we go this way? * I'm still undecided as of why we need the widget realDpi. I'm afraid I do not understand your comment completetly. I'll answwer on question that I understood. 1. The system can not force us to have the same DPI in all monitors, since the system can not change physical DPI of the screen (at least in the Universe #3 :D). 2. We use widget object to get the monitor in which the display the pages (and its current DPI). Albert Astals Cid wrote: I'm going to be on holiday most of september, so unless someone else takes care of this review you'll have to wait until I come back. Eugene Shalygin wrote: Well, then just commit it right now ;) Could you please then try to answer my question before going on holiday? Should be learning some Japanese, but oh well, i'm already here. * Why you need Pixels? Regarding the pixels divided... I'm not sure now :). The story had been started with aim to get correct scale on screen, as you certainly remember. To my understanding, Page::width() and Page::height() are in screen pixels (at least it seems to me like this from reading of e.g. PageView::updateItemSize()). If this is correct, PageView class should handle screen DPI, and all generators should set page size in points (or in something, that has a dimension). Will we go this way? Well, i'm undeccided on this one, i'd like to share as much dpi-pixel conversion code, and putting it outside the generator helps this, but of course it means we have to change more *core* code that's also not so great, so well think if you could make it so some of the code that does dpi-pixel was shared a bit more up the chain. About the other generators, they don't return Points so we wouldn't need to change them back and forth * I'm still undecided as of why we need the widget realDpi. I'm afraid I do not understand your comment completetly. I'll answwer on question that I understood. 1. The system can not force us to have the same DPI in all monitors, since the system can not change physical DPI of the screen (at least in the Universe #3 :D). It is, but as far as I've been told X only has one DPI setting so... 2. We use widget object to get the monitor in which the display the pages (and its current DPI). ... are you sure about this? Everyone I asked as told me that if I have a two screen desktop shared across two monitors with different DPI, I'll get the same DPI (one of the two monitors) when querying on both, bsically because if this did not happen how would you render something that is shown on both screens because it's in the middle? - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111829/#review38556 --- On Aug. 21, 2013, 12:56 a.m., Eugene Shalygin wrote: --- This is an automatically generated e-mail. To reply, visit:
[Okular-devel] [okular] [Bug 323391] Impossible to reduce the width of documents with portrait and landscape pages
https://bugs.kde.org/show_bug.cgi?id=323391 --- Comment #11 from Albert Astals Cid aa...@kde.org --- Or at least adding them as CC, yeah, can you do that, please? -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 323563] incorrect rendering while viewing PDF; it does print correctly
https://bugs.kde.org/show_bug.cgi?id=323563 Christoph Feck christ...@maxiom.de changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME --- Comment #6 from Christoph Feck christ...@maxiom.de --- I just tested with a clean config. Trim Margins is not enabled by default, so at some point you enabled it. I think it makes sense that Okular remembers this option between invokations, because someone might be highly annoyed, if he had to change it every time. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 323721] Okular crashes on corrupted pdf
https://bugs.kde.org/show_bug.cgi?id=323721 --- Comment #6 from Christoph Feck christ...@maxiom.de --- Francesco, if you can provide the information requested in comment #5, please add it. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 322407] Okular does not properly display some gradients
https://bugs.kde.org/show_bug.cgi?id=322407 --- Comment #4 from Don Rhummy donrhu...@yahoo.com --- (In reply to comment #3) To further investigate this issue, KDE developers need the information requested in comment #2. If you can provide it, or need help with finding that information, please add a comment. sorry, been busy, I will provide an example but won't have time for about 3 weeks. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111829: Use DPI of current screen for PDF rendering
On Aug. 25, 2013, 6:13 p.m., Albert Astals Cid wrote: Ok, the code looks sane but there are two things that still make me unsure about this whole thing: * Why you need Pixels? In the bug you say Points, but actually it is pixels, DIVIDED by 72. That is not true, the page size of a PDF is defined in points (well it's actually defined in UserUnits but that defaults to the Point value) Why do you say it's pixels DIVIDED by 72? I'd be happier if we could still have the PDF backend return stuff in points and have all the dpi conversion magic in the layers above it * I'm still undecided as of why we need the widget realDpi. Reasons: As far as I know (though my knowledge may not be very good :D) all the systems force you to have the same DPI in all the monitors, so having to pass the widget seems nice it's going to do magic when I move it to another monitor, but that's really not happening no? Or at least if there was a system in which you could have different screens with different monitors, we miss something so that when you move it from one monitor to another the dpi gets recalculated no? I know this may sound like I'm stalling the patch, but it is really not, I just want to make sure we end up with a patch that we're all happy and convinced with. Eugene Shalygin wrote: * Why you need Pixels? Regarding the pixels divided... I'm not sure now :). The story had been started with aim to get correct scale on screen, as you certainly remember. To my understanding, Page::width() and Page::height() are in screen pixels (at least it seems to me like this from reading of e.g. PageView::updateItemSize()). If this is correct, PageView class should handle screen DPI, and all generators should set page size in points (or in something, that has a dimension). Will we go this way? * I'm still undecided as of why we need the widget realDpi. I'm afraid I do not understand your comment completetly. I'll answwer on question that I understood. 1. The system can not force us to have the same DPI in all monitors, since the system can not change physical DPI of the screen (at least in the Universe #3 :D). 2. We use widget object to get the monitor in which the display the pages (and its current DPI). Albert Astals Cid wrote: I'm going to be on holiday most of september, so unless someone else takes care of this review you'll have to wait until I come back. Eugene Shalygin wrote: Well, then just commit it right now ;) Could you please then try to answer my question before going on holiday? Albert Astals Cid wrote: Should be learning some Japanese, but oh well, i'm already here. * Why you need Pixels? Regarding the pixels divided... I'm not sure now :). The story had been started with aim to get correct scale on screen, as you certainly remember. To my understanding, Page::width() and Page::height() are in screen pixels (at least it seems to me like this from reading of e.g. PageView::updateItemSize()). If this is correct, PageView class should handle screen DPI, and all generators should set page size in points (or in something, that has a dimension). Will we go this way? Well, i'm undeccided on this one, i'd like to share as much dpi-pixel conversion code, and putting it outside the generator helps this, but of course it means we have to change more *core* code that's also not so great, so well think if you could make it so some of the code that does dpi-pixel was shared a bit more up the chain. About the other generators, they don't return Points so we wouldn't need to change them back and forth * I'm still undecided as of why we need the widget realDpi. I'm afraid I do not understand your comment completetly. I'll answwer on question that I understood. 1. The system can not force us to have the same DPI in all monitors, since the system can not change physical DPI of the screen (at least in the Universe #3 :D). It is, but as far as I've been told X only has one DPI setting so... 2. We use widget object to get the monitor in which the display the pages (and its current DPI). ... are you sure about this? Everyone I asked as told me that if I have a two screen desktop shared across two monitors with different DPI, I'll get the same DPI (one of the two monitors) when querying on both, bsically because if this did not happen how would you render something that is shown on both screens because it's in the middle? First of all, thanks for your time! Well, i'm undeccided on this one, i'd like to share as much dpi-pixel conversion code,... so well think if you could make it so some of the code that does dpi-pixel.. OK. Maybe it would be better to to this separaterly (in separate review request)? I can work on that. But it would be
[Okular-devel] [okular] [Bug 324241] Files generated with QTextDocument can't be opened with okular
https://bugs.kde.org/show_bug.cgi?id=324241 --- Comment #1 from Aleix Pol aleix...@kde.org --- Created attachment 82020 -- https://bugs.kde.org/attachment.cgi?id=82020action=edit here's a file to reproduce the problem LibreOffice can open it -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 249364] PATCH: Fit best (best-fit) zoom
https://bugs.kde.org/show_bug.cgi?id=249364 Jekyll Wu adap...@gmail.com changed: What|Removed |Added Version Fixed In||4.12.0 -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Review Request 112370: BugFix for bug 323434/323435
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112370/ --- Review request for Okular. Description --- BugFix 323434/323435. Zoom factor now are rounded. Diffs - ui/pageview.cpp 0d6c567d836340555b3101b58178a9247959543a Diff: http://git.reviewboard.kde.org/r/112370/diff/ Testing --- done on local machine Thanks, Tingnan Zhang ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
