From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carlos Aguilar Newsgroups: gmane.emacs.devel Subject: Re: Suggestion / feature request Date: Thu, 19 Apr 2012 18:36:41 +0200 Message-ID: <4F903F19.80603@unilim.fr> References: <4F901313.5040804@unilim.fr> <87sjfzst54.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050506080309070807060507" X-Trace: dough.gmane.org 1334853435 27296 80.91.229.3 (19 Apr 2012 16:37:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 Apr 2012 16:37:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 19 18:37:10 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SKuLz-0000eT-7K for ged-emacs-devel@m.gmane.org; Thu, 19 Apr 2012 18:37:07 +0200 Original-Received: from localhost ([::1]:34888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SKuLy-00072J-Gk for ged-emacs-devel@m.gmane.org; Thu, 19 Apr 2012 12:37:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SKuLr-00071P-B6 for emacs-devel@gnu.org; Thu, 19 Apr 2012 12:37:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SKuLm-0002BW-BH for emacs-devel@gnu.org; Thu, 19 Apr 2012 12:36:58 -0400 Original-Received: from mail.unilim.fr ([164.81.1.45]:46985 helo=smtp.unilim.fr) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SKuLl-0002Az-TL for emacs-devel@gnu.org; Thu, 19 Apr 2012 12:36:54 -0400 Original-Received: from [164.81.39.165] ([164.81.39.165]) (authenticated bits=0) by smtp.unilim.fr (8.13.1/8.13.1) with ESMTP id q3JGaftw023354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Apr 2012 18:36:41 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 In-Reply-To: <87sjfzst54.fsf@thinkpad.tsdh.de> X-TagToolbar-Keys: D20120419183641383 X-Univ-Limoges-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (smtp.unilim.fr [164.81.1.45]); Thu, 19 Apr 2012 18:36:41 +0200 (CEST) X-Univ-Limoges-MD: Pas de virus trouve X-Scanned-By: MIMEDefang 2.67 on 164.81.1.45 X-Univ-Limoges-MailScanner-Information: Serveur Anti-virus Please contact postmaster@unilim.fr for more information X-Univ-Limoges-MailScanner-ID: q3JGaftw023354 X-Univ-Limoges-MailScanner: Found to be clean X-Univ-Limoges-MailScanner-Envelope-From: carlos.aguilar@unilim.fr X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 164.81.1.45 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:149821 Archived-At: This is a multi-part message in MIME format. --------------050506080309070807060507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.unilim.fr id q3JGaftw023354 Le 19/04/2012 16:17, Tassilo Horn a =E9crit : > Carlos Aguilar writes: > > Hi Carlos, > >> I often use doc-view mode with medium to large pdf/ps/dvi files, when >> writing/modifying latex documents. > Yes, frequently changing documents are clearly not the prime use-case > for doc-view, exactly because of the reasons you mention. Do you use > AUCTeX for writing your documents? If yes, then preview-latex might be > exactly what you need. > > ,----[ (info "(preview-latex)Top") ] > | preview-latex is a package embedding preview fragments into Emacs > | source buffers under the AUCTeX editing environment for LaTeX. It us= es > | `preview.sty' for the extraction of certain environments (most notabl= y > | displayed formulas). Other applications of this style file are > | possible and exist. > `---- > Ummm I suppose I am a bit of a maniac I really feel unconfortable if I=20 don't have the real pdf in front of me and can go back and forward to=20 check the global aspect of the document ... >> I wondered if it would be possible to keep a set of signatures of the >> pdf/ps/dvi pages processed so that those that are unchanged are not >> reconverted to (already existing) bitmap images. > Um, I have no idea how to do that. Doc-view only knows the PNG images > generated from the original document, and you can't compare those with > pages in the document. > > Well, it also has the old document's contents in the current buffer and > the updated document is on the file system, so in theory it could also > compare the documents. But I have no clue how to do that. Googling > around, I've found http://www.qtrac.eu/comparepdf.html, but I'm not sur= e > if it does the trick. (Oh, and of course if the comparison of the docs > is not significantly cheaper than a reconversion, there's no sense in > doing so. ;-)) Of course it must be MUCH cheaper. I have tried to use pdftk burst (which splits almost instantaneously a=20 pdf file in a set of files with one page each) with two closely=20 different versions of a large pdf. The idea was : if the pdf for each=20 file is exactly the same when pages are unchanged just a checksum will=20 do the test (and be very significantly cheaper than a reconversion). The resulting pdf files are close for each page but different. Maybe=20 there is a workaround with pdftk or directly with gs ... but before=20 doing that the question is : Would you change doc-view if it is possible to find a (simple enough)=20 way to obtain the functionality I am talking about ? Or do you believe=20 this is uninteresting/dangerous/outofscope ? cheers, Carlos > Bye, > Tassilo --------------050506080309070807060507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Le 19/04/2012 16:17, Tassilo Horn a écrit : 
Carlos Aguilar <carlos.aguilar@unilim.fr> writes:

Hi Carlos,


I often use doc-view mode with medium to large pdf/ps/dvi files, when
writing/modifying latex documents.

Yes, frequently changing documents are clearly not the prime use-case
for doc-view, exactly because of the reasons you mention.  Do you use
AUCTeX for writing your documents?  If yes, then preview-latex might be
exactly what you need.

,----[ (info "(preview-latex)Top") ]
|    preview-latex is a package embedding preview fragments into Emacs
| source buffers under the AUCTeX editing environment for LaTeX.  It uses
| `preview.sty' for the extraction of certain environments (most notably
| displayed formulas).  Other applications of this style file are
| possible and exist.
`----
Ummm I suppose I am a bit of a maniac I really feel unconfortable if I don't have the real pdf in front of me and can go back and forward to check the global aspect of the document  ... 

      

        
I wondered if it would be possible to keep a set of signatures of the
pdf/ps/dvi pages processed so that those that are unchanged are not
reconverted to (already existing) bitmap images.


      

      
Um, I have no idea how to do that.  Doc-view only knows the PNG images
generated from the original document, and you can't compare those with
pages in the document.

Well, it also has the old document's contents in the current buffer and
the updated document is on the file system, so in theory it could also
compare the documents.  But I have no clue how to do that.  Googling
around, I've found http://www.qtrac.eu/comparepdf.html, but I'm not sure
if it does the trick.  (Oh, and of course if the comparison of the docs
is not significantly cheaper than a reconversion, there's no sense in
doing so. ;-))


    

    Of course it must be MUCH cheaper. 

    

    I have tried to use pdftk burst (which splits almost instantaneously
    a pdf file in a set of files with one page each) with two closely
    different versions of a large pdf. The idea was : if the pdf for
    each file is exactly the same when pages are unchanged just a
    checksum will do the test (and be very significantly cheaper than a
    reconversion).

    

    The resulting pdf files are close for each page but different. Maybe
    there is a workaround with pdftk or directly with gs ... but before
    doing that the question is :

    Would you change doc-view if it is possible to find a (simple
    enough) way to obtain the functionality I am talking about ? Or do
    you believe this is uninteresting/dangerous/outofscope ?

    

    cheers,

    

    Carlos

    

    

    

      
Bye,
Tassilo


    

  


--------------050506080309070807060507--