Re: [Okular-devel] Dt. 29th July - status
Let's meet on #okular, tomorrow (3rd August) around 7pm european time. On Fri, Aug 2, 2013 at 11:57 AM, Jaydeep Solanki wrote: > > > > On Fri, Aug 2, 2013 at 2:24 AM, Albert Astals Cid wrote: > >> El Dijous, 1 d'agost de 2013, a les 23:04:23, Jaydeep Solanki va escriure: >> > On Thu, Aug 1, 2013 at 1:49 AM, Albert Astals Cid >> wrote: >> > > El Dimecres, 31 de juliol de 2013, a les 23:32:46, Jaydeep Solanki va >> > > >> > > escriure: >> > > > On Wed, Jul 31, 2013 at 3:13 AM, Albert Astals Cid >> > > >> > > wrote: >> > > > > El Dimarts, 30 de juliol de 2013, a les 11:19:45, Jaydeep Solanki >> va >> > > > > >> > > > > escriure: >> > > > > > On Tue, Jul 30, 2013 at 1:41 AM, Albert Astals Cid < >> aa...@kde.org> >> > > > > >> > > > > wrote: >> > > > > > > El Dilluns, 29 de juliol de 2013, a les 23:57:38, Jaydeep >> Solanki >> > > >> > > va >> > > >> > > > > > > escriure: >> > > > > > > > Hi, >> > > > > > > > As compared to other days, I didn't do much today. >> > > > > > > > >> > > > > > > > But found some really interesting facts about our image not >> > > >> > > loading >> > > >> > > > > > > problem. >> > > > > > > >> > > > > > > > I know it's not possible but some how the override is not >> called >> > > > > >> > > > > instead >> > > > > >> > > > > > > > the default implementation is called, I found out this by >> > > > > > > > placing >> > > > > > > > the >> > > > > > > > images next to the binary and it works. Images load, which >> > > > > > > > indirectly >> > > > > > > > indicates that it is loading using default implementation. >> > > > > > > > >> > > > > > > > I also tried removing the override, and having the images >> next >> > > > > > > > to >> > > > > > > > the >> > > > > > > > binary, everything works. >> > > > > > > > >> > > > > > > > If you have any hint, I would really appreciate it, because >> I'm >> > > > > >> > > > > really >> > > > > >> > > > > > > > in >> > > > > > > > need of one. >> > > > > > > >> > > > > > > Have you tried debugging it? At some point in Qt there has to >> call >> > > > > > > loadResource? What about putting a breakpoint in >> > > > > > > QTextDocument::loadResource >> > > > > > > and see what happens? >> > > > > > >> > > > > > I tried it in the first place, but it doesn't hit the break >> point, >> > > > > > that's >> > > > > > how I concluded loadResource is not called. >> > > > > > It hits the breakpoint for other files. >> > > > > >> > > > > You set the breakpoint in EpubDocument::loadResource or >> > > > > QTextDocument::loadResource? >> > > > >> > > > EpubDocument::loadResource >> > > >> > > So you say that QTextDocument is somehow loading a file without using >> > > loadResource? >> > >> > yes, without using the EpubDocument::loadResource(), but it uses >> > QTextDocument::loadResource(). I can say that because if resources are >> next >> > to binary, it loads. >> >> So you have put a breakpoint in QTextDocument::loadResource and have >> checked >> that QTextDocument::loadResource is called but >> EpubDocument::loadResource is >> not? >> > Yup, that's exactly what happens. > >> >> Cheers, >> Albert >> >> > >> > > > > Again, do you have a small test case? >> > > > >> > > > sadly no >> > > >> > > How big is the test case then? >> > >> > I have a mini version of the epub that shows this behaviour, that's all >> I >> > have. >> > >> > > Cheers, >> > > >> > > Albert >> > > >> > > > > Albert >> > > > > >> > > > > > > > Also, I have started discovering QTextDocument source. It >> has a >> > > > > > > > class >> > > > > > > >> > > > > > > named >> > > > > > > >> > > > > > > > QTextHtmlParser that does all the magic, I saw how it >> > > > > > > > categorises >> > > > > >> > > > > Html >> > > > > >> > > > > > > > elements, but I'm still not sure how it handles Css. I'll >> look >> > > >> > > into >> > > >> > > > > it >> > > > > >> > > > > > > > further. >> > > > > > > >> > > > > > > Cool :-) >> > > > > > > >> > > > > > > > BTW, do you also contribute to Qt ? I saw you on #qt-labs. >> > > > > > > >> > > > > > > I have done some small patches here and there, yes. >> > > > > > > >> > > > > > > Cheers, >> > > > > > > >> > > > > > > Albert >> > > > > > > >> > > > > > > > Cheers, >> > > > > > > > Jaydeep >> > > > > > > >> > > > > > > ___ >> > > > > > > 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 >> > > >> > > ___ >> > > 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] Dt. 29th July - status
On Fri, Aug 2, 2013 at 2:24 AM, Albert Astals Cid wrote: > El Dijous, 1 d'agost de 2013, a les 23:04:23, Jaydeep Solanki va escriure: > > On Thu, Aug 1, 2013 at 1:49 AM, Albert Astals Cid wrote: > > > El Dimecres, 31 de juliol de 2013, a les 23:32:46, Jaydeep Solanki va > > > > > > escriure: > > > > On Wed, Jul 31, 2013 at 3:13 AM, Albert Astals Cid > > > > > > wrote: > > > > > El Dimarts, 30 de juliol de 2013, a les 11:19:45, Jaydeep Solanki > va > > > > > > > > > > escriure: > > > > > > On Tue, Jul 30, 2013 at 1:41 AM, Albert Astals Cid < > aa...@kde.org> > > > > > > > > > > wrote: > > > > > > > El Dilluns, 29 de juliol de 2013, a les 23:57:38, Jaydeep > Solanki > > > > > > va > > > > > > > > > > escriure: > > > > > > > > Hi, > > > > > > > > As compared to other days, I didn't do much today. > > > > > > > > > > > > > > > > But found some really interesting facts about our image not > > > > > > loading > > > > > > > > > > problem. > > > > > > > > > > > > > > > I know it's not possible but some how the override is not > called > > > > > > > > > > instead > > > > > > > > > > > > > the default implementation is called, I found out this by > > > > > > > > placing > > > > > > > > the > > > > > > > > images next to the binary and it works. Images load, which > > > > > > > > indirectly > > > > > > > > indicates that it is loading using default implementation. > > > > > > > > > > > > > > > > I also tried removing the override, and having the images > next > > > > > > > > to > > > > > > > > the > > > > > > > > binary, everything works. > > > > > > > > > > > > > > > > If you have any hint, I would really appreciate it, because > I'm > > > > > > > > > > really > > > > > > > > > > > > > in > > > > > > > > need of one. > > > > > > > > > > > > > > Have you tried debugging it? At some point in Qt there has to > call > > > > > > > loadResource? What about putting a breakpoint in > > > > > > > QTextDocument::loadResource > > > > > > > and see what happens? > > > > > > > > > > > > I tried it in the first place, but it doesn't hit the break > point, > > > > > > that's > > > > > > how I concluded loadResource is not called. > > > > > > It hits the breakpoint for other files. > > > > > > > > > > You set the breakpoint in EpubDocument::loadResource or > > > > > QTextDocument::loadResource? > > > > > > > > EpubDocument::loadResource > > > > > > So you say that QTextDocument is somehow loading a file without using > > > loadResource? > > > > yes, without using the EpubDocument::loadResource(), but it uses > > QTextDocument::loadResource(). I can say that because if resources are > next > > to binary, it loads. > > So you have put a breakpoint in QTextDocument::loadResource and have > checked > that QTextDocument::loadResource is called but EpubDocument::loadResource > is > not? > Yup, that's exactly what happens. > > Cheers, > Albert > > > > > > > > Again, do you have a small test case? > > > > > > > > sadly no > > > > > > How big is the test case then? > > > > I have a mini version of the epub that shows this behaviour, that's all I > > have. > > > > > Cheers, > > > > > > Albert > > > > > > > > Albert > > > > > > > > > > > > > Also, I have started discovering QTextDocument source. It > has a > > > > > > > > class > > > > > > > > > > > > > > named > > > > > > > > > > > > > > > QTextHtmlParser that does all the magic, I saw how it > > > > > > > > categorises > > > > > > > > > > Html > > > > > > > > > > > > > elements, but I'm still not sure how it handles Css. I'll > look > > > > > > into > > > > > > > > it > > > > > > > > > > > > > further. > > > > > > > > > > > > > > Cool :-) > > > > > > > > > > > > > > > BTW, do you also contribute to Qt ? I saw you on #qt-labs. > > > > > > > > > > > > > > I have done some small patches here and there, yes. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Albert > > > > > > > > > > > > > > > Cheers, > > > > > > > > Jaydeep > > > > > > > > > > > > > > ___ > > > > > > > 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 > > > > > > ___ > > > 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 > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 322943] Cannot print Google Patents PDFs
https://bugs.kde.org/show_bug.cgi?id=322943 --- Comment #7 from marcandre.laverdi...@gmail.com --- Hello, Nothing changed on the print preview. However, I am getting this on the console: invalidfont -10 okular(22139)/okular (Spectre) GSRendererThread::run: Generated image does not match wanted size: [0x0] vs requested [88x124] QImage::scaled: Image is a null image invalidfont -10 okular(22139)/okular (Spectre) GSRendererThread::run: Generated image does not match wanted size: [0x0] vs requested [555x785] QImage::scaled: Image is a null image invalidfont -10 okular(22139)/okular (Spectre) GSRendererThread::run: Generated image does not match wanted size: [0x0] vs requested [78x110] QImage::scaled: Image is a null image invalidfont -10 okular(22139)/okular (Spectre) GSRendererThread::run: Generated image does not match wanted size: [0x0] vs requested [555x785] QImage::scaled: Image is a null image Marc-André LAVERDIÈRE "Perseverance must finish its work so that you may be mature and complete, not lacking anything." -James 1:4 http://asimplediscipleslife.blogspot.com/ mlaverd.theunixplace.com On Thu, Aug 1, 2013 at 4:31 PM, Albert Astals Cid wrote: > https://bugs.kde.org/show_bug.cgi?id=322943 > > --- Comment #6 from Albert Astals Cid --- > Ok, please try this in the shell > > export LANG=C > okular thefile.pdf > > does File -> Print Preview, work now? > > And if it does, does regular printing work? > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 323070] The presentation mode of Okular does not allow to zoom in or out
https://bugs.kde.org/show_bug.cgi?id=323070 Albert Astals Cid changed: What|Removed |Added Status|NEEDSINFO |UNCONFIRMED Resolution|WAITINGFORINFO |--- Severity|normal |wishlist --- Comment #3 from Albert Astals Cid --- I've done lots of presentations and never ever felt the need to zoom in, in fact it seems to me like it's a bug in you presentation if you need to zoom in to a particular part of your slides. Note that in Acrobat Reader you are not using the presentation mode but the full screen mode. We do also have a fullscreen mode you may find better for your needs. I'm going to leave this as wish+unconfirmed since to be honest i'm not convinced the presentation mode needs zoom at all. -- 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 323070] The presentation mode of Okular does not allow to zoom in or out
https://bugs.kde.org/show_bug.cgi?id=323070 --- Comment #2 from Sputnik --- (In reply to comment #1) > The presentation mode is for giving presentations, why do you need to zoom > in/out while giving a presentation? Thanks for asking. Well I thought it is obvious. I always missed it in Okular from the first release as it was the first feature I really use in programs like the Acrobat Reader - fullscreen mode (presentation) and zoom. And of course I thought it would come quickly (which wasn't the case so far...) I think I already wrote some reasons down for it above: * During presentations one may want to zoom into a detail (and has to leave the presentation mode currently to do so!) * By far more often I do in fact use the so called "presentation mode" as I do it in programs like the Acrobat Reader – for focussed reading without distraction of GUI elements. The only thing is that especially Okular is not capable to handle this in a good manner without zoom... sadly. * The current presentation mode is great for documents made for example with Impress (which does have it's own presentation mode). It's great for documents that fit perfectly into the screen. However if one tries to make a presentation with a ... normal ... also printable document (DIN A4 / US letter / ebook etc.) zooming is often necessary as the vertical orientation of the document simply does fit well on a normal computer screen. – The non-presentation mode handles this just wonderful. – But I can not understand why this behaviour is not part of the presentation mode then. I personally almost never have documents that fit into a normal horizontal screen... mostly vertical ones. This part of the usage is the real bug as documents that do not fit natively into the screen may often become unreadable in the presentation mode. Once again the expected behaviour – let's take Acroread: Go into the presentation mode there with [Ctrl]+[L] - and just use the normal shortcuts to zoom in and out. This small feature is expected, but missing in Okular. Thanks again! - It would be great if I could use Okular more often ... without having to change the program just because of this missing feature! :) -- 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] Dt. 1st August - status
El Dijous, 1 d'agost de 2013, a les 22:58:33, Jaydeep Solanki va escriure: > Hi, > I solved yesterday's issue, got it working. > I can detect visibility property. > > Now the question is how to hide an element when "visibility : hidden", one > approach I have implemented is make the text color transparent, but that > doesn't solve the issue, because the text is not visible but it can be > selected. > Any other ideas ? Making the text not selectable somehow, most probably that's not a one liner, since otherwise if it was the Qt guys would have implemented it. > > For, "visibility : collapse", what I'm thinking of is to delete the current > node, which has visibility equal to collapse, but the cache here is, I'm > inside a method of that object and I want to delete the object itself. > Possible ? Looks sensinble. Cheers, Albert > > I'm attaching a diff, if you want to have a look at the implementation. > > Cheers, > Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 29th July - status
El Dijous, 1 d'agost de 2013, a les 23:04:23, Jaydeep Solanki va escriure: > On Thu, Aug 1, 2013 at 1:49 AM, Albert Astals Cid wrote: > > El Dimecres, 31 de juliol de 2013, a les 23:32:46, Jaydeep Solanki va > > > > escriure: > > > On Wed, Jul 31, 2013 at 3:13 AM, Albert Astals Cid > > > > wrote: > > > > El Dimarts, 30 de juliol de 2013, a les 11:19:45, Jaydeep Solanki va > > > > > > > > escriure: > > > > > On Tue, Jul 30, 2013 at 1:41 AM, Albert Astals Cid > > > > > > > > wrote: > > > > > > El Dilluns, 29 de juliol de 2013, a les 23:57:38, Jaydeep Solanki > > > > va > > > > > > > > escriure: > > > > > > > Hi, > > > > > > > As compared to other days, I didn't do much today. > > > > > > > > > > > > > > But found some really interesting facts about our image not > > > > loading > > > > > > > > problem. > > > > > > > > > > > > > I know it's not possible but some how the override is not called > > > > > > > > instead > > > > > > > > > > > the default implementation is called, I found out this by > > > > > > > placing > > > > > > > the > > > > > > > images next to the binary and it works. Images load, which > > > > > > > indirectly > > > > > > > indicates that it is loading using default implementation. > > > > > > > > > > > > > > I also tried removing the override, and having the images next > > > > > > > to > > > > > > > the > > > > > > > binary, everything works. > > > > > > > > > > > > > > If you have any hint, I would really appreciate it, because I'm > > > > > > > > really > > > > > > > > > > > in > > > > > > > need of one. > > > > > > > > > > > > Have you tried debugging it? At some point in Qt there has to call > > > > > > loadResource? What about putting a breakpoint in > > > > > > QTextDocument::loadResource > > > > > > and see what happens? > > > > > > > > > > I tried it in the first place, but it doesn't hit the break point, > > > > > that's > > > > > how I concluded loadResource is not called. > > > > > It hits the breakpoint for other files. > > > > > > > > You set the breakpoint in EpubDocument::loadResource or > > > > QTextDocument::loadResource? > > > > > > EpubDocument::loadResource > > > > So you say that QTextDocument is somehow loading a file without using > > loadResource? > > yes, without using the EpubDocument::loadResource(), but it uses > QTextDocument::loadResource(). I can say that because if resources are next > to binary, it loads. So you have put a breakpoint in QTextDocument::loadResource and have checked that QTextDocument::loadResource is called but EpubDocument::loadResource is not? Cheers, Albert > > > > > Again, do you have a small test case? > > > > > > sadly no > > > > How big is the test case then? > > I have a mini version of the epub that shows this behaviour, that's all I > have. > > > Cheers, > > > > Albert > > > > > > Albert > > > > > > > > > > > Also, I have started discovering QTextDocument source. It has a > > > > > > > class > > > > > > > > > > > > named > > > > > > > > > > > > > QTextHtmlParser that does all the magic, I saw how it > > > > > > > categorises > > > > > > > > Html > > > > > > > > > > > elements, but I'm still not sure how it handles Css. I'll look > > > > into > > > > > > it > > > > > > > > > > > further. > > > > > > > > > > > > Cool :-) > > > > > > > > > > > > > BTW, do you also contribute to Qt ? I saw you on #qt-labs. > > > > > > > > > > > > I have done some small patches here and there, yes. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Albert > > > > > > > > > > > > > Cheers, > > > > > > > Jaydeep > > > > > > > > > > > > ___ > > > > > > 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 > > > > ___ > > 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
[Okular-devel] [okular] [Bug 322943] Cannot print Google Patents PDFs
https://bugs.kde.org/show_bug.cgi?id=322943 --- Comment #6 from Albert Astals Cid --- Ok, please try this in the shell export LANG=C okular thefile.pdf does File -> Print Preview, work now? And if it does, does regular printing work? -- 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 322739] okular crashes while saving annotation to okular document archive
https://bugs.kde.org/show_bug.cgi?id=322739 --- Comment #13 from Albert Astals Cid --- "Is there any merit in staying with the version I have installed at the moment?" Probably not, please get a newer version either self-compiling or from your distro and try again, those "impossible happened" errors are quite weird -- 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 322919] Crash on exit while PDF file is updated
https://bugs.kde.org/show_bug.cgi?id=322919 --- Comment #3 from Albert Astals Cid --- I don't have such a big latex file, can you provide one to us to help reproduce the problem? -- 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 323070] The presentation mode of Okular does not allow to zoom in or out
https://bugs.kde.org/show_bug.cgi?id=323070 Albert Astals Cid changed: What|Removed |Added Status|UNCONFIRMED |NEEDSINFO CC||aa...@kde.org Resolution|--- |WAITINGFORINFO --- Comment #1 from Albert Astals Cid --- The presentation mode is for giving presentations, why do you need to zoom in/out while giving a presentation? -- 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 111829: Use DPI of current screen for PDF rendering
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111829/ --- (Updated Aug. 1, 2013, 9:11 p.m.) Review request for Okular and Albert Astals Cid. Changes --- qDebug() -> kDebug() Description --- This patch relies on changes to LibKScreen, submitted in https://git.reviewboard.kde.org/r/111827/ This patch does not solve the problem in bug completely, but makes Okular behaviour more correct (see below). The problem (in the bug) is that Okular uses fixed DPI for PDF rendering (72.0 dots per inch) and therefore scale of rendered document becomes incorrect. With current mainline laptop screens having DPI easily twice larger than this constant (72), the problem shows itself quiet strongly. Additional problems araise with multiscreen configuration, when 1) DPI of each individual screen may be different, and 2) there is no tools in Qt to detect DPI of individual screens in virtual desktop mode. Therefore XRandr has to be used for DPI detection. Raw XRandr is bad dependency for Okular and libkscreen is proposed instead. This patch approach to the solution in the following way: 1. libkscreen detection staff is added to CMakeLists.txt and config.h 2. It changes Utils::realDpi() function to use libkscreen if present. With libkscreen the function looks for output that contains maximal part of given widget (suppose to be used for document rendering) and returns DPI of that screen. 3. Genenerator interface is extended by adding UtilizeDPI feature and setDPI() method, that is called by Document class right before calling loadXXX() if the generator supports this feature 4. Poppler generator is changed to support UtilizeDPI feature. 5. PageSizeMetric enum is extended with Pixels value to explicitly say that page size is defined in screen pixels (see my posts in the bug); Poppler generator uses this case. To completetly fix the bug, Document must invalidate generated pixmaps after the widget movements into another screen. I do not know how to track this without subclassing the main window class. Therefore I decided to publish this part of work to get your responce, especially regarding item 3 (Generator class changes). In the current state, manual reloading of a document after moving Okular to another screen fixes the scale, that is, in my eyes, is quiet helpful already. Even if we subclass the Okular main window, I do not know what to do when Okular is used as KPart. This addresses bug 268757. http://bugs.kde.org/show_bug.cgi?id=268757 Diffs (updated) - CMakeLists.txt 217337f config-okular.h.cmake 7217f8d core/document.cpp 6d462f6 core/document_p.h 3a257de core/generator.h a5a971b core/generator.cpp 41beb92 core/utils.h 8d5d5fc core/utils.cpp 5dd8448 generators/poppler/generator_pdf.h 5d5853a generators/poppler/generator_pdf.cpp 1a44523 Diff: http://git.reviewboard.kde.org/r/111829/diff/ Testing --- Manual. In all screens, that report correct physical size to XRandr, size of documents is correct Thanks, Eugene Shalygin ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 322919] Crash on exit while PDF file is updated
https://bugs.kde.org/show_bug.cgi?id=322919 --- Comment #2 from aux...@gmail.com --- In order to reproduce this the PDF file must take so long to generate, that "Reloading the document..." is displayed while attempting to close okular. For small latex files the window of opportunity is too short. -- 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] Dt. 29th July - status
On Thu, Aug 1, 2013 at 1:49 AM, Albert Astals Cid wrote: > El Dimecres, 31 de juliol de 2013, a les 23:32:46, Jaydeep Solanki va > escriure: > > On Wed, Jul 31, 2013 at 3:13 AM, Albert Astals Cid > wrote: > > > El Dimarts, 30 de juliol de 2013, a les 11:19:45, Jaydeep Solanki va > > > > > > escriure: > > > > On Tue, Jul 30, 2013 at 1:41 AM, Albert Astals Cid > > > > > > wrote: > > > > > El Dilluns, 29 de juliol de 2013, a les 23:57:38, Jaydeep Solanki > va > > > > > > > > > > escriure: > > > > > > Hi, > > > > > > As compared to other days, I didn't do much today. > > > > > > > > > > > > But found some really interesting facts about our image not > loading > > > > > > > > > > problem. > > > > > > > > > > > I know it's not possible but some how the override is not called > > > > > > instead > > > > > > > > > the default implementation is called, I found out this by placing > > > > > > the > > > > > > images next to the binary and it works. Images load, which > > > > > > indirectly > > > > > > indicates that it is loading using default implementation. > > > > > > > > > > > > I also tried removing the override, and having the images next to > > > > > > the > > > > > > binary, everything works. > > > > > > > > > > > > If you have any hint, I would really appreciate it, because I'm > > > > > > really > > > > > > > > > in > > > > > > need of one. > > > > > > > > > > Have you tried debugging it? At some point in Qt there has to call > > > > > loadResource? What about putting a breakpoint in > > > > > QTextDocument::loadResource > > > > > and see what happens? > > > > > > > > I tried it in the first place, but it doesn't hit the break point, > > > > that's > > > > how I concluded loadResource is not called. > > > > It hits the breakpoint for other files. > > > > > > You set the breakpoint in EpubDocument::loadResource or > > > QTextDocument::loadResource? > > > > EpubDocument::loadResource > > So you say that QTextDocument is somehow loading a file without using > loadResource? > yes, without using the EpubDocument::loadResource(), but it uses QTextDocument::loadResource(). I can say that because if resources are next to binary, it loads. > > > > Again, do you have a small test case? > > > > sadly no > > How big is the test case then? > I have a mini version of the epub that shows this behaviour, that's all I have. > > Cheers, > Albert > > > > > > Albert > > > > > > > > > Also, I have started discovering QTextDocument source. It has a > > > > > > class > > > > > > > > > > named > > > > > > > > > > > QTextHtmlParser that does all the magic, I saw how it categorises > > > > > > Html > > > > > > > > > elements, but I'm still not sure how it handles Css. I'll look > into > > > > > > it > > > > > > > > > further. > > > > > > > > > > Cool :-) > > > > > > > > > > > BTW, do you also contribute to Qt ? I saw you on #qt-labs. > > > > > > > > > > I have done some small patches here and there, yes. > > > > > > > > > > Cheers, > > > > > > > > > > Albert > > > > > > > > > > > Cheers, > > > > > > Jaydeep > > > > > > > > > > ___ > > > > > 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 > > ___ > 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
[Okular-devel] Dt. 1st August - status
Hi, I solved yesterday's issue, got it working. I can detect visibility property. Now the question is how to hide an element when "visibility : hidden", one approach I have implemented is make the text color transparent, but that doesn't solve the issue, because the text is not visible but it can be selected. Any other ideas ? For, "visibility : collapse", what I'm thinking of is to delete the current node, which has visibility equal to collapse, but the cache here is, I'm inside a method of that object and I want to delete the object itself. Possible ? I'm attaching a diff, if you want to have a look at the implementation. Cheers, Jaydeep visibility_detect.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 302358] Open Recent or Open toolbar button
https://bugs.kde.org/show_bug.cgi?id=302358 --- Comment #5 from Albert Astals Cid --- It is possible, if you can provide a patch it may make it for 4.12. I'd prefer if you opened a new bug and found other people that agreed with you to vote on that bug. We have lots of users with their "this feature is crucial for me" wish, and voting on bugs/features helps us decide in which we can focus our manpower -- 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 302358] Open Recent or Open toolbar button
https://bugs.kde.org/show_bug.cgi?id=302358 Knut Esztermann changed: What|Removed |Added CC||k...@esztermann.de --- Comment #4 from Knut Esztermann --- I think, this is a regression. I always loved the functionality of the combined open/open recent button. Maybe it is possible, to provide a combined toolbar button optionally? -- 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 323070] New: The presentation mode of Okular does not allow to zoom in or out
https://bugs.kde.org/show_bug.cgi?id=323070 Bug ID: 323070 Summary: The presentation mode of Okular does not allow to zoom in or out Classification: Unclassified Product: okular Version: unspecified Platform: unspecified OS: All Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: sputniksh...@gmail.com Please add a zooming possibility for Okular in presentation mode. This is a not only a feature request – but also a bug report: Some vertical documents are simply unreadable in the presentation mode currently (for example because the fonts are too small on a whole-page-view). Remember – viewing a printable document, like most ebooks or DIN A4 / US letter format documents are meant to be read vertically. The already existing presentation mode is the better mode for reading documents compared with the normal windowed mode as it focusses on the pure document. The black background is better for the eyes and there is no GUI that distracts from the content of the document. It sadly is not that useful without this zooming feature. While performing a presentation one may have the wish to zoom in and out a special detail of the document (like a chart or image). This ironically not possible without leaving the presentation mode. Most other PDF readers deal with it without problems. Reproducible: Always Steps to Reproduce: 1. Open the presentation mode. 2. Zooming is not possible. 3. Expected Results: To be able to use the normal shortcuts like [Ctrl]+[+] or [Ctrl]+[-] or replacements for them. -- 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 173681] Large PDF pages cause Okular to crawl
https://bugs.kde.org/show_bug.cgi?id=173681 Albert Astals Cid changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Albert Astals Cid --- Orso is your pdf a "large pdf"? Seems a regular A4. Does not qualify as large in my book of large things. Anyway i'm closing this bug as fixed if you have separate please open separate bugs, otherwise it's going to turn into the regular bug dump that it's impossible to fix because there's lots of users complaining about lots of different and unrelated things -- 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 173681] Large PDF pages cause Okular to crawl
https://bugs.kde.org/show_bug.cgi?id=173681 Otso Helenius changed: What|Removed |Added CC||k...@pi-xi.net --- Comment #20 from Otso Helenius --- I'm running 4.10.5 on F19 and still suffering from ridiculously slow page thumbnail generation and page rendering. This was also present on the Ubuntu 13.04 KDE spin. The poppler-qt lib is 0.22.1. For example, rendering some of the page thumbs for this pdf take roughly 20 seconds and the actual pages around 15 seconds: http://www.skrolli.fi/2013.2.web.pdf on a Core-i7. (To be fair, Evince suffers from similar lag in rendering the pages). With Adobe Reader, Foxit reader and Sumatra PDF rendering is pretty much instantaneous even with the cover pages. I'm expecting to get similar performance with Okular. -- 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
