From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?=D3scar_Fuentes?= Subject: Re: doc-view-mode Date: Thu, 13 Aug 2009 00:26:20 +0200 Message-ID: <87y6po3bzn.fsf@telefonica.net> References: <877hx84ypn.fsf_-_@telefonica.net> <877hx8logp.fsf@thinkpad.tsdh.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbMHN-00072r-Cn for emacs-orgmode@gnu.org; Wed, 12 Aug 2009 18:26:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbMHH-00072H-V6 for emacs-orgmode@gnu.org; Wed, 12 Aug 2009 18:26:44 -0400 Received: from [199.232.76.173] (port=33074 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbMHH-00072E-Q3 for emacs-orgmode@gnu.org; Wed, 12 Aug 2009 18:26:39 -0400 Received: from main.gmane.org ([80.91.229.2]:51067 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MbMHH-0003Ro-AE for emacs-orgmode@gnu.org; Wed, 12 Aug 2009 18:26:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MbMHD-0002wH-Ev for emacs-orgmode@gnu.org; Wed, 12 Aug 2009 22:26:35 +0000 Received: from 211.red-83-36-171.dynamicip.rima-tde.net ([83.36.171.211]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Aug 2009 22:26:35 +0000 Received: from ofv by 211.red-83-36-171.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Aug 2009 22:26:35 +0000 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hello Tassilo. Tassilo Horn writes: >> Converting the pdf|ps|dvi file to images is exactly what your >> favourite viewer does. The problem with doc-view-mode is that it >> converts *all* pages on the document to image *files* which are left >> on some place of the hard disk. > > I think that's the only practical solution, else you would have to wait > about a scond when switching to the next page. I have no problem waiting a second or two, although some experimentation shows that it is pretty fast opening a small pdf doc and even faster refreshing the image after M-x doc-view-enlarge. This is on Linux with a 2.4 GHz CPU. [snip] > Why are many files a problem for you? With that approach, opening a > document for the second time works instantly. And by default those > images are stored somewhere in /tmp: As said above, instantaneous response is not required for me. The problem with converting all the document to image files is that I often open large pdf's (several thousand pages) and small/medium dynamically generated pdf's. This would create tens of thousands of image files on a busy day (no exaggerating) which would require several gigabytes. Perhaps the most important problem with converting the full doc to image files is that it is a cpu and filesystem intensive process that can take a long time (think a fully illustrated 1000 page pdf). It steals cpu cycles on a busy machine (I often read while a long build or test suite is running) and drains battery on laptops/netbooks. [snip] IMHO, a user-configurable switch for "render this page and delete it before rendering the next" would be okay. More advanced options like keeping just the last N recently viewed pages of M documents (plus the succesive page of the current one) would be nice too, but if doc-view-mode supported the simple one-page option, it would be fine for me. P.D.: After some experimentation with doc-view it seems to me that the file image cache system is flawed: open a large pdf file -> doc-view starts conversion -> enlarge -> doc-view cancels previous conversion, throws away the files, and starts a new one -> shring -> cancel, throw and restart again, etc -> close the pdf view -> open the same pdf view -> if the cache I guess you thought that creating separate caches for every new zoom level would be too much caching :-) It seems there is a bug: open a large pdf -> before the conversion ends, kill the buffer -> open the pdf again -> the conversion is not resumed, only those pages converted on the previous session are accesible. -- Óscar