[okular] [Bug 449690] Add a ‘Fit Content Width’ zoom level
https://bugs.kde.org/show_bug.cgi?id=449690 Thomas Fischer changed: What|Removed |Added CC||fisc...@unix-ag.uni-kl.de --- Comment #1 from Thomas Fischer --- I second his feature request. In addition to ‘Fit Content Width’, there should be a ‘Fit Page’s Content’ as well. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 438250] New: Transparent support for "PDF portfolios"
https://bugs.kde.org/show_bug.cgi?id=438250 Bug ID: 438250 Summary: Transparent support for "PDF portfolios" Product: okular Version: 21.04.1 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-devel@kde.org Reporter: fisc...@unix-ag.uni-kl.de Target Milestone: --- I have encountered PDF files that, when being opened in Okular, only show a large logo from Adobe and the text "For the best experience, open this PDF portfolio in Acrobat X or Adobe Reader X, or later." and below that a button-like image labeled "Get Adobe Reader Now!". The button is a link to Adobe's webpage. Okluar also notifies in a blue box above that this PDF file contains embedded files. The embedded files are one or several PDF files that can be viewed or saved in the list in window "Embedded Files". So, the technical support for "PDF portfolios" is there as a portfolio seems to be a regular PDF file only containing a scary image of "don't use third-party PDF viewers" plus a few attached regular PDF files. However, it is made to trick users into believing that Okular does not support such portfolios as the attachment notification is easy to miss in such a situation. A better way to handle such a situation for Okular would be: - if it is just one embedded PDF file, then immediately discard the "outer" PDF with the scary warning and show the embedded one only. Notify about this redirection via a non-intrusive notification like the one for the embedded files. - if several PDF files are embedded, show a concatenated version of the in the main viewer so that it looks like one PDF file. Still, never show the scary image, but show the "This document has embedded files" notification to allow retrieving the embedded PDF files individually. Example PDF file are easy to find by just searching the Internet for the scary text message. One example is: https://www.irs.gov/pub/irs-prior/f7200--2021.pdf (which is probably legal to use and archive as being a US government document). -- You are receiving this mail because: You are the assignee for the bug.
[Okular-devel] [okular] [Bug 360603] New: Markdown (.md) support
https://bugs.kde.org/show_bug.cgi?id=360603 Bug ID: 360603 Summary: Markdown (.md) support Product: okular Version: unspecified Platform: unspecified URL: https://en.wikipedia.org/wiki/Markdown OS: All Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: New backend wishes Assignee: okular-devel@kde.org Reporter: fisc...@unix-ag.uni-kl.de From Wikipedia: "Markdown is a lightweight markup language with plain text formatting syntax designed so that it can be converted to HTML and many other formats using a tool by the same name. Markdown is often used to format readme files, for writing messages in online discussion forums, and to create rich text using a plain text editor." Relevance: Markdown is getting increasingly popular, especially in Web-base/supported development such as done on Github. Code: Numerous libraries to convert Markdown into other formats like HTML. As an example how Markdown is rendered in a Qt application, please see CuteMarkEd (https://github.com/cloose/CuteMarkEd). Implementation: In KDE4 times, I would have suggested a KPart which makes use of an existing third-party library for the Markdown-to-HTML process and then rendering the result in a KHTML part (or just QTextDocument). However, as Konqueror for KF5 doesn't seem to happen, Okular is the next best choice as a viewer. 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 359555] New: Scalable Vector Graphics (SVG) support
https://bugs.kde.org/show_bug.cgi?id=359555 Bug ID: 359555 Summary: Scalable Vector Graphics (SVG) support Product: okular Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: New backend wishes Assignee: okular-devel@kde.org Reporter: fisc...@unix-ag.uni-kl.de Back in the KDE4 days, there was a SVG rendering KPart that allowed viewing SVG files (Scalable Vector Graphics) from within Konqueror. Said SVG KPart seems to be dead now, the latest code commit is from 2011. My proposal is to scrap whatever code is useful (it relies most likely on Qt's QSvgRenderer class) and build a backend for Okular. I would even assume that parts of the PDF renderer can be re-used, as a SVG graphics (apart from animations that I personally see as non-essential) is in many aspects like a single-page PDF file. 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 356127] New: "Save as" dialog for "Save copy as": path editing widget and list widget out of sync
https://bugs.kde.org/show_bug.cgi?id=356127 Bug ID: 356127 Summary: "Save as" dialog for "Save copy as": path editing widget and list widget out of sync Product: okular Version: unspecified Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: fisc...@unix-ag.uni-kl.de After a successful "Save copy as" operation, the next save copy as operation will re-use the previous target directory as its base directory in the "save as" dialog in the 'directory' path editing widget. The list widget below, supposed to show the content of this directory (files contained) still shows the current PDF file's directory's location Reproducible: Always Steps to Reproduce: 1. Create temporary directories /tmp/A and /tmp/B 2. Create example PDF files /tmp/A/a.pdf and /tmp/A/b.pdf 3. Open /tmp/A/a.pdf in Okular 4. "Save Copy as" this file as /tmp/B/a.pdf 5. Issue "Save Copy as" a second time to get a "Save as" dialog again. Observe that the path editing widget shows "/tmp/B" (last location of a successful "save copy as" operation), whereas the file list widget below shows the content of "/tmp/A" (the current location of the currently open directory), as you will see both a.pdf and b.pdf (the latter does not exist in /tmp/B). -- 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 356127] "Save as" dialog for "Save copy as": path editing widget and list widget out of sync
https://bugs.kde.org/show_bug.cgi?id=356127 --- Comment #1 from Thomas Fischer <fisc...@unix-ag.uni-kl.de> --- When reporting this bug in KDE's Bugzilla, version 1.0.0 was not in the list of available versions. This should be fixed as well. I am using Okular 1.0.0 on KDE Frameworks 5.16.0 using Qt 5.5.1 on X11/xcb. -- 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 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/ --- (Updated Jan. 22, 2014, 8:39 p.m.) Review request for Okular. Changes --- Patch uses a class derived from KJob to encapsulate potentially long-running calls to pdftocairo. Code compiles and starts, but when opening a .pdf file, Okular crashes with the following output on the command line (program was installed in /tmp/kde-usr): ASSERT failure in QWidget: Widgets must be created in the GUI thread., file kernel/qwidget.cpp, line 1301 KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = okular path = /tmp/kde-usr/bin pid = 14074 KCrash: Arguments: /tmp/kde-usr/bin/okular --nocrashhandler /home/tf/test.pdf KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit sock_file=/home/tf/.kde4/socket-corvus/kdeinit4__0 okular: Fatal IO error: client killed Repository: 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 (updated) - core/document.h fe296e0 core/document.cpp 19eaa70 core/generator.h 19c81d5 core/generator.cpp 23b274b generators/poppler/generator_pdf.h eb91f66 generators/poppler/generator_pdf.cpp f08a571 ui/pageview.cpp 65967bf Diff: https://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 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
On Jan. 13, 2014, 10:48 p.m., Albert Astals Cid wrote: ui/minibar.h, line 130 https://git.reviewboard.kde.org/r/111410/diff/9/?file=233890#file233890line130 I'd appreciate if you did not revert my code. Sorry, that must have been an accidential change. I must have made the patch based on some older master code. I just removed the lines changing minibar and will upload a new patch. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/#review47351 --- On Jan. 12, 2014, 10:46 p.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/ --- (Updated Jan. 12, 2014, 10:46 p.m.) Review request for Okular. Repository: 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 fa6345f core/generator.h 3cf40c2 core/generator.cpp 41beb92 generators/poppler/generator_pdf.h 5d5853a generators/poppler/generator_pdf.cpp 839a324 ui/minibar.h 5654ad8 ui/minibar.cpp 6a501b8 ui/pageview.cpp 65967bf Diff: https://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 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/ --- (Updated Jan. 14, 2014, 10:46 a.m.) Review request for Okular. Changes --- Removing patch lines that affect minibar. Repository: 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 (updated) - core/document.h fe296e0 core/document.cpp fa6345f core/generator.h 3cf40c2 core/generator.cpp 41beb92 generators/poppler/generator_pdf.h 5d5853a generators/poppler/generator_pdf.cpp 839a324 ui/pageview.cpp 65967bf Diff: https://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
[Okular-devel] vtable error [Was: Re: Review Request 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo]
Hello, No, I am building on a RAM disk, empty build directory. No moc files in sources, just checked. Do you get the same error with my patch? This information would allow me to better trace back this error... Bye, Thomas Thomas Fischer wrote: I will upload a new patch soon. It should address the three issues, except for that I have problems linking the code (undefined reference to `vtable for PDFGenerator'). Maybe you can see what the problem is ... You usually get that where some .moc problem is happening. Make sure you have a clean build. signature.asc Description: OpenPGP digital signature ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
On Oct. 15, 2013, 12:33 a.m., Albert Astals Cid wrote: generators/poppler/generator_pdf.cpp, line 1538 https://git.reviewboard.kde.org/r/111410/diff/8/?file=185148#file185148line1538 This needs to be made async, this will potentiall freeze the UI for a while depending on what we ask pdftocairo to do. That obviously means you can't return a bool, but should probably return something like a KJob. Yes, i know the old export doesn't do that, but the fact that we did it wrong before is not an excuse for doing it wrong now :-) I will upload a new patch soon. It should address the three issues, except for that I have problems linking the code (undefined reference to `vtable for PDFGenerator'). Maybe you can see what the problem is ... - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/#review41759 --- On Aug. 27, 2013, 10:11 p.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/ --- (Updated Aug. 27, 2013, 10:11 p.m.) Review request for Okular. Repository: 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: https://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 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/ --- (Updated Jan. 12, 2014, 10:46 p.m.) Review request for Okular. Changes --- New patch, addresses the comments up to the introduction of KJob as a return value for exportPageRangeTo and exportSinglePageRegionTo. The code compiles, but linking fails with some cryptic vtable error. Repository: 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 (updated) - core/document.h fe296e0 core/document.cpp fa6345f core/generator.h 3cf40c2 core/generator.cpp 41beb92 generators/poppler/generator_pdf.h 5d5853a generators/poppler/generator_pdf.cpp 839a324 ui/minibar.h 5654ad8 ui/minibar.cpp 6a501b8 ui/pageview.cpp 65967bf Diff: https://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 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
On Dec. 29, 2013, 8:49 p.m., Albert Astals Cid wrote: Thomas, did you see my comments? Are you planning to keep working on this? I had started to work on this a few months ago, hit some issues, got occupied with other things, forgot about it. Maybe I can resume during the weekend... - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/#review46409 --- On Aug. 27, 2013, 10:11 p.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/111410/ --- (Updated Aug. 27, 2013, 10:11 p.m.) Review request for Okular. Repository: 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: https://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 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/ --- (Updated Aug. 27, 2013, 8:11 p.m.) Review request for Okular. Changes --- Addressing aacid's comments on diff revision #7 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 (updated) - 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 110003: Best-fit zoom
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/ --- (Updated Aug. 17, 2013, 8:24 p.m.) Review request for Okular. Changes --- Addressing Albert Astals Cid's recent comments on constness, version numbers, and documentation (handbook). Description --- Attached patch implements best-fit zoom for Okular. It is a refined version of the patch submitted in bug report 249364, attachment 51069. The refinement addresses the scrollbar issues as observed in continuous view mode. This addresses bug 249364. http://bugs.kde.org/show_bug.cgi?id=249364 Diffs (updated) - conf/dlggeneralbase.ui f2c9efd conf/okular.kcfg 1e23d61 doc/index.docbook 432aee2 part.rc 64aeffb ui/pageview.h 5484cc5 ui/pageview.cpp 5944072 Diff: http://git.reviewboard.kde.org/r/110003/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 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
On Aug. 16, 2013, 10:18 p.m., Albert Astals Cid wrote: core/generator.h, line 395 http://git.reviewboard.kde.org/r/111410/diff/6/?file=181596#file181596line395 Why are these not const anymore? Constructing an instance of QProcess to run pdftocairo requires passing a non-const QObject pointer and this is used. I changed it to creating the instance without a parent. - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111410/#review38002 --- On Aug. 16, 2013, 9:17 p.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111410/ --- (Updated Aug. 16, 2013, 9:17 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 5944072 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 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/ --- (Updated Aug. 17, 2013, 9:11 p.m.) Review request for Okular. Changes --- Addressing recent comments: re-introducing const-ness, making search for pdftocairo binary lazy, ... 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 (updated) - 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 5944072 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 110003: Best-fit zoom
On Aug. 14, 2013, 9:55 p.m., Albert Astals Cid wrote: Second, I am trying to add Auto Fit as one of the default zoom settings in the configuration dialog. Although I was quite sure I did not miss a spot and the option turns up in the settings dialog, choosing Auto Fit does not get activated when restarting Okular. Any hints what goes wrong? You aware this setting only applies for files you've never opened? Is this your problem? Indeed. I tested it with another file I had never opened before and AutoFit was active as expected. So, is there anything left or is my patch good to be accepted? - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/#review37805 --- On July 7, 2013, 11:04 p.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/ --- (Updated July 7, 2013, 11:04 p.m.) Review request for Okular. Description --- Attached patch implements best-fit zoom for Okular. It is a refined version of the patch submitted in bug report 249364, attachment 51069. The refinement addresses the scrollbar issues as observed in continuous view mode. This addresses bug 249364. http://bugs.kde.org/show_bug.cgi?id=249364 Diffs - conf/dlggeneralbase.ui f2c9efd conf/okular.kcfg 1e23d61 part.rc 64aeffb ui/pageview.h 5484cc5 ui/pageview.cpp 16b00ab Diff: http://git.reviewboard.kde.org/r/110003/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 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/ --- (Updated Aug. 16, 2013, 9:17 p.m.) Review request for Okular. Changes --- Updating the patch according to the comments by Albert Astals Cid. 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 (updated) - 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 5944072 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 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/ --- (Updated July 23, 2013, 9:24 p.m.) Review request for Okular. Changes --- This patch refactors the export to be inside the generators. The dialog to cancel does not yet exist. This new implementation hooks into the existing selection extract menu actions and uses the generator instead of the existing general implemenation when possible as the generator-based implemenation may offer more features (more file formats or higher resolutions). 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 (updated) - core/document.h fe296e0 core/document.cpp 6731d87 core/generator.h a5a971b core/generator.cpp 41beb92 generators/poppler/generator_pdf.h 5d5853a generators/poppler/generator_pdf.cpp 122ece5 ui/pageview.cpp 16b00ab 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 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/ --- (Updated July 23, 2013, 9:26 p.m.) Review request for Okular. Changes --- Previous upload had wrong diff. Hopefully more luck this time... 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 (updated) - core/document.h fe296e0 core/document.cpp 6731d87 core/generator.h a5a971b core/generator.cpp 41beb92 generators/poppler/generator_pdf.h 5d5853a generators/poppler/generator_pdf.cpp 122ece5 ui/pageview.cpp 16b00ab 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 111410: Selection tool: copy/extract as vector graphic by calling pdftocairo
On July 7, 2013, 10:31 p.m., Albert Astals Cid wrote: The location of the code in pageview.cpp is therefore justified as the image and text extract code is located in the same class. However, I agree that pageview.cpp is rather large and should be refactored. That is not true, the the extraction of images and text is properly abstracted in the generator class and each file-type backend implements it in its own, or do you see the code that handles pdf text extraction in pageview.cpp? Albert Astals Cid wrote: So at Akademy we did a BoF about Okular, the decision about this feature was: * It is acceptable to call pdftocairo * The current way of organizing the code is not acceptable, it needs to be a generator supported feature, i.e. there needs to be API in generators so that they can say if they support this feature or not and if they do the code has to be in the generator side * The one second time limit needs to be removed and instead a dialog saying Exporting with a cancel button in case the process decides to run forever Do you think you can work in these improvements? Any question on how to proceed? I agree that the current code isn't really well-integrated. I will look into how to refactor the code to follow the generator structure. The exporting dialog can be added in a second step. I haven't looked into the details yet, but I'll contact you if I have problems. - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111410/#review35702 --- On July 7, 2013, 10:22 p.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111410/ --- (Updated July 7, 2013, 10:22 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 - ui/pageview.cpp 16b00ab 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 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/ --- (Updated July 7, 2013, 10:22 p.m.) Review request for Okular. Changes --- it's not in the correct place, why is all this exporting functionality in pageview.cpp? If at all this should be integrated with the File-Export functionality and not be coded in pageview.cpp but in the proper appropiate backend This is a misunderstanding. My code does not export whole pages (which File-Export implies and what pdftocairo supports, too), but only the user's selection just like the existing text and image extraction. I made some screenshots which should clarify the situation: http://imgur.com/iHxAws1,Vgjbb5l,VavhqMv (img #1: new context menu when selecting a region of a PDF page; img #2: bitmap as extract with the current Image solution; img #3: PDF file extract using the Vector option, opened in Okular) The location of the code in pageview.cpp is therefore justified as the image and text extract code is located in the same class. However, I agree that pageview.cpp is rather large and should be refactored. Having a vector graphic extract is an serious feature. As my screenshots document, if you want to extract a tiny piece of a PDF file, the existing bitmap feature gives you an image of the size as you see it. Inserting such bitmaps in other documents or slides results in badly scaled images. Obviously, a vector graphic does not suffer from this problem. I don't think calling an external tool is a good idea, but it is true it's the only easy way to provide the functionality Indeed. As pdftocairo's code is Gtk-based, inserting it into Okular may cause problems on its own. The best solution I would see is if the Qt4 backend would support this feature or if a solution using QPrinter-to-PDF would work. I could investigate those two options, but only if there is a realistic chance that the result will be included in 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 (updated) - ui/pageview.cpp 16b00ab 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 110003: Best-fit zoom
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/ --- (Updated July 7, 2013, 11:04 p.m.) Review request for Okular. Changes --- The patch reflects two changes based on comments in the Forum. First, it renames the feature to auto fit which a majority of comments support as a better name than best fit. Second, I am trying to add Auto Fit as one of the default zoom settings in the configuration dialog. Although I was quite sure I did not miss a spot and the option turns up in the settings dialog, choosing Auto Fit does not get activated when restarting Okular. Any hints what goes wrong? Description --- Attached patch implements best-fit zoom for Okular. It is a refined version of the patch submitted in bug report 249364, attachment 51069. The refinement addresses the scrollbar issues as observed in continuous view mode. This addresses bug 249364. http://bugs.kde.org/show_bug.cgi?id=249364 Diffs (updated) - conf/dlggeneralbase.ui f2c9efd conf/okular.kcfg 1e23d61 part.rc 64aeffb ui/pageview.h 5484cc5 ui/pageview.cpp 16b00ab Diff: http://git.reviewboard.kde.org/r/110003/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 110003: Best-fit zoom
On April 14, 2013, 10:07 p.m., Albert Astals Cid wrote: Can you please describe your best fit algorithm? I am finding that in my 1920x1080 resolution best fit is giving me a Fit to width while in evince i get a Fit to page that may actually make more sense since i am seeing more info in that Fit to page than in this Fit to width and i can still read it. Thomas Fischer wrote: My best-fit code switches between three zoom types depending on the relation of aspect ratio of Okular's area to show content and the aspect ratio of the shown page. Depending on this relation, it assumes that one of the following three cases is true: (1) Both ratios are very similar, e.g. when you are looking on landscape-oriented PDF slides in a maximized Okular window (4:3 aspect ratio). Fit-page is the best viewing mode here. (2) You have have a wide Okular window (e.g. maximize on a wide screen) viewing a portrait-oriented A4 document such as a letter. If you eye sight and your screen is good, you can still read it, but don't assume everyone else can. So a better choice may be to fit-width zoom the page, even if only a small section is visible, but at least the text should be readable. (3) You have a split-screen Okular window (e.g. right or left half of your screen), but you are looking at a landscape-oriented document. Again, it may be a better choice to fit-height zoom your document than to fit-page zoom it if you want to read the fineprint. On extreme cases, best-fit may zoom in a way that the document becomes even hard to read, but in most cases it has its benefits being a good approximation for typical use-cases (in my personal view). Albert Astals Cid wrote: Do you think you could take a few screenshots of the various scenarios with various kind of document formats in both okular+your patch and evince and post them to forums.kde.org so that people can comment (even the forums have poll support IIRC) which of the two Best Fit algorithms they like more? If we're going to do a Best Fit, lets make sure it's Best Fit by all people's opinion and not just based or your or my personal view. Wrote a posting in KDE Forum: http://forum.kde.org/viewtopic.php?f=251t=111777 - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/#review31033 --- On April 14, 2013, 11:26 a.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/ --- (Updated April 14, 2013, 11:26 a.m.) Review request for Okular. Description --- Attached patch implements best-fit zoom for Okular. It is a refined version of the patch submitted in bug report 249364, attachment 51069. The refinement addresses the scrollbar issues as observed in continuous view mode. This addresses bug 249364. http://bugs.kde.org/show_bug.cgi?id=249364 Diffs - part.rc 64aeffb ui/pageview.h 5e839f2 ui/pageview.cpp 6e093ef Diff: http://git.reviewboard.kde.org/r/110003/diff/ Testing --- Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 321350] New: Selection tool: copy/extract as vector graphic
https://bugs.kde.org/show_bug.cgi?id=321350 Bug ID: 321350 Summary: Selection tool: copy/extract as vector graphic Classification: Unclassified Product: okular Version: 0.16.4 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: PDF backend Assignee: okular-devel@kde.org Reporter: fisc...@unix-ag.uni-kl.de Currently, the selection tool of Okular allows to extract a region of a document as text or as a pixmap (same resolution as shown on screen). This solution is not satisfactory if a vector image like a diagram or a plot has to be extracted. There exists a command line tool called pdftocairo which allows to specify a region of a PDF document and to render this region as PS, EPS, PDF, or SVG. However, figuring out the crop parameters requires trial and error. Thus, it would be a huge benefit if Okular could make use of the cropping and rendering of pdftocairo through its already existing selection feature. 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 321351] New: selection tool: copy/extract as high-resolution
https://bugs.kde.org/show_bug.cgi?id=321351 Bug ID: 321351 Summary: selection tool: copy/extract as high-resolution Classification: Unclassified Product: okular Version: 0.16.4 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: PDF backend Assignee: okular-devel@kde.org Reporter: fisc...@unix-ag.uni-kl.de Currently, the selection tool of Okular allows to extract a region of a document as text or as a pixmap. This pixmap is has same resolution as the document is shown on screen. This solution is not satisfactory if a high-resolution image has to be extracted as e.g. necessary for further processing and printing. Instead, the pixmap should be rendered and copied/saved in a larger resolution if specified so by the user in the settings. 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 110003: Best-fit zoom
On April 14, 2013, 10:07 p.m., Albert Astals Cid wrote: Can you please describe your best fit algorithm? I am finding that in my 1920x1080 resolution best fit is giving me a Fit to width while in evince i get a Fit to page that may actually make more sense since i am seeing more info in that Fit to page than in this Fit to width and i can still read it. My best-fit code switches between three zoom types depending on the relation of aspect ratio of Okular's area to show content and the aspect ratio of the shown page. Depending on this relation, it assumes that one of the following three cases is true: (1) Both ratios are very similar, e.g. when you are looking on landscape-oriented PDF slides in a maximized Okular window (4:3 aspect ratio). Fit-page is the best viewing mode here. (2) You have have a wide Okular window (e.g. maximize on a wide screen) viewing a portrait-oriented A4 document such as a letter. If you eye sight and your screen is good, you can still read it, but don't assume everyone else can. So a better choice may be to fit-width zoom the page, even if only a small section is visible, but at least the text should be readable. (3) You have a split-screen Okular window (e.g. right or left half of your screen), but you are looking at a landscape-oriented document. Again, it may be a better choice to fit-height zoom your document than to fit-page zoom it if you want to read the fineprint. On extreme cases, best-fit may zoom in a way that the document becomes even hard to read, but in most cases it has its benefits being a good approximation for typical use-cases (in my personal view). - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/#review31033 --- On April 14, 2013, 11:26 a.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/ --- (Updated April 14, 2013, 11:26 a.m.) Review request for Okular. Description --- Attached patch implements best-fit zoom for Okular. It is a refined version of the patch submitted in bug report 249364, attachment 51069. The refinement addresses the scrollbar issues as observed in continuous view mode. This addresses bug 249364. http://bugs.kde.org/show_bug.cgi?id=249364 Diffs - part.rc 64aeffb ui/pageview.h 5e839f2 ui/pageview.cpp 6e093ef Diff: http://git.reviewboard.kde.org/r/110003/diff/ Testing --- Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Review Request 110003: Best-fit zoom
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110003/ --- Review request for Okular. Description --- Attached patch implements best-fit zoom for Okular. It is a refined version of the patch submitted in bug report 249364, attachment 51069. The refinement addresses the scrollbar issues as observed in continuous view mode. This addresses bug 249364. http://bugs.kde.org/show_bug.cgi?id=249364 Diffs - ui/pageview.h 5e839f2 ui/pageview.cpp 6e093ef Diff: http://git.reviewboard.kde.org/r/110003/diff/ Testing --- Thanks, Thomas Fischer ___ 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 #10 from Thomas Fischer fisc...@unix-ag.uni-kl.de --- Submitted as review 110003: https://git.reviewboard.kde.org/r/110003/ -- 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 #7 from Thomas Fischer fisc...@unix-ag.uni-kl.de --- (In reply to comment #6) Any luck? It looks like the problem you observed is related to mixing best-fit and continuous view. Both features mess with the vertical scroll bar. The problem does not appear if you use single-page view. -- 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: Properties dialog: switch to QFormLayout and showing icon for mime type
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107357/ --- (Updated Dec. 31, 2012, 8:17 p.m.) Review request for Okular. Changes --- Fixing buddy problem by calling QFormLayout::addRow(QWidget*, QWidget*) instead of QFormLayout::addRow(const QString , QWidget*). Minor fix in the mimetype label internationalization. Description --- This patch changes the properties dialog to use QFormLayout instead of a two-column QGridLayout. This should make the dialog more compatible with other user interfaces. For the mime type row, instead of just showing the mime type's name, a small QLabel is used to show the mime type's icon. Maybe it would be a good idea to not only show the mime type's name, but also the description (KMimeType::comment(..)). Example: PDF Document (application/pdf) Diffs (updated) - ui/propertiesdialog.cpp 2ef8220 Diff: http://git.reviewboard.kde.org/r/107357/diff/ Testing --- Screenshots --- QFormLayout and mime type icon http://git.reviewboard.kde.org/r/107357/s/835/ Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request: Show paper size names like ISO/DIN A4 instead of just paper size in numbers
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107350/ --- (Updated Nov. 16, 2012, 10:33 p.m.) Review request for Okular. Changes --- Rewriting patch to use big switch to cover all paper sizes QPrinter knows. Avoids i18n for static constants. Description --- This patch makes Okular not only show a document's size (width x height) in inches or millimeters, but it will try to guess the paper format's name as well. Example: So far, for an opened PDF file in the Properties dialog (File - Properties), it would print Page Size: 210,016 x 297,011 mm. Using this patch, it would say instead 210,016 x 297,011 mm (portrait ISO/DIN A4) Diffs (updated) - core/document.cpp 3e4e21a core/document_p.h 4a20561 Diff: http://git.reviewboard.kde.org/r/107350/diff/ Testing --- Works for example files using format ISO/DIN A4 and legal. No example files for other formats available (e.g. Japanese JIS-B or tabloid). Screenshots --- Showing paper format portrait ISO/DIN A4 http://git.reviewboard.kde.org/r/107350/s/834/ Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request: Properties dialog: switch to QFormLayout and showing icon for mime type
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107357/ --- (Updated Nov. 17, 2012, 10:56 a.m.) Review request for Okular. Changes --- Updating description Description (updated) --- This patch changes the properties dialog to use QFormLayout instead of a two-column QGridLayout. This should make the dialog more compatible with other user interfaces. For the mime type row, instead of just showing the mime type's name, a small QLabel is used to show the mime type's icon. Maybe it would be a good idea to not only show the mime type's name, but also the description (KMimeType::comment(..)). Example: PDF Document (application/pdf) Diffs - ui/propertiesdialog.cpp 2ef8220 Diff: http://git.reviewboard.kde.org/r/107357/diff/ Testing --- Screenshots --- QFormLayout and mime type icon http://git.reviewboard.kde.org/r/107357/s/835/ Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request: Properties dialog: switch to QFormLayout and showing icon for mime type
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107357/ --- (Updated Nov. 17, 2012, 5:09 p.m.) Review request for Okular. Changes --- Instead of writing out the raw mimetype (example: application/pdf), it shows a description of the mime type followed by the mime type's name in parentheses (example: PDF document (application/pdf)). Description --- This patch changes the properties dialog to use QFormLayout instead of a two-column QGridLayout. This should make the dialog more compatible with other user interfaces. For the mime type row, instead of just showing the mime type's name, a small QLabel is used to show the mime type's icon. Maybe it would be a good idea to not only show the mime type's name, but also the description (KMimeType::comment(..)). Example: PDF Document (application/pdf) Diffs (updated) - ui/propertiesdialog.cpp 2ef8220 Diff: http://git.reviewboard.kde.org/r/107357/diff/ Testing --- Screenshots --- QFormLayout and mime type icon http://git.reviewboard.kde.org/r/107357/s/835/ Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request: Properties dialog: switch to QFormLayout and showing icon for mime type
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107357/ --- (Updated Nov. 17, 2012, 7:51 p.m.) Review request for Okular. Changes --- Addressing issues: - KMimeType::mimeType may return 0, please account for that - convert the QLatin1String into a i18nc so translators can change the order or the way of showing, maybe () is not usual, if they need it Description --- This patch changes the properties dialog to use QFormLayout instead of a two-column QGridLayout. This should make the dialog more compatible with other user interfaces. For the mime type row, instead of just showing the mime type's name, a small QLabel is used to show the mime type's icon. Maybe it would be a good idea to not only show the mime type's name, but also the description (KMimeType::comment(..)). Example: PDF Document (application/pdf) Diffs (updated) - ui/propertiesdialog.cpp 2ef8220 Diff: http://git.reviewboard.kde.org/r/107357/diff/ Testing --- Screenshots --- QFormLayout and mime type icon http://git.reviewboard.kde.org/r/107357/s/835/ Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request: Properties dialog: switch to QFormLayout and showing icon for mime type
On Nov. 17, 2012, 2:14 p.m., Albert Astals Cid wrote: The QFormLayout is not needed, that's a class totally tailored for small screen state devices (phones) and it's not going to happen that we port this dialog to a phone. The icon thing looks like a nice addition and i don't object to the showing of the comment either, The QFormLayout is not needed, that's a class totally tailored for small screen state devices (phones) According to the documentation, this is only one argument to use this class. The other one is that it adepts to the desktop's settings (KDE, Gnome, Windows, Mac) regarding layout alignment. In this respect, it is an improvement over the previous addWidget(..., Qt::AlignRight); Finally, the addRow statement takes care of creating the label instead of creating and layouting QLabel *key manually. The icon thing looks like a nice addition and i don't object to the showing of the comment either Working on that ... - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107357/#review22121 --- On Nov. 17, 2012, 10:56 a.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107357/ --- (Updated Nov. 17, 2012, 10:56 a.m.) Review request for Okular. Description --- This patch changes the properties dialog to use QFormLayout instead of a two-column QGridLayout. This should make the dialog more compatible with other user interfaces. For the mime type row, instead of just showing the mime type's name, a small QLabel is used to show the mime type's icon. Maybe it would be a good idea to not only show the mime type's name, but also the description (KMimeType::comment(..)). Example: PDF Document (application/pdf) Diffs - ui/propertiesdialog.cpp 2ef8220 Diff: http://git.reviewboard.kde.org/r/107357/diff/ Testing --- Screenshots --- QFormLayout and mime type icon http://git.reviewboard.kde.org/r/107357/s/835/ Thanks, Thomas Fischer ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 151614] store annotations with documents
https://bugs.kde.org/show_bug.cgi?id=151614 Thomas Fischer fisc...@unix-ag.uni-kl.de changed: What|Removed |Added CC||fisc...@unix-ag.uni-kl.de --- Comment #153 from Thomas Fischer fischer unix-ag uni-kl de 2011-05-06 10:56:20 --- Hello, Would it be too hard (or a viable partial solution) to use iText as a plugin to save/export the Okular annotations to a native PDF? And the same thing when loading a PDF with annotations, informing the user that the PDF contains attachments/annotations and if he wants to import the native/original annotations to Okular's annotation format? I came across with iText for Java very recently, and even though one have a dependency here on Java to be able to use the library, could this be an option to a user to have a choice to manipulate PDFs with iText on a plugin in Okular? Being iText open source and a great reference to manipulate PDF in the Java world, I think it is pertinent to ask. Another solution would be to migrate the code/algorithm to Qt/C++ so it could be used here and in other OS projects, at least while no one comes up with a better solution. Porting a library from Java or C# to C++ can be quite an effort considering that e.g. C++ has no garbage collection compared with Java and C#. Plus, whenever there is a new version of iText, you have to port those changes/bugfixes as well. Keeping iText as it is and use it as an external plugin would be an option, too, but adds external dependencies. If external dependencies would be no problem, one could implement the generating/manipulating PDF part in pdfLaTeX or other tools as well. Using an external tool can only be a short-term solution until a real solution matures (see below). In the best case, Okular could use a shared library in C or C++ to do the PDF manipulation. Some search revealed the following option (in no particular order): * The GNU PDF library which is still in its infancy but may be a future alternative. * Poppler seems to support some writing features, at least I found some mailing list posting from 2008 on this. I don't know if it is supported by the Qt4 bindings yet. * PDFedit is/was a Qt3 program to edit PDF files. I used it for some time, but its inner design must have been horrible, as it got slower and slower the more changes you made. Still, one could look at its implementation and learn how to edit PDF files. The most solid approach IMHO would be to look into Poppler's features and the Qt4 bindings. If those bindings are not sufficient, make the necessary changes for a clean, well-designed API. Once the API is mature, integrate it into the PDF part (or inherit into a new KParts::ReadWritePart). Let me see if I have some time during the weekend to dig through Poppler's source code to give a more qualified comment here ... (This is my personal oppinion, as I am not affiliated with the Okular maintainers) -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- 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] [Bug 249364] PATCH: Fit best (best-fit) zoom
https://bugs.kde.org/show_bug.cgi?id=249364 --- Comment #5 from Thomas Fischer fischer unix-ag uni-kl de 2010-09-19 09:39:31 --- There is a problem with the scrollbar code and i can make it quite easily remove the vertical scrollbar when it should be there. Screenshot attached. Haven't found a good solution yet. Could be necessary to rewrite/improve the current code for zooming and scrollbar visibility. I will continue to look into a simple solution, though... -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- 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] [Bug 249364] PATCH: Fit best (best-fit) zoom
https://bugs.kde.org/show_bug.cgi?id=249364 --- Comment #2 from Thomas Fischer fischer unix-ag uni-kl de 2010-09-04 11:22:14 --- Is that 1.25 supposed to be the aspectRatio of the users screen? No, not directly. The patch first computes the aspect ratios of the page and the aspect ratio of the space available to display the page (as determined by rowHeight and colWidth). Then both aspect ratios are compared by dividing one with another, the result is stored in variable rel. If both aspect ratios are very similar, such as when viewing presentations in a full-screen okular on a 3:4 or 16:9 monitor, rel is somewhere around 1 and the best zoom option would be fit page (third case in the following if block). Now, this very similar has to be put in a numeric value and this is aspectRatioRelation. Having a value of 1.25, it states that if 0.8rel1.25 holds, best fit page is the best zoom option. If rel is below 0.8, the page to view is relatively higher than the available space and fit width is most appropriate to utilize the space best. Fit page would render any text on the page unreadable (assuming I would open an A4 page/portrait with normal 10-12pt text). The same principle holds for rel 1.25 resulting in a fit height zoom. Another advantage with best fit is, that in the page fit case no scrolling is necessary and the mouse wheel allows to jump between pages (very useful for slide sets), and in the other two cases, only one scroll bar is used making browsing through the document much easier. I hope this explains the patch... -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- 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] Patch for best fit zoom
Hello,
as a regular Okular user, I have an itch that I was scratching: I was
looking for a zoom setting that is appropriate both for viewing
presentations (in non-fullscreen mode) and text documents (portrait
format).
I came up with a best fit zoom level which corresponds to the existing
fit width and fit page zoom levels.
The best-fit setting compares the aspect ratios of the document and the
viewing area it is shown in. If the aspect ratios nearly match, a page
will be shown in fit page mode. This is useful e.g. for presentations,
where a slide has a similar aspect ratio like the screen. If the aspect
ratio is very different, such as in cases with portrait text documents,
the document is scaled to fit width and you only have to scroll
vertically. If the document is much wider, it is scaled to fit the
height and you scroll horizontally only.
The attached patch introduces this feature while being just below 7k in
size. Additionally, I removed/replaced some fit text zoom which seemed
to be dead code. The patch is for KDE 4.3.4, but it should be no problem
apply it to the upcoming 4.4 or trunk.
However, there is one major bug in my patch. If the ratio between aspect
ratios is very close to switching between either of the three zooming
modes, Okular may continuously switch between two modes. This seems to
happen as Okular shows scrollbars if necessary, which change the view
area's size (and this aspect), which in turn triggers the change in
mode. As this new mode does not need scrollbars, they get disabled again
and the circle closes. I have not yet found a nice and clean solution
here.
Comments are welcome.
Bye,
Thomas
diff -Naur orig_kdegraphics-4.3.4/okular/part.rc kdegraphics-4.3.4/okular/part.rc
--- orig_kdegraphics-4.3.4/okular/part.rc 2009-02-18 17:28:33.0 +0100
+++ kdegraphics-4.3.4/okular/part.rc 2010-01-16 17:38:49.0 +0100
@@ -29,6 +29,7 @@
Action name=view_zoom_out/
Action name=view_fit_to_width/
Action name=view_fit_to_page/
+Action name=view_fit_to_best/
Action name=zoom_fit_rect/
Separator/
Action name=view_continuous/
diff -Naur orig_kdegraphics-4.3.4/okular/ui/pageview.cpp kdegraphics-4.3.4/okular/ui/pageview.cpp
--- orig_kdegraphics-4.3.4/okular/ui/pageview.cpp 2009-11-27 14:03:14.0 +0100
+++ kdegraphics-4.3.4/okular/ui/pageview.cpp 2010-01-16 18:44:47.0 +0100
@@ -159,7 +159,7 @@
KAction * aZoomOut;
KToggleAction * aZoomFitWidth;
KToggleAction * aZoomFitPage;
-KToggleAction * aZoomFitText;
+KToggleAction * aZoomFitBest;
KActionMenu * aViewMode;
KToggleAction * aViewContinuous;
QAction * aPrevAction;
@@ -345,7 +345,7 @@
d-aToggleAnnotator = 0;
d-aZoomFitWidth = 0;
d-aZoomFitPage = 0;
-d-aZoomFitText = 0;
+d-aZoomFitBest = 0;
d-aViewMode = 0;
d-aViewContinuous = 0;
d-aPrevAction = 0;
@@ -465,11 +465,10 @@
ac-addAction(view_fit_to_page, d-aZoomFitPage );
connect( d-aZoomFitPage, SIGNAL( toggled( bool ) ), SLOT( slotFitToPageToggled( bool ) ) );
-/*
-d-aZoomFitText = new KToggleAction(KIcon( zoom-fit-best ), i18n(Fit Text), this);
-ac-addAction(zoom_fit_text, d-aZoomFitText );
-connect( d-aZoomFitText, SIGNAL( toggled( bool ) ), SLOT( slotFitToTextToggled( bool ) ) );
-*/
+d-aZoomFitBest = new KToggleAction(KIcon( zoom-fit-best ), i18n(Fit Best), this);
+ac-addAction(view_fit_to_best, d-aZoomFitBest );
+connect( d-aZoomFitBest, SIGNAL( toggled( bool ) ), SLOT( slotFitToBestToggled( bool ) ) );
+
// View-Layout actions
d-aViewMode = new KActionMenu( KIcon( view-split-left-right ), i18n( View Mode ), this );
@@ -592,7 +591,7 @@
Okular::Settings::setViewMode( 0 );
d-aZoomFitWidth-setChecked( true );
d-aZoomFitPage-setChecked( false );
-//d-aZoomFitText-setChecked( false );
+d-aZoomFitBest-setChecked( false );
d-aViewMode-menu()-actions().at( 0 )-setChecked( true );
viewport()-setUpdatesEnabled( false );
slotRelayoutPages();
@@ -2462,6 +2461,35 @@
item-setWHZC( (int)(zoom * width), (int)(zoom * height), zoom, crop );
d-zoomFactor = zoom;
}
+else if ( d-zoomMode == ZoomFitBest )
+{
+double uiAspect = (double)rowHeight / (double)colWidth;
+double pageAspect = (double)height / (double)width;
+
+if ( ( uiAspect / pageAspect ) 1.25 )
+{
+// UI space is relatively much higher than the page
+zoom = (double)rowHeight / (double)height;
+}
+else if ( ( uiAspect / pageAspect ) 0.8 )
+{
+// UI space is relatively much wider than the page in relation
+zoom = (double)colWidth / (double)width;
+}
+else
+{
+// aspect ratios of page and UI space are very similar
+double scaleW = (double)colWidth / (double)width;
+double scaleH = (double)rowHeight / (double)height;
