- User Since
- Aug 21 2017, 7:57 PM (82 w, 5 d)
Feb 14 2019
The test plan still says that Ctrl+P will select the page ("or press combination of CTRL and P to select the entire page"). As far as I understand the previous comments, this is Alt+P now, isn't it? (I didn't do any tests.) Can you update the description accordingly?
Feb 2 2019
Thanks a lot! I'll take a look at these links.
(accidently closed the revision, so reopending it now)
Thanks for the super-quick review!
Feb 1 2019
Jan 17 2019
Changes in this revision:
Adapted according to Albert's feedback:
Jan 16 2019
If you have any other idea on how to avoid that issue with the printFiles() methods, I'd be thankful to hear about this.
- Adapt order of ScaleMode enum values as implicitly suggested in Albert's comment (I missed that at first)
Changes in this revision:
Changes in this revision:
Jan 15 2019
Thanks for the feedback and info. I've update the change accordingly now.
Undo accidental whitespace changes
Implement improvements suggested by Albert:
Adapt according to Albert's feedback:
Jan 12 2019
Jan 11 2019
OK, I understand. I don't have any strong opinion on this then.
Changes in this version:
I'd also prefer to leave the current behaviour of a left-click as it is, regardless of the exact position. That is also in line with what e.g. LibreOffice Impress does. Allowing to go back by doing a single-finger swipe sounds great.
Jan 8 2019
Thanks for the explanation!
Jan 5 2019
I find the approach interesting at least. However, I currently don't know enough of the different Poppler backends to really assess the situation properly. My thought was that it might possibly make sense to add an experimental option to enable this and https://git.reviewboard.kde.org/r/130235/ if the Arthur backend has general advantages over Splash and there was the plan to get it "production-ready". Can anybody quickly explain what the situation and plan with those backends is or is that too complex?
Jan 4 2019
Dec 25 2018
Sep 21 2018
Thanks for your helpful feedback. Given the last comments, I agree that having text selection mode is probably not particularly useful for touch displays. I'm thus abandoning this change.
Jul 20 2018
While testing, the options did not seem to have any effect for me; changing them did not affect the printout.
Jul 10 2018
@arthurpeters: Thanks for your ideas on this. For now, I'd like to stick with the two options that have been discussed so far in this change (see reasoning in D10974#217969) and suggest to handle potential further improvements separately.
In general, I really like the idea of providing this new option.
Jun 29 2018
I might have missed something, but I'm not yet sure what the "correct" wording for the two options in the radio button or combobox would be. :-)
Jun 7 2018
@aacid , @ngraham : Any chance we can reach a concensus here?
I personally don't have a strong opinion on what the best term to use in the dialog is and could live with all suggestions made so far.
Looking at the Firefox screenshot, the option "Ignore print margins and scale to full page" came to my mind in addition (which is quite long, but might be clear on what is happening?).
May 25 2018
I'm not really sure by myself yet, but does it help to say "print area" instead of "printable area" (i.e. "Fit to print area") to take into account that the margins being used are not necessarily the hardware margins of the printer (which define the "printable area")? Would it be clear for users what this refers to?
May 24 2018
Changes to previous version:
May 18 2018
Apr 19 2018
Mar 9 2018
(Don't) Set margins based on QPrinter::fullPage()
Mar 4 2018
Mar 2 2018
Once https://phabricator.kde.org/D7962 should make it to Okular, it might make sense to reconsider using the combobox for the scaling options that this adds for the PDF generator case (or how to properly merge the two approaches for the QPrinter and the lpr approaches).
In general, this option is not only relevant for the PDF generator, but (as Albert mentioned on the bug report) for all generators that use FilePrinter.
This change currently only addresses the PDF case.
Jan 21 2018
As mentioned in https://bugs.kde.org/show_bug.cgi?id=389224#c2 , there is the following new commit for Purpose that should fix the build when the "old" name is used for the dependency: https://cgit.kde.org/purpose.git/commit/?id=20a304236100b29014403a894cbda2d93ab28e41
Dec 16 2017
Dec 15 2017
I tested this a bit and find it really nice that rendering of the actual page (rather than the thumbnail) usually starts at once when re-rendering is needed (e.g. when zoom level is changed).
Also, closing Okular now works fast, even if rendering is still in progress. (The shell prompt is shown almost immediately after closing Okular when it was started from the command line.)
The 2 suggested improvements are now implemented.
Rename to "kprinter5", update includes
Dec 14 2017
Dec 6 2017
Nov 13 2017
Nov 8 2017
Open pdf file, add anotation, close app
You get dialog about losing changes, check that save, discard, cancel all do what they say