[Okular-devel] [okular] [Bug 169847] split view feature
https://bugs.kde.org/show_bug.cgi?id=169847 Ruslan Kabatsayev b7.10110...@gmail.com changed: What|Removed |Added CC||b7.10110...@gmail.com -- 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 114153: An Idea: Render PDF annotations internally while they are being moved
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/ --- Review request for Okular. Repository: okular Description --- Unlike in other document formats, the annotations on PDF documents are rendered by the Poppler back-end along with the document itself. Because this document rendering step is expensive we don't render annotations on PDF documents while the annotations are being moved (With Ctrl+Left click drag). Instead of rendering the annotation itself during the move, we render a dashed outline of the annotation. For non-PDF document types the annotations are rendered by Okular on top of the document, and so there is no large performance penalty in rendering the annotation smoothly as it is moved. I find the aesthetic experience of moving annotations on non-PDF to be much more pleasing. In this small patch updates the paintCroppedPageOnPainter() function draw external annotations using the internal annotation drawing logic while the annotation is being moved. It also removes the dashed annotation outline during the move. With this small change the experience of moving an annotation on a PDF now matches that of moving an annotation on the other document formats. Two small oddities: The rendering of the popup note icon differs between the Poppler back-end and Okular's internal rendering so the icon changes form while being moved and then changes back after being dropped. The rendering of fonts on inline notes between the Poppler back-end and Okular's internal rendering seems to differ in some cases so as you move an inline note the font changes. Thoughts? Diffs - ui/pagepainter.cpp d5d9c3e Diff: http://git.reviewboard.kde.org/r/114153/diff/ Testing --- Tested drawing and moving each of the annotation types on a PDF document and on a DVI document. The behavior on the DVI document is unchanged. I find the behavior on the PDF document to be more natural. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114153: An Idea: Render PDF annotations internally while they are being moved
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/#review44611 --- Don't have an opinion to be honest. It is true that for some cases it looks better, but for some others it looks weird since you switch between text rendered by poppler and text rendered by us. I'm not oposed to either. Fabio? - Albert Astals Cid On Nov. 27, 2013, 3:22 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/ --- (Updated Nov. 27, 2013, 3:22 p.m.) Review request for Okular. Repository: okular Description --- Unlike in other document formats, the annotations on PDF documents are rendered by the Poppler back-end along with the document itself. Because this document rendering step is expensive we don't render annotations on PDF documents while the annotations are being moved (With Ctrl+Left click drag). Instead of rendering the annotation itself during the move, we render a dashed outline of the annotation. For non-PDF document types the annotations are rendered by Okular on top of the document, and so there is no large performance penalty in rendering the annotation smoothly as it is moved. I find the aesthetic experience of moving annotations on non-PDF to be much more pleasing. In this small patch updates the paintCroppedPageOnPainter() function draw external annotations using the internal annotation drawing logic while the annotation is being moved. It also removes the dashed annotation outline during the move. With this small change the experience of moving an annotation on a PDF now matches that of moving an annotation on the other document formats. Two small oddities: The rendering of the popup note icon differs between the Poppler back-end and Okular's internal rendering so the icon changes form while being moved and then changes back after being dropped. The rendering of fonts on inline notes between the Poppler back-end and Okular's internal rendering seems to differ in some cases so as you move an inline note the font changes. Thoughts? Diffs - ui/pagepainter.cpp d5d9c3e Diff: http://git.reviewboard.kde.org/r/114153/diff/ Testing --- Tested drawing and moving each of the annotation types on a PDF document and on a DVI document. The behavior on the DVI document is unchanged. I find the behavior on the PDF document to be more natural. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114153: An Idea: Render PDF annotations internally while they are being moved
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/#review44612 --- Rendering differences (that I judged ugly) were the reason why I chose to go the dashed outline route. - Fabio D'Urso On Nov. 27, 2013, 3:22 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/ --- (Updated Nov. 27, 2013, 3:22 p.m.) Review request for Okular. Repository: okular Description --- Unlike in other document formats, the annotations on PDF documents are rendered by the Poppler back-end along with the document itself. Because this document rendering step is expensive we don't render annotations on PDF documents while the annotations are being moved (With Ctrl+Left click drag). Instead of rendering the annotation itself during the move, we render a dashed outline of the annotation. For non-PDF document types the annotations are rendered by Okular on top of the document, and so there is no large performance penalty in rendering the annotation smoothly as it is moved. I find the aesthetic experience of moving annotations on non-PDF to be much more pleasing. In this small patch updates the paintCroppedPageOnPainter() function draw external annotations using the internal annotation drawing logic while the annotation is being moved. It also removes the dashed annotation outline during the move. With this small change the experience of moving an annotation on a PDF now matches that of moving an annotation on the other document formats. Two small oddities: The rendering of the popup note icon differs between the Poppler back-end and Okular's internal rendering so the icon changes form while being moved and then changes back after being dropped. The rendering of fonts on inline notes between the Poppler back-end and Okular's internal rendering seems to differ in some cases so as you move an inline note the font changes. Thoughts? Diffs - ui/pagepainter.cpp d5d9c3e Diff: http://git.reviewboard.kde.org/r/114153/diff/ Testing --- Tested drawing and moving each of the annotation types on a PDF document and on a DVI document. The behavior on the DVI document is unchanged. I find the behavior on the PDF document to be more natural. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114153: An Idea: Render PDF annotations internally while they are being moved
On Nov. 27, 2013, 7:44 p.m., Albert Astals Cid wrote: Don't have an opinion to be honest. It is true that for some cases it looks better, but for some others it looks weird since you switch between text rendered by poppler and text rendered by us. I'm not oposed to either. Fabio? A compromise would be to only use this approach for the geometric shapes (Ink stroke, line, polygon, and ellipse) and keep that past behavior for everything else. The geometric shapes seem to me to be rendered nearly identically in Okular as in Poppler. - Jon --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/#review44611 --- On Nov. 27, 2013, 3:22 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/ --- (Updated Nov. 27, 2013, 3:22 p.m.) Review request for Okular. Repository: okular Description --- Unlike in other document formats, the annotations on PDF documents are rendered by the Poppler back-end along with the document itself. Because this document rendering step is expensive we don't render annotations on PDF documents while the annotations are being moved (With Ctrl+Left click drag). Instead of rendering the annotation itself during the move, we render a dashed outline of the annotation. For non-PDF document types the annotations are rendered by Okular on top of the document, and so there is no large performance penalty in rendering the annotation smoothly as it is moved. I find the aesthetic experience of moving annotations on non-PDF to be much more pleasing. In this small patch updates the paintCroppedPageOnPainter() function draw external annotations using the internal annotation drawing logic while the annotation is being moved. It also removes the dashed annotation outline during the move. With this small change the experience of moving an annotation on a PDF now matches that of moving an annotation on the other document formats. Two small oddities: The rendering of the popup note icon differs between the Poppler back-end and Okular's internal rendering so the icon changes form while being moved and then changes back after being dropped. The rendering of fonts on inline notes between the Poppler back-end and Okular's internal rendering seems to differ in some cases so as you move an inline note the font changes. Thoughts? Diffs - ui/pagepainter.cpp d5d9c3e Diff: http://git.reviewboard.kde.org/r/114153/diff/ Testing --- Tested drawing and moving each of the annotation types on a PDF document and on a DVI document. The behavior on the DVI document is unchanged. I find the behavior on the PDF document to be more natural. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114153: An Idea: Render PDF annotations internally while they are being moved
On Nov. 27, 2013, 7:49 p.m., Fabio D'Urso wrote: Rendering differences (that I judged ugly) were the reason why I chose to go the dashed outline route. Yeah, that makes sense. How do you feel about my idea above of only using this approach for the geometric annotations? To my eye the rendering looks almost identical. - Jon --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/#review44612 --- On Nov. 27, 2013, 3:22 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/ --- (Updated Nov. 27, 2013, 3:22 p.m.) Review request for Okular. Repository: okular Description --- Unlike in other document formats, the annotations on PDF documents are rendered by the Poppler back-end along with the document itself. Because this document rendering step is expensive we don't render annotations on PDF documents while the annotations are being moved (With Ctrl+Left click drag). Instead of rendering the annotation itself during the move, we render a dashed outline of the annotation. For non-PDF document types the annotations are rendered by Okular on top of the document, and so there is no large performance penalty in rendering the annotation smoothly as it is moved. I find the aesthetic experience of moving annotations on non-PDF to be much more pleasing. In this small patch updates the paintCroppedPageOnPainter() function draw external annotations using the internal annotation drawing logic while the annotation is being moved. It also removes the dashed annotation outline during the move. With this small change the experience of moving an annotation on a PDF now matches that of moving an annotation on the other document formats. Two small oddities: The rendering of the popup note icon differs between the Poppler back-end and Okular's internal rendering so the icon changes form while being moved and then changes back after being dropped. The rendering of fonts on inline notes between the Poppler back-end and Okular's internal rendering seems to differ in some cases so as you move an inline note the font changes. Thoughts? Diffs - ui/pagepainter.cpp d5d9c3e Diff: http://git.reviewboard.kde.org/r/114153/diff/ Testing --- Tested drawing and moving each of the annotation types on a PDF document and on a DVI document. The behavior on the DVI document is unchanged. I find the behavior on the PDF document to be more natural. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 328029] Have highlighted text show in xml file in docdata directory
https://bugs.kde.org/show_bug.cgi?id=328029 Fabio D'Urso fabiodu...@hotmail.it changed: What|Removed |Added CC||fabiodu...@hotmail.it --- Comment #5 from Fabio D'Urso fabiodu...@hotmail.it --- You can read the coordinates of the highlighted rectangles from the xml file, and use them to extract the corresponding text from the PDF file. I think you can use okular's own API to do that, have a look at Page::text(RegularAreaRect *) (http://api.kde.org/4.x-api/kdegraphics-apidocs/okular/html/classOkular_1_1Page.html#a11ab0f2abe5c1e760c046a33fd5393f3). You can also directly obtain the list of the annotations using okular's API instead of parsing the xml data. -- 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 114153: An Idea: Render PDF annotations internally while they are being moved
On Nov. 27, 2013, 7:49 p.m., Fabio D'Urso wrote: Rendering differences (that I judged ugly) were the reason why I chose to go the dashed outline route. Jon Mease wrote: Yeah, that makes sense. How do you feel about my idea above of only using this approach for the geometric annotations? To my eye the rendering looks almost identical. It works for me. IIRC, however, there are some differences with straight lines having non-null leader lines (ie those optional perpendicular segments at the endings), maybe you can change Okular's rendering to match Poppler's. BTW, the long-term fix I have in mind is to patch Poppler to render annotations separately to different pixmaps than the rest of the page, so we can really paint them on top of the page inexpensively. But this is lots of work and I have no time to do that at the moment :( so yeah, it works for me! :D - Fabio --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/#review44612 --- On Nov. 27, 2013, 3:22 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/ --- (Updated Nov. 27, 2013, 3:22 p.m.) Review request for Okular. Repository: okular Description --- Unlike in other document formats, the annotations on PDF documents are rendered by the Poppler back-end along with the document itself. Because this document rendering step is expensive we don't render annotations on PDF documents while the annotations are being moved (With Ctrl+Left click drag). Instead of rendering the annotation itself during the move, we render a dashed outline of the annotation. For non-PDF document types the annotations are rendered by Okular on top of the document, and so there is no large performance penalty in rendering the annotation smoothly as it is moved. I find the aesthetic experience of moving annotations on non-PDF to be much more pleasing. In this small patch updates the paintCroppedPageOnPainter() function draw external annotations using the internal annotation drawing logic while the annotation is being moved. It also removes the dashed annotation outline during the move. With this small change the experience of moving an annotation on a PDF now matches that of moving an annotation on the other document formats. Two small oddities: The rendering of the popup note icon differs between the Poppler back-end and Okular's internal rendering so the icon changes form while being moved and then changes back after being dropped. The rendering of fonts on inline notes between the Poppler back-end and Okular's internal rendering seems to differ in some cases so as you move an inline note the font changes. Thoughts? Diffs - ui/pagepainter.cpp d5d9c3e Diff: http://git.reviewboard.kde.org/r/114153/diff/ Testing --- Tested drawing and moving each of the annotation types on a PDF document and on a DVI document. The behavior on the DVI document is unchanged. I find the behavior on the PDF document to be more natural. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114153: An Idea: Render PDF annotations internally while they are being moved
On Nov. 27, 2013, 7:49 p.m., Fabio D'Urso wrote: Rendering differences (that I judged ugly) were the reason why I chose to go the dashed outline route. Jon Mease wrote: Yeah, that makes sense. How do you feel about my idea above of only using this approach for the geometric annotations? To my eye the rendering looks almost identical. Fabio D'Urso wrote: It works for me. IIRC, however, there are some differences with straight lines having non-null leader lines (ie those optional perpendicular segments at the endings), maybe you can change Okular's rendering to match Poppler's. BTW, the long-term fix I have in mind is to patch Poppler to render annotations separately to different pixmaps than the rest of the page, so we can really paint them on top of the page inexpensively. But this is lots of work and I have no time to do that at the moment :( so yeah, it works for me! :D Thanks for the feedback. I'll give this a shot and update the patch accordingly. I'll also see if I can generate some annotations with leader lines in Foxit and take a look at Okular's rendering. BTW, the larger project I'm working towards right now is to be able to write on PDFs in Okular with a Wacom tablet and be able to bulk-select words (collections of ink strokes) and move them around like in Xournal. This update will really improve the appearance of this bulk translation of annotations. I like the sound of this Poppler patch, but it certainly does sound like a lot of work. - Jon --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/#review44612 --- On Nov. 27, 2013, 3:22 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/ --- (Updated Nov. 27, 2013, 3:22 p.m.) Review request for Okular. Repository: okular Description --- Unlike in other document formats, the annotations on PDF documents are rendered by the Poppler back-end along with the document itself. Because this document rendering step is expensive we don't render annotations on PDF documents while the annotations are being moved (With Ctrl+Left click drag). Instead of rendering the annotation itself during the move, we render a dashed outline of the annotation. For non-PDF document types the annotations are rendered by Okular on top of the document, and so there is no large performance penalty in rendering the annotation smoothly as it is moved. I find the aesthetic experience of moving annotations on non-PDF to be much more pleasing. In this small patch updates the paintCroppedPageOnPainter() function draw external annotations using the internal annotation drawing logic while the annotation is being moved. It also removes the dashed annotation outline during the move. With this small change the experience of moving an annotation on a PDF now matches that of moving an annotation on the other document formats. Two small oddities: The rendering of the popup note icon differs between the Poppler back-end and Okular's internal rendering so the icon changes form while being moved and then changes back after being dropped. The rendering of fonts on inline notes between the Poppler back-end and Okular's internal rendering seems to differ in some cases so as you move an inline note the font changes. Thoughts? Diffs - ui/pagepainter.cpp d5d9c3e Diff: http://git.reviewboard.kde.org/r/114153/diff/ Testing --- Tested drawing and moving each of the annotation types on a PDF document and on a DVI document. The behavior on the DVI document is unchanged. I find the behavior on the PDF document to be more natural. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 328026] Having the option to paste selected text into an annotation.
https://bugs.kde.org/show_bug.cgi?id=328026 Albert Astals Cid aa...@kde.org changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WONTFIX --- Comment #5 from Albert Astals Cid aa...@kde.org --- Saves 2 steps and increases the number of entries in the menu, every entry you add there you make the menu harder to use because people get lost in what they want to choose from the menu. Personally I don't think your use case is that used that makes sense to add a new entry in the menu. Thanks for your opinion though :-) -- 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 328026] Having the option to paste selected text into an annotation.
https://bugs.kde.org/show_bug.cgi?id=328026 --- Comment #6 from Chris George technat...@gmail.com --- No worries. I was trying to work towards the same goal as Docear, but using the much easier path of extracting the data required from okular's unique xml file. I guess I'll just wait for them to complete their standards based project and use their tools to get the work done. It will be interesting to see which pdf reader they choose to use. Not many of them are cross platform and support the required two way communication. I was considering requesting a keyboard shortcut instead of a menu entry, but okular's unusual method of copying text precludes that. -- 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 113973: Proof of concept magnifying glass found in old kdvi (or current xdvi)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113973/#review44625 --- As said in IRC, i'm not really thrilled about this feature, but on the other hand its quite separate from existing code, so it's not that bad, anyway it has a huge blocker you mention in the form of the hack, so you need to first fix that. ui/magnifierview.cpp http://git.reviewboard.kde.org/r/113973/#comment31851 hardcoded colors are usually bad, there's nothing in KColorScheme you can use? ui/magnifierview.cpp http://git.reviewboard.kde.org/r/113973/#comment31852 this- is quite un-C++-y please remove ui/magnifierview.cpp http://git.reviewboard.kde.org/r/113973/#comment31853 static const int? ui/magnifierview.cpp http://git.reviewboard.kde.org/r/113973/#comment31854 This needs i18n - Albert Astals Cid On Nov. 20, 2013, 5:53 p.m., Michal Humpula wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113973/ --- (Updated Nov. 20, 2013, 5:53 p.m.) Review request for Okular. Repository: okular Description --- I realy missed the magnifying glass feature from the old kdvi, which comes very handy if you are doing typesetting. So I finaly told myself to hack it in and here comes the patch for it. The 01-hack.patch is allowing the document to render big pixmaps for non tiled views. The rest is quite straightforward. The magnifier can scroll the view apropriately, doesn't fall of the edges and hovers correctly from one page to another. So the remaining question is, what is the status of this: core/document_p.h:213 // FIXME This is a hack, we need to support multiple tiled observers, but for the moment we only support one Is someone working on it? Diffs - CMakeLists.txt 217337f conf/okular.kcfg deabd07 ui/magnifierview.h PRE-CREATION ui/magnifierview.cpp PRE-CREATION ui/pageview.h 9c15af6 ui/pageview.cpp 65967bf Diff: http://git.reviewboard.kde.org/r/113973/diff/ Testing --- File Attachments Allow BIG pixmaps http://git.reviewboard.kde.org/media/uploaded/files/2013/11/20/52c4f894-2286-421e-8025-45027d93524e__01-hack.patch Thanks, Michal Humpula ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 328026] Having the option to paste selected text into an annotation.
https://bugs.kde.org/show_bug.cgi?id=328026 --- Comment #7 from Albert Astals Cid aa...@kde.org --- How is our method of copying text unusual? -- 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 114019: [GCI] Extend AudioPlayer so that it gives info about if something is playing at the moment or not.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114019/#review44632 --- This review has been submitted with commit f98f55db9d6dc669e4b49c70baa006fc1801d44d by Albert Astals Cid on behalf of Egor Matirov to branch master. - Commit Hook On Nov. 23, 2013, 5:44 p.m., Egor Matirov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114019/ --- (Updated Nov. 23, 2013, 5:44 p.m.) Review request for Okular. Repository: okular Description --- Extend AudioPlayer so that it gives info about if something is playing at the moment or not according to GCI task: - http://www.google-melange.com/gci/task/view/google/gci2013/5789010593054720 Diffs - core/audioplayer.h 7697562 core/audioplayer.cpp af59588 core/audioplayer_p.h c6d43cf Diff: http://git.reviewboard.kde.org/r/114019/diff/ Testing --- Thanks, Egor Matirov ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114019: [GCI] Extend AudioPlayer so that it gives info about if something is playing at the moment or not.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114019/ --- (Updated Nov. 27, 2013, 10:27 p.m.) Status -- This change has been marked as submitted. Review request for Okular. Repository: okular Description --- Extend AudioPlayer so that it gives info about if something is playing at the moment or not according to GCI task: - http://www.google-melange.com/gci/task/view/google/gci2013/5789010593054720 Diffs - core/audioplayer.h 7697562 core/audioplayer.cpp af59588 core/audioplayer_p.h c6d43cf Diff: http://git.reviewboard.kde.org/r/114019/diff/ Testing --- Thanks, Egor Matirov ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114060: Proposed viewport transition refinements for Find and Undo/Redo actions
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114060/#review44637 --- core/document.h http://git.reviewboard.kde.org/r/114060/#comment31861 const for NormalizedRect? Also since this is just used by core/* stufff do we really to make it public? Can it go to some _p.h? core/document.cpp http://git.reviewboard.kde.org/r/114060/#comment31862 const core/document.cpp http://git.reviewboard.kde.org/r/114060/#comment31863 const core/documentcommands.cpp http://git.reviewboard.kde.org/r/114060/#comment31865 const core/documentcommands.cpp http://git.reviewboard.kde.org/r/114060/#comment31866 const core/utils.h http://git.reviewboard.kde.org/r/114060/#comment31867 Same question as before, since this method seems to be used only in core/* can you see if you can put it in some _p.h so we don't expose it to the rest of the world? - Albert Astals Cid On Nov. 24, 2013, 2:23 a.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114060/ --- (Updated Nov. 24, 2013, 2:23 a.m.) Review request for Okular. Repository: okular Description --- This patch introduces viewport transitions for undo/redo actions on annotations and forms. When an annotation/form action is undone/redone but the associated annotation/form is not currently visible, the viewport is updated to center on the undo/redo action. If the annotation/form is visible, the viewport is not updated. The viewport transitions for the Find action have also been updated to this same algorithm. Previously the viewport was moved to center on each matching search term even if the search term was already visible in the viewport. This lead to unnecessary viewport transitions if the search term matched several items in a single paragraph for example. These proposed changes to the viewport transition behavior are consistent with the find and undo behavior of many existing applications including Kate, Open Office, and Foxit PDF Reader. Diffs - core/document.h fe296e0 core/document.cpp 265ee09 core/documentcommands.cpp 7799bb0 core/documentcommands_p.h fe1c577 core/page.cpp 0bafa99 core/utils.h 8d5d5fc core/utils.cpp 5dd8448 Diff: http://git.reviewboard.kde.org/r/114060/diff/ Testing --- Manual testing of the viewport behavior for find and undo/redo actions on several documents. I also tested that the desired behavior is maintained when documents are rotated. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114153: An Idea: Render PDF annotations internally while they are being moved
On Nov. 27, 2013, 7:49 p.m., Fabio D'Urso wrote: Rendering differences (that I judged ugly) were the reason why I chose to go the dashed outline route. Jon Mease wrote: Yeah, that makes sense. How do you feel about my idea above of only using this approach for the geometric annotations? To my eye the rendering looks almost identical. Fabio D'Urso wrote: It works for me. IIRC, however, there are some differences with straight lines having non-null leader lines (ie those optional perpendicular segments at the endings), maybe you can change Okular's rendering to match Poppler's. BTW, the long-term fix I have in mind is to patch Poppler to render annotations separately to different pixmaps than the rest of the page, so we can really paint them on top of the page inexpensively. But this is lots of work and I have no time to do that at the moment :( so yeah, it works for me! :D Jon Mease wrote: Thanks for the feedback. I'll give this a shot and update the patch accordingly. I'll also see if I can generate some annotations with leader lines in Foxit and take a look at Okular's rendering. BTW, the larger project I'm working towards right now is to be able to write on PDFs in Okular with a Wacom tablet and be able to bulk-select words (collections of ink strokes) and move them around like in Xournal. This update will really improve the appearance of this bulk translation of annotations. I like the sound of this Poppler patch, but it certainly does sound like a lot of work. You don't need FoxIt at all :) Just create a straight line in Okular and set its Leader Line and Leader Line Extension Length properties, then compare Poppler's and PagePainter's renderings. If they look the same, then I was not remembering correctly :P - Fabio --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/#review44612 --- On Nov. 27, 2013, 3:22 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114153/ --- (Updated Nov. 27, 2013, 3:22 p.m.) Review request for Okular. Repository: okular Description --- Unlike in other document formats, the annotations on PDF documents are rendered by the Poppler back-end along with the document itself. Because this document rendering step is expensive we don't render annotations on PDF documents while the annotations are being moved (With Ctrl+Left click drag). Instead of rendering the annotation itself during the move, we render a dashed outline of the annotation. For non-PDF document types the annotations are rendered by Okular on top of the document, and so there is no large performance penalty in rendering the annotation smoothly as it is moved. I find the aesthetic experience of moving annotations on non-PDF to be much more pleasing. In this small patch updates the paintCroppedPageOnPainter() function draw external annotations using the internal annotation drawing logic while the annotation is being moved. It also removes the dashed annotation outline during the move. With this small change the experience of moving an annotation on a PDF now matches that of moving an annotation on the other document formats. Two small oddities: The rendering of the popup note icon differs between the Poppler back-end and Okular's internal rendering so the icon changes form while being moved and then changes back after being dropped. The rendering of fonts on inline notes between the Poppler back-end and Okular's internal rendering seems to differ in some cases so as you move an inline note the font changes. Thoughts? Diffs - ui/pagepainter.cpp d5d9c3e Diff: http://git.reviewboard.kde.org/r/114153/diff/ Testing --- Tested drawing and moving each of the annotation types on a PDF document and on a DVI document. The behavior on the DVI document is unchanged. I find the behavior on the PDF document to be more natural. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 328026] Having the option to paste selected text into an annotation.
https://bugs.kde.org/show_bug.cgi?id=328026 --- Comment #8 from Chris George technat...@gmail.com --- It was the first thing I noticed about the application. The normal procedure in most textual applications, like web browsers, word-processors and text editors is to be able to highlight text with the selection tool and then use the standard Ctrl-C or r-click, copy. Normally when a user releases the mouse button or the shift key when using the keyboard to select text, the selected text just sits there waiting for the next step. It is totally a niche use case, only applicable to maybe a couple million students and researchers around the world, but being able to select text and have it immediately injected into an annotation would be very handy. Having the annotation easily accessible via the xml file, as it currently is, is brilliant for my application. I am trying to put together something that makes sense, the Docear path is too top heavy IMO. They have chosen to build their workflow around a mindmap and have yet to do much work on the authoring side of the equation, I am working with a programmer's outliner and authoring tool. But I am not a programmer. I am a student. I am working through a python course at the moment, but it will be a long time until I am competent enough to write my own pdf parsing utility. I was overjoyed to find okular and have been using it for a couple of years to highlight text, copy it, paste it into a note annotation (then reformatting it to all be on one line instead of several) and access it in the xml file via the outliner when I am writing the paper that I did the research for. I have been keeping my eyes open for opportunities to improve the situation and was looking ahead to when Docear completes their pdf parser. They are mainly there, but it has been a chore trying to find a reader that meets their needs and they have had to write a pretty hefty interface to their app. This will probably allow them to write a filter for okular to get the info out they want, I was looking for a backdoor. I use linux, cross platform is not my priority and I have no problem using the tools at hand to make this work. The outliner is cross platform and so is okular. I am polishing the workflow and trying to make it as smooth and seamless as possible. This is a minor niggle and it probably isn't worth your time. Someday I will find a way capture annotations, highlighted text and bookmarks right from the pdf. Until then I am just happy to have access to the xml file in the docdata directory in order to get the contents of the notes back out of the pdf. I pretty much don't use the highlighter, as the positional information in the xml file does me no good (but the text would) or the bookmarks, as I have no way of jumping to one on opening the pdf via command line. I'll just keep making do for now. Thanks for taking the time. Chris On Wed, Nov 27, 2013 at 2:08 PM, Albert Astals Cid aa...@kde.org wrote: https://bugs.kde.org/show_bug.cgi?id=328026 --- Comment #7 from Albert Astals Cid aa...@kde.org --- How is our method of copying text unusual? -- You are receiving this mail because: You reported the bug. -- 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 328026] Having the option to paste selected text into an annotation.
https://bugs.kde.org/show_bug.cgi?id=328026 --- Comment #9 from Albert Astals Cid aa...@kde.org --- (In reply to comment #8) It was the first thing I noticed about the application. The normal procedure in most textual applications, like web browsers, word-processors and text editors is to be able to highlight text with the selection tool and then use the standard Ctrl-C or r-click, copy. Normally when a user releases the mouse button or the shift key when using the keyboard to select text, the selected text just sits there waiting for the next step. And don't we select text in the same way? -- 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 328026] Having the option to paste selected text into an annotation.
https://bugs.kde.org/show_bug.cgi?id=328026 --- Comment #10 from Chris George technat...@gmail.com --- I cannot select via inserting the cursor between two letters or at the beginning of a sentence and mouse drag or shift-arrow to select the text I want. I must select a block of text, usually including text from the preceding line that I didn't really want and text from beyond the end of the sentence I want as sentences rarely line up with the end of a line. I cannot think of another application that behaves like this. On pasting this text into an editor, or an annotation box, I must also eliminate the line breaks in order to make the text usable in the destination application, which I assume is a function of the block selection method as opposed to the insertion point, drag line by line method. -- 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 114060: Proposed viewport transition refinements for Find and Undo/Redo actions
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114060/ --- (Updated Nov. 28, 2013, 12:47 a.m.) Review request for Okular. Changes --- Updates based on Albert's feedback Repository: okular Description --- This patch introduces viewport transitions for undo/redo actions on annotations and forms. When an annotation/form action is undone/redone but the associated annotation/form is not currently visible, the viewport is updated to center on the undo/redo action. If the annotation/form is visible, the viewport is not updated. The viewport transitions for the Find action have also been updated to this same algorithm. Previously the viewport was moved to center on each matching search term even if the search term was already visible in the viewport. This lead to unnecessary viewport transitions if the search term matched several items in a single paragraph for example. These proposed changes to the viewport transition behavior are consistent with the find and undo behavior of many existing applications including Kate, Open Office, and Foxit PDF Reader. Diffs (updated) - core/document.h fe296e0 core/document.cpp 265ee09 core/document_p.h 3a257de core/documentcommands.cpp 7799bb0 core/documentcommands_p.h fe1c577 core/page.cpp 0bafa99 core/utils.cpp 5dd8448 core/utils_p.h df82fe1 Diff: http://git.reviewboard.kde.org/r/114060/diff/ Testing --- Manual testing of the viewport behavior for find and undo/redo actions on several documents. I also tested that the desired behavior is maintained when documents are rotated. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 114060: Proposed viewport transition refinements for Find and Undo/Redo actions
On Nov. 27, 2013, 11:16 p.m., Albert Astals Cid wrote: core/utils.h, line 78 http://git.reviewboard.kde.org/r/114060/diff/1/?file=219403#file219403line78 Same question as before, since this method seems to be used only in core/* can you see if you can put it in some _p.h so we don't expose it to the rest of the world? Moved to util_p.h On Nov. 27, 2013, 11:16 p.m., Albert Astals Cid wrote: core/document.h, line 728 http://git.reviewboard.kde.org/r/114060/diff/1/?file=219398#file219398line728 const for NormalizedRect? Also since this is just used by core/* stufff do we really to make it public? Can it go to some _p.h? Moved to DocumentPrivate class - Jon --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114060/#review44637 --- On Nov. 28, 2013, 12:47 a.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114060/ --- (Updated Nov. 28, 2013, 12:47 a.m.) Review request for Okular. Repository: okular Description --- This patch introduces viewport transitions for undo/redo actions on annotations and forms. When an annotation/form action is undone/redone but the associated annotation/form is not currently visible, the viewport is updated to center on the undo/redo action. If the annotation/form is visible, the viewport is not updated. The viewport transitions for the Find action have also been updated to this same algorithm. Previously the viewport was moved to center on each matching search term even if the search term was already visible in the viewport. This lead to unnecessary viewport transitions if the search term matched several items in a single paragraph for example. These proposed changes to the viewport transition behavior are consistent with the find and undo behavior of many existing applications including Kate, Open Office, and Foxit PDF Reader. Diffs - core/document.h fe296e0 core/document.cpp 265ee09 core/document_p.h 3a257de core/documentcommands.cpp 7799bb0 core/documentcommands_p.h fe1c577 core/page.cpp 0bafa99 core/utils.cpp 5dd8448 core/utils_p.h df82fe1 Diff: http://git.reviewboard.kde.org/r/114060/diff/ Testing --- Manual testing of the viewport behavior for find and undo/redo actions on several documents. I also tested that the desired behavior is maintained when documents are rotated. Thanks, Jon Mease ___ 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
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112370/ --- (Updated Nov. 28, 2013, 7:35 a.m.) Review request for Okular. Changes --- This new patch will mimic the behavior of Adobe Reader. 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 (updated) - ui/pageview.h 9c15af674e22c2b162fbd330228eb92545cbf805 ui/pageview.cpp 65967bf9399980e89953cce3c6d7145f41155c86 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
