Doc-view resizing

Doc-view resizing

[Stefan Monnier]

Any objection to the patch below?


        Stefan


--- orig/lisp/doc-view.el
+++ mod/lisp/doc-view.el
@@ -102,7 +102,8 @@
 ;; - better menu.
 ;; - don't use `find-file'.
 ;; - Bind slicing to a drag event.
-;; - zoom (the whole document and/or just the region around the cursor).
+;; - doc-view-fit-doc-to-window and doc-view-fit-window-to-doc.
+;; - zoom a the region around the cursor (like xdvi).
 ;; - get rid of the silly arrow in the fringe.
 ;; - improve anti-aliasing (pdf-utils gets it better).
 
@@ -154,11 +155,16 @@
   '("-dSAFER" ;; Avoid security problems when rendering files from untrusted
 	      ;; sources.
     "-dNOPAUSE" "-sDEVICE=png16m" "-dTextAlphaBits=4"
-    "-dBATCH" "-dGraphicsAlphaBits=4" "-dQUIET" "-r100")
+    "-dBATCH" "-dGraphicsAlphaBits=4" "-dQUIET")
   "A list of options to give to ghostscript."
   :type '(repeat string)
   :group 'doc-view)
 
+(defcustom doc-view-resolution 100
+  "Dots per inch resolution used to render the documents.
+Higher values result in larger images."
+  :type 'number)
+
 (defcustom doc-view-dvipdfm-program (executable-find "dvipdfm")
   "Program to convert DVI files to PDF.
 
@@ -253,6 +259,9 @@
     (define-key map (kbd "M-<")       'doc-view-first-page)
     (define-key map (kbd "M->")       'doc-view-last-page)
     (define-key map [remap goto-line] 'doc-view-goto-page)
+    ;; Shrink/grow
+    (define-key map "+"               'doc-view-enlarge)
+    (define-key map "-"               'doc-view-shrink)
     ;; Killing/burying the buffer (and the process)
     (define-key map (kbd "q")         'bury-buffer)
     (define-key map (kbd "k")         'doc-view-kill-proc-and-buffer)
@@ -448,6 +457,20 @@
 
 ;;;; Conversion Functions
 
+(defvar doc-view-shrink-factor 1.1)
+
+(defun doc-view-enlarge (factor)
+  "Enlarge the document."
+  (interactive (list doc-view-shrink-factor))
+  (set (make-local-variable 'doc-view-resolution)
+       (* factor doc-view-resolution))
+  (doc-view-reconvert-doc))
+
+(defun doc-view-shrink (factor)
+  "Enlarge the document."
+  (interactive (list doc-view-shrink-factor))
+  (doc-view-enlarge (/ 1.0 factor)))
+
 (defun doc-view-reconvert-doc ()
   "Reconvert the current document.
 Should be invoked when the cached images aren't up-to-date."
@@ -503,6 +526,7 @@
 	       (append (list "pdf/ps->png" doc-view-conversion-buffer
 			     doc-view-ghostscript-program)
 		       doc-view-ghostscript-options
+                       (list (format "-r%d" (round doc-view-resolution)))
 		       (list (concat "-sOutputFile=" png))
 		       (list pdf-ps)))
 	mode-line-process (list (format ":%s" doc-view-current-converter-process)))

Re: Doc-view resizing

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

> Any objection to the patch below?

[...]

> @@ -154,11 +155,16 @@
>    '("-dSAFER" ;; Avoid security problems when rendering files from untrusted
>  	      ;; sources.
>      "-dNOPAUSE" "-sDEVICE=png16m" "-dTextAlphaBits=4"
> -    "-dBATCH" "-dGraphicsAlphaBits=4" "-dQUIET" "-r100")
> +    "-dBATCH" "-dGraphicsAlphaBits=4" "-dQUIET")
>    "A list of options to give to ghostscript."
>    :type '(repeat string)
>    :group 'doc-view)
>  
> +(defcustom doc-view-resolution 100
> +  "Dots per inch resolution used to render the documents.
> +Higher values result in larger images."
> +  :type 'number)
> +

That's fine.

For the resizing: I didn't test the patch, but +/- will reconvert the
whole doc, right?  I think that's inacceptable slow.  Let's say you're
reading page 333 and now you hit `+'.  That will make page 1 current and
it'll need too much time till page 333 has been converted again.

A better and much mode general approach would be to implement image
zooming in emacs, e.g.

    (insert-image IMAGE &optional STRING AREA SLICE)

would become

    (insert-image IMAGE &optional STRING AREA SLICE ZOOM)

where ZOOM is the factor for zooming the image.  Of course, that costs
more effort to implement, but various other modes could benefit from it,
too (i.e. image-mode, image-dired, emacs-w3m, Gnus).

Any volunteers?

Bye,
Tassilo

Re: Doc-view resizing

[Stefan Monnier]

> For the resizing: I didn't test the patch, but +/- will reconvert the
> whole doc, right?  I think that's inacceptable slow.  Let's say you're
> reading page 333 and now you hit `+'.  That will make page 1 current and
> it'll need too much time till page 333 has been converted again.

Yes, that's a problem, but the same problem occurs when the file gets
modified and the buffer needs to be reverted (e.g. if you use
auto-revert-mode).  I.e. the `reconvert' functionality would benefit
from being able to transform page 333 first and the rest afterwards.

> A better and much mode general approach would be to implement image
> zooming in emacs, e.g.

>     (insert-image IMAGE &optional STRING AREA SLICE)

> would become

>     (insert-image IMAGE &optional STRING AREA SLICE ZOOM)

> where ZOOM is the factor for zooming the image.  Of course, that costs
> more effort to implement, but various other modes could benefit from it,
> too (i.e. image-mode, image-dired, emacs-w3m, Gnus).

That is not the same functionality: zooming the bitmap will not give you
the same quality.  It's probably a worthwhile feature, but it different
from the one I'm proposing.


        Stefan

Re: Doc-view resizing

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> For the resizing: I didn't test the patch, but +/- will reconvert the
>> whole doc, right?  I think that's inacceptable slow.  Let's say you're
>> reading page 333 and now you hit `+'.  That will make page 1 current and
>> it'll need too much time till page 333 has been converted again.
>
> Yes, that's a problem, but the same problem occurs when the file
> gets modified and the buffer needs to be reverted (e.g. if you use
> auto-revert-mode).  I.e. the `reconvert' functionality would benefit
> from being able to transform page 333 first and the rest afterwards.

AUCTeX's preview-latex does that kind of thing.  This necessitates
talking to Ghostscript and, in the case of PostScript, parsing the DSC
comments.  While this sort of parsing should not be required for PDF,
I do not know enough about it and the Ghostscript interaction with
PDF, preview-latex uses pdf2dsc in order to convert PDF into a
pseudo-structured PostScript file including DSC comments, and then
basically works with that.

I would think that some of the code talking to Ghostscript and the
stuff parsing the DSC comments should be possible to be recycled from
there: the whole of preview-latex is copyright-assigned to the FSF.

-- 
David Kastrup

Re: Doc-view resizing

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> For the resizing: I didn't test the patch, but +/- will reconvert the
>> whole doc, right?  I think that's inacceptable slow.  Let's say
>> you're reading page 333 and now you hit `+'.  That will make page 1
>> current and it'll need too much time till page 333 has been converted
>> again.
>
> Yes, that's a problem, but the same problem occurs when the file gets
> modified and the buffer needs to be reverted (e.g. if you use
> auto-revert-mode).  I.e. the `reconvert' functionality would benefit
> from being able to transform page 333 first and the rest afterwards.

I agree.

>> A better and much mode general approach would be to implement image
>> zooming in emacs, e.g.
>
>>     (insert-image IMAGE &optional STRING AREA SLICE)
>
>> would become
>
>>     (insert-image IMAGE &optional STRING AREA SLICE ZOOM)
>
>> where ZOOM is the factor for zooming the image.  Of course, that
>> costs more effort to implement, but various other modes could benefit
>> from it, too (i.e. image-mode, image-dired, emacs-w3m, Gnus).
>
> That is not the same functionality: zooming the bitmap will not give
> you the same quality.

What if you set `doc-view-resolution' to a high value so that in general
zooming means shrinking the image?  Will the quality still suffer from
that?

Bye,
Tassilo

Re: Doc-view resizing

[Stefan Monnier]

> What if you set `doc-view-resolution' to a high value so that in general
> zooming means shrinking the image?  Will the quality still suffer from
> that?

I was thinking of exactly that right after sending my message.
I'm not sure if I'd want to use it for the "zoom to fit the available
screen real estate" (which is what my enlarge/shrink are for).

OTOH we could use it similarly to xdvi: xdvi renders to a high
resolution and then scale it back for display, always by an
integer factor.  This has 2 advantages: the scaling can be used for
anti-aliasing (and the integer factor seems to ensure a good result),
and the unscaled version can be displayed very quickly.

Assuming we can shrink images in a way that gives us good anti-aliasing,
that would be a very attractive approach: it allows us to "zoom around
cursor" like xdvi, and may also give us better anti-aliasing than the
one done by gs (which isn't stellar, sadly).


        Stefan

Image zooming for emacs (was: Doc-view resizing)

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> OTOH we could use it similarly to xdvi: xdvi renders to a high
> resolution and then scale it back for display, always by an integer
> factor.  This has 2 advantages: the scaling can be used for
> anti-aliasing (and the integer factor seems to ensure a good result),
> and the unscaled version can be displayed very quickly.
>
> Assuming we can shrink images in a way that gives us good
> anti-aliasing, that would be a very attractive approach: it allows us
> to "zoom around cursor" like xdvi, and may also give us better
> anti-aliasing than the one done by gs (which isn't stellar, sadly).

I think we should add image zooming (shrinking) to etc/TODO.  Maybe
somebody volunteers.

Bye,
Tassilo