[Okular-devel] [okular] [Bug 327635] Epub - images overflow page.
https://bugs.kde.org/show_bug.cgi?id=327635 --- Comment #14 from jaydeep --- You'll have to install it from source. Instructions can be found on http://okular.kde.org/download.php -- 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 327635] Epub - images overflow page.
https://bugs.kde.org/show_bug.cgi?id=327635 --- Comment #11 from jaydeep --- I'm sure the images in Learning QGIS will render properly in latest version of Okular, because it has been fixed. But the previous one from the boat building book needs some work. So I would recommend you to update Okular and try it once again. -- 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 327635] Epub - images overflow page.
https://bugs.kde.org/show_bug.cgi?id=327635 jaydeep changed: What|Removed |Added CC||j.solank...@yahoo.com --- Comment #6 from jaydeep --- If we look at the html of the epub file, the image on page 9 is not actually **an** image, it's two images in a row inside a table. To fix this, I guess we need to do some preprocessing that makes sure images inside tables don't end up consume too much space. I'm not sure, but may be I can fix this, if you give me some time. -- 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] GSoC 2013 clean patches
Hi, A cleaner version of patches are available on branch 'gsoc2013'. All except autotest for internal links is there. I'm having some issues recreating it. I'll push it as soon as I get it working. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Delete branch gsoc2013
Hi, Please delete branch 'gsoc2013'. Also send me a confirmation, so that I can push it again. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Mentorship at Google Code-In
On Thu, Oct 17, 2013 at 2:47 AM, Albert Astals Cid wrote: > El Dijous, 17 d'octubre de 2013, a les 02:27:27, Jaydeep Solanki va > escriure: > > Hi, > > Hi > > > I would like to know if anyone of you is going to be a mentor for Google > > Code-In. > > I'm not planning to get involved. > > > Also, can I be a mentor ? I was a GSoC 2013 student under KDE, Okular. > > Sure, why not? > > Cheers, > Albert > > P.S: We should find a day to try to go through your work and get it merged > upstream before the 4.12 freeze date in 2 weeks. > How about this weekend ? Saturday ? > > 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] Mentorship at Google Code-In
Hi, I would like to know if anyone of you is going to be a mentor for Google Code-In. Also, can I be a mentor ? I was a GSoC 2013 student under KDE, Okular. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 325909] okular crashed after opening with CBUS125EPM001007.epub
https://bugs.kde.org/show_bug.cgi?id=325909 jaydeep changed: What|Removed |Added CC||j.solank...@yahoo.com --- Comment #3 from jaydeep --- Update libepub. What you are suffering from was a bug in libepub, which has been fixed in newer versions. -- 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] TextDocument Multithreading
On Thu, Sep 26, 2013 at 11:50 PM, Jaydeep Solanki wrote: > I have created a small project, uploaded to g...@git.kde.org: > scratch/jsolanki/TxtDocumentTest01 > may be u'll get a permission denied error when configuring, *fix :* either run cmake as root or change the install_prefix and run configure again. May be there's a better way to do what I'm doing with CMake but I'm not so good at it, thus did something that requires little bit of change but works. > > May be you'd like to have a look at it. > I have (extracted and) uploaded the file that made it crash the most, to > data folder in that repo. > > & It doesn't crash. > > > On Wed, Sep 25, 2013 at 11:48 PM, Jaydeep Solanki wrote: > >> >> >> >> On Wed, Sep 25, 2013 at 11:40 PM, Albert Astals Cid wrote: >> >>> El Dimecres, 25 de setembre de 2013, a les 23:19:11, Jaydeep Solanki va >>> escriure: >>> > On Wed, Sep 25, 2013 at 11:01 PM, Jaydeep Solanki >>> wrote: >>> > > Running it under helgrind, gives >>> > > this<https://www.dropbox.com/s/5v3bh1v6le8adkr/helg.txt>output. >>> > > >>> > > It shows a warning near the region where we get a crash saying >>> "*conflicts >>> > > with a previous write of size 4 by thread #4*", L117 in helgrind >>> output >>> > > file >>> > > >>> > > Also, can you please throw some light on what the warning is trying >>> to >>> > > say. What is a 'conflict on previous write' ? >>> > >>> > I read the documentation and understood what it is, but it doesn't >>> give any >>> > insight about what's going wrong. >>> > >>> > BTW, I tried a few times with helgrind & it didn't crash. >>> >>> Yeah, it may go so slow that it doesn't really race/crash itself. >>> >>> I am betting on saying "this is a bug in Qt" but let's prove it first ;-) >>> >>> My suggestion, do this: Write a simple program that spawns two threads, >>> in >>> each thread you create a QTextDocument, add some text to it and then >>> simply >>> loop its rendering to a QImage forever. >>> >>> Let's see if that crashes or not. If not, we can build up from there >>> trying to >>> make it more like what Okular does until it crashes. >>> >>> You up to it? >>> >> Yes >> >>> >>> Cheers, >>> Albert >>> >>> > >>> > > On Mon, Sep 23, 2013 at 1:40 PM, Jaydeep Solanki >> >wrote: >>> > >> On Mon, Sep 23, 2013 at 3:17 AM, Albert Astals Cid >>> wrote: >>> > >>> El Dilluns, 23 de setembre de 2013, a les 02:05:23, Jaydeep >>> Solanki va >>> > >>> >>> > >>> escriure: >>> > >>> > On Sun, Sep 22, 2013 at 9:21 PM, Albert Astals Cid < >>> aa...@kde.org> >>> > >>> >>> > >>> wrote: >>> > >>> > > El Dissabte, 21 de setembre de 2013, a les 23:16:56, Jaydeep >>> Solanki >>> > >>> >>> > >>> va >>> > >>> >>> > >>> > > escriure: >>> > >>> > > > On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid < >>> aa...@kde.org> >>> > >>> > > >>> > >>> > > wrote: >>> > >>> > > > > El Dissabte, 21 de setembre de 2013, a les 14:50:50, >>> Jaydeep >>> > >>> >>> > >>> Solanki >>> > >>> >>> > >>> > > > > va >>> > >>> > > > > >>> > >>> > > > > escriure: >>> > >>> > > > > > Hi, >>> > >>> > > > > >>> > >>> > > > > Hi >>> > >>> > > > > >>> > >>> > > > > > @Albert, >>> > >>> > > > > > Welcome back :) >>> > >>> > > > > >>> > >>> > > > > Thanks :-) >>> > >>> > > > > >>> > >>> > > > > > As you might be aware GSoC is coming to an end, I want >>> to wrap >>> > >>> > > > > > thin
Re: [Okular-devel] TextDocument Multithreading
I have created a small project, uploaded to g...@git.kde.org: scratch/jsolanki/TxtDocumentTest01 May be you'd like to have a look at it. I have (extracted and) uploaded the file that made it crash the most, to data folder in that repo. & It doesn't crash. On Wed, Sep 25, 2013 at 11:48 PM, Jaydeep Solanki wrote: > > > > On Wed, Sep 25, 2013 at 11:40 PM, Albert Astals Cid wrote: > >> El Dimecres, 25 de setembre de 2013, a les 23:19:11, Jaydeep Solanki va >> escriure: >> > On Wed, Sep 25, 2013 at 11:01 PM, Jaydeep Solanki >> wrote: >> > > Running it under helgrind, gives >> > > this<https://www.dropbox.com/s/5v3bh1v6le8adkr/helg.txt>output. >> > > >> > > It shows a warning near the region where we get a crash saying >> "*conflicts >> > > with a previous write of size 4 by thread #4*", L117 in helgrind >> output >> > > file >> > > >> > > Also, can you please throw some light on what the warning is trying to >> > > say. What is a 'conflict on previous write' ? >> > >> > I read the documentation and understood what it is, but it doesn't give >> any >> > insight about what's going wrong. >> > >> > BTW, I tried a few times with helgrind & it didn't crash. >> >> Yeah, it may go so slow that it doesn't really race/crash itself. >> >> I am betting on saying "this is a bug in Qt" but let's prove it first ;-) >> >> My suggestion, do this: Write a simple program that spawns two threads, in >> each thread you create a QTextDocument, add some text to it and then >> simply >> loop its rendering to a QImage forever. >> >> Let's see if that crashes or not. If not, we can build up from there >> trying to >> make it more like what Okular does until it crashes. >> >> You up to it? >> > Yes > >> >> Cheers, >> Albert >> >> > >> > > On Mon, Sep 23, 2013 at 1:40 PM, Jaydeep Solanki > >wrote: >> > >> On Mon, Sep 23, 2013 at 3:17 AM, Albert Astals Cid >> wrote: >> > >>> El Dilluns, 23 de setembre de 2013, a les 02:05:23, Jaydeep Solanki >> va >> > >>> >> > >>> escriure: >> > >>> > On Sun, Sep 22, 2013 at 9:21 PM, Albert Astals Cid > > >> > >>> >> > >>> wrote: >> > >>> > > El Dissabte, 21 de setembre de 2013, a les 23:16:56, Jaydeep >> Solanki >> > >>> >> > >>> va >> > >>> >> > >>> > > escriure: >> > >>> > > > On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid < >> aa...@kde.org> >> > >>> > > >> > >>> > > wrote: >> > >>> > > > > El Dissabte, 21 de setembre de 2013, a les 14:50:50, Jaydeep >> > >>> >> > >>> Solanki >> > >>> >> > >>> > > > > va >> > >>> > > > > >> > >>> > > > > escriure: >> > >>> > > > > > Hi, >> > >>> > > > > >> > >>> > > > > Hi >> > >>> > > > > >> > >>> > > > > > @Albert, >> > >>> > > > > > Welcome back :) >> > >>> > > > > >> > >>> > > > > Thanks :-) >> > >>> > > > > >> > >>> > > > > > As you might be aware GSoC is coming to an end, I want to >> wrap >> > >>> > > > > > things >> > >>> > > > > > up. >> > >>> > > > > > >> > >>> > > > > > I have a few days, and I want to finish multi-threading >> > >>> >> > >>> support for >> > >>> >> > >>> > > > > > ePubs >> > >>> > > > > > before GSoC ends. I have created a patch, but it crashes >> > >>> >> > >>> sometimes, >> > >>> >> > >>> > > I'm >> > >>> > > >> > >>> > > > > > unable to find a reason to that. >> > >>> > > > > >> > >>> > > > > Where's the patch?
Re: [Okular-devel] Review Request 109364: Get background color from KColorScheme (kde system settings)
> On July 21, 2013, 9:07 p.m., Albert Astals Cid wrote: > > Jaydeep, can you confirm you are working so that > > http://bugs.kde.org/attachment.cgi?id=51488 can be correctly seen in a dark > > colorscheme? > > Jaydeep Solanki wrote: > I tried it, with color scheme "Krita-darker" (background colors dark & > foreground colors light). > Here's how it looks, http://db.tt/iHkjbxN1 > > Am I missing something ? > > Jaydeep Solanki wrote: > ok, I can reproduce it now. > > Albert Astals Cid wrote: > So Jaydeep do we have a fix? is this fix correct? What should we do > regarding this review request? > > Albert Astals Cid wrote: > Jaydeep? I agree with Albert, this isn't a proper fix. There are chances of having black on black! Just try your patch, with http://bugs.kde.org/attachment.cgi?id=51488, and you'll know what we are trying to say. ( use dark color scheme ) BTW, I don't think making the user switch color schemes just to view a simple epub is the solution. Make him like Okular :) - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109364/#review36250 --- On July 21, 2013, 9:06 p.m., Azat Khuzhin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109364/ > ------- > > (Updated July 21, 2013, 9:06 p.m.) > > > Review request for Okular and Jaydeep Solanki. > > > Description > --- > > Instead of just force it to white. > > This must fix bug 306572. > https://bugs.kde.org/show_bug.cgi?id=306572 > > > This addresses bug 306572. > http://bugs.kde.org/show_bug.cgi?id=306572 > > > Diffs > - > > core/textdocumentgenerator.cpp f370ded > > Diff: http://git.reviewboard.kde.org/r/109364/diff/ > > > Testing > --- > > > Thanks, > > Azat Khuzhin > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111681: TextDocumentGenerator: Use black as default text color
> On Sept. 26, 2013, 2:10 a.m., Albert Astals Cid wrote: > > I'm again confused, isn't the idea that we respect the colors specified on > > the file? Or not? Jaydeep, what's the final decision we took? > > Christoph Feck wrote: > Albert, the issue is that some documents do not indicate text color, they > just assume. > > Albert Astals Cid wrote: > Right, so if they assume and we follow the color scheme, all is nice, no? > You'll get your weird black on red as defined on your color scheme? Or that's > something we don't like and we want it to be black on white not obeying your > color scheme? > > Christoph Feck wrote: > Yes, you can follow the color scheme, but then you have to do it for both > background and foreground. But right now, Okular uses a white background. > > In the description I explained why I think following the color scheme > might be bad: If you follow the color scheme, then you can break (i.e. render > invisible) documents that _do_ set text colors, especially for users that use > a dark color scheme. > > Of course, a third option would be to ignore all colors in the document, > and force both background and foreground to use the color scheme, but then > "colorful" documents would look boring. > > Albert Astals Cid wrote: > Why would someone set the text color and not the background color? Does > that happen? Okay, here's what we need : i) if text color is explicitly specified in html/css use that, else use black. ii) if background color is specified use that, else use white. iii)link color should be independent of the color scheme ( i.e. it should be blue ) What your patch does, i) if no color is specified, it uses black for text, but if a color is specified it uses that color ( I checked ). ii) Link color still depends on the color scheme. ( I saw you have included a line to set the link color to blue, but it follows the theme color ) It would be nice if you can do something about he background color too, because the implementation that we have in epubs takes care of that (see branch 'epub-qtextdoc'). - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111681/#review40816 --- On Aug. 20, 2013, 4:10 p.m., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111681/ > --- > > (Updated Aug. 20, 2013, 4:10 p.m.) > > > Review request for Okular. > > > Description > --- > > As indicated in bug 322547, some documents do not specify a text color, and > probably assume the default text color to be black. QTextDocument, however, > defaults to using the system text color. > > This patch changes the default text color to Qt::black. It should affect > epub, fb2, odt, and plain text generators. > > I think it is better to use this approach instead of changing the paper color > to use the system background color (see bug 253583), because > > 1) the document might specify a text color in some places, > > 2) the user is able to change the fg/bg colors anyway using Okular's > Accessibility options, and those probably expect black on white. > > > This addresses bugs 253583 and 322547. > http://bugs.kde.org/show_bug.cgi?id=253583 > http://bugs.kde.org/show_bug.cgi?id=322547 > > > Diffs > - > > core/textdocumentgenerator.cpp b260b3f > > Diff: http://git.reviewboard.kde.org/r/111681/diff/ > > > Testing > --- > > I tested the document from bug 322547 comment #3. > > > Thanks, > > Christoph Feck > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] TextDocument Multithreading
On Wed, Sep 25, 2013 at 11:40 PM, Albert Astals Cid wrote: > El Dimecres, 25 de setembre de 2013, a les 23:19:11, Jaydeep Solanki va > escriure: > > On Wed, Sep 25, 2013 at 11:01 PM, Jaydeep Solanki > wrote: > > > Running it under helgrind, gives > > > this<https://www.dropbox.com/s/5v3bh1v6le8adkr/helg.txt>output. > > > > > > It shows a warning near the region where we get a crash saying > "*conflicts > > > with a previous write of size 4 by thread #4*", L117 in helgrind output > > > file > > > > > > Also, can you please throw some light on what the warning is trying to > > > say. What is a 'conflict on previous write' ? > > > > I read the documentation and understood what it is, but it doesn't give > any > > insight about what's going wrong. > > > > BTW, I tried a few times with helgrind & it didn't crash. > > Yeah, it may go so slow that it doesn't really race/crash itself. > > I am betting on saying "this is a bug in Qt" but let's prove it first ;-) > > My suggestion, do this: Write a simple program that spawns two threads, in > each thread you create a QTextDocument, add some text to it and then simply > loop its rendering to a QImage forever. > > Let's see if that crashes or not. If not, we can build up from there > trying to > make it more like what Okular does until it crashes. > > You up to it? > Yes > > Cheers, > Albert > > > > > > On Mon, Sep 23, 2013 at 1:40 PM, Jaydeep Solanki >wrote: > > >> On Mon, Sep 23, 2013 at 3:17 AM, Albert Astals Cid > wrote: > > >>> El Dilluns, 23 de setembre de 2013, a les 02:05:23, Jaydeep Solanki > va > > >>> > > >>> escriure: > > >>> > On Sun, Sep 22, 2013 at 9:21 PM, Albert Astals Cid > > >>> > > >>> wrote: > > >>> > > El Dissabte, 21 de setembre de 2013, a les 23:16:56, Jaydeep > Solanki > > >>> > > >>> va > > >>> > > >>> > > escriure: > > >>> > > > On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid < > aa...@kde.org> > > >>> > > > > >>> > > wrote: > > >>> > > > > El Dissabte, 21 de setembre de 2013, a les 14:50:50, Jaydeep > > >>> > > >>> Solanki > > >>> > > >>> > > > > va > > >>> > > > > > > >>> > > > > escriure: > > >>> > > > > > Hi, > > >>> > > > > > > >>> > > > > Hi > > >>> > > > > > > >>> > > > > > @Albert, > > >>> > > > > > Welcome back :) > > >>> > > > > > > >>> > > > > Thanks :-) > > >>> > > > > > > >>> > > > > > As you might be aware GSoC is coming to an end, I want to > wrap > > >>> > > > > > things > > >>> > > > > > up. > > >>> > > > > > > > >>> > > > > > I have a few days, and I want to finish multi-threading > > >>> > > >>> support for > > >>> > > >>> > > > > > ePubs > > >>> > > > > > before GSoC ends. I have created a patch, but it crashes > > >>> > > >>> sometimes, > > >>> > > >>> > > I'm > > >>> > > > > >>> > > > > > unable to find a reason to that. > > >>> > > > > > > >>> > > > > Where's the patch? > > >>> > > > > > >>> > > > Diff attached > > >>> > > > > > >>> > > > File to test on : > > >>> > > > link< > > >>> > > >>> > https://www.dropbox.com/s/x63kkjf8q4h4fdy/Getting%20Gold%20by%20J_C_F_J > > >>> > > >>> > > > ohnson.epub> > > >>> > > > > > >>> > > > > Do you have a backtrace of the crash? > > >>> > > > > > >>> > > > I have got two different backtraces, using the same ePub > > >>> > > > > > >>> > > > Backtrace 1 :
Re: [Okular-devel] TextDocument Multithreading
On Wed, Sep 25, 2013 at 11:01 PM, Jaydeep Solanki wrote: > Running it under helgrind, gives > this<https://www.dropbox.com/s/5v3bh1v6le8adkr/helg.txt>output. > > It shows a warning near the region where we get a crash saying "*conflicts > with a previous write of size 4 by thread #4*", L117 in helgrind output > file > > Also, can you please throw some light on what the warning is trying to > say. What is a 'conflict on previous write' ? > I read the documentation and understood what it is, but it doesn't give any insight about what's going wrong. BTW, I tried a few times with helgrind & it didn't crash. > > > On Mon, Sep 23, 2013 at 1:40 PM, Jaydeep Solanki wrote: > >> >> >> >> On Mon, Sep 23, 2013 at 3:17 AM, Albert Astals Cid wrote: >> >>> El Dilluns, 23 de setembre de 2013, a les 02:05:23, Jaydeep Solanki va >>> escriure: >>> > On Sun, Sep 22, 2013 at 9:21 PM, Albert Astals Cid >>> wrote: >>> > > El Dissabte, 21 de setembre de 2013, a les 23:16:56, Jaydeep Solanki >>> va >>> > > >>> > > escriure: >>> > > > On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid >>> > > >>> > > wrote: >>> > > > > El Dissabte, 21 de setembre de 2013, a les 14:50:50, Jaydeep >>> Solanki >>> > > > > va >>> > > > > >>> > > > > escriure: >>> > > > > > Hi, >>> > > > > >>> > > > > Hi >>> > > > > >>> > > > > > @Albert, >>> > > > > > Welcome back :) >>> > > > > >>> > > > > Thanks :-) >>> > > > > >>> > > > > > As you might be aware GSoC is coming to an end, I want to wrap >>> > > > > > things >>> > > > > > up. >>> > > > > > >>> > > > > > I have a few days, and I want to finish multi-threading >>> support for >>> > > > > > ePubs >>> > > > > > before GSoC ends. I have created a patch, but it crashes >>> sometimes, >>> > > >>> > > I'm >>> > > >>> > > > > > unable to find a reason to that. >>> > > > > >>> > > > > Where's the patch? >>> > > > >>> > > > Diff attached >>> > > > >>> > > > File to test on : >>> > > > link< >>> > > >>> > > >>> https://www.dropbox.com/s/x63kkjf8q4h4fdy/Getting%20Gold%20by%20J_C_F_J >>> > > >>> > > > ohnson.epub> >>> > > > >>> > > > > Do you have a backtrace of the crash? >>> > > > >>> > > > I have got two different backtraces, using the same ePub >>> > > > >>> > > > Backtrace 1 : http://paste.kde.org/p0b9a1e1e/ >>> > > > >>> > > > Backtrace 2 : http://paste.kde.org/pa4e31b12/ >>> > > >>> > > Any reason you have not installed debug symbols for Qt to get a >>> better >>> > > bracktrace (less ??)? >>> > >>> > Installed it. >>> > still I'm not able to make any sense out of it. >>> > >>> > Updated backtrace : http://paste.kde.org/pa8f27933/ >>> >>> How are you getting the backtrace? >> >> I use Qt Creator, when it crashes I use create full backtrace option to >> get this backtrace. >> Further more using gdb + terminal I get >> this<http://paste.kde.org/p11fad1cf/>backtrace. >> >> Can you mark in which thread the crash is >>> happening? >>> >> I get an ABORT signal when TextDocumentGeneratorPrivate::createTextPage(. >> . .) is called inside core/textdocumentgenerator.cpp. Now inside that 99% >> of the times I get a crash on L81 (my branch). >> >>> >>> Cheers, >>> Albert >>> >>> > >>> > > Cheers, >>> > > >>> > > Albert >>> > > >>> > > > > What has changed >>> > > > > since last time we tried to do this? >>> > > > >>> > > > I have noticed that it only crashes when the epub has an adequate >>> amount >>> > > >>> > > of >>> > > >>> > > > images. Epubs with no images or 1 or 2 images are less likely to >>> crash. >>> > > >>> > > The >>> > > >>> > > > more the images the more likely it is to crash. >>> > > > >>> > > > Now we don't have to guess if it will crash on this file or not. >>> > > > Considering all this, I have given you an ePub that is most likely >>> to >>> > > >>> > > crash >>> > > >>> > > > atleast once before completing a round trip (top to bottom & >>> bottom to >>> > > > top). >>> > > > >>> > > > > Cheers, >>> > > > > >>> > > > > Albert >>> > > > > >>> > > > > > So, can we please help, me get this done. >>> > > > > > It's the same bug that we once tried to fix on IRC. >>> > > > > > >>> > > > > > I'll be available on #okular, same time as usual. >>> > > > > > >>> > > > > > 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] TextDocument Multithreading
Running it under helgrind, gives this<https://www.dropbox.com/s/5v3bh1v6le8adkr/helg.txt>output. It shows a warning near the region where we get a crash saying "*conflicts with a previous write of size 4 by thread #4*", L117 in helgrind output file Also, can you please throw some light on what the warning is trying to say. What is a 'conflict on previous write' ? On Mon, Sep 23, 2013 at 1:40 PM, Jaydeep Solanki wrote: > > > > On Mon, Sep 23, 2013 at 3:17 AM, Albert Astals Cid wrote: > >> El Dilluns, 23 de setembre de 2013, a les 02:05:23, Jaydeep Solanki va >> escriure: >> > On Sun, Sep 22, 2013 at 9:21 PM, Albert Astals Cid >> wrote: >> > > El Dissabte, 21 de setembre de 2013, a les 23:16:56, Jaydeep Solanki >> va >> > > >> > > escriure: >> > > > On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid >> > > >> > > wrote: >> > > > > El Dissabte, 21 de setembre de 2013, a les 14:50:50, Jaydeep >> Solanki >> > > > > va >> > > > > >> > > > > escriure: >> > > > > > Hi, >> > > > > >> > > > > Hi >> > > > > >> > > > > > @Albert, >> > > > > > Welcome back :) >> > > > > >> > > > > Thanks :-) >> > > > > >> > > > > > As you might be aware GSoC is coming to an end, I want to wrap >> > > > > > things >> > > > > > up. >> > > > > > >> > > > > > I have a few days, and I want to finish multi-threading support >> for >> > > > > > ePubs >> > > > > > before GSoC ends. I have created a patch, but it crashes >> sometimes, >> > > >> > > I'm >> > > >> > > > > > unable to find a reason to that. >> > > > > >> > > > > Where's the patch? >> > > > >> > > > Diff attached >> > > > >> > > > File to test on : >> > > > link< >> > > >> > > >> https://www.dropbox.com/s/x63kkjf8q4h4fdy/Getting%20Gold%20by%20J_C_F_J >> > > >> > > > ohnson.epub> >> > > > >> > > > > Do you have a backtrace of the crash? >> > > > >> > > > I have got two different backtraces, using the same ePub >> > > > >> > > > Backtrace 1 : http://paste.kde.org/p0b9a1e1e/ >> > > > >> > > > Backtrace 2 : http://paste.kde.org/pa4e31b12/ >> > > >> > > Any reason you have not installed debug symbols for Qt to get a better >> > > bracktrace (less ??)? >> > >> > Installed it. >> > still I'm not able to make any sense out of it. >> > >> > Updated backtrace : http://paste.kde.org/pa8f27933/ >> >> How are you getting the backtrace? > > I use Qt Creator, when it crashes I use create full backtrace option to > get this backtrace. > Further more using gdb + terminal I get > this<http://paste.kde.org/p11fad1cf/>backtrace. > > Can you mark in which thread the crash is >> happening? >> > I get an ABORT signal when TextDocumentGeneratorPrivate::createTextPage(. > . .) is called inside core/textdocumentgenerator.cpp. Now inside that 99% > of the times I get a crash on L81 (my branch). > >> >> Cheers, >> Albert >> >> > >> > > Cheers, >> > > >> > > Albert >> > > >> > > > > What has changed >> > > > > since last time we tried to do this? >> > > > >> > > > I have noticed that it only crashes when the epub has an adequate >> amount >> > > >> > > of >> > > >> > > > images. Epubs with no images or 1 or 2 images are less likely to >> crash. >> > > >> > > The >> > > >> > > > more the images the more likely it is to crash. >> > > > >> > > > Now we don't have to guess if it will crash on this file or not. >> > > > Considering all this, I have given you an ePub that is most likely >> to >> > > >> > > crash >> > > >> > > > atleast once before completing a round trip (top to bottom & bottom >> to >> > > > top). >> > > > >> > > > > Cheers, >> > > > > >> > > > > Albert >> > > > > >> > > > > > So, can we please help, me get this done. >> > > > > > It's the same bug that we once tried to fix on IRC. >> > > > > > >> > > > > > I'll be available on #okular, same time as usual. >> > > > > > >> > > > > > 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] List of bugs / features finished during GSoC
Done! On Wed, Sep 25, 2013 at 4:37 AM, Albert Astals Cid wrote: > El Dimarts, 24 de setembre de 2013, a les 18:28:09, Jaydeep Solanki va > escriure: > > On Tue, Sep 24, 2013 at 2:08 AM, Albert Astals Cid > wrote: > > > El Dimarts, 24 de setembre de 2013, a les 01:44:35, Jaydeep Solanki va > > > > > > escriure: > > > > Hi, > > > > > > > > Here's a link > > > > <https://www.dropbox.com/s/wl8yobpk6oc6i79/GSoC%20patches.pdf>to a > file > > > > showing all the bug fixes and features implemented by me during GSoC. > > > > > > > > P.S. I have ignored small and tiny commits. > > > > > > Nice, can you please make sure you merge master to your branch? > > > > 'master' to 'epub-qtextdoc' ? > > Yes > > > is this just for testing if there are any > > conflicts ? > > It is also that I can diff the branches more easily. > > > > > Or did you mean, 'epub-qtextdoc' to 'master' ? > > No, I don't want you to merge all your stuff to master without review. > > > Cheers, > Albert > > > > > > Cheers, > > > > > > Albert > > > > > > > Had a great time! > > > > More importantly learned a lot, and all the credit goes to 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
Re: [Okular-devel] List of bugs / features finished during GSoC
On Tue, Sep 24, 2013 at 2:08 AM, Albert Astals Cid wrote: > El Dimarts, 24 de setembre de 2013, a les 01:44:35, Jaydeep Solanki va > escriure: > > Hi, > > > > Here's a link > > <https://www.dropbox.com/s/wl8yobpk6oc6i79/GSoC%20patches.pdf>to a file > > showing all the bug fixes and features implemented by me during GSoC. > > > > P.S. I have ignored small and tiny commits. > > Nice, can you please make sure you merge master to your branch? > 'master' to 'epub-qtextdoc' ? is this just for testing if there are any conflicts ? Or did you mean, 'epub-qtextdoc' to 'master' ? > > Cheers, > Albert > > > > > > > Had a great time! > > More importantly learned a lot, and all the credit goes to 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] List of bugs / features finished during GSoC
Hi, Here's a link <https://www.dropbox.com/s/wl8yobpk6oc6i79/GSoC%20patches.pdf>to a file showing all the bug fixes and features implemented by me during GSoC. P.S. I have ignored small and tiny commits. Had a great time! More importantly learned a lot, and all the credit goes to Albert. :) Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] TextDocument Multithreading
On Mon, Sep 23, 2013 at 3:17 AM, Albert Astals Cid wrote: > El Dilluns, 23 de setembre de 2013, a les 02:05:23, Jaydeep Solanki va > escriure: > > On Sun, Sep 22, 2013 at 9:21 PM, Albert Astals Cid > wrote: > > > El Dissabte, 21 de setembre de 2013, a les 23:16:56, Jaydeep Solanki va > > > > > > escriure: > > > > On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid > > > > > > wrote: > > > > > El Dissabte, 21 de setembre de 2013, a les 14:50:50, Jaydeep > Solanki > > > > > va > > > > > > > > > > escriure: > > > > > > Hi, > > > > > > > > > > Hi > > > > > > > > > > > @Albert, > > > > > > Welcome back :) > > > > > > > > > > Thanks :-) > > > > > > > > > > > As you might be aware GSoC is coming to an end, I want to wrap > > > > > > things > > > > > > up. > > > > > > > > > > > > I have a few days, and I want to finish multi-threading support > for > > > > > > ePubs > > > > > > before GSoC ends. I have created a patch, but it crashes > sometimes, > > > > > > I'm > > > > > > > > > unable to find a reason to that. > > > > > > > > > > Where's the patch? > > > > > > > > Diff attached > > > > > > > > File to test on : > > > > link< > > > > > > > https://www.dropbox.com/s/x63kkjf8q4h4fdy/Getting%20Gold%20by%20J_C_F_J > > > > > > > ohnson.epub> > > > > > > > > > Do you have a backtrace of the crash? > > > > > > > > I have got two different backtraces, using the same ePub > > > > > > > > Backtrace 1 : http://paste.kde.org/p0b9a1e1e/ > > > > > > > > Backtrace 2 : http://paste.kde.org/pa4e31b12/ > > > > > > Any reason you have not installed debug symbols for Qt to get a better > > > bracktrace (less ??)? > > > > Installed it. > > still I'm not able to make any sense out of it. > > > > Updated backtrace : http://paste.kde.org/pa8f27933/ > > How are you getting the backtrace? I use Qt Creator, when it crashes I use create full backtrace option to get this backtrace. Further more using gdb + terminal I get this<http://paste.kde.org/p11fad1cf/>backtrace. Can you mark in which thread the crash is > happening? > I get an ABORT signal when TextDocumentGeneratorPrivate::createTextPage(. . .) is called inside core/textdocumentgenerator.cpp. Now inside that 99% of the times I get a crash on L81 (my branch). > > Cheers, > Albert > > > > > > Cheers, > > > > > > Albert > > > > > > > > What has changed > > > > > since last time we tried to do this? > > > > > > > > I have noticed that it only crashes when the epub has an adequate > amount > > > > > > of > > > > > > > images. Epubs with no images or 1 or 2 images are less likely to > crash. > > > > > > The > > > > > > > more the images the more likely it is to crash. > > > > > > > > Now we don't have to guess if it will crash on this file or not. > > > > Considering all this, I have given you an ePub that is most likely to > > > > > > crash > > > > > > > atleast once before completing a round trip (top to bottom & bottom > to > > > > top). > > > > > > > > > Cheers, > > > > > > > > > > Albert > > > > > > > > > > > So, can we please help, me get this done. > > > > > > It's the same bug that we once tried to fix on IRC. > > > > > > > > > > > > I'll be available on #okular, same time as usual. > > > > > > > > > > > > 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] TextDocument Multithreading
On Sun, Sep 22, 2013 at 9:21 PM, Albert Astals Cid wrote: > El Dissabte, 21 de setembre de 2013, a les 23:16:56, Jaydeep Solanki va > escriure: > > On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid > wrote: > > > El Dissabte, 21 de setembre de 2013, a les 14:50:50, Jaydeep Solanki va > > > > > > escriure: > > > > Hi, > > > > > > Hi > > > > > > > @Albert, > > > > Welcome back :) > > > > > > Thanks :-) > > > > > > > As you might be aware GSoC is coming to an end, I want to wrap things > > > > up. > > > > > > > > I have a few days, and I want to finish multi-threading support for > > > > ePubs > > > > before GSoC ends. I have created a patch, but it crashes sometimes, > I'm > > > > unable to find a reason to that. > > > > > > Where's the patch? > > > > Diff attached > > > > File to test on : > > link< > https://www.dropbox.com/s/x63kkjf8q4h4fdy/Getting%20Gold%20by%20J_C_F_J > > ohnson.epub> > > > Do you have a backtrace of the crash? > > > > I have got two different backtraces, using the same ePub > > > > Backtrace 1 : http://paste.kde.org/p0b9a1e1e/ > > > > Backtrace 2 : http://paste.kde.org/pa4e31b12/ > > Any reason you have not installed debug symbols for Qt to get a better > bracktrace (less ??)? > Installed it. still I'm not able to make any sense out of it. Updated backtrace : http://paste.kde.org/pa8f27933/ > > Cheers, > Albert > > > > > > What has changed > > > since last time we tried to do this? > > > > I have noticed that it only crashes when the epub has an adequate amount > of > > images. Epubs with no images or 1 or 2 images are less likely to crash. > The > > more the images the more likely it is to crash. > > > > Now we don't have to guess if it will crash on this file or not. > > Considering all this, I have given you an ePub that is most likely to > crash > > atleast once before completing a round trip (top to bottom & bottom to > > top). > > > > > Cheers, > > > > > > Albert > > > > > > > So, can we please help, me get this done. > > > > It's the same bug that we once tried to fix on IRC. > > > > > > > > I'll be available on #okular, same time as usual. > > > > > > > > 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
Re: [Okular-devel] TextDocument Multithreading
On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid wrote: > El Dissabte, 21 de setembre de 2013, a les 14:50:50, Jaydeep Solanki va > escriure: > > Hi, > > Hi > > > > > @Albert, > > Welcome back :) > > Thanks :-) > > > > > As you might be aware GSoC is coming to an end, I want to wrap things up. > > > > I have a few days, and I want to finish multi-threading support for ePubs > > before GSoC ends. I have created a patch, but it crashes sometimes, I'm > > unable to find a reason to that. > > Where's the patch? Diff attached File to test on : link<https://www.dropbox.com/s/x63kkjf8q4h4fdy/Getting%20Gold%20by%20J_C_F_Johnson.epub> > Do you have a backtrace of the crash? I have got two different backtraces, using the same ePub Backtrace 1 : http://paste.kde.org/p0b9a1e1e/ Backtrace 2 : http://paste.kde.org/pa4e31b12/ > What has changed > since last time we tried to do this? > I have noticed that it only crashes when the epub has an adequate amount of images. Epubs with no images or 1 or 2 images are less likely to crash. The more the images the more likely it is to crash. Now we don't have to guess if it will crash on this file or not. Considering all this, I have given you an ePub that is most likely to crash atleast once before completing a round trip (top to bottom & bottom to top). > > Cheers, > Albert > > > > > So, can we please help, me get this done. > > It's the same bug that we once tried to fix on IRC. > > > > I'll be available on #okular, same time as usual. > > > > Cheers, > > Jaydeep > > ___ > Okular-devel mailing list > Okular-devel@kde.org > https://mail.kde.org/mailman/listinfo/okular-devel > ePubThreading.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] TextDocument Multithreading
Hi, @Albert, Welcome back :) As you might be aware GSoC is coming to an end, I want to wrap things up. I have a few days, and I want to finish multi-threading support for ePubs before GSoC ends. I have created a patch, but it crashes sometimes, I'm unable to find a reason to that. So, can we please help, me get this done. It's the same bug that we once tried to fix on IRC. I'll be available on #okular, same time as usual. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Test embedded audio - Epub
Hi, Anyone interested in testing patch related to epub containing embedded audio ? Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Epub video support - done!
Hi, As you all might be knowing, I was struggling a lot to make this happen, it has come to an end. It's working fine with me. But during this process, I removed a line of code, which I didn't understand and without it everything's working fine. Just to make sure I don't break anything after committing it, I would like to know what is that line of code doing? here's the link<https://projects.kde.org/projects/kde/kdegraphics/okular/repository/revisions/master/entry/core/textdocumentgenerator.cpp#L323>to it. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Struggling with Annotations
Hi, Guys, as Albert (who was a great helping hand to me) is away, it would be great if you all can fill in :) Problem : Unable to position video widget. Here's what we know till now : - As epubs use TextDocuments, in core/textdocumentgenerator.cpp there's a signal named addAnnotation(annot, startCursorPos, endCursorPos). It adds the annotations, but I'm not sure if startCursorPos & endCursorPos is of any use. I tried out some experiments and it resulted that no matter what positions I give it renders the annotation the same place. ( I even tried it with line annotation ) - So, the cursor positions aren't helpful - Next what comes to mind is MovieAnnotation::setBoundingRectangle(NormalizedRect), I don't know why but this too doesn't work. - Also I always have to specify the video size to the video widget otherwise the video widget takes up the whole page, which is not too big problem, it can be fixed. - Despite of whatever I do the video widget is stuck at (0,0) with a fixed size. I tried to read all the code and figure it out myself, but it's a lot to digest for me. Also it always requires me a huge amount of time to understand someone else's code. Here's a link <https://www.dropbox.com/s/vg07jr0kolzn6u0/videoEpub.epub> to an epub containing video. *Any help is appreciated.* Thank you. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] TextDocument - Annotations
Hi, Anyone who has ever worked with annotations, more specifically annotations with TextDocument, please respond back. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Patch test
Hello, I'm working to get videos working in epubs, and I'm not sure if it's my Phonon Gstreamer backend that's causing problem or what. So if someone can help me test my patch it would be great. I have attached the patch, use branch 'epub-qtextdocument', and here's the link <https://www.dropbox.com/s/vg07jr0kolzn6u0/videoEpub.epub> to the file to test. Please let me know if the video inside the epub plays or not. Thank you. Cheers, Jaydeep movieannot.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 28th August - status
On Thu, Aug 29, 2013 at 2:41 AM, Fabio D'Urso wrote: > On Thursday, August 29, 2013 01:23:48 AM Jaydeep Solanki wrote: > > On Wed, Aug 28, 2013 at 2:00 AM, Jaydeep Solanki > wrote: > > > Hi, > > > > > > I noticed that the (movie) annotation version actually works, it's just > > > that it takes a few seconds to start. > > > > > > Current status is I can hear the video playing but no visual. > > > > I have visual now, working on playing video using raw data, and fixing > > position of video widget, currently it's displayed at (0,0). > > Hi, > > In case it's relevant for your work, there's an interesting comment about > playing from QByteArray in core/movie.cpp > Yeah, I saw it, but according to the comment, it should be fixed. No ? Also in generators/epub/epubdocument.cpp::loadResource(..) when I load video, I get data = "" and size = the size of the video file in bits. Result, is the video doesn't get played. :/ > > Fabio > > > > > > To debug this, I turned off a lot of features like drawingContent > (because > > > the video player is not drawn using converter), turned off the > textpages, > > > etc. > > > Now what I see are random lines, which I guess was supposed to be the > > > video. > > > > > > Plus, the audio doesn't play when loading movie from QByteArray, but > works > > > when using a file from other location (which I used to test). Seems to > be > > > a > > > minor bug, will be easy to fix once I get at least something working. > > > > > > Note : if you want to try out what I'm seeing, a patch is attached, > and if > > > you might have seen something similar it would be helpful. > > > > > > Epub > > > link< > https://epub-samples.googlecode.com/files/cc-shared-culture-20120130 > > > .epub>to test. > > > > > > 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
Re: [Okular-devel] Dt. 28th August - status
On Wed, Aug 28, 2013 at 2:00 AM, Jaydeep Solanki wrote: > Hi, > > I noticed that the (movie) annotation version actually works, it's just > that it takes a few seconds to start. > > Current status is I can hear the video playing but no visual. > I have visual now, working on playing video using raw data, and fixing position of video widget, currently it's displayed at (0,0). > To debug this, I turned off a lot of features like drawingContent (because > the video player is not drawn using converter), turned off the textpages, > etc. > Now what I see are random lines, which I guess was supposed to be the > video. > > Plus, the audio doesn't play when loading movie from QByteArray, but works > when using a file from other location (which I used to test). Seems to be a > minor bug, will be easy to fix once I get at least something working. > > Note : if you want to try out what I'm seeing, a patch is attached, and if > you might have seen something similar it would be helpful. > > Epub > link<https://epub-samples.googlecode.com/files/cc-shared-culture-20120130.epub>to > test. > > Cheers, > Jaydeep > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 28th August - status
Hi, I noticed that the (movie) annotation version actually works, it's just that it takes a few seconds to start. Current status is I can hear the video playing but no visual. To debug this, I turned off a lot of features like drawingContent (because the video player is not drawn using converter), turned off the textpages, etc. Now what I see are random lines, which I guess was supposed to be the video. Plus, the audio doesn't play when loading movie from QByteArray, but works when using a file from other location (which I used to test). Seems to be a minor bug, will be easy to fix once I get at least something working. Note : if you want to try out what I'm seeing, a patch is attached, and if you might have seen something similar it would be helpful. Epub link<https://epub-samples.googlecode.com/files/cc-shared-culture-20120130.epub>to test. Cheers, Jaydeep video.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Receiving emails from build.kde.org on build failures
I think it's great, it's definitely better to know if your commit broke something. There might be many people like me who don't build tests, unless it is necessary. ;) On Sat, Aug 24, 2013 at 5:24 PM, Albert Astals Cid wrote: > Hi guys, what do you think about build.kde.org sending this list an email > when > okular[1] fails compiling (or the tests stop passing)? > > I think it's an awesome idea but don't want to tell the sysadmins to flip > the > switch if people here think those emails would be spam. > > Also, hopefully we should not get many of those since people compile and > run > the tests before committing, right? ;-) > > Cheers, > Albert > > [1] http://build.kde.org/view/kdegraphics/job/okular_master/ > [1] http://build.kde.org/view/kdegraphics/job/okular_stable/ > ___ > 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] Multimedia annotations / actions - Dt. 24th August 2013
On Sat, Aug 24, 2013 at 3:01 AM, Albert Astals Cid wrote: > El Dissabte, 24 d'agost de 2013, a les 00:27:34, Jaydeep Solanki va > escriure: > > Hi, > > > > I still have two more exams left, on Monday & Tuesday, but I can work on > > weekend. > > > > In the effort to make ePubs view video and play audio, I previously tried > > Movie annotations, unfortunately it didn't work. > > > > So, I thought may be MovieAction or SoundAction will work, but I was > wrong > > > > :( > > > > I have attached a simple patch, which shows how I'm using Actions. > > I understand that using Actions won't show anything except text in place > of > > video/audio but at least if it works it should play sound. > > > > *If some one finds I'm not using Movie/Sound Actions properly or I'm > > missing something please do respond. Also people who are involved in > > annotations like Audio/Video, I would like to have a little chat, to get > > some info about annotations.* > > > > According to me the only way we can show a video widget over a > > QTextDocument is annotations, we can overlay a video widget over the > > position there is an embedded video. Same is the case for audio. > > Yeah and that's what ui/videowidget.cpp does, no? > Yes, that is done in pageview.cpp, here<https://projects.kde.org/projects/kde/kdegraphics/okular/repository/revisions/master/entry/ui/pageview.cpp#L912>. Every file which contains movie annotation, a videowidget is created for it. Seeing this I added a movie annotation; pageview.cpp does its work by creating a videowidget, but it doesn't show up. Can you please name some people who work on annotations? It will speed things up. > > 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] Multimedia annotations / actions - Dt. 24th August 2013
Hi, I still have two more exams left, on Monday & Tuesday, but I can work on weekend. In the effort to make ePubs view video and play audio, I previously tried Movie annotations, unfortunately it didn't work. So, I thought may be MovieAction or SoundAction will work, but I was wrong :( I have attached a simple patch, which shows how I'm using Actions. I understand that using Actions won't show anything except text in place of video/audio but at least if it works it should play sound. *If some one finds I'm not using Movie/Sound Actions properly or I'm missing something please do respond. Also people who are involved in annotations like Audio/Video, I would like to have a little chat, to get some info about annotations.* According to me the only way we can show a video widget over a QTextDocument is annotations, we can overlay a video widget over the position there is an embedded video. Same is the case for audio. Cheers, Jaydeep actions.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111681: TextDocumentGenerator: Use black as default text color
> On Aug. 17, 2013, 2:28 a.m., Albert Astals Cid wrote: > > To be honest i'm a bit confused by all the different patches trying to fix > > the same thing, there's this one, the other one that tries to use > > kcolorscheme, the other one that tries to let the user choose. > > > > And what I don't understand is why we need these patches. I would > > understand that if an epub sets the background color it will also set the > > text color (so all is fine, none of "our" colors is used) and if no color > > is set, i would undertand that the color scheme by the user provides > > acceptable colors. > > > > So where is the problem? > > Christoph Feck wrote: > The problem is not documents that set colors, but those that set no > colors (for example, plain text files). > > In the rendering code, the pixmap is pre-filled with hard-coded white > color, but the text is actually rendered using the system's foreground color. > This leads to "white on white" with dark color schemes (which usually use > white text). > > There are, as you see, several ways to fix it. Why I believe this one > makes more sense that using the system's background color: See my rationale > at "Description" above. > > Albert Astals Cid wrote: > Ok, can you try Jaydeep's branch epub-qtextdoc according to > https://www.dropbox.com/s/mgf778ug6yjie2l/GSoC%20patches.odt the color issues > are fixed there. Can you confirm? Is the solution acceptable for you? > > Christoph Feck wrote: > From quickly checking commit 1823cf9998555e22c6f3d8701728882dc34b244b > (which is documented to fix the color issue), I see that Jaydeep injects CSS > code to change QTextDocument's default color to Qt::black. While this might > have the same result, my approach is simpler and uses less resources. > > Additionally, it looks like his patch is limited to epub, while my patch > works for all generators that use textdocumentgenerator.cpp? > > Jaydeep might clarify, if I am wrong. > > Christoph Feck wrote: > (Let me add that I wasn't aware about his work while I wrote the patch. I > have no intention to disturb his work.) > > Jaydeep Solanki wrote: > For sure, you patch addresses a bigger issue by fixing this for all > generators that use TextDocumentGenerator. > I'd be happy to remove my patch for this patch, but I'm still not finding > the links in blue color. > Albert can you please confirm, if the links show up in blue. > > Jaydeep Solanki wrote: > Okay, it seems that my color scheme was the culprit for not showing links > in blue. I changed color scheme and now it works. > Albert, IMHO this patch seems more appropriate. The other one with > KColorScheme doesn't seem so good, as it changes the background color of the > document which is not necessary. > > Albert Astals Cid wrote: > Hmmm, well, but you're saying that the links in blue still depend on the > color scheme, no? That's still not good. Christoph any idea why that may > happen? > > Christoph Feck wrote: > I updated the patch to use the (brighter) blue color, instead of > darkBlue. It should now match the color Jaydeep uses. I prefer the darker > version, though, because it makes text with many links easier to read. Christoph, I guess Albert is talking about a scenario when the color scheme has a non blue color for links. Like in my case, I previously used "Krita-dark" color scheme, which has links in white. In such cases too Okular needs to display links in blue. - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111681/#review37994 --- On Aug. 20, 2013, 4:10 p.m., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111681/ > --- > > (Updated Aug. 20, 2013, 4:10 p.m.) > > > Review request for Okular. > > > Description > --- > > As indicated in bug 322547, some documents do not specify a text color, and > probably assume the default text color to be black. QTextDocument, however, > defaults to using the system text color. > > This patch changes the default text color to Qt::black. It should affect > epub, fb2, odt, and plain text generators. > > I think it is better to use this approach instead of changing the paper
Re: [Okular-devel] Review Request 111681: TextDocumentGenerator: Use black as default text color
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111681/#review38048 --- core/textdocumentgenerator.cpp <http://git.reviewboard.kde.org/r/111681/#comment28138> This isn't necessary, after clicking a link, the images aren't going to update. So, if it is never going to be displayed, it's better not to write it. - Jaydeep Solanki On Aug. 17, 2013, 2:28 a.m., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111681/ > --- > > (Updated Aug. 17, 2013, 2:28 a.m.) > > > Review request for Okular. > > > Description > --- > > As indicated in bug 322547, some documents do not specify a text color, and > probably assume the default text color to be black. QTextDocument, however, > defaults to using the system text color. > > This patch changes the default text color to Qt::black. It should affect > epub, fb2, odt, and plain text generators. > > I think it is better to use this approach instead of changing the paper color > to use the system background color (see bug 253583), because > > 1) the document might specify a text color in some places, > > 2) the user is able to change the fg/bg colors anyway using Okular's > Accessibility options, and those probably expect black on white. > > > This addresses bugs 253583 and 322547. > http://bugs.kde.org/show_bug.cgi?id=253583 > http://bugs.kde.org/show_bug.cgi?id=322547 > > > Diffs > - > > core/textdocumentgenerator.cpp b260b3f > > Diff: http://git.reviewboard.kde.org/r/111681/diff/ > > > Testing > --- > > I tested the document from bug 322547 comment #3. > > > Thanks, > > Christoph Feck > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111681: TextDocumentGenerator: Use black as default text color
> On Aug. 17, 2013, 2:28 a.m., Albert Astals Cid wrote: > > To be honest i'm a bit confused by all the different patches trying to fix > > the same thing, there's this one, the other one that tries to use > > kcolorscheme, the other one that tries to let the user choose. > > > > And what I don't understand is why we need these patches. I would > > understand that if an epub sets the background color it will also set the > > text color (so all is fine, none of "our" colors is used) and if no color > > is set, i would undertand that the color scheme by the user provides > > acceptable colors. > > > > So where is the problem? > > Christoph Feck wrote: > The problem is not documents that set colors, but those that set no > colors (for example, plain text files). > > In the rendering code, the pixmap is pre-filled with hard-coded white > color, but the text is actually rendered using the system's foreground color. > This leads to "white on white" with dark color schemes (which usually use > white text). > > There are, as you see, several ways to fix it. Why I believe this one > makes more sense that using the system's background color: See my rationale > at "Description" above. > > Albert Astals Cid wrote: > Ok, can you try Jaydeep's branch epub-qtextdoc according to > https://www.dropbox.com/s/mgf778ug6yjie2l/GSoC%20patches.odt the color issues > are fixed there. Can you confirm? Is the solution acceptable for you? > > Christoph Feck wrote: > From quickly checking commit 1823cf9998555e22c6f3d8701728882dc34b244b > (which is documented to fix the color issue), I see that Jaydeep injects CSS > code to change QTextDocument's default color to Qt::black. While this might > have the same result, my approach is simpler and uses less resources. > > Additionally, it looks like his patch is limited to epub, while my patch > works for all generators that use textdocumentgenerator.cpp? > > Jaydeep might clarify, if I am wrong. > > Christoph Feck wrote: > (Let me add that I wasn't aware about his work while I wrote the patch. I > have no intention to disturb his work.) > > Jaydeep Solanki wrote: > For sure, you patch addresses a bigger issue by fixing this for all > generators that use TextDocumentGenerator. > I'd be happy to remove my patch for this patch, but I'm still not finding > the links in blue color. > Albert can you please confirm, if the links show up in blue. Okay, it seems that my color scheme was the culprit for not showing links in blue. I changed color scheme and now it works. Albert, IMHO this patch seems more appropriate. The other one with KColorScheme doesn't seem so good, as it changes the background color of the document which is not necessary. - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111681/#review37994 --- On Aug. 17, 2013, 2:28 a.m., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111681/ > --- > > (Updated Aug. 17, 2013, 2:28 a.m.) > > > Review request for Okular. > > > Description > --- > > As indicated in bug 322547, some documents do not specify a text color, and > probably assume the default text color to be black. QTextDocument, however, > defaults to using the system text color. > > This patch changes the default text color to Qt::black. It should affect > epub, fb2, odt, and plain text generators. > > I think it is better to use this approach instead of changing the paper color > to use the system background color (see bug 253583), because > > 1) the document might specify a text color in some places, > > 2) the user is able to change the fg/bg colors anyway using Okular's > Accessibility options, and those probably expect black on white. > > > This addresses bugs 253583 and 322547. > http://bugs.kde.org/show_bug.cgi?id=253583 > http://bugs.kde.org/show_bug.cgi?id=322547 > > > Diffs > - > > core/textdocumentgenerator.cpp b260b3f > > Diff: http://git.reviewboard.kde.org/r/111681/diff/ > > > Testing > --- > > I tested the document from bug 322547 comment #3. > > > Thanks, > > Christoph Feck > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111681: TextDocumentGenerator: Use black as default text color
> On Aug. 17, 2013, 2:28 a.m., Albert Astals Cid wrote: > > To be honest i'm a bit confused by all the different patches trying to fix > > the same thing, there's this one, the other one that tries to use > > kcolorscheme, the other one that tries to let the user choose. > > > > And what I don't understand is why we need these patches. I would > > understand that if an epub sets the background color it will also set the > > text color (so all is fine, none of "our" colors is used) and if no color > > is set, i would undertand that the color scheme by the user provides > > acceptable colors. > > > > So where is the problem? > > Christoph Feck wrote: > The problem is not documents that set colors, but those that set no > colors (for example, plain text files). > > In the rendering code, the pixmap is pre-filled with hard-coded white > color, but the text is actually rendered using the system's foreground color. > This leads to "white on white" with dark color schemes (which usually use > white text). > > There are, as you see, several ways to fix it. Why I believe this one > makes more sense that using the system's background color: See my rationale > at "Description" above. > > Albert Astals Cid wrote: > Ok, can you try Jaydeep's branch epub-qtextdoc according to > https://www.dropbox.com/s/mgf778ug6yjie2l/GSoC%20patches.odt the color issues > are fixed there. Can you confirm? Is the solution acceptable for you? > > Christoph Feck wrote: > From quickly checking commit 1823cf9998555e22c6f3d8701728882dc34b244b > (which is documented to fix the color issue), I see that Jaydeep injects CSS > code to change QTextDocument's default color to Qt::black. While this might > have the same result, my approach is simpler and uses less resources. > > Additionally, it looks like his patch is limited to epub, while my patch > works for all generators that use textdocumentgenerator.cpp? > > Jaydeep might clarify, if I am wrong. > > Christoph Feck wrote: > (Let me add that I wasn't aware about his work while I wrote the patch. I > have no intention to disturb his work.) For sure, you patch addresses a bigger issue by fixing this for all generators that use TextDocumentGenerator. I'd be happy to remove my patch for this patch, but I'm still not finding the links in blue color. Albert can you please confirm, if the links show up in blue. - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111681/#review37994 --- On Aug. 17, 2013, 2:28 a.m., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111681/ > --- > > (Updated Aug. 17, 2013, 2:28 a.m.) > > > Review request for Okular. > > > Description > --- > > As indicated in bug 322547, some documents do not specify a text color, and > probably assume the default text color to be black. QTextDocument, however, > defaults to using the system text color. > > This patch changes the default text color to Qt::black. It should affect > epub, fb2, odt, and plain text generators. > > I think it is better to use this approach instead of changing the paper color > to use the system background color (see bug 253583), because > > 1) the document might specify a text color in some places, > > 2) the user is able to change the fg/bg colors anyway using Okular's > Accessibility options, and those probably expect black on white. > > > This addresses bugs 253583 and 322547. > http://bugs.kde.org/show_bug.cgi?id=253583 > http://bugs.kde.org/show_bug.cgi?id=322547 > > > Diffs > - > > core/textdocumentgenerator.cpp b260b3f > > Diff: http://git.reviewboard.kde.org/r/111681/diff/ > > > Testing > --- > > I tested the document from bug 322547 comment #3. > > > Thanks, > > Christoph Feck > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 9th August - status
On Sat, Aug 17, 2013 at 2:06 AM, Albert Astals Cid wrote: > El Divendres, 16 d'agost de 2013, a les 22:29:38, Jaydeep Solanki va > escriure: > > How it occurs : > > > > 1) Open an ePub > > 2) As soon as it opens, hold Right arrow key, till it reaches the end of > > document or crashes > > > > another way would be > > > > 2) Hold PgUp/ PgDn key, till it reaches the end of document or crashes. > > > > *Note:* it doesn't always crash. In fact the probability of it crashing > is > > very low, thus it gets difficult to debug. > > Have you tried with the helgrind tool of valgrind? > yes The only information related to us, that I got is http://paste.kde.org/p14eda246/ It says nothing about QTextDocument::drawContents(..). > > Cheers, > Albert > > > > > On Tue, Aug 13, 2013 at 3:17 AM, Albert Astals Cid > wrote: > > > El Dissabte, 10 d'agost de 2013, a les 01:19:14, Jaydeep Solanki va > > > > > > escriure: > > > > Hi, > > > > I have tested yesterday's patch (without lock) with about 15 > different > > > > epubs, and it crashed only once. I tried the same epub that made it > > > > crash > > > > once a few more times, but it didn't crash. Thus, crash doesn't > depend > > > > on > > > > the epub. > > > > > > > > I observed a few things, it crashes only when I'm scrolling the > pages at > > > > super fast speed (like pressing PgDn or right arrow key), this tells > > > > that > > > > generating pixmaps fast makes it break, so I set the performance to > > > > > > Greedy, > > > > > > > which makes Okular generate all the pixmaps as soon as possible, but > it > > > > never crashes there! > > > > > > > > The error that it gave me when crash occurred was "memory > corrupted", so > > > > > > I > > > > > > > tried valgrind, but it didn't detect any invalid memory. > > > > > > > > May be whenever you get time give it a try. Let's see if it crashes > with > > > > you. > > > > > > Can you please exactly tell me what you are doing and describe the > crash > > > you > > > are getting? > > > > > > 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
Re: [Okular-devel] Dt. 9th August - status
How it occurs : 1) Open an ePub 2) As soon as it opens, hold Right arrow key, till it reaches the end of document or crashes another way would be 2) Hold PgUp/ PgDn key, till it reaches the end of document or crashes. *Note:* it doesn't always crash. In fact the probability of it crashing is very low, thus it gets difficult to debug. On Tue, Aug 13, 2013 at 3:17 AM, Albert Astals Cid wrote: > El Dissabte, 10 d'agost de 2013, a les 01:19:14, Jaydeep Solanki va > escriure: > > Hi, > > I have tested yesterday's patch (without lock) with about 15 different > > epubs, and it crashed only once. I tried the same epub that made it crash > > once a few more times, but it didn't crash. Thus, crash doesn't depend on > > the epub. > > > > I observed a few things, it crashes only when I'm scrolling the pages at > > super fast speed (like pressing PgDn or right arrow key), this tells that > > generating pixmaps fast makes it break, so I set the performance to > Greedy, > > which makes Okular generate all the pixmaps as soon as possible, but it > > never crashes there! > > > > The error that it gave me when crash occurred was "memory corrupted", so > I > > tried valgrind, but it didn't detect any invalid memory. > > > > May be whenever you get time give it a try. Let's see if it crashes with > > you. > > Can you please exactly tell me what you are doing and describe the crash > you > are getting? > > 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] Dt. 14th August - status
Hi, I talked with qt guys, one thing I found out is no more features will be added to 4.8, so the visibility patch will be added to qt5. May be it will be helpful when KDE Frameworks 5 will release and Okular will be using qt5. Secondly, I'm trying to implement something that will let users play videos embedded into epubs. What I have thought of is, to provide a link in place of the video, when clicked on it, video will be played in the system default video player. Comments ? Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 12th August - status
On Tue, Aug 13, 2013 at 3:46 AM, Albert Astals Cid wrote: > El Dimarts, 13 d'agost de 2013, a les 00:27:48, Jaydeep Solanki va > escriure: > > Hi, > > > > Setup gerrit and created review request, for "visibility : collapse". > > https://codereview.qt-project.org/#change,62839 > > Nice :-) > > > I'll be working on updating it as and when I get more info. > > It's there :D > > > I'm kind of free besides it, so I was thinking to start with MathML. I > saw > > a few libs but mostly available in javascript, but considering > > QTextDocument's limited support, I think we'll have to come up with > > something different. May be some lib that gives us svgs out of matml code > > that we can directly show (just a thought). > > > > Or if you have something else that I can help with ? > > Are you keeping a list of all the bugfixes/features you have implemented > together with a document that proves the code change plus the rationale > used > for each of the patches? > Here <https://www.dropbox.com/s/mgf778ug6yjie2l/GSoC%20patches.odt>'s a file with links, in case you need. > > That would be really useful :-) > > 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] Dt. 12th August - status
Hi, Setup gerrit and created review request, for "visibility : collapse". https://codereview.qt-project.org/#change,62839 I'll be working on updating it as and when I get more info. I'm kind of free besides it, so I was thinking to start with MathML. I saw a few libs but mostly available in javascript, but considering QTextDocument's limited support, I think we'll have to come up with something different. May be some lib that gives us svgs out of matml code that we can directly show (just a thought). Or if you have something else that I can help with ? Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 10th August - status
Hi, I talked with Konstantin Ritt (irc nick : rittk) on #qt-labs, he told me to submit a review request for the changes that I have done till now. I'll submit a review request soon, because I have a read only copy of Qt, and cloning it again from my home connection will take ages. I tried changing the url, but it didn't work. I'll send a review request on Monday, when I go to college. I also discussed the hiding a part of a line issue, he told we'll be going step by step. First he'll be reviewing code for "visibility=collapsed", then we'll take it further. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 9th August - status
Hi, I have tested yesterday's patch (without lock) with about 15 different epubs, and it crashed only once. I tried the same epub that made it crash once a few more times, but it didn't crash. Thus, crash doesn't depend on the epub. I observed a few things, it crashes only when I'm scrolling the pages at super fast speed (like pressing PgDn or right arrow key), this tells that generating pixmaps fast makes it break, so I set the performance to Greedy, which makes Okular generate all the pixmaps as soon as possible, but it never crashes there! The error that it gave me when crash occurred was "memory corrupted", so I tried valgrind, but it didn't detect any invalid memory. May be whenever you get time give it a try. Let's see if it crashes with you. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 6th August - status
On Fri, Aug 9, 2013 at 1:44 AM, Albert Astals Cid wrote: > El Divendres, 9 d'agost de 2013, a les 01:36:18, Jaydeep Solanki va > escriure: > > yes it won't wait > > So the UI thread won't block, right? Because you said it would. > yes, if there are two QTextDocuments one used in UI thread and other in non-UI thread, and considering all the rendering is taking place in non-UI thread then there is no reason that will block the UI thread > > Cheers, > Albert > > > > > On Fri, Aug 9, 2013 at 1:33 AM, Albert Astals Cid wrote: > > > El Divendres, 9 d'agost de 2013, a les 01:11:25, Jaydeep Solanki va > > > > > > escriure: > > > > On Thu, Aug 8, 2013 at 2:25 AM, Albert Astals Cid > wrote: > > > > > El Dijous, 8 d'agost de 2013, a les 01:36:12, Jaydeep Solanki va > > > > > > escriure: > > > > > > On Thu, Aug 8, 2013 at 1:21 AM, Albert Astals Cid > > > > > > > wrote: > > > > > > > El Dijous, 8 d'agost de 2013, a les 01:09:27, Jaydeep Solanki > va > > > > > > > > > > escriure: > > > > > > > > Yes I know I have not took care of it here, I just wanted to > > > > > > > > show > > > > > > > > you > > > > > > > > the > > > > > > > > approach. And I still have no clue on how to delete the > static > > > > > > > > > > object. > > > > > > > > > > > > > I tried QScopedPointer, it doesn't help > > > > > > > > > > > > > > > > And what to do with the clone method, I mean it's not > virtual, > > > > > > can't > > > > > > > > > > > include EpubDocument because of circular dependency, then ? > > > > > > > > Those were the two I can think of. > > > > > > > > > > > > > > Well, what's the point in fixing B if it needs A and you don't > > > > > > > know > > > > > > > > > > how to > > > > > > > > > > > > fix > > > > > > > A? > > > > > > > > > > > > But don't you think both A and B in this case can be solved > > > > > > > > > > independently, > > > > > > > > > > > because if I first fix threading and then fix the cloning issue, > I > > > > > > just > > > > > > > > > have to replace the name of the method. > > > > > > > > > > > > For me it's totally okay, to fix resource loading issue first. > > > > > > > > > > > > You have got any ideas, on how to avoid cyclic dependency and > clone > > > > > > it ? > > > > > > > > Why do you need to clone it > > > > > > > > I clone because I read it > > > > here< > > > > > > > http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-rich-> > > > text-processing> . > > > > > > Ok, that's most probably a non issue nowadays when a QPixmap is > basically > > > thread friendly in almost most platforms, but ok. > > > > > > > > , i'm still waiting for the answer to > > > > > > > > > > "Why would the UI thread have to wait?" > > > > > > > > it wouldn't have to wait if two different mutexes are used. > > > > > > If all the rendering is done in the second thread, why is the UI thread > > > waiting for a mutex at all? > > > > > > Cheers, > > > > > > Albert > > > > > > > > Albert > > > > > > > > > > > > Please concentrate on doing first things first. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Albert > > > > > > > > > > > > > > > On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid < > > > > > > aa...@kde.org> > > > > > > > > > > wrote: > > > > > > > > > El Dijous, 8 d'agost de 2013, a les 00:37:42, Jaydeep > Solanki > > > > > > va > > > > > > > > > > escriure: > > > > > >
Re: [Okular-devel] Dt. 6th August - status
yes it won't wait On Fri, Aug 9, 2013 at 1:33 AM, Albert Astals Cid wrote: > El Divendres, 9 d'agost de 2013, a les 01:11:25, Jaydeep Solanki va > escriure: > > On Thu, Aug 8, 2013 at 2:25 AM, Albert Astals Cid wrote: > > > El Dijous, 8 d'agost de 2013, a les 01:36:12, Jaydeep Solanki va > escriure: > > > > On Thu, Aug 8, 2013 at 1:21 AM, Albert Astals Cid > wrote: > > > > > El Dijous, 8 d'agost de 2013, a les 01:09:27, Jaydeep Solanki va > > > > > > escriure: > > > > > > Yes I know I have not took care of it here, I just wanted to show > > > > > > you > > > > > > the > > > > > > approach. And I still have no clue on how to delete the static > > > > > > object. > > > > > > > > > I tried QScopedPointer, it doesn't help > > > > > > > > > > > > And what to do with the clone method, I mean it's not virtual, > can't > > > > > > include EpubDocument because of circular dependency, then ? > > > > > > Those were the two I can think of. > > > > > > > > > > Well, what's the point in fixing B if it needs A and you don't know > > > > > > how to > > > > > > > > fix > > > > > A? > > > > > > > > But don't you think both A and B in this case can be solved > > > > > > independently, > > > > > > > because if I first fix threading and then fix the cloning issue, I > just > > > > have to replace the name of the method. > > > > > > > > For me it's totally okay, to fix resource loading issue first. > > > > > > > > You have got any ideas, on how to avoid cyclic dependency and clone > it ? > > > > > > Why do you need to clone it > > > > I clone because I read it > > here< > http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-rich-> > text-processing> . > > Ok, that's most probably a non issue nowadays when a QPixmap is basically > thread friendly in almost most platforms, but ok. > > > > > > , i'm still waiting for the answer to > > > > > > "Why would the UI thread have to wait?" > > > > it wouldn't have to wait if two different mutexes are used. > > If all the rendering is done in the second thread, why is the UI thread > waiting for a mutex at all? > > Cheers, > Albert > > > > > > Albert > > > > > > > > Please concentrate on doing first things first. > > > > > > > > > > Cheers, > > > > > > > > > > Albert > > > > > > > > > > > On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid < > aa...@kde.org> > > > > > > > > > > wrote: > > > > > > > El Dijous, 8 d'agost de 2013, a les 00:37:42, Jaydeep Solanki > va > > > > > > > > > > escriure: > > > > > > > > I tried a lot of approaches for TextDocument threading and > > > > > > finally I > > > > > > > > > > > settled to a really simple approach (as it makes generator > > > > > > threaded > > > > > > > > as > > > > > > > > > > > > well > > > > > > > > > > > > > > > as gives best performance), diff attached. > > > > > > > > I just want to ask, how to know when the document is closed > and > > > > > > > > > > delete > > > > > > > > > > > > that > > > > > > > > > > > > > > > pointer, because now if I close a document and open another > > > > > > document > > > > > > > > > > images > > > > > > > > > > > > > > > displayed are of the previous document. > > > > > > > > > > > > > > How does this fix the incorrect loadResource being called? > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Albert > > > > > > > > > > > > > > > On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso < > > > > > > fabiodu...@hotmail.it> > > > > > > > &
Re: [Okular-devel] Dt. 8th August - status
On Fri, Aug 9, 2013 at 1:31 AM, Albert Astals Cid wrote: > El Divendres, 9 d'agost de 2013, a les 01:09:18, Jaydeep Solanki va > escriure: > > forgot to attach > > Can you explain your locking, not sure i understand it. > QMutexLocker will lock the mutex in its constructor and unlock it in its destructor. > > Cheers, > Albert > > > > > On Fri, Aug 9, 2013 at 1:07 AM, Jaydeep Solanki > wrote: > > > Hi, > > > > > > Finally an end to cloning and threading issue. > > > Diff attached. I have kept QElapsedTimer, just in case you if you want > to > > > check performance. I'll remove it and qDebug() when pushing it. > > > > > > *A possible improvement:* > > > While a non UI thread is creating a cloned object using > > > TextDocumentConverter::convert(), the UI thread should be generating > > > pixmaps till the cloned object is created. > > ___ > 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. 6th August - status
On Thu, Aug 8, 2013 at 2:25 AM, Albert Astals Cid wrote: > El Dijous, 8 d'agost de 2013, a les 01:36:12, Jaydeep Solanki va escriure: > > On Thu, Aug 8, 2013 at 1:21 AM, Albert Astals Cid wrote: > > > El Dijous, 8 d'agost de 2013, a les 01:09:27, Jaydeep Solanki va > escriure: > > > > Yes I know I have not took care of it here, I just wanted to show you > > > > the > > > > approach. And I still have no clue on how to delete the static > object. > > > > I tried QScopedPointer, it doesn't help > > > > > > > > And what to do with the clone method, I mean it's not virtual, can't > > > > include EpubDocument because of circular dependency, then ? > > > > Those were the two I can think of. > > > > > > Well, what's the point in fixing B if it needs A and you don't know > how to > > > fix > > > A? > > > > But don't you think both A and B in this case can be solved > independently, > > because if I first fix threading and then fix the cloning issue, I just > > have to replace the name of the method. > > > > For me it's totally okay, to fix resource loading issue first. > > > > You have got any ideas, on how to avoid cyclic dependency and clone it ? > > Why do you need to clone it I clone because I read it here<http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-rich-text-processing> . > , i'm still waiting for the answer to > > "Why would the UI thread have to wait?" > it wouldn't have to wait if two different mutexes are used. > > Albert > > > > > > Please concentrate on doing first things first. > > > > > > Cheers, > > > > > > Albert > > > > > > > On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid > > > > > > wrote: > > > > > El Dijous, 8 d'agost de 2013, a les 00:37:42, Jaydeep Solanki va > > > > > > escriure: > > > > > > I tried a lot of approaches for TextDocument threading and > finally I > > > > > > settled to a really simple approach (as it makes generator > threaded > > > > > > as > > > > > > > > well > > > > > > > > > > > as gives best performance), diff attached. > > > > > > I just want to ask, how to know when the document is closed and > > > > > > delete > > > > > > > > that > > > > > > > > > > > pointer, because now if I close a document and open another > document > > > > > > > > > > images > > > > > > > > > > > displayed are of the previous document. > > > > > > > > > > How does this fix the incorrect loadResource being called? > > > > > > > > > > Cheers, > > > > > > > > > > Albert > > > > > > > > > > > On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso < > fabiodu...@hotmail.it> > > > > > > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Wednesday, August 07, 2013 12:31:41 AM Albert Astals Cid > wrote: > > > > > > > > El Dimarts, 6 d'agost de 2013, a les 20:52:25, Jaydeep > Solanki > > > > > > > > va > > > > > > > > > > > > > > escriure: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I have implemented a simple Qt Visibility support, which > hides > > > > > > > > > > text, > > > > > > > > > > > > it's > > > > > > > > > > > > > > > > doesn't hide the exact area of the text, because the way > > > > > > > > > > QTextDocument > > > > > > > > > > > > is > > > > > > > > > > > > > > > > developed it is impossible to implement an approach that > hides > > > > > > > > > > only a > > > > > > > > > > > > part > > > > > > > > > > > > > > > > of line. Either we can hide a line or not hide it. > > > > > > > > > And implementing an approach in which incrementing the
Re: [Okular-devel] Dt. 8th August - status
forgot to attach On Fri, Aug 9, 2013 at 1:07 AM, Jaydeep Solanki wrote: > Hi, > > Finally an end to cloning and threading issue. > Diff attached. I have kept QElapsedTimer, just in case you if you want to > check performance. I'll remove it and qDebug() when pushing it. > > *A possible improvement:* > While a non UI thread is creating a cloned object using > TextDocumentConverter::convert(), the UI thread should be generating > pixmaps till the cloned object is created. > > > threading_cloning.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 8th August - status
Hi, Finally an end to cloning and threading issue. Diff attached. I have kept QElapsedTimer, just in case you if you want to check performance. I'll remove it and qDebug() when pushing it. *A possible improvement:* While a non UI thread is creating a cloned object using TextDocumentConverter::convert(), the UI thread should be generating pixmaps till the cloned object is created. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 6th August - status
On Thu, Aug 8, 2013 at 1:21 AM, Albert Astals Cid wrote: > El Dijous, 8 d'agost de 2013, a les 01:09:27, Jaydeep Solanki va escriure: > > Yes I know I have not took care of it here, I just wanted to show you the > > approach. And I still have no clue on how to delete the static object. > > I tried QScopedPointer, it doesn't help > > > > And what to do with the clone method, I mean it's not virtual, can't > > include EpubDocument because of circular dependency, then ? > > Those were the two I can think of. > > Well, what's the point in fixing B if it needs A and you don't know how to > fix > A? > But don't you think both A and B in this case can be solved independently, because if I first fix threading and then fix the cloning issue, I just have to replace the name of the method. For me it's totally okay, to fix resource loading issue first. You have got any ideas, on how to avoid cyclic dependency and clone it ? > > Please concentrate on doing first things first. > > Cheers, > Albert > > > > > On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid > wrote: > > > El Dijous, 8 d'agost de 2013, a les 00:37:42, Jaydeep Solanki va > escriure: > > > > I tried a lot of approaches for TextDocument threading and finally I > > > > settled to a really simple approach (as it makes generator threaded > as > > > > > > well > > > > > > > as gives best performance), diff attached. > > > > I just want to ask, how to know when the document is closed and > delete > > > > > > that > > > > > > > pointer, because now if I close a document and open another document > > > > > > images > > > > > > > displayed are of the previous document. > > > > > > How does this fix the incorrect loadResource being called? > > > > > > Cheers, > > > > > > Albert > > > > > > > On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso > > > > > > wrote: > > > > > Hi, > > > > > > > > > > On Wednesday, August 07, 2013 12:31:41 AM Albert Astals Cid wrote: > > > > > > El Dimarts, 6 d'agost de 2013, a les 20:52:25, Jaydeep Solanki va > > > > > > > > > > escriure: > > > > > > > Hi, > > > > > > > > > > > > > > I have implemented a simple Qt Visibility support, which hides > > > > > > text, > > > > > > > > it's > > > > > > > > > > > > doesn't hide the exact area of the text, because the way > > > > > > QTextDocument > > > > > > > > is > > > > > > > > > > > > developed it is impossible to implement an approach that hides > > > > > > only a > > > > > > > > part > > > > > > > > > > > > of line. Either we can hide a line or not hide it. > > > > > > > And implementing an approach in which incrementing the cursor > and > > > > > > not > > > > > > > > > > inserting the text was my idea, but it seems they are using the > > > > > > text > > > > > > > > > > so > > > > > > > much that, I'm not able to get a way to exclude the text and > > > > > > implement > > > > > > > > > > visibility. > > > > > > > > > > > > Before continuing to work on that, i think you should explore > with > > > > > > the > > > > > > > > > Qt > > > > > > guys how feasible is this work to be accepted upstream with the > > > > > > known > > > > > > limitations you mention, because if it's not going to be > accepted, > > > > > > it's > > > > > > > > not > > > > > > > > > > > really useful for us since we can't expect people to patch their > Qt > > > > > > for > > > > > > > > us. > > > > > > > > > > > > Regarding the threaded QTextDocument, I tried the approach you > > > > > > said, > > > > > > > > and > > > > > > > > > > > > it > > > > > > > seems that it is also blocking UI, even more
Re: [Okular-devel] Dt. 6th August - status
Yes I know I have not took care of it here, I just wanted to show you the approach. And I still have no clue on how to delete the static object. I tried QScopedPointer, it doesn't help And what to do with the clone method, I mean it's not virtual, can't include EpubDocument because of circular dependency, then ? Those were the two I can think of. On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid wrote: > El Dijous, 8 d'agost de 2013, a les 00:37:42, Jaydeep Solanki va escriure: > > I tried a lot of approaches for TextDocument threading and finally I > > settled to a really simple approach (as it makes generator threaded as > well > > as gives best performance), diff attached. > > I just want to ask, how to know when the document is closed and delete > that > > pointer, because now if I close a document and open another document > images > > displayed are of the previous document. > > How does this fix the incorrect loadResource being called? > > Cheers, > Albert > > > > > On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso > wrote: > > > Hi, > > > > > > On Wednesday, August 07, 2013 12:31:41 AM Albert Astals Cid wrote: > > > > El Dimarts, 6 d'agost de 2013, a les 20:52:25, Jaydeep Solanki va > > > > > > escriure: > > > > > Hi, > > > > > > > > > > I have implemented a simple Qt Visibility support, which hides > text, > > > > > > it's > > > > > > > > doesn't hide the exact area of the text, because the way > QTextDocument > > > > > > is > > > > > > > > developed it is impossible to implement an approach that hides > only a > > > > > > part > > > > > > > > of line. Either we can hide a line or not hide it. > > > > > And implementing an approach in which incrementing the cursor and > not > > > > > inserting the text was my idea, but it seems they are using the > text > > > > > so > > > > > much that, I'm not able to get a way to exclude the text and > implement > > > > > visibility. > > > > > > > > Before continuing to work on that, i think you should explore with > the > > > > Qt > > > > guys how feasible is this work to be accepted upstream with the known > > > > limitations you mention, because if it's not going to be accepted, > it's > > > > > > not > > > > > > > really useful for us since we can't expect people to patch their Qt > for > > > > > > us. > > > > > > > > Regarding the threaded QTextDocument, I tried the approach you > said, > > > > > > and > > > > > > > > it > > > > > seems that it is also blocking UI, even more then single threaded. > > > > > > Suppose > > > > > > > > I'm on a page and the next page is loading in other thread, the UI > > > > > > thread > > > > > > > > will have to wait till the other thread finishes it's job (because > of > > > > > locking), which takes a bit more time than usual because it is > > > > > > generated > > > > > > > > from a cloned QTextDocument. > > > > > > > > Why would the UI thread have to wait? > > > > > > Disclaimer: I haven't read the whole discussion, so this idea might > not be > > > applicable. If I understood correctly, there's some object that needs > to > > > be > > > cloned because its methods are not reentrant, but cloning is expensive. > > > > > > I was thinking about keeping a pool of clones, initially containing > only > > > one > > > instance, and adding a new clone to the pool when an instance is > requested > > > and > > > there are no readily available ones. > > > > > > Of course this approach, if feasible at all, will waste memory. > Depending > > > on > > > the size of the object it might pay or not. > > > > > > > > Regarding the clone method overriding in EpubDocument, I'm using a > > > > > > dynamic > > > > > > > > property, to store the name of the generator, and using it I decide > > > > > > which > > > > > > > > method to call EpubDocument::myClone() or QTextDocument::clone() in > > > > > TextDocumentGenerator
Re: [Okular-devel] Dt. 6th August - status
I tried a lot of approaches for TextDocument threading and finally I settled to a really simple approach (as it makes generator threaded as well as gives best performance), diff attached. I just want to ask, how to know when the document is closed and delete that pointer, because now if I close a document and open another document images displayed are of the previous document. On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso wrote: > Hi, > > On Wednesday, August 07, 2013 12:31:41 AM Albert Astals Cid wrote: > > El Dimarts, 6 d'agost de 2013, a les 20:52:25, Jaydeep Solanki va > escriure: > > > Hi, > > > > > > I have implemented a simple Qt Visibility support, which hides text, > it's > > > doesn't hide the exact area of the text, because the way QTextDocument > is > > > developed it is impossible to implement an approach that hides only a > part > > > of line. Either we can hide a line or not hide it. > > > And implementing an approach in which incrementing the cursor and not > > > inserting the text was my idea, but it seems they are using the text so > > > much that, I'm not able to get a way to exclude the text and implement > > > visibility. > > > > Before continuing to work on that, i think you should explore with the Qt > > guys how feasible is this work to be accepted upstream with the known > > limitations you mention, because if it's not going to be accepted, it's > not > > really useful for us since we can't expect people to patch their Qt for > us. > > > > > Regarding the threaded QTextDocument, I tried the approach you said, > and > > > it > > > seems that it is also blocking UI, even more then single threaded. > Suppose > > > I'm on a page and the next page is loading in other thread, the UI > thread > > > will have to wait till the other thread finishes it's job (because of > > > locking), which takes a bit more time than usual because it is > generated > > > from a cloned QTextDocument. > > > > Why would the UI thread have to wait? > > Disclaimer: I haven't read the whole discussion, so this idea might not be > applicable. If I understood correctly, there's some object that needs to be > cloned because its methods are not reentrant, but cloning is expensive. > > I was thinking about keeping a pool of clones, initially containing only > one > instance, and adding a new clone to the pool when an instance is requested > and > there are no readily available ones. > > Of course this approach, if feasible at all, will waste memory. Depending > on > the size of the object it might pay or not. > > > > Regarding the clone method overriding in EpubDocument, I'm using a > dynamic > > > property, to store the name of the generator, and using it I decide > which > > > method to call EpubDocument::myClone() or QTextDocument::clone() in > > > TextDocumentGenerator. > > > > You can't call EpubDocument::myClone in TextDocumentGenerator, that > > introduces a circular dependency. > > > > > One more thing I noticed about Okular is it doesn't free up memory, > after > > > the document is closed, it frees after Okular quits, so my question is > > > does > > > it use the memory (cached pixmaps) when I load the same document again > ? > > > > Nope, it should free it, if it doesn't it's a bug that has to be fixed. > > I remember reading somewhere that most free() implementations don't > actually > return the memory back to the OS, instead they keep free'd blocks in a > internal pool for future reuse. Eventually, when the process dies, all of > its > memory is reclaimed back by the OS. > > As Albert said, Okular does "free" pixmaps, but maybe you see that behavior > for this reason. > Makes sense. > > > Cheers, > > Albert > > > > > Cheers, > > > Jaydeep > > > > ___ > > Okular-devel mailing list > > Okular-devel@kde.org > > https://mail.kde.org/mailman/listinfo/okular-devel > > -- > Fabio > > ___ > Okular-devel mailing list > Okular-devel@kde.org > https://mail.kde.org/mailman/listinfo/okular-devel > TxtDocThread.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 6th August - status
Hi, I have implemented a simple Qt Visibility support, which hides text, it's doesn't hide the exact area of the text, because the way QTextDocument is developed it is impossible to implement an approach that hides only a part of line. Either we can hide a line or not hide it. And implementing an approach in which incrementing the cursor and not inserting the text was my idea, but it seems they are using the text so much that, I'm not able to get a way to exclude the text and implement visibility. Regarding the threaded QTextDocument, I tried the approach you said, and it seems that it is also blocking UI, even more then single threaded. Suppose I'm on a page and the next page is loading in other thread, the UI thread will have to wait till the other thread finishes it's job (because of locking), which takes a bit more time than usual because it is generated from a cloned QTextDocument. Regarding the clone method overriding in EpubDocument, I'm using a dynamic property, to store the name of the generator, and using it I decide which method to call EpubDocument::myClone() or QTextDocument::clone() in TextDocumentGenerator. One more thing I noticed about Okular is it doesn't free up memory, after the document is closed, it frees after Okular quits, so my question is does it use the memory (cached pixmaps) when I load the same document again ? Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 4th August - status
On Mon, Aug 5, 2013 at 12:25 AM, Albert Astals Cid wrote: > El Diumenge, 4 d'agost de 2013, a les 23:31:02, Jaydeep Solanki va > escriure: > > Hi, > > > > Regarding the TextDocument threaded rendering issue, I implemented a > clone > > method to return an EpubDocument. QTextDocument::clone() is not a virtual > > method, so either we'll have to make it virtual or change the signature > of > > clone method in EpubDocument. > > I made QTextDocument::clone() virtual. > > You can't do that. It will change the ABI of Qt and that's simply not > acceptable. > > > It worked fine, but despite of all the optimizations I can do, it takes > > around 400 to 500 ms to clone & 600 - 700 ms to draw, which is huge! I > > checked QTextDocument::clone() it is a bit faster (because it has direct > > access to the private classes), but won't make any difference. > > > > To make it even faster I tried it without cloning ( kept mutex locking ), > > it takes around 200 to 500ms, still bad. Finally, to get an estimate > about > > what it takes without threading, I tried the non-threaded version, & to > my > > surprise it broke all records 0 to 100ms depending on the content. > > That is weird, why would locking take 400ms? > That's for the worst case, suppose for 4 threads, 1st thread draws other all wait, 2nd draws, 3rd and 4th wait, then 3rd draws and 4th waits. Now 4th gets a change, which will accumulate a lot of time spent waiting. > > > Here I learnt one thing, drawing from a just cloned QTextDocument takes > > more time, and I guess that's because of the cachedResources. > > > > I even tried QAtomicPointer, but it breaks at several places. > > > > I tried a lot to make it work faster, because I know you have announced > it > > in Acadamy that Okular will be getting threaded rendering for > > QTextDocument, but may be for now it is better to leave it single > threaded. > > Don't worry, It was a BoF with around 5 people. If it can't be done, it > can't > be done. > > *BUT* on the other hand even having a slower version that is thread is > interesting since it means the UI doesn't get blocked. We may think if it > makes sense to do the "viewport requests" in the UI thread for the speed > and > the "preloading requests" in the non-UI thread for UI smoothness. > UI will only be blocked when Okular is on Greedy Performance and it's a single threaded generator. So instead of making it support threading I think it would be better to decrease the performance (i.e. from Greedy to Normal) for single threaded generators. This way we won't encounter a UI blocking situation and will also get the benefit of not having the overhead of locking. I have attached a patch. > > Cheers, > Albert > > > > > Note: I used QElapsedTimer to get the estimated time. > > > > Cheers, > > Jaydeep > > ___ > Okular-devel mailing list > Okular-devel@kde.org > https://mail.kde.org/mailman/listinfo/okular-devel > TxtDoc_THread.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 4th August - status
And for the comparisons, I have Intel i5-2430M Processor<http://ark.intel.com/products/53450> On Sun, Aug 4, 2013 at 11:31 PM, Jaydeep Solanki wrote: > Hi, > > Regarding the TextDocument threaded rendering issue, I implemented a clone > method to return an EpubDocument. QTextDocument::clone() is not a virtual > method, so either we'll have to make it virtual or change the signature of > clone method in EpubDocument. > I made QTextDocument::clone() virtual. > > It worked fine, but despite of all the optimizations I can do, it takes > around 400 to 500 ms to clone & 600 - 700 ms to draw, which is huge! I > checked QTextDocument::clone() it is a bit faster (because it has direct > access to the private classes), but won't make any difference. > > To make it even faster I tried it without cloning ( kept mutex locking ), > it takes around 200 to 500ms, still bad. Finally, to get an estimate about > what it takes without threading, I tried the non-threaded version, & to my > surprise it broke all records 0 to 100ms depending on the content. > > Here I learnt one thing, drawing from a just cloned QTextDocument takes > more time, and I guess that's because of the cachedResources. > > I even tried QAtomicPointer, but it breaks at several places. > > I tried a lot to make it work faster, because I know you have announced it > in Acadamy that Okular will be getting threaded rendering for > QTextDocument, but may be for now it is better to leave it single threaded. > > Note: I used QElapsedTimer to get the estimated time. > > Cheers, > Jaydeep > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 4th August - status
Hi, Regarding the TextDocument threaded rendering issue, I implemented a clone method to return an EpubDocument. QTextDocument::clone() is not a virtual method, so either we'll have to make it virtual or change the signature of clone method in EpubDocument. I made QTextDocument::clone() virtual. It worked fine, but despite of all the optimizations I can do, it takes around 400 to 500 ms to clone & 600 - 700 ms to draw, which is huge! I checked QTextDocument::clone() it is a bit faster (because it has direct access to the private classes), but won't make any difference. To make it even faster I tried it without cloning ( kept mutex locking ), it takes around 200 to 500ms, still bad. Finally, to get an estimate about what it takes without threading, I tried the non-threaded version, & to my surprise it broke all records 0 to 100ms depending on the content. Here I learnt one thing, drawing from a just cloned QTextDocument takes more time, and I guess that's because of the cachedResources. I even tried QAtomicPointer, but it breaks at several places. I tried a lot to make it work faster, because I know you have announced it in Acadamy that Okular will be getting threaded rendering for QTextDocument, but may be for now it is better to leave it single threaded. Note: I used QElapsedTimer to get the estimated time. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 3rd August - status
Hi, So, today we found out TextDocument threaded rendering is not ready. I'll submit a patch tomorrow. I'm still working on getting the text unselectable. What I'm trying to do is somehow get the cursor to increment and not insert the text. If it can be done, it will be the best solution. Lack of comments in private classes makes it a rough ride, but I'm trying my best. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 2nd August - status
Hi, Collapse support is done. For hidden visibility, I think I'm going to need some time, may be a day, the main reason being I'm not aware with QTextCursor code, & for hiding text it is needed. 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
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
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
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] Dt. 31th July - status
Hi, Today, gui/text/QCssParser made some sense to me. So, I tried to take a small step, make it detect "visibility" property in css. I made some changes, but found it doesn't work. I met a person on #qt-labs who was familiar with QCssParser, but the time I finished making changes he was gone. I'm attaching the diff file here, if you have got some time, have a look at it, if not tomorrow I'll try debugging it or ask someone on #qt-labs. PS : diff is based on Qt 4.8.6 Cheers, Jaydeep visibility_detect.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 29th July - status
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 > > Again, do you have a small test case? > sadly no > > 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
Re: [Okular-devel] Dt. 30th July - status
QCssParser from the files you sent me. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 30th July - status
And ya, I have submitted the Midterm Evaluation On Wed, Jul 31, 2013 at 7:51 AM, Jaydeep Solanki wrote: > QCssParser > > > On Wed, Jul 31, 2013 at 2:56 AM, Albert Astals Cid wrote: > >> El Dimecres, 31 de juliol de 2013, a les 00:42:07, Jaydeep Solanki va >> escriure: >> > Hi, >> > I'm reading and reading and reading the source, if I get something >> useful, >> > I try it out. >> > I have got a rough idea about what they are doing and what I have to do. >> > >> > But I guess it will take me some time to get it working. I have started >> > modifying the source, but I'm just at the beginning. >> >> Source of? >> >> 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
Re: [Okular-devel] Dt. 30th July - status
QCssParser On Wed, Jul 31, 2013 at 2:56 AM, Albert Astals Cid wrote: > El Dimecres, 31 de juliol de 2013, a les 00:42:07, Jaydeep Solanki va > escriure: > > Hi, > > I'm reading and reading and reading the source, if I get something > useful, > > I try it out. > > I have got a rough idea about what they are doing and what I have to do. > > > > But I guess it will take me some time to get it working. I have started > > modifying the source, but I'm just at the beginning. > > Source of? > > 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] Dt. 30th July - status
Hi, I'm reading and reading and reading the source, if I get something useful, I try it out. I have got a rough idea about what they are doing and what I have to do. But I guess it will take me some time to get it working. I have started modifying the source, but I'm just at the beginning. 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
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. > > > 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] Dt. 29th July - status
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. 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. BTW, do you also contribute to Qt ? I saw you on #qt-labs. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 28th July - status
Hi, All the bugs reported on bugs.kde.org related to epub backend, have been fixed (except 1 that says elements with visibility:none also show up in epubs, the reason for it is quite obvious, QTextdocument doesn't support visibility), so today I thought to give other bugs a shot. Since long I wanted to have an indication in the toc showing under which topic are we currently viewing, the document. More explanation: Suppose in the toc, introduction is on page 5, first chapter is on page 7 and I'm on page 6, then Okular doesn't show any indication regarding where am I currently. However, it shows a little triangle next to the label, if I'm exactly on page 5 (i.e. introduction) or page 7 (i.e. 1st chapter). For what I want is it to show I'm still in the introduction section, although I'm on page 6. (indication refers to kind of a selection or something) And regarding the images not loading issue, I'll give it another chance, tomorrow. Then continue with this toc thing. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 27th July - status
Hi, As we were discussing about the two files mentioned in Bug 318485, not displaying images, there's really something strange with it. I tried loading that epub without its CSS, nothing changed. I copy-pasted the html from the epub to QTextDocument::setHtml() in converter.cpp, still not loading images. But when I tried it in a different project, with a QTextEdit, loads it successfully. That indicates that there must be some bug in EpubDocument (subclass of QTextDocument) but we are not doing anything fancy there, except overriding QTextDocument::loadResource(). Whenever you get some time, please have a look at it. Here<https://www.dropbox.com/s/z3kuqm2bg4s4qmf/cc1.epub>'s a link to a minified version (containing just a single page) of one of those epubs. >From tomorrow, I'll move on with something else. Also, now huge images won't span outside of a page. [fixed] Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 26th July - status
On Fri, Jul 26, 2013 at 11:51 PM, Albert Astals Cid wrote: > El Divendres, 26 de juliol de 2013, a les 23:31:00, Jaydeep Solanki va > escriure: > > On Fri, Jul 26, 2013 at 11:20 PM, Albert Astals Cid > wrote: > > > El Divendres, 26 de juliol de 2013, a les 21:58:43, Jaydeep Solanki va > > > > > > escriure: > > > > Hi, > > > > > > > > Yesterday while I was testing for Bug 318485, I found that both the > > > > files > > > > mentioned there have a small bug ( they fail to load images ). I'm > > > > facing > > > > this issue with only those two files, for every other file it works. > > > > > > > > So today, I though to fix it first. > > > > I have been trying to find the reason but till now it's unclear to me > > > > what's causing it. > > > > I saw the Html that is given as an output by QTextDocument, but no > > > > clues. > > > > Also a strange thing I noticed here is it doesn't even call > > > > QTextDocument::loadResource(), for getting the image. > > > > > > That is indeed strange, is the html markup somewhat special? Can you > write > > > a > > > simple html that shows the problem in QTextDocument? > > > > I'm trying to reproduce it separately, I'll inform you as soon I get it. > > > > > > For a while I thought the epubs might be created incorrectly, but it > > > > > > works > > > > > > > perfectly on calibre. > > > > > > > > I'll investigate it further tomorrow. > > > > > > > > BTW, I'm still facing issues while pushing to my branch, can you > please > > > > confirm if everything's fine on KDE side ? > > > > > > I can push fine to the okular repo, want me try to push to your branch? > > > > Yes, because I tried, > > ssh -T g...@git.kde.org, > > and it shows I have RW access to Okular > > Yep, it works fine (I can commit) > > You may want to drop by the #kde-sysadmin channel and maybe someone can > help > you. > Yes, they helped me, & now it's working. > > If not post the error here and I'll see what i can do tomorrow (heading > out to > real life now). > > Cheers, > Albert > > > > > > 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
Re: [Okular-devel] Dt. 26th July - status
On Fri, Jul 26, 2013 at 11:20 PM, Albert Astals Cid wrote: > El Divendres, 26 de juliol de 2013, a les 21:58:43, Jaydeep Solanki va > escriure: > > Hi, > > > > Yesterday while I was testing for Bug 318485, I found that both the files > > mentioned there have a small bug ( they fail to load images ). I'm facing > > this issue with only those two files, for every other file it works. > > > > So today, I though to fix it first. > > I have been trying to find the reason but till now it's unclear to me > > what's causing it. > > I saw the Html that is given as an output by QTextDocument, but no clues. > > Also a strange thing I noticed here is it doesn't even call > > QTextDocument::loadResource(), for getting the image. > > That is indeed strange, is the html markup somewhat special? Can you write > a > simple html that shows the problem in QTextDocument? > I'm trying to reproduce it separately, I'll inform you as soon I get it. > > > > > For a while I thought the epubs might be created incorrectly, but it > works > > perfectly on calibre. > > > > I'll investigate it further tomorrow. > > > > BTW, I'm still facing issues while pushing to my branch, can you please > > confirm if everything's fine on KDE side ? > > I can push fine to the okular repo, want me try to push to your branch? > Yes, because I tried, ssh -T g...@git.kde.org, and it shows I have RW access to Okular > > 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] Dt. 26th July - status
Hi, Yesterday while I was testing for Bug 318485, I found that both the files mentioned there have a small bug ( they fail to load images ). I'm facing this issue with only those two files, for every other file it works. So today, I though to fix it first. I have been trying to find the reason but till now it's unclear to me what's causing it. I saw the Html that is given as an output by QTextDocument, but no clues. Also a strange thing I noticed here is it doesn't even call QTextDocument::loadResource(), for getting the image. For a while I thought the epubs might be created incorrectly, but it works perfectly on calibre. I'll investigate it further tomorrow. BTW, I'm still facing issues while pushing to my branch, can you please confirm if everything's fine on KDE side ? Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt.24th July - status
Hi, Fixed Bug 318485 <https://bugs.kde.org/show_bug.cgi?id=318485>. While pushing it, sometimes I get, "403 forbidden" & sometimes "502 Bad Gateway". I don't know the reason. I'll try later tonight. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111681: TextDocumentGenerator: Use black as default text color
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111681/#review36480 --- Can you please confirm if the links are shown properly - Jaydeep Solanki On July 25, 2013, 5:30 p.m., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111681/ > --- > > (Updated July 25, 2013, 5:30 p.m.) > > > Review request for Okular and Albert Astals Cid. > > > Description > --- > > As indicated in bug 322547, some documents do not specify a text color, and > probably assume the default text color to be black. QTextDocument, however, > defaults to using the system text color. > > This patch changes the default text color to Qt::black. It should affect > epub, fb2, odt, and plain text generators. > > I think it is better to use this approach instead of changing the paper color > to use the system background color (see bug 253583), because > > 1) the document might specify a text color in some places, > > 2) the user is able to change the fg/bg colors anyway using Okular's > Accessibility options, and those probably expect black on white. > > > This addresses bugs 253583 and 322547. > http://bugs.kde.org/show_bug.cgi?id=253583 > http://bugs.kde.org/show_bug.cgi?id=322547 > > > Diffs > - > > core/textdocumentgenerator.cpp b260b3f > > Diff: http://git.reviewboard.kde.org/r/111681/diff/ > > > Testing > --- > > I tested the document from bug 322547 comment #3. > > > Thanks, > > Christoph Feck > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111681: TextDocumentGenerator: Use black as default text color
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111681/#review36476 --- Links still suffer from Bug 322547. Below is an epub, showing this http://goo.gl/Rknh6N - Jaydeep Solanki On July 25, 2013, 4:50 p.m., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111681/ > --- > > (Updated July 25, 2013, 4:50 p.m.) > > > Review request for Okular and Albert Astals Cid. > > > Description > --- > > As indicated in bug 322547, some documents do not specify a text color, and > probably assume the default text color to be black. QTextDocument, however, > defaults to using the system text color. > > This patch changes the default text color to Qt::black. It should affect > epub, fb2, odt, and plain text generators. > > I think it is better to use this approach instead of changing the paper color > to use the system background color (see bug 253583), because > > 1) the document might specify a text color in some places, > > 2) the user is able to change the fg/bg colors anyway using Okular's > Accessibility options, and those probably expect black on white. > > > This addresses bugs 253583 and 322547. > http://bugs.kde.org/show_bug.cgi?id=253583 > http://bugs.kde.org/show_bug.cgi?id=322547 > > > Diffs > - > > core/textdocumentgenerator.cpp b260b3f > > Diff: http://git.reviewboard.kde.org/r/111681/diff/ > > > Testing > --- > > I tested the document from bug 322547 comment #3. > > > Thanks, > > Christoph Feck > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111554: SVG support for Epubs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111554/ --- (Updated July 25, 2013, 4:50 p.m.) Status -- This change has been discarded. Review request for Okular. Description --- Epubs use the below syntax to load svg images I just replace that with tags & add QImage as a resource. Diffs - generators/epub/CMakeLists.txt 9442f61 generators/epub/converter.cpp 74df151 generators/epub/epubdocument.h 714ede6 Diff: http://git.reviewboard.kde.org/r/111554/diff/ Testing --- The below link contains two epub files having svg images as cover. https://www.dropbox.com/sh/xcqfwn8khbqac0d/vDRuFRw9vq Thanks, Jaydeep Solanki ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111640: Remove Magic Stuff from Epub Generator
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111640/ --- (Updated July 25, 2013, 4:50 p.m.) Status -- This change has been discarded. Review request for Okular. Description --- Guess this is more proper implementation. Diffs - generators/epub/converter.h 969dc9f generators/epub/converter.cpp 74df151 generators/epub/epubdocument.h 714ede6 generators/epub/epubdocument.cpp ae19f8a Diff: http://git.reviewboard.kde.org/r/111640/diff/ Testing --- Thanks, Jaydeep Solanki ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 23rd July - status
Dt. 24th July - status, Yes, I found your idea more elegant, so I have updated the patch here<https://git.reviewboard.kde.org/r/111640/>. ( because, it was based on my previous patch to remove magicStrings ) I used epubs given here <https://git.reviewboard.kde.org/r/109364/> + some more epubs to test. On Tue, Jul 23, 2013 at 11:59 PM, Albert Astals Cid wrote: > El Dimarts, 23 de juliol de 2013, a les 23:07:14, Jaydeep Solanki va > escriure: > > Hi, > > Hi > > > Regarding the unreadable text issue, in dark color scheme, I thought it > > would be great if Okular can detect background color of the document & > set > > text color accordingly. > > > > So far I'm able to get the background color of the document. > > I use QRegExp to get the background color from CSS. > > > > By tomorrow, I'll be able to show you a working demo (may not be perfect) > > but it'll work. > > Why can't we just simply obey the colors the file mandates for background > and > text without doing any hacks? > > 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
Re: [Okular-devel] Review Request 111640: Remove Magic Stuff from Epub Generator
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111640/ --- (Updated July 24, 2013, 10:31 p.m.) Review request for Okular. Changes --- This will also fix, the unreadable text issue in dark color scheme. Description --- Guess this is more proper implementation. Diffs (updated) - generators/epub/converter.h 969dc9f generators/epub/converter.cpp 74df151 generators/epub/epubdocument.h 714ede6 generators/epub/epubdocument.cpp ae19f8a Diff: http://git.reviewboard.kde.org/r/111640/diff/ Testing --- Thanks, Jaydeep Solanki ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 23rd July - status
Hi, Regarding the unreadable text issue, in dark color scheme, I thought it would be great if Okular can detect background color of the document & set text color accordingly. So far I'm able to get the background color of the document. I use QRegExp to get the background color from CSS. By tomorrow, I'll be able to show you a working demo (may not be perfect) but it'll work. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 109364: Get background color from KColorScheme (kde system settings)
> On July 21, 2013, 9:07 p.m., Albert Astals Cid wrote: > > Jaydeep, can you confirm you are working so that > > http://bugs.kde.org/attachment.cgi?id=51488 can be correctly seen in a dark > > colorscheme? > > Jaydeep Solanki wrote: > I tried it, with color scheme "Krita-darker" (background colors dark & > foreground colors light). > Here's how it looks, http://db.tt/iHkjbxN1 > > Am I missing something ? ok, I can reproduce it now. - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109364/#review36250 --- On July 21, 2013, 9:06 p.m., Azat Khuzhin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109364/ > --- > > (Updated July 21, 2013, 9:06 p.m.) > > > Review request for Okular and Jaydeep Solanki. > > > Description > --- > > Instead of just force it to white. > > This must fix bug 306572. > https://bugs.kde.org/show_bug.cgi?id=306572 > > > This addresses bug 306572. > http://bugs.kde.org/show_bug.cgi?id=306572 > > > Diffs > - > > core/textdocumentgenerator.cpp f370ded > > Diff: http://git.reviewboard.kde.org/r/109364/diff/ > > > Testing > --- > > > Thanks, > > Azat Khuzhin > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [okular] [Bug 322704] Okular crashes when opening epub document
https://bugs.kde.org/show_bug.cgi?id=322704 --- Comment #8 from jaydeep --- Robert, updating libepub will fix this. This bug was fixed some time ago. http://sourceforge.net/p/ebook-tools/code/145/ -- 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 111554: SVG support for Epubs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111554/ --- (Updated July 22, 2013, 11:30 a.m.) Review request for Okular. Changes --- Now we don't need that mysterious 42. Description --- Epubs use the below syntax to load svg images I just replace that with tags & add QImage as a resource. Diffs (updated) - generators/epub/CMakeLists.txt 9442f61 generators/epub/converter.cpp 74df151 generators/epub/epubdocument.h 714ede6 Diff: http://git.reviewboard.kde.org/r/111554/diff/ Testing --- The below link contains two epub files having svg images as cover. https://www.dropbox.com/sh/xcqfwn8khbqac0d/vDRuFRw9vq Thanks, Jaydeep Solanki ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Review Request 111640: Remove Magic Stuff from Epub Generator
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111640/ --- Review request for Okular. Description --- Guess this is more proper implementation. Diffs - generators/epub/converter.h 969dc9f generators/epub/converter.cpp 74df151 Diff: http://git.reviewboard.kde.org/r/111640/diff/ Testing --- Thanks, Jaydeep Solanki ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 109364: Get background color from KColorScheme (kde system settings)
> On July 21, 2013, 3:37 p.m., Albert Astals Cid wrote: > > Jaydeep, can you confirm you are working so that > > http://bugs.kde.org/attachment.cgi?id=51488 can be correctly seen in a dark > > colorscheme? I tried it, with color scheme "Krita-darker" (background colors dark & foreground colors light). Here's how it looks, http://db.tt/iHkjbxN1 Am I missing something ? - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109364/#review36250 --- On July 21, 2013, 3:36 p.m., Azat Khuzhin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109364/ > --- > > (Updated July 21, 2013, 3:36 p.m.) > > > Review request for Okular and Jaydeep Solanki. > > > Description > --- > > Instead of just force it to white. > > This must fix bug 306572. > https://bugs.kde.org/show_bug.cgi?id=306572 > > > This addresses bug 306572. > http://bugs.kde.org/show_bug.cgi?id=306572 > > > Diffs > - > > core/textdocumentgenerator.cpp f370ded > > Diff: http://git.reviewboard.kde.org/r/109364/diff/ > > > Testing > --- > > > Thanks, > > Azat Khuzhin > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111554: SVG support for Epubs
> On July 18, 2013, 2:31 p.m., Albert Astals Cid wrote: > > generators/epub/converter.cpp, line 220 > > <http://git.reviewboard.kde.org/r/111554/diff/1/?file=171295#file171295line220> > > > > Where does this 718/560 come from? > > Jaydeep Solanki wrote: > Width of a page is 600, and as we are having a padding of 20px around a > page, it gives 560(600 - 20[left] - 20[right]). > Similarly in the case of height, we have a page of size 800 leaving the > padding we get 760. > A page break is inserted after a page delimiter(PD) is encountered. A PD > also takes up some space, so if we just count the paddings & the size of the > content then including the PD will exceed a page's size & the second page > will contain PD + page break, which makes it a blank page. > So, to fit all that in a single page, I made it 718 (800 - 20[top] - > 20[bottom] - height of PD). > > I found the height of PD, with some trial & error. > > Albert Astals Cid wrote: > it'd be cool if we could have some static conts int around for those > values. > > Also, can you check where that PD value comes from? Maybe it depends on > the style you are using and thus we should query it using QStyle? Regarding PD value, we can get height of a line, using mTextDocument->documentLayout()->blockBoundingRect(mTextDocument->find(magicString).block()).height(); but it gives the height of only the text, which doesn't include height of upper & lower padding. What I found using trial & error was 42, what the above code returns is 15. What we need is the area highlighted in the below image, http://db.tt/DyPBbTvK - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111554/#review36121 --- On July 19, 2013, 8:29 p.m., Jaydeep Solanki wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111554/ > --- > > (Updated July 19, 2013, 8:29 p.m.) > > > Review request for Okular. > > > Description > --- > > Epubs use the below syntax to load svg images > > > > > > I just replace that with tags & add QImage as a resource. > > > Diffs > - > > generators/epub/CMakeLists.txt 9442f61 > generators/epub/converter.cpp 74df151 > generators/epub/epubdocument.h 714ede6 > > Diff: http://git.reviewboard.kde.org/r/111554/diff/ > > > Testing > --- > > The below link contains two epub files having svg images as cover. > https://www.dropbox.com/sh/xcqfwn8khbqac0d/vDRuFRw9vq > > > Thanks, > > Jaydeep Solanki > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111554: SVG support for Epubs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111554/ --- (Updated July 19, 2013, 8:29 p.m.) Review request for Okular. Changes --- static const ints added Description --- Epubs use the below syntax to load svg images I just replace that with tags & add QImage as a resource. Diffs (updated) - generators/epub/CMakeLists.txt 9442f61 generators/epub/converter.cpp 74df151 generators/epub/epubdocument.h 714ede6 Diff: http://git.reviewboard.kde.org/r/111554/diff/ Testing --- The below link contains two epub files having svg images as cover. https://www.dropbox.com/sh/xcqfwn8khbqac0d/vDRuFRw9vq Thanks, Jaydeep Solanki ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request 111554: SVG support for Epubs
> On July 18, 2013, 2:31 p.m., Albert Astals Cid wrote: > > generators/epub/converter.cpp, line 220 > > <http://git.reviewboard.kde.org/r/111554/diff/1/?file=171295#file171295line220> > > > > Where does this 718/560 come from? Width of a page is 600, and as we are having a padding of 20px around a page, it gives 560(600 - 20[left] - 20[right]). Similarly in the case of height, we have a page of size 800 leaving the padding we get 760. A page break is inserted after a page delimiter(PD) is encountered. A PD also takes up some space, so if we just count the paddings & the size of the content then including the PD will exceed a page's size & the second page will contain PD + page break, which makes it a blank page. So, to fit all that in a single page, I made it 718 (800 - 20[top] - 20[bottom] - height of PD). I found the height of PD, with some trial & error. - Jaydeep --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111554/#review36121 ------- On July 17, 2013, 8:13 p.m., Jaydeep Solanki wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111554/ > --- > > (Updated July 17, 2013, 8:13 p.m.) > > > Review request for Okular. > > > Description > --- > > Epubs use the below syntax to load svg images > > > > > > I just replace that with tags & add QImage as a resource. > > > Diffs > - > > generators/epub/epubdocument.h 714ede6 > generators/epub/converter.cpp 74df151 > generators/epub/CMakeLists.txt 9442f61 > > Diff: http://git.reviewboard.kde.org/r/111554/diff/ > > > Testing > --- > > The below link contains two epub files having svg images as cover. > https://www.dropbox.com/sh/xcqfwn8khbqac0d/vDRuFRw9vq > > > Thanks, > > Jaydeep Solanki > > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] SVG support for Epubs
For your convenience, here <https://git.reviewboard.kde.org/r/111554/>'s a review request. On Tue, Jul 16, 2013 at 10:06 PM, Jaydeep Solanki wrote: > Hi, > I'm attaching here a patch that adds support for SVG images in Epubs. > I'm sending you the patch in mail because Review Board didn't accept my > patch. > So instead of going for other alternatives I thought it would be easy to > send you the patch through mail. > > This <https://www.dropbox.com/sh/xcqfwn8khbqac0d/vDRuFRw9vq> contains two > epub files having svg images as cover. > > *Note :: it is for branch "epub-qtextdoc".* > > Cheers, > Jaydeep > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Review Request 111554: SVG support for Epubs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111554/ --- Review request for Okular. Description --- Epubs use the below syntax to load svg images I just replace that with tags & add QImage as a resource. Diffs - generators/epub/epubdocument.h 714ede6 generators/epub/converter.cpp 74df151 generators/epub/CMakeLists.txt 9442f61 Diff: http://git.reviewboard.kde.org/r/111554/diff/ Testing --- The below link contains two epub files having svg images as cover. https://www.dropbox.com/sh/xcqfwn8khbqac0d/vDRuFRw9vq Thanks, Jaydeep Solanki ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] SVG support for Epubs
Hi, I'm attaching here a patch that adds support for SVG images in Epubs. I'm sending you the patch in mail because Review Board didn't accept my patch. So instead of going for other alternatives I thought it would be easy to send you the patch through mail. This <https://www.dropbox.com/sh/xcqfwn8khbqac0d/vDRuFRw9vq> contains two epub files having svg images as cover. *Note :: it is for branch "epub-qtextdoc".* Cheers, Jaydeep svg.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Dt. 15th July - status
On Tue, Jul 16, 2013 at 3:18 PM, Albert Astals Cid wrote: > El Dilluns, 15 de juliol de 2013, a les 22:41:11, Jaydeep Solanki va > escriure: > > Please ignore this. > > I unknowingly sent it to the list. > > Why you don't like the list getting this message? > I don't know, I guess I just had a habit of sending it to you. Anyways, from now I'll make sure I send it to the list. > > Cheers, > Albert > > > > > On Mon, Jul 15, 2013 at 10:37 PM, Jaydeep Solanki > wrote: > > > Hi, > > > While I continue my discussion with nakeee regarding ebook-tools, I'm > > > trying to add support for svg images. > > > > > > 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
Re: [Okular-devel] Dt. 15th July - status
Please ignore this. I unknowingly sent it to the list. On Mon, Jul 15, 2013 at 10:37 PM, Jaydeep Solanki wrote: > Hi, > While I continue my discussion with nakeee regarding ebook-tools, I'm > trying to add support for svg images. > > Cheers, > Jaydeep > ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Dt. 15th July - status
Hi, While I continue my discussion with nakeee regarding ebook-tools, I'm trying to add support for svg images. Cheers, Jaydeep ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Reading TOC using 'ebook-tools'
here<https://github.com/jjmcd/mi-arpsc/blob/master/downloads/Michigan_2010_Summary/epub/ARPSC-2010-Michigan_2010_Summary-en-US.epub>'s a link to the file. On Fri, Jul 12, 2013 at 2:23 PM, E L wrote: > Hi, > Any chance you can send me the file which has problems? > > The code was supposed to handle that case, maybe I got the wrong > xml function. > > Thanks, > nakee > > > On Thu, Jul 11, 2013 at 6:07 PM, Jaydeep Solanki wrote: > >> Hello, >> I guess PinoTree is the maintainer of 'ebook-tools'. >> >> I noticed that epubs with a prefix in toc.ncx don't succeed in parsing >> toc. >> In my case I have an epub which contains the following in toc.ncx: >> >> where 'ncx' is a prefix. >> >> Seeing a function named '_get_possible_namespace', I thought it would be >> doing what I want, but I'm not sure it does the same. >> >> So I created a small function which compares key elements (like navPoint, >> navMap, etc.) with given prefix. In my case 'ncx'. >> >> I have seen that it is really rare of people using prefixes. >> >> BTW, is 'ncx' the default prefix ? or there can be others ? >> >> 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
Re: [Okular-devel] Reading TOC using 'ebook-tools'
Here's the diff file. On Thu, Jul 11, 2013 at 8:37 PM, Jaydeep Solanki wrote: > Hello, > I guess PinoTree is the maintainer of 'ebook-tools'. > > I noticed that epubs with a prefix in toc.ncx don't succeed in parsing toc. > In my case I have an epub which contains the following in toc.ncx: > > where 'ncx' is a prefix. > > Seeing a function named '_get_possible_namespace', I thought it would be > doing what I want, but I'm not sure it does the same. > > So I created a small function which compares key elements (like navPoint, > navMap, etc.) with given prefix. In my case 'ncx'. > > I have seen that it is really rare of people using prefixes. > > BTW, is 'ncx' the default prefix ? or there can be others ? > > Cheers, > Jaydeep > patch.diff Description: Binary data ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
