Version: 0.4 (using KDE 3.4.0, Debian Package 4:3.4.0-0ubuntu3.1 (3.1)) Compiler: gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2) OS: Linux (i686) release 2.6.11.7 This wish would be expecially useful during presentations. If I select "aggressive" memory behaviour, and read a certain number of pages, those pages are prerendered (I suppose) and faster to load. Since on complicated presentations a slide (which might be only a sub-slide if you think about effects as in latex-beamer) can take 2-3 seconds to load it is a little uncomfortable. Could the next "n" slides be loaded while reading a slide, where n depends on available memory and can eventually be the whole document?
I totally agree with you. I like kpdf and I'm using it for my daily work. But in presentations I still prefer Acrobat Reader, because it's preloading the next page(s). Sometimes kpdf is taking up to 10 seconds for switching to the next slide. Of course that's not the general case, but it happens if you are using some (detailed) images.
Does Okular do this? As far as I understood kpdf is going to replaced by Okular
Oops, now I see there is already an option in the kpdf settings for preloading the next slides. To active this option in kpdf 0.5.8 you have to go to settings->configure kpdf->performance->memory usage and select "aggressive". Good job, kpdf team!
Stefan. Vincenzo is already refering to this option. He wants to be able to preload more pages. I would like this also since I have 3 Gb RAM and usually only use 500 Mb. It doesn't make any sense to me that I can't select to preload the next 10 pages or more.
Oh. Thanks for the correction and sorry for my last post. You're right. In aggressive mode kpdf is already caching much more then 10 pages, but it is only preloading *one* page.
*** Bug 126806 has been marked as a duplicate of this bug. ***
My wish was about prerendering, not only preloading, so quote: " My suggestion -- with such option switched on kpdf should use RAM to its maximum. Prerender pages backward and forward to given limit /*/ at the given zoom. If user move for example forward, prerender for one backward page, 2 /*/ forward. If user change zoom, start prerendering pages again but keeping the previous renderings /*; just for case if user set the previous zoom/. So, after few seconds I could basically view static screens without images loading, text blur, etc. /*/ -- just an example, I think all these should be configurable. "
Prerendering *is* preloading. You can call it "walla walla", but it's called "preloading".
It would be useful to use correct terms. If you mean loading data in advance it is preloading, if you mean rendering in advance it is prerendering. Thank you.
It is correct, because it preLOADs in memory pixmaps of pages. Beside that, it would also be useful if you would avoid using only your vision of the facts, and of bug reports (aka quoting because it's not like I want). Thank you.
What is the walla-walla term for preloading (loading data in advance from disk) then? It is not my vision, it is dictionary. Thank you. And since when quoting is bad I don't know.
My wish is about pre-rendering then :)
> What is the walla-walla term for preloading (loading data in advance from disk) then? In the case of KPDF, none, as all the document is read from disk at once. > And since when quoting is bad I don't know. Since it adds nothing to the bug, except the classic "I want tons of options" of yours. @Vincenzo: preloading is correct, despite Maciej's ideas.
> preloading is correct, despite Maciej's ideas. As I said before, it is a dictionary not me -- loading does not mean rendering (after all you can load the document without rendering, pdftk is just an example). Do not reinvent English, thank you. Ok, enough said -- in short, I opt for option with which user could control the limits of prerendering the document in context of available RAM. Pino, if you want to discuss technical issues of this report to make kpdf/okular better, please do, but if you want to discuss personal matters please find place somewhere else.
> As I said before, it is a dictionary not me Preloading is a KPDF term used since ages (eg, look in the configuration dialog). There is not other meaning in KPDF, and users use and always used preloading. Nobody is reiventing anything, this is a consolidated term in KPDF. You like it or not, of course. Ah, and referring to personal tastes, that applies to a good percentage of your bug reports (and no, I am not inventing anything). On my side, this is my last non-pertinet message to this bug report (unless you continue on your personal POV, of course).
> There is not other meaning in KPDF, and users use and always used > preloading. Nobody is reiventing anything, this is a consolidated term in > KPDF. > You like it or not, of course. It is not matter of liking -- KPDF is not alone app, there is whole KDE and it would be really good to provide uniform UI. If one app uses term X for reading, other for computing, another for drawing this leads to messy environment. There are also side effects: to understand incorrectly/not precisely used term you have to know the internals of the application, it is also harder for translators to provide accurate translation. The general rule is: use the minimal vocabulary and use it in consistent way. It is not a crime to make a mistake, spotting misused term is rather a good opportunity to improve application. I don't know why you see this as some kind of attack.
You both STOP NOW It makes no sense to keep arguing when everyone understands what the wish is about
KPDF is no longer under development so i'm closing this bug as wontfix. If you feel Okular (KPDF successor) features in this area still do not fulfill your needs please open a new bug report.