El Dilluns, 25 de novembre de 2013, a les 20:26:23, Ingo Kl=F6cker va e= scriure: > On Monday 25 November 2013 00:12:34 Albert Astals Cid wrote: > > El Dilluns, 25 de novembre de 2013, a les 00:01:41, Mark Gaiser va >=20 > escriure: > > > On Sun, Nov 24, 2013 at 10:09 PM, Albert Astals Cid >=20 > wrote: > > > > El Diumenge, 24 de novembre de 2013, a les 19:42:25, Mark Gaise= r > > > > va > >=20 > > escriure: > > > >> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid >=20 > wrote: > > > >> > In Okular we just got bug > > > >> > https://bugs.kde.org/show_bug.cgi?id=3D327846 > > > >> > PDF Render time is unreasonably slow over cifs on high laten= cy > > > >> > (WAN) > > > >> > network connections > > > >> >=20 > > > >> > Basically the issue is that poppler is quite read-intensive > > > >> > over files, reading them over and over, and since the file i= s > > > >> > "local but really remote" it takes ages to render for big > > > >> > files. > > > >> >=20 > > > >> > The only solution i can think of is doing a local copy and t= hen > > > >> > working on > > > >> > that. > > > >>=20 > > > >> That would work with small files (< 10 MB) but will get you in= to > > > >> trouble for bigger files. > > > >=20 > > > > Why? > > >=20 > > > See my example below. > > >=20 > > > >> You can't - or shouldn't - do that in an automated manner. If = the > > > >> user manually copies the file and then opens it in a pdf reade= r: > > > >> fine. Just don't auto copy the file. So you can probably give > > > >> the user a popup suggesting them to copy the file to his local= > > > >> drive? > > > >=20 > > > > Why? If you open a huge file by smb:// it'll copy it to the loc= al > > > > file anyway, so why should not we copy it? > > >=20 > > > Right. True but should it be like that? > > > Lets take playing a movie from smb as an example. If you do that = now > > > in for example mplayer then kde will simply copy the movie to you= r > > > local drive and start playing it. But should that be the case? I > > > consider it a massive usability bug. One that isn't easy to fix. = If > > > you would mount the same share as cifs then the system "thinks" i= t's > > > local and just plays the movie without copying. > > >=20 > > > That is how it should be. Copying to your local system is a nasty= > > > workaround which should imho be prevented. > >=20 > > A PDF file is not a movie, it can't be read lineraly. >=20 > Does the PDF format really prevent me from reading just the first 2 > pages of a 100 pages document if I just download the first few KBs of= > the PDF file? I don't know the PDF format, so this question is seriou= s. It [mostly] does. The XRef (table that references everything else on th= e file)=20 is at the end of the file. So we need that, of course in protocols like= CIFS=20 we can just read the end of the file without downloading it all. But th= at=20 still leaves us with objects that reference eachother all over and unle= ss the=20 file is specially crafted (so called Linearized PDF) it'll mostly be "t= he=20 whole file", so no you don't need *always* the whole file, but you most= ly do. > If the answer to the question is no, then it does make a lot of sense= to > load the file iteratively. For example, if I just want to have a quic= k > look at the document (e.g. the abstract on the first page) to decide > whether it's really the document I am looking for, then I surely don'= t > want to wait for the entire document to be downloaded. Yes, that can be done, as it is my plan, but still will need to downloa= d the=20 whole file most of the times. Cheers, Albert >=20 >=20 > Regards, > Ingo