[Okular-devel] [okular] [Bug 325650] New: reading direction Right to Left
https://bugs.kde.org/show_bug.cgi?id=325650 Bug ID: 325650 Summary: reading direction Right to Left Classification: Unclassified Product: okular Version: 0.17.1 Platform: unspecified OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: PDF backend Assignee: okular-devel@kde.org Reporter: fahad.alsa...@gmail.com One feature I liked in Adobe Reader is the control over reading direction from Left to Right or Right to Left. I hope it will implemented in Okular one day. Please see the attached image for more understanding. Reproducible: Always -- 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 325650] reading direction Right to Left
https://bugs.kde.org/show_bug.cgi?id=325650 Christoph Feck christ...@maxiom.de changed: What|Removed |Added Status|UNCONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #2 from Christoph Feck christ...@maxiom.de --- What does this option change? Scrolling direction on key presses? Please clarify exactly how Okular should work with this option enabled. -- 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 325650] reading direction Right to Left
https://bugs.kde.org/show_bug.cgi?id=325650 --- Comment #3 from Fahad Al-Saidi fahad.alsa...@gmail.com --- This option gives the control over the order of pages when the view mode is facing pages (Center First page). I have attached two screen-shots one from adobe reader after enabling Reading direction Right to Left and the other from okular the current behavior. I tried to number the page in red to see what is changes. This feature is useful with RTL language and you want to read tow page in the same view or you want to preview you book before sending it to the printer. -- 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 325650] reading direction Right to Left
https://bugs.kde.org/show_bug.cgi?id=325650 --- Comment #4 from Fahad Al-Saidi fahad.alsa...@gmail.com --- Created attachment 82675 -- https://bugs.kde.org/attachment.cgi?id=82675action=edit Adobe reader- reading direction options (Right to Left) -- 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 325650] reading direction Right to Left
https://bugs.kde.org/show_bug.cgi?id=325650 --- Comment #5 from Fahad Al-Saidi fahad.alsa...@gmail.com --- Created attachment 82676 -- https://bugs.kde.org/attachment.cgi?id=82676action=edit Okular- the current reading direction (left to right) -- 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 325677] New: okular fails to open .cbr files with newest unrar installed
https://bugs.kde.org/show_bug.cgi?id=325677 Bug ID: 325677 Summary: okular fails to open .cbr files with newest unrar installed Classification: Unclassified Product: okular Version: 0.17.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Comicbook backend Assignee: okular-devel@kde.org Reporter: joerg_sch...@web.de After trying to open a .cbr file which was previously opened without error, i only got the message that the file couldn't be opened. I checked my package install history and there was a recent unrar upgrade to version 1:5.0.12-1. Okular can't open all tried .cbr files if this version is installed. As a temporary workaround i downgraded unrar to the previous version 1:4.2.4-1 which solved the issue. Note that there only seems to be a problem with unrar, since i didn't had to downgrade libunrar as well, which is currently at version 1:5.0.12-1. Reproducible: Always Steps to Reproduce: 1. Install unrar version 1:5.0.12-1 2. open a .cbr file with okular 3. Error Actual Results: No file opened. Error Message received, stating that the file couldn't be opened. Expected Results: Opened and shown the file's contents. -- 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 112135: Fix for Bug 323262 and Bug 323263
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112135/ --- (Updated Oct. 5, 2013, 8:20 p.m.) Review request for Okular. Changes --- I updated the tests so that no new external files are needed (I gave up testing Document::searchText and contended myself with testing TextPage::findText only, since I have not changed the Document class; so I could easily use synthetic test pages). By the way, my tests cover Bug 309030 already (testHyphenAtEndOfPage). Bugs: 323262 and 323263 http://bugs.kde.org/show_bug.cgi?id=323262 http://bugs.kde.org/show_bug.cgi?id=323263 Repository: okular Description --- This patch solves Bug 323262 and Bug 323263. I also refactored and simplified the code a little. By removing unnecessary calls to toLower in TextPagePrivate::findTextInternalForward and TextPagePrivate::findTextInternalBackward I also fixed a small bug: the letter capital I with dot above (U+0130) did not match itself in case-insensitive mode on Qt 4.8.4 (U+0130 still does not match lowercase i (U+0069), which can be considered another bug, that I didn't fix (although this behavior conforms to the Unicode case folding rules)). (I did not implement the Knuth-Morris-Pratt algorithm that I promised in a comment of Bug 323263 because on second thought I find that the win, if any, would probably be negligible except for some very special documents and special query strings.) Diffs (updated) - core/textpage_p.h 8ecf0c9 core/textpage.cpp 855942d tests/searchtest.cpp 495107d Diff: http://git.reviewboard.kde.org/r/112135/diff/ Testing --- Thanks, Jaan Vajakas ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 325650] reading direction Right to Left
https://bugs.kde.org/show_bug.cgi?id=325650 Christoph Feck christ...@maxiom.de changed: What|Removed |Added Status|NEEDSINFO |UNCONFIRMED Resolution|WAITINGFORINFO |--- --- Comment #6 from Christoph Feck christ...@maxiom.de --- Thanks for the update, swapping the two facing pages makes sense in RTL reading mode. -- 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 112370: BugFix for bug 323434/323435
On Oct. 2, 2013, 11:14 p.m., Albert Astals Cid wrote: Hmmm, i like how now, if i write 154% on there and press the zoom in+zoomout i'm still at 154%, while with your code i'm back to 144% But not sure if that is of any value but i still like it. What do you guys think, is it valuable? Tingnan Zhang wrote: I think with my modification it will go back to 140% (not 144%). And currently, if you put 194% and press the zoom in + zoom out, you will not get 194%, but 184% instead. Also, if you click zoom in/out when the view is in fit width or fit page mode, you will ended up with some 2-digit precision floating number displayed. I think too that this property (being able to reach the original zoom level by zooming out/in, instead of going to the zoom level drop-down box) would be nice. For the case when the user has entered a custom zoom level, having this behavior and solving bugs 323434/323435 at the same time would make the code more complex (it should then store the original zoom level somewhere). But I think a good compromise would be to guarantee this property only in case the user has selected one of the items from the zoom level menu (one of the percentages or Fit Width or Fit Page). E. g. Adobe Reader has this property. - Jaan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112370/#review41149 --- On Oct. 1, 2013, 11:52 p.m., Tingnan Zhang wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112370/ --- (Updated Oct. 1, 2013, 11:52 p.m.) Review request for Okular. Repository: okular Description --- BugFix 323434/323435. Zoom factor now will be properly rounded to those interval values like 140%, 250%, etc, when using zoom in and out feature. 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
Re: [Okular-devel] Review Request 112135: Fix for Bug 323262 and Bug 323263
On Sept. 25, 2013, 9 p.m., Albert Astals Cid wrote: core/textpage.cpp, line 120 http://git.reviewboard.kde.org/r/112135/diff/2/?file=185753#file185753line120 This is an unrelated fix, right? Yes, I noticed it by reviewing the code. I have also added a test for it (testHyphenWithYOverlap). - Jaan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112135/#review40819 --- On Oct. 5, 2013, 8:20 p.m., Jaan Vajakas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112135/ --- (Updated Oct. 5, 2013, 8:20 p.m.) Review request for Okular. Bugs: 323262 and 323263 http://bugs.kde.org/show_bug.cgi?id=323262 http://bugs.kde.org/show_bug.cgi?id=323263 Repository: okular Description --- This patch solves Bug 323262 and Bug 323263. I also refactored and simplified the code a little. By removing unnecessary calls to toLower in TextPagePrivate::findTextInternalForward and TextPagePrivate::findTextInternalBackward I also fixed a small bug: the letter capital I with dot above (U+0130) did not match itself in case-insensitive mode on Qt 4.8.4 (U+0130 still does not match lowercase i (U+0069), which can be considered another bug, that I didn't fix (although this behavior conforms to the Unicode case folding rules)). (I did not implement the Knuth-Morris-Pratt algorithm that I promised in a comment of Bug 323263 because on second thought I find that the win, if any, would probably be negligible except for some very special documents and special query strings.) Diffs - core/textpage_p.h 8ecf0c9 core/textpage.cpp 855942d tests/searchtest.cpp 495107d Diff: http://git.reviewboard.kde.org/r/112135/diff/ Testing --- Thanks, Jaan Vajakas ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 325677] okular fails to open .cbr files with newest unrar installed
https://bugs.kde.org/show_bug.cgi?id=325677 Christoph Feck christ...@maxiom.de changed: What|Removed |Added CC||christ...@maxiom.de --- Comment #1 from Christoph Feck christ...@maxiom.de --- Works here with openSUSE unrar package (unrar-5.0.11-2.1.5.i586). unrar --version UNRAR 5.00 freeware Copyright (c) 1993-2013 Alexander Roshal Please add the output of unrar --version. Could you also please enable all messages with kdebugdialog in Konsole, and add the output from Okular when trying to open the .cbr? -- 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
