[okular] [Bug 464008] PDF formular don't show checked check-boxes in the printout
https://bugs.kde.org/show_bug.cgi?id=464008 Albert Astals Cid changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #7 from Albert Astals Cid --- > The print preview don't work properly in my Okular version (shows only the > PDF plain text Yeah opensuse is weird like that i think you need to install extra stuff because reasons you can ask them. Since I'm not interested in doing opensuse support, please install from flathub https://flathub.org/apps/details/org.kde.okular and run it from there and tell me if you can see the checked checkbox when doing print preview -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 466604] feature request: add option to add highlighting to right click context menu on text selection
https://bugs.kde.org/show_bug.cgi?id=466604 Albert Astals Cid changed: What|Removed |Added CC||aa...@kde.org Severity|normal |wishlist -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 462349] Not switching between marker and text-chooser, marked text stays
https://bugs.kde.org/show_bug.cgi?id=462349 --- Comment #6 from Albert Astals Cid --- I'm not sure what you're reporting then :D The screenshot from issue #3 is correct, you have text selection and annotation and they both correctly are shown, but you said that was a bug? But then you show us a video in which that does not happen (which seems a bug to me, but not to you?) So according to you is there a bug then or not? -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 Albert Astals Cid changed: What|Removed |Added CC||aa...@kde.org --- Comment #10 from Albert Astals Cid --- > Okular currently converts pdf files to postscript and sends that to the > printer (I forgot why exactly). Because thousands of years ago printing PDF files directly was not something that worked. -- You are receiving this mail because: You are the assignee for the bug.
Digital signature: font & content of the rectangle
Dear Okular developers, I am using Okular to e-sign documents (using Belgian Eid) and I really appreciate your work. However, I don't find the options to configure the signature drawn on the pdf (font, content, etc.) and I need to make a huge rectangle to have a visible signature (which is not often possible). It is possible to have information about this configuration or do you know when this feature will be available ? Thank you. Best regards, Guillaume Gheysen
Re:
El dimecres, 15 de març de 2023, a les 22:23:19 (CET), Shivodit Gill va escriure: > On 3/15/23 05:07, Albert Astals Cid wrote: > > El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va escriure: > >> Hello, > > > > Hello, please write a Subject to your emails. > > Sorry about that, I forgot to add a subject line and only realized it > after I had sent the mail, since GMail doesn't warn about missing > subject lines. I'll make sure to not repeat this in the future. > > >> I am a college student planning to contribute to KDE for GSoC '23, by > >> taking on the task of improving Okular on Android. I have the following > >> questions: > >> > >> 1. What will be the use case of implementing the Android AFontMatcher > >> > >> font API? > >> > >> Initially I had tested a .pdf file in Okular for Android, and the > >> text in that file did not load at all. So I assumed that this API > >> would help to find the correct fonts in such situations, so that > >> text content could be properly shown. > > > > Exactly. > > > >> However, now I am not sure - I tried some other pdfs with text, > >> and all of them rendered the text correctly. The issue with font > >> rendering only occurs when viewing the earlier mentioned pdf file. > >> If I use the "Print to file" option to create a duplicate of the > >> problematic pdf, the duplicated pdf loads correctly on Okular for > >> Android. Weirdly enough, the same problematic pdf renders correctly > >> when opened in desktop Okular. > >> > >> 2. Since the AFontMatcher API will be implemented in the Poppler > >> backend, > >> > >> I was wondering in which files/directories the programming work > >> would be done. > >> > >> Initially I assumed work would be done in the generator/poppler > >> directory of the Okular repo, but that turned out to be incorrect. > >> > >> After some digging, I stumbled upon the freedesktop Poppler repo, > >> (https://gitlab.freedesktop.org/poppler/poppler and it contains) > >> the code files for the Qt5 Poppler interface. I'm guessing the work > >> will be done here? > > > > No, the code will not be in the Qt5 Poppler interface, keep digging your > > almost there. > > I see, me being close probably means I'm in the correct repo, right? If > yes, then my guess is that the work will be happening in the poppler > directory of the Poppler repo. Reasoning being that it contains some > .cc/.cpp files which deal with some information related to fonts.. Yes, that is the proper folder. > > >> 3. This is a bit off-topic, but why is the pdf mentioned above having > >> > >> trouble with text rendering? All other pdfs with text content render > >> correctly, but only this specific file has trouble with loading on > >> Android Okular but it gets shown correctly everywhere else, including > >> other pdf viewers on Android. I can send the pdf if someone > >> would like to take a look at it. > > > > Without the PDF I can only guess is because the PDF doesn't embed its > > fonts. > I see, so maybe duplicating the entire pdf using the 'Print to File' > functionality causes the proper fonts/their substitutes to get embedded? > > I've also uploaded the faulty pdf I mentioned to this google drive link, > please check it out when you get the chance. > > Faulty pdf: > https://drive.google.com/file/d/1oid-cZwady9jaCpdZb4wShflDId-RHFu/view?usp=s > haring There's nothing faulty about that pdf, having non embedded fonts is perfectly ok, and that's why we need poppler+Android to support that scenario. Cheers, Albert > > Thanks, > Shivodit > > > Cheers, > > > > Albert > >> > >> Thanks, > >> Shivodit
Re:
On 3/15/23 05:07, Albert Astals Cid wrote: > El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va escriure: >> Hello, > > Hello, please write a Subject to your emails. Sorry about that, I forgot to add a subject line and only realized it after I had sent the mail, since GMail doesn't warn about missing subject lines. I'll make sure to not repeat this in the future. > >> >> I am a college student planning to contribute to KDE for GSoC '23, by >> taking on the task of improving Okular on Android. I have the following >> questions: >> >> 1. What will be the use case of implementing the Android AFontMatcher >> font API? >> >> Initially I had tested a .pdf file in Okular for Android, and the >> text in that file did not load at all. So I assumed that this API >> would help to find the correct fonts in such situations, so that >> text content could be properly shown. > > Exactly. > >> >> However, now I am not sure - I tried some other pdfs with text, >> and all of them rendered the text correctly. The issue with font >> rendering only occurs when viewing the earlier mentioned pdf file. >> If I use the "Print to file" option to create a duplicate of the >> problematic pdf, the duplicated pdf loads correctly on Okular for >> Android. Weirdly enough, the same problematic pdf renders correctly >> when opened in desktop Okular. >> >> 2. Since the AFontMatcher API will be implemented in the Poppler backend, >> I was wondering in which files/directories the programming work >> would be done. >> >> Initially I assumed work would be done in the generator/poppler >> directory of the Okular repo, but that turned out to be incorrect. >> >> After some digging, I stumbled upon the freedesktop Poppler repo, >> (https://gitlab.freedesktop.org/poppler/poppler and it contains) >> the code files for the Qt5 Poppler interface. I'm guessing the work >> will be done here? > > No, the code will not be in the Qt5 Poppler interface, keep digging your > almost there. I see, me being close probably means I'm in the correct repo, right? If yes, then my guess is that the work will be happening in the poppler directory of the Poppler repo. Reasoning being that it contains some .cc/.cpp files which deal with some information related to fonts.. >> >> 3. This is a bit off-topic, but why is the pdf mentioned above having >> trouble with text rendering? All other pdfs with text content render >> correctly, but only this specific file has trouble with loading on >> Android Okular but it gets shown correctly everywhere else, including >> other pdf viewers on Android. I can send the pdf if someone >> would like to take a look at it. > > Without the PDF I can only guess is because the PDF doesn't embed its fonts. > I see, so maybe duplicating the entire pdf using the 'Print to File' functionality causes the proper fonts/their substitutes to get embedded? I've also uploaded the faulty pdf I mentioned to this google drive link, please check it out when you get the chance. Faulty pdf: https://drive.google.com/file/d/1oid-cZwady9jaCpdZb4wShflDId-RHFu/view?usp=sharing Thanks, Shivodit > Cheers, > Albert > >> >> Thanks, >> Shivodit > > > >
[okular] [Bug 467419] New: Okular crashed when connecting usb-c docking with 4k screen
https://bugs.kde.org/show_bug.cgi?id=467419 Bug ID: 467419 Summary: Okular crashed when connecting usb-c docking with 4k screen Classification: Applications Product: okular Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: o.malek...@gmail.com Target Milestone: --- Application: okular (22.12.2) Qt Version: 5.15.8 Frameworks Version: 5.102.0 Operating System: Linux 6.1.8-1-default x86_64 Windowing System: X11 Distribution: "openSUSE Tumbleweed" DrKonqi: 5.26.5 [KCrashBackend] -- Information about the crash: Not sure if crashed happend while disconneted or connected to dock. The reporter is unsure if this crash is reproducible. -- Backtrace: Application: Okular (okular), signal: Segmentation fault [KCrash Handler] #4 0x7fe366d6954d in __memmove_avx_unaligned_erms () from /lib64/libc.so.6 #5 0x7fe362b0e3ba in ?? () from /lib64/libQt5XcbQpa.so.5 #6 0x7fe362b0e9b9 in ?? () from /lib64/libQt5XcbQpa.so.5 #7 0x7fe362b0f2f9 in ?? () from /lib64/libQt5XcbQpa.so.5 #8 0x7fe367b4d462 in QBackingStore::flush(QRegion const&, QWindow*, QPoint const&) () from /lib64/libQt5Gui.so.5 #9 0x7fe3681b2a7f in QWidgetRepaintManager::flush (this=this@entry=0x563114e12900, widget=0x563114440040, region=..., widgetTextures=) at kernel/qwidgetrepaintmanager.cpp:1198 #10 0x7fe3681b4609 in QWidgetRepaintManager::flush (this=0x563114e12900) at kernel/qwidgetrepaintmanager.cpp:1096 #11 0x7fe3681b6688 in QWidgetRepaintManager::paintAndFlush (this=0x563114e12900) at kernel/qwidgetrepaintmanager.cpp:1028 #12 0x7fe3681ff3e1 in QWidgetWindow::handleResizeEvent (this=0x563114e00450, event=0x7fff9fd4d220) at kernel/qwidgetwindow.cpp:841 #13 0x7fe36820334b in QWidgetWindow::event (this=0x563114e00450, event=0x7fff9fd4d220) at kernel/qwidgetwindow.cpp:322 #14 0x7fe3681a544e in QApplicationPrivate::notify_helper (this=, receiver=0x563114e00450, e=0x7fff9fd4d220) at kernel/qapplication.cpp:3640 #15 0x7fe3674dc1e8 in QCoreApplication::notifyInternal2 (receiver=0x563114e00450, event=0x7fff9fd4d220) at kernel/qcoreapplication.cpp:1064 #16 0x7fe367977ccc in QGuiApplicationPrivate::processGeometryChangeEvent(QWindowSystemInterfacePrivate::GeometryChangeEvent*) () from /lib64/libQt5Gui.so.5 #17 0x7fe36794f26c in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /lib64/libQt5Gui.so.5 #18 0x7fe362b1914a in ?? () from /lib64/libQt5XcbQpa.so.5 #19 0x7fe365d1ba90 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #20 0x7fe365d1be48 in ?? () from /lib64/libglib-2.0.so.0 #21 0x7fe365d1bedc in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #22 0x7fe367533c16 in QEventDispatcherGlib::processEvents (this=0x5631143d60f0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #23 0x7fe3674dac5b in QEventLoop::exec (this=this@entry=0x7fff9fd4d4a0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #24 0x7fe3674e2dc6 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #25 0x56311405d1f6 in ?? () #26 0x7fe366c2c5b0 in __libc_start_call_main () from /lib64/libc.so.6 #27 0x7fe366c2c679 in __libc_start_main_impl () from /lib64/libc.so.6 #28 0x56311405dd05 in ?? () [Inferior 1 (process 18739) detached] The reporter indicates this bug may be a duplicate of or related to bug 465146. Reported using DrKonqi -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 385951] Some applications dont show menubar after disabling global menu again
https://bugs.kde.org/show_bug.cgi?id=385951 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #13 from Bernd Steinhauser --- There's many more. I recently put the global menu in the title bar, just to try it out again. Big mistake. Ever since, I have been fighting to get the menu bar back in so many apps. Dolphin, ksudoku, konsole, just to name a few. In some cases, Ctrl+m helps, in others it doesn't. e.g. for ksudoku I couldn't find any way to get it back other than to edit the rc file. I really would not recommend anybody to use the global menu unless they are 100% sure they will never want the menubar back. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 464608] Search results are not highlighted correctly after using "Settings>>Configure Okular…>>Accessibility>>Change colors"
https://bugs.kde.org/show_bug.cgi?id=464608 acox@gmail.com changed: What|Removed |Added CC||acox@gmail.com -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #9 from Sergio --- I have opened a request for feedback or for participation in the discussion on the poppler tracker: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1377 -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #8 from Sergio --- A few more questions: 1) Is the conversion to ps currently done by poppler? I see a Poppler::PSConverter object being used. If so, regardless of the conveniency of practicing the intermediate postscript conversion is there a poppler bug ultimately? Should an issue be opened with them? 2) when you ask for the rasterization, is the rasterization always happening at 300x300 dpi in unix regardless of the printer resolution? I see mention to a discussion at https://git.reviewboard.kde.org/r/130218/, but that site is dead. Thanks again! -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #7 from Sergio --- (In reply to Oliver Sander from comment #6) > I fully agree that `force rasterization` is only a workaround. > > Okular currently converts pdf files to postscript and sends that to the > printer (I forgot why exactly). Presumably it is the conversion step that > goes wrong in your case. Most likely the issue is indeed in this conversion. Noticed that if you pre-process the PDF via a pdf-to-pdf conversion via Ghostscript (which most likely results in a simpler PDF) then the PDF prints fine. For sure the PDF to PDF conversion via ghostscript changes the way in which the fonts are embedded because the `pdffonts` utility returns different results. I wonder if the conversion is related to the need to select page ranges or to do page scaling, but both things should be manageable at the PDF level. Or if it is needed by non-CUPS platforms (windows) where PDF might not be the "standard" way of describing the page for printing. If you want to have a look at the code: That's at > `generator_pdf.cpp:1366`. > There used to be a patch that made Okular send the pdf file straight to the > printer, but I can't seem to find it right now. Resurrecting this patch might have good potential! > And then there's the official Qt way of printing: Render everything to a > `QPrinter` object. Code for that is at > https://invent.kde.org/graphics/okular/-/merge_requests/411 , but that has > its own set of problems. I had a look at it, but I am not sure I fully understand. If I get it correctly, the QPrinter object is an object you paint onto (sort of QPainter?). So if you have an application that wants to draw something meant to be printed you do that on the QPrinter object and in this way you get something that is printable. However, in case of a PDF document this seems a bit redundant and prone to be lossy: first you paint the PDF on the QPrinter object and then the QPrinter object converts its content back to PDF for printing (at least on CUPS platforms). I understand that the set of problems you mention are indeed a consequence of the first conversion. Maybe if Qtpdfium grows a PDF->Qpainter rendering path that might overcome some of the limitations of the poppler rendering path, but still the QPrinter route appears to me as not the most efficient one. For complex PDFs it could also slow things down a bit. Is my understanding correct? -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #6 from Oliver Sander --- I fully agree that `force rasterization` is only a workaround. Okular currently converts pdf files to postscript and sends that to the printer (I forgot why exactly). Presumably it is the conversion step that goes wrong in your case. If you want to have a look at the code: That's at `generator_pdf.cpp:1366`. There used to be a patch that made Okular send the pdf file straight to the printer, but I can't seem to find it right now. And then there's the official Qt way of printing: Render everything to a `QPrinter` object. Code for that is at https://invent.kde.org/graphics/okular/-/merge_requests/411 , but that has its own set of problems. -- You are receiving this mail because: You are the assignee for the bug.
