Re: [Okular-devel] Review Request 109627: Outline based selection for annotation elements
On March 21, 2013, 11:22 p.m., Albert Astals Cid wrote: core/area.h, line 28 http://git.reviewboard.kde.org/r/109627/diff/1/?file=120762#file120762line28 Don't think this belongs to area.h to be honest Would you prefer something like this: bool ObjectRect::boundedContains( double x, double y, double xScale, double yScale ) const I don't really use the constant for anything other than that except for the eraser but - if that were to be extended for a configurable brush size - that would need to be changed anyway. On March 21, 2013, 11:22 p.m., Albert Astals Cid wrote: core/area.h, line 82 http://git.reviewboard.kde.org/r/109627/diff/1/?file=120762#file120762line82 don't particulary like the distanceSqr name, but it seems we where already using it, so let it be i guess :D Agreed, but changing this in ObjectRect would break BC :) - Peter --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109627/#review29666 --- On March 23, 2013, 7:52 p.m., Peter Grasch wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109627/ --- (Updated March 23, 2013, 7:52 p.m.) Review request for Okular. Description --- Multiple features in Okular require to determine what object is at a given position. Traditionally, this relied on the bounding boxes of the given object. These do not necessarily correlate with the user would expect (for example, a diagonal line of 1px has a very large bounding box). This patch implementes shape based selection for the following annotation types: Ink, Geometric, Line, Highlight. Other objects default to the old behaviour. Diffs - core/annotations.h 72abdff core/annotations.cpp 49ab5bd core/annotations_p.h 221572d core/area.h 4f63759 core/area.cpp d772fc0 core/page.cpp 1db2763 tests/CMakeLists.txt 6a26b3e tests/annotationstest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/109627/diff/ Testing --- I tested the annotation objects above and a couple of special cases mentioned in the IRC. Thanks, Peter Grasch ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Regarding css in epubs
On Tue, Apr 2, 2013 at 4:17 AM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 1 d'abril de 2013, a les 13:52:27, Jaydeep Solanki va escriure: Hello, I remember Albert, telling me about css being ignored in epub documents, so I had a look into it. I'm not sure if we are adding the stylesheet from external css files to TextDocument. I tried to add it and it seems to work, it has some limitations, but I'm working on it. As said in https://git.reviewboard.kde.org/r/109364/ did you have a look at EpubDocument::loadResource ? Okay, my bad, EpubDocument::loadResource() gets all the css from external files. But I'm not sure, how will we go on fixing this bug, may be you (Albert) can give a hint. Cheers, Jaydeep Cheers, Albert Here http://paste.kde.org/713162/ is something that I tried. Please have a look at it. Cheers, Jaydeep Solanki ___ 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
Re: [Okular-devel] Review Request 107442: Add undo/redo support for annotations
On April 3, 2013, 9:16 p.m., Albert Astals Cid wrote: I was about to commit and then i saw we still have the m_prevAnnotTextCursorPos and m_prevAnnotTextAnchorPos maps. Do we really need them? As far as I can see they only get used to fill the commands for the AnnotWindow, can't we cache old those values to feed the command in AnnotWindow itself? Jon Mease wrote: Do you mean have the annotWindow keep track of its own previous cursor and anchor positions and then pass them in as arguments along with the annotation's new contents? If so I believe I already implemented this approach in a previous version of the patch so it won't be hard to dig it back up again. Thanks Yes, sorry if I made you go back and forth, but the less things we have as caches in document the better, they will get rotten eventually. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107442/#review30337 --- On March 27, 2013, 12:10 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107442/ --- (Updated March 27, 2013, 12:10 p.m.) Review request for Okular. Description --- This patch adds undo/redo support to Okular's annotation manipulation commands. Functionality: The following actions can be undone and redone: creation and removal of annotations, editing arbitrary annotation properties, relocating annotations with Ctrl+drag, and editing the text contents of an annotation. This patch does not include support for undoing and redoing editing actions on forms. This addresses bug 177501. http://bugs.kde.org/show_bug.cgi?id=177501 Diffs - core/annotations.h 72abdff core/annotations.cpp 49ab5bd core/annotations_p.h 221572d core/document.h 6ff6536 core/document.cpp 5ab759e core/document_p.h fb3aec6 core/page.cpp 1db2763 part.rc 39c1571 ui/annotationpropertiesdialog.cpp 4b02258 ui/annotwindow.h f7df9f6 ui/annotwindow.cpp c1bafb9 ui/guiutils.h 2ae4ab3 ui/guiutils.cpp 1d67d3a ui/pageview.cpp b018dfe Diff: http://git.reviewboard.kde.org/r/107442/diff/ Testing --- I have tested the undoing and redoing of the specified annotation actions using .dvi and .pdf documents. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 317824] New: Highlight color of search term is overlapping with annotation
https://bugs.kde.org/show_bug.cgi?id=317824 Bug ID: 317824 Summary: Highlight color of search term is overlapping with annotation Classification: Unclassified Product: okular Version: 0.15.5 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-devel@kde.org Reporter: jianl...@ntu.edu.tw Since the highlight colors of search term and annotation (with yello highlighter) are identical, I couldn't find the search result on an annotated document. 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
Re: [Okular-devel] Review Request 107442: Add undo/redo support for annotations
On April 3, 2013, 9:16 p.m., Albert Astals Cid wrote: I was about to commit and then i saw we still have the m_prevAnnotTextCursorPos and m_prevAnnotTextAnchorPos maps. Do we really need them? As far as I can see they only get used to fill the commands for the AnnotWindow, can't we cache old those values to feed the command in AnnotWindow itself? Jon Mease wrote: Do you mean have the annotWindow keep track of its own previous cursor and anchor positions and then pass them in as arguments along with the annotation's new contents? If so I believe I already implemented this approach in a previous version of the patch so it won't be hard to dig it back up again. Thanks Albert Astals Cid wrote: Yes, sorry if I made you go back and forth, but the less things we have as caches in document the better, they will get rotten eventually. No problem, I'll make the update in a day or two. - Jon --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107442/#review30337 --- On March 27, 2013, 12:10 p.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107442/ --- (Updated March 27, 2013, 12:10 p.m.) Review request for Okular. Description --- This patch adds undo/redo support to Okular's annotation manipulation commands. Functionality: The following actions can be undone and redone: creation and removal of annotations, editing arbitrary annotation properties, relocating annotations with Ctrl+drag, and editing the text contents of an annotation. This patch does not include support for undoing and redoing editing actions on forms. This addresses bug 177501. http://bugs.kde.org/show_bug.cgi?id=177501 Diffs - core/annotations.h 72abdff core/annotations.cpp 49ab5bd core/annotations_p.h 221572d core/document.h 6ff6536 core/document.cpp 5ab759e core/document_p.h fb3aec6 core/page.cpp 1db2763 part.rc 39c1571 ui/annotationpropertiesdialog.cpp 4b02258 ui/annotwindow.h f7df9f6 ui/annotwindow.cpp c1bafb9 ui/guiutils.h 2ae4ab3 ui/guiutils.cpp 1d67d3a ui/pageview.cpp b018dfe Diff: http://git.reviewboard.kde.org/r/107442/diff/ Testing --- I have tested the undoing and redoing of the specified annotation actions using .dvi and .pdf documents. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 317824] Highlight color of search term is overlapping with annotation
https://bugs.kde.org/show_bug.cgi?id=317824 Albert Astals Cid aa...@kde.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||aa...@kde.org Resolution|--- |DUPLICATE --- Comment #1 from Albert Astals Cid aa...@kde.org --- *** This bug has been marked as a duplicate of bug 273968 *** -- 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 273968] Usability: change highlight color for text search and/or annotation
https://bugs.kde.org/show_bug.cgi?id=273968 Albert Astals Cid aa...@kde.org changed: What|Removed |Added CC||jianl...@ntu.edu.tw --- Comment #4 from Albert Astals Cid aa...@kde.org --- *** Bug 317824 has been marked as a duplicate of this 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 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 --- Comment #14 from Albert Astals Cid aa...@kde.org --- Oh no, 0.22 works too, i just created it with 0.23 because it was what i had installed, let me attach one created with 0.22 -- 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 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 --- Comment #15 from Albert Astals Cid aa...@kde.org --- Created attachment 78638 -- https://bugs.kde.org/attachment.cgi?id=78638action=edit Filled file with poppler 0.22 -- 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 106761: Use libffmpegthumbnailer to create first-frame images in SnapshotTaker
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106761/#review30385 --- Tobias are you still interested in implementing this? If no answer comes in a month I'll discard the review. - Albert Astals Cid On Oct. 8, 2012, 8:48 a.m., Tobias Koenig wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106761/ --- (Updated Oct. 8, 2012, 8:48 a.m.) Review request for Okular. Description --- In the old implementation the Phonon::VideoWidget::snapshot() method was used to create the first-frame (poster) images for a movie, however the Phonon API and the backends (gstreamer and vlc) provide no reliable way to take the snapshot of the first frame. For this reason this patch adds an additional option to use the libffmpegthumbnailer library to take the snapshot of the first frame. It is faster than using the VideoWidget::snapshot() method and always returns the requested frame. Diffs - ui/CMakeLists.txt b80c447 ui/config-snapshot-method.h.cmake PRE-CREATION ui/snapshottaker.h e34c3e0 ui/snapshottaker.cpp 362d249 CMakeLists.txt a057e82 cmake/modules/FindFfmpegThumbnailer.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/106761/diff/ Testing --- Thanks, Tobias Koenig ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 109041: Change search highlight color
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109041/#review30386 --- No comments? Shall I just discard the review until we agree on a solution? - Albert Astals Cid On Feb. 19, 2013, 12:45 p.m., Jaydeep Solanki wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109041/ --- (Updated Feb. 19, 2013, 12:45 p.m.) Review request for Okular. Description --- change search highlight color, as the annotation highlight color is the same which makes it difficult to differentiate between them. This addresses bug 273968. http://bugs.kde.org/show_bug.cgi?id=273968 Diffs - ui/findbar.cpp f00f883 ui/presentationsearchbar.cpp 68c0128 Diff: http://git.reviewboard.kde.org/r/109041/diff/ Testing --- Thanks, Jaydeep Solanki ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 109021: Font selector for TextDocumentGenerator
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109021/#review30393 --- Azat you still interested in working on this? - Albert Astals Cid On Feb. 23, 2013, 11:56 a.m., Azat Khuzhin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109021/ --- (Updated Feb. 23, 2013, 11:56 a.m.) Review request for Okular, Albert Astals Cid and Eike Hein. Description --- Development history: https://github.com/azat/okular/compare/master...font-selector-for-plain-text-formats Link to thread from mailing list: http://comments.gmane.org/gmane.comp.kde.devel.okular/13279 Diffs - conf/dlggeneralbase.ui f2c9efd conf/okular_core.kcfg 054b5c1 core/textdocumentgenerator.h dd75c5c core/textdocumentgenerator.cpp f370ded core/textdocumentgenerator_p.h 749d6f2 Diff: http://git.reviewboard.kde.org/r/109021/diff/ Testing --- Tested manually Thanks, Azat Khuzhin ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 109021: Font selector for TextDocumentGenerator
On April 4, 2013, 6:19 p.m., Albert Astals Cid wrote: Azat you still interested in working on this? Yes, I will try to look at this weekend. I don't have enough time for this at weekdays. - Azat --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109021/#review30393 --- On Feb. 23, 2013, 11:56 a.m., Azat Khuzhin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109021/ --- (Updated Feb. 23, 2013, 11:56 a.m.) Review request for Okular, Albert Astals Cid and Eike Hein. Description --- Development history: https://github.com/azat/okular/compare/master...font-selector-for-plain-text-formats Link to thread from mailing list: http://comments.gmane.org/gmane.comp.kde.devel.okular/13279 Diffs - conf/dlggeneralbase.ui f2c9efd conf/okular_core.kcfg 054b5c1 core/textdocumentgenerator.h dd75c5c core/textdocumentgenerator.cpp f370ded core/textdocumentgenerator_p.h 749d6f2 Diff: http://git.reviewboard.kde.org/r/109021/diff/ Testing --- Tested manually Thanks, Azat Khuzhin ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 --- Comment #16 from Marcus Furlong furlo...@gmail.com --- The must be something different in our environments then. I'm using opensuse 12.3, okular 0.16.0 on KDE 4.10.0. Is there a compile-time option to enable this in poppler or okular? I downloaded your second attachment and I can see the form data you have entered. I add my own form data and save, and when I close okular and reopen the same file, the text is there. But my text is saved externally. If I do the following, the form data reverts to your text mv morsa.pdf morsa1.pdf okular morsa1.pdf and the form data I had saved is only visible in .kde4/share/apps/okular/docdata/107650.morsa.pdf.xml -- 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 107442: Add undo/redo support for annotations
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107442/ --- (Updated April 5, 2013, 12:29 a.m.) Review request for Okular. Changes --- I have removed the QMaps from Document that were used to cache the previous cursor and anchor positions for the contents of all annotations. This responsibility now lies with the annotWindow class. Document::editPageAnnotationContentsOrCursor has been renamed to Document::editPageAnnotationContents as it should now only be called if the contents themselves have changed. The previous cursor and anchor positions have been added to this method signature. I also made a few small updates to EditTextCommand to prevent consecutive edits involving the insertion or deletiion newlines from being merged together into a single undo command. This is to be consistent with the undo behavior of other text editors like Kate. Description --- This patch adds undo/redo support to Okular's annotation manipulation commands. Functionality: The following actions can be undone and redone: creation and removal of annotations, editing arbitrary annotation properties, relocating annotations with Ctrl+drag, and editing the text contents of an annotation. This patch does not include support for undoing and redoing editing actions on forms. This addresses bug 177501. http://bugs.kde.org/show_bug.cgi?id=177501 Diffs (updated) - core/annotations.h 72abdff core/annotations.cpp 49ab5bd core/annotations_p.h 221572d core/document.h 6ff6536 core/document.cpp 5ab759e core/document_p.h fb3aec6 core/page.cpp 1db2763 part.rc 39c1571 ui/annotationpropertiesdialog.cpp 4b02258 ui/annotwindow.h f7df9f6 ui/annotwindow.cpp c1bafb9 ui/guiutils.h 2ae4ab3 ui/guiutils.cpp 1d67d3a ui/pageview.cpp b018dfe Diff: http://git.reviewboard.kde.org/r/107442/diff/ Testing --- I have tested the undoing and redoing of the specified annotation actions using .dvi and .pdf documents. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 317856] New: [okular] saves opened file metadata in ~/.kde/share/apps/okular/docdata/ which can leak info, use hash instead
https://bugs.kde.org/show_bug.cgi?id=317856 Bug ID: 317856 Summary: [okular] saves opened file metadata in ~/.kde/share/apps/okular/docdata/ which can leak info, use hash instead Classification: Unclassified Product: okular Version: 0.16.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: markota...@gmail.com okular save information aboud _ever opened_ files in a folder (~/.kde/share/apps/okular/docdata/) where files are described as some number.filename.pdf.xml For security reasons I suggest using a hash of a file name instead. This leads to better privacy (not ultimate, of course) if someone wanted to check what the user has read. Thoughts: 1/ include absolute path in the name hash, so a/my.pdf and b/my.pdf are treated differently - its a question if such a behavior is a bug, or a feature. 2/ include size in bytes in name-hash, so different files named the same are handeled. 2.1/ what about comments to file, filled in form fields - do they change file size? (pdf) Thanks for consideration. Cheers, mark 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 317856] [okular] saves opened file metadata in ~/.kde/share/apps/okular/docdata/ which can leak info, use hash instead
https://bugs.kde.org/show_bug.cgi?id=317856 Fabio D'Urso fabiodu...@hotmail.it changed: What|Removed |Added CC||fabiodu...@hotmail.it --- Comment #1 from Fabio D'Urso fabiodu...@hotmail.it --- (In reply to comment #0) 2/ include size in bytes in name-hash, so different files named the same are handeled. some number is the size in bytes 2.1/ what about comments to file, filled in form fields - do they change file size? (pdf) If you save them through save as they do; if you just let okular autosave on close into the docdata folder they don't, because the original file is left untouched my two cents.. :) -- 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 162219] RFE: adjust view to the position where you clicked into the thumbnail
https://bugs.kde.org/show_bug.cgi?id=162219 alvaro alvaro@gmail.com changed: What|Removed |Added CC||alvaro@gmail.com --- Comment #1 from alvaro alvaro@gmail.com --- i see the same behavior on Okular 0.15.4, on linux arch. on continuous page mode, with fill-width zoom, when a click is done on a thumbnail, the shown page is in the middle, i.e. 2 pages are shown at half each one. it is really annoying. -- 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
