bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

This patch created by Sho Nakatani <lay.sakura@gmail.com> (in Cc) adds a
feature to fit the current doc to the window height/width.  I already
tested it, and it works as expected.  The emacs coding standards are
also met.

I have instructed Nakatani in doing the copyright assignment, and he is
willing to do so.  When the assignment is confirmed, I'll apply and push
his changes.

Here's the patch:

--8<---------------cut here---------------start------------->8---
=== modified file 'lisp/doc-view.el'
--- old/lisp/doc-view.el	2011-01-25 04:08:28 +0000
+++ new/lisp/doc-view.el	2011-03-28 08:59:52 +0000
@@ -327,6 +327,10 @@
     ;; Zoom in/out.
     (define-key map "+"               'doc-view-enlarge)
     (define-key map "-"               'doc-view-shrink)
+    ;; Fit the image to the window
+    (define-key map "W"               'doc-view-fit-width-to-window)
+    (define-key map "H"               'doc-view-fit-height-to-window)
+    (define-key map "P"               'doc-view-fit-page-to-window)
     ;; Killing the buffer (and the process)
     (define-key map (kbd "k")         'doc-view-kill-proc-and-buffer)
     (define-key map (kbd "K")         'doc-view-kill-proc)
@@ -665,6 +669,45 @@
   (interactive (list doc-view-shrink-factor))
   (doc-view-enlarge (/ 1.0 factor)))
 
+(defun doc-view-fit-width-to-window ()
+  "Fit the image width to the window width."
+  (interactive)
+  (let ((img-width (car (image-display-size
+                         (image-get-display-property))))
+        (win-width (- (nth 2 (window-inside-edges))
+                      (nth 0 (window-inside-edges)))))
+    (doc-view-enlarge (/ win-width img-width))))
+
+(defun doc-view-fit-height-to-window ()
+  "Fit the image height to the window width."
+  (interactive)
+  (let ((img-height (cdr (image-display-size
+                          (image-get-display-property))))
+        (win-height (- (nth 3 (window-inside-edges))
+                       (nth 1 (window-inside-edges)))))
+    ;; When users call 'doc-view-fit-height-to-window',
+    ;; they might want to go to next page by typing SPC
+    ;; ONLY once. So I used '(- win-height 1)' instead of
+    ;; 'win-height'
+    (doc-view-enlarge (/ (- win-height 1) img-height))))
+
+(defun doc-view-fit-page-to-window ()
+  "Fit the image to the window.
+More specifically, this function enlarges image by:
+
+min {(window-width / image-width), (window-height / image-height)} times."
+  (interactive)
+  (let ((img-width (car (image-display-size
+                         (image-get-display-property))))
+        (win-width (- (nth 2 (window-inside-edges))
+                      (nth 0 (window-inside-edges))))
+        (img-height (cdr (image-display-size
+                          (image-get-display-property))))
+        (win-height (- (nth 3 (window-inside-edges))
+                       (nth 1 (window-inside-edges)))))
+    (doc-view-enlarge (min (/ win-width img-width)
+                           (/ (- win-height 1) img-height)))))
+
 (defun doc-view-reconvert-doc ()
   "Reconvert the current document.
 Should be invoked when the cached images aren't up-to-date."

--8<---------------cut here---------------end--------------->8---

bug#8364: Acknowledgement (24.0.9999; PATCH: Fit to width/height/page for doc-view.el)

[Tassilo Horn]

Here's a corresponding ChangeLog entry:

--8<---------------cut here---------------start------------->8---
2011-03-28  Sho Nakatani <lay.sakura@gmail.com>

	* doc-view.el (doc-view-fit-width-to-window)
	(doc-view-fit-height-to-window, doc-view-fit-page-to-window): New
	functions for fitting the shown image to the Emacs window size.
	(doc-view-mode-map): Add bindings for the new functions.
--8<---------------cut here---------------end--------------->8---

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Stefan Monnier]

> This patch created by Sho Nakatani <lay.sakura@gmail.com> (in Cc) adds a
> feature to fit the current doc to the window height/width.  I already
> tested it, and it works as expected.  The emacs coding standards are
> also met.

> I have instructed Nakatani in doing the copyright assignment, and he is
> willing to do so.  When the assignment is confirmed, I'll apply and push
> his changes.

Good, thanks.  I'll still have to do it by hand, sadly, since I like to
"fit the text" rather than "fit the page", i.e. I like to keep the
margins outside of the viewable area.  A command to do that
automatically would be really nifty.


        Stefan

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[sho nakatani]

HI Stefan,

> Good, thanks.  I'll still have to do it by hand, sadly, since I like to
> "fit the text" rather than "fit the page", i.e. I like to keep the
> margins outside of the viewable area.  A command to do that
> automatically would be really nifty.

Sad to say, I have no idea to realize such function, although I completely
agree with you.
Currently, the scale factor for enlarge/shrink is determined by the ratio of
the size of PNG image to the size of window. It is pretty difficult to specify
where 'margins' are from PNG image.

It might be possible if the scale factor is determined not from PNG image
but from PDF/PS. However, it is far difficult than current implementation.

Anyway, thank you so much for your advice.

-- 
Sho Nakatani <lay.sakura@gmail.com>

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Stefan Monnier]

>> Good, thanks.  I'll still have to do it by hand, sadly, since I like to
>> "fit the text" rather than "fit the page", i.e. I like to keep the
>> margins outside of the viewable area.  A command to do that
>> automatically would be really nifty.
> Sad to say, I have no idea to realize such function, although I completely
> agree with you.

Neither do I, which is why I haven't implemented it yet.

Actually, I think it's largely impossible to do it the way I like to do
it by hand, because I often keep page headers and footers outside of the
viewable area, so the tool would have to be able to recognize those
automatically, which seems close to impossible.
I've tried to use pdfcrop a few times but it almost always bumps into
some text displayed in some corner and ends up showing me more than
I want to see.


        Stefan

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[joakim]

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

>>> Good, thanks.  I'll still have to do it by hand, sadly, since I like to
>>> "fit the text" rather than "fit the page", i.e. I like to keep the
>>> margins outside of the viewable area.  A command to do that
>>> automatically would be really nifty.
>> Sad to say, I have no idea to realize such function, although I completely
>> agree with you.
>
> Neither do I, which is why I haven't implemented it yet.
>
> Actually, I think it's largely impossible to do it the way I like to do
> it by hand, because I often keep page headers and footers outside of the
> viewable area, so the tool would have to be able to recognize those
> automatically, which seems close to impossible.
> I've tried to use pdfcrop a few times but it almost always bumps into
> some text displayed in some corner and ends up showing me more than
> I want to see.

"unpaper" is free software and is actually pretty good at finding
margins automatically. Maybe that could be called optionally? It would
just be used to find margins and provide the coordinates to docview.

Also I have some code to call "opencv" to find lens dust in an Emacs
image in my "Emsane" package on github.

Just some random feedback for you.

>
>
>         Stefan
>
>
>
>

-- 
Joakim Verona

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

sho nakatani <lay.sakura@gmail.com> writes:

Hi!

>> Good, thanks.  I'll still have to do it by hand, sadly, since I like
>> to "fit the text" rather than "fit the page", i.e. I like to keep the
>> margins outside of the viewable area.  A command to do that
>> automatically would be really nifty.
>
> Sad to say, I have no idea to realize such function, although I completely
> agree with you.
> Currently, the scale factor for enlarge/shrink is determined by the ratio of
> the size of PNG image to the size of window. It is pretty difficult to specify
> where 'margins' are from PNG image.

Users can cut the margins using the slice feature (`s m').  The
information about the current slice (X Y WIDTH HEIGHT) can be accessed
using the `doc-view-current-slice' macro.  So it seems doable to
calculate the right zoom factor and adjust the slice accordingly after
zooming if a slice was set.  How that can be done is left as an exercise
to the reader. ;-)

Nakatani, feel free to implement that, and send updated patches to this
"bug" report.

> It might be possible if the scale factor is determined not from PNG
> image but from PDF/PS.  However, it is far difficult than current
> implementation.

I'd advice not to add special-case code for certain kinds of documents.

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[sho nakatani]

2011/3/29 Tassilo Horn <tassilo@member.fsf.org>:

Hi!

> Users can cut the margins using the slice feature (`s m').  The
> information about the current slice (X Y WIDTH HEIGHT) can be accessed
> using the `doc-view-current-slice' macro.  So it seems doable to
> calculate the right zoom factor and adjust the slice accordingly after
> zooming if a slice was set.  How that can be done is left as an exercise
> to the reader. ;-)

Wow.. I've completely misunderstood the meaning of `margine' ;-)
I tried the slice feature first. It is GREAT!

I want to implement `fit-slice-to-window' feature!
I have not touched the feature yet, so it is possible I will encounter
big problems (for me!).

Please be patient and wait for the new feature.

--
Sho Nakatani

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

sho nakatani <lay.sakura@gmail.com> writes:

Hi Nakatani,

> I tried the slice feature first. It is GREAT!

Good to hear.

> I want to implement `fit-slice-to-window' feature!
> I have not touched the feature yet, so it is possible I will encounter
> big problems (for me!).

Feel free to ask if you encounter problems, preferably on the
emacs-devel list.

> Please be patient and wait for the new feature.

You have all the time you need.  The "copyright dance" takes at least
two weeks, anyway. ;-)

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[sho nakatani]

Hi!

I'm trying to add `fit-slice-to-window' feature in doc-view.el.

Here, `slice' is a part of region of an image.
If you set a slice  on an image in DocViewMode, the region outside the
slice will disappear.
Slice is originally defined in image-mode.el, which doc-view.el requires.

Now I encounter a problem.
I wrote `doc-view-fit-slice-width-to-window' function below but it
doesn't work good.
Just copy and paste the code to lisp/image-mode.el and evaluate it to test.

What I want to implement is:

1. Calculate the scale factor to make the slice fit to window from
slice size and window size.
2. Enlarge the image by the scale factor.
3. Set new slice to the image.

The problem is:

*   I don't know how to reflect a new slice to an image.
    I tried a lot of sequences of `enlarge', `set slice', `reconvert',
`redisplay'.
    But all of the trials ended up failure..
    Here's what I have understood from the code.

    Usually, `doc-view-set-slice' is called to set a slice, in which
`doc-view-goto-page' is called internally to
    redisplay the image.
    However, just calling `doc-view-set-slice' is not enough here
because the image should reconverted
    after it is enlarged. So I set the scale factor to `doc-view-resolution'
    and then called `doc-view-reconvert-doc' (this is what
"(doc-view-enlarge factor)" does).
    So currently I set both new slice and new scale and then call
`doc-view-reconvert-doc'.
    However, `doc-view-reconvert-doc' doesn't call
`doc-view-goto-page' to redisplay the image by the time
    all of the pages are converted.

I'm waiting for your help.
Thanks.

===CODE===
(defun doc-view-fit-slice-width-to-window ()
  (interactive)
  (let ((slice (doc-view-current-slice)))
    (if (null slice)
        (doc-view-fit-width-to-window)

      ;; If slice is set
      (let* ((slice-width (nth 2 slice))
             (win-width (- (nth 2 (window-inside-pixel-edges))
                           (nth 0 (window-inside-pixel-edges))))
             (scale-factor (/ (float win-width) (float slice-width)))
             (new-slice (mapcar (lambda (x) (* scale-factor x)) slice)))

        (set (make-local-variable 'doc-view-resolution)
             (ceiling (* scale-factor doc-view-resolution))) ;Set new
size for image.
        (setf (doc-view-current-slice) nil) ;Set slice.
        (doc-view-reconvert-doc)        ;First, cache file is deleted.
                                        ;Then, new file with new scale
is created.
                                        ;Finally, the new file is
displayed with THE SAME SLICE AS BEFORE
                                        ;by the time all pages are converted
))))
===CODE END===


2011/3/29 Tassilo Horn <tassilo@member.fsf.org>:
> sho nakatani <lay.sakura@gmail.com> writes:
>
> Hi Nakatani,
>
>> I tried the slice feature first. It is GREAT!
>
> Good to hear.
>
>> I want to implement `fit-slice-to-window' feature!
>> I have not touched the feature yet, so it is possible I will encounter
>> big problems (for me!).
>
> Feel free to ask if you encounter problems, preferably on the
> emacs-devel list.
>
>> Please be patient and wait for the new feature.
>
> You have all the time you need.  The "copyright dance" takes at least
> two weeks, anyway. ;-)
>
> Bye,
> Tassilo
>



-- 
Sho Nakatani

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

Hi Nakatani,

thanks a lot for fiddeling with the issue.  I've found the bug in your
code.  Here's a working function:

--8<---------------cut here---------------start------------->8---
(defun doc-view-fit-slice-width-to-window ()
  (interactive)
  (let ((slice (doc-view-current-slice)))
    (if (null slice)
        (doc-view-fit-width-to-window)
      ;; If slice is set
      (let* ((slice-width (nth 2 slice))
             (win-width (- (nth 2 (window-inside-pixel-edges))
                           (nth 0 (window-inside-pixel-edges))))
             (scale-factor (/ (float win-width) (float slice-width)))
             (new-slice (mapcar (lambda (x) (ceiling (* scale-factor x))) slice)))
	(set (make-local-variable 'doc-view-resolution)
             (ceiling (* scale-factor doc-view-resolution)))
	(doc-view-enlarge scale-factor)
        (setf (doc-view-current-slice) new-slice)
	(doc-view-goto-page (doc-view-current-page))))))
--8<---------------cut here---------------end--------------->8---

The problematic issue was that the `new-slice' calculated by the
`mapcar' contained floating point numbers, which are not allowed for
slice specs.  I found out by using `edebug-defun' on
`doc-view-insert-image'.

One minor thing: I would prefer if your three original functions would
respect the current slice if there is one, instead of adding a fourth
function for that purpose.  Could you please make it that way?

Thanks again, you really did very impressive work!

And I'm especially pleased that my assumption of calculating the right
scales of both image and slices out of the plain images without
resorting to external tools turned out being right. ;-)

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

sho nakatani <lay.sakura@gmail.com> writes:

Hi Nakatani,

> But your function doesn't work for some files.

What exactly doesn't work?

> I attached an example PDF file (written in Japanse).

Sorry, but my ghostscript crashes with that file.  Since I update to
ghostscript 9.x, I get crashes for some PDF files...

--8<---------------cut here---------------start------------->8---
   **** Warning: can't process font stream, loading font by the name.
Error: /undefined in findresource
Operand stack:
   --dict:5/14(L)--   F3   15.919   --dict:5/5(L)--   --dict:5/5(L)--   Ryumin-Light-Identity-H   --dict:9/12(ro)(G)--   --nostringval--   CIDFontObject   --dict:7/7(L)--   --dict:7/7(L)--   Adobe-Japan1
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1894   1   3   %oparray_pop   1893   1   3   %oparray_pop   1877   1   3   %oparray_pop   --nostringval--   --nostringval--   2   1   78   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   false   1   %stopped_push   --nostringval--   %loop_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %loop_continue
Dictionary stack:
   --dict:1164/1684(ro)(G)--   --dict:1/20(G)--   --dict:82/200(L)--   --dict:82/200(L)--   --dict:108/127(ro)(G)--   --dict:295/300(ro)(G)--   --dict:23/30(L)--   --dict:6/8(L)--   --dict:21/40(L)--   --dict:7/15(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 9.01: Unrecoverable error, exit code 1
--8<---------------cut here---------------end--------------->8---

Even if I open that file with Evince, I mostly see boxes instead of
japanese glyphs. :-(

If you have more files that don't work, feel free to send them to me.
(No need to attach them all to this bug report.)

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[sho nakatani]

Tassilo

Hi Tassilo,


>> But your function doesn't work for some files.
>
> What exactly doesn't work?

I meant that after calling `doc-view-fit-slice-width-to-window' the
image disappeared from the window.
I tested some files written in both English and Japanese.
After that, I realized only images written in Japanese sometimes (not
always) cause this error.

I guess this error is related with font set and ghostscript, or my own
environment.
We non-Westerner are sometimes bothered by errors related by fonts.
Actually, DocViewMode display files in English quite well but
sometimes it fails to display files in Japanese.

In my opinion, current implementation is enough for use.
As I said, I sometimes fail to view PDF/PS files in DocViewMode, so I
don't mind so much even if
`doc-view-fit-slice-width-to-window' causes an error.
Also, if a file written in Japanese can be displayed by DocViewMode,
at least `doc-view-fit-*-to-window'
without slice succeeds.
Adding `doc-view-fit-slice-to-window' feature does help viewing English files,
and it does not do ANY harm for viewing Japanese files.
So I suggest to add this new feature.

I'll send a patch soon.
Thanks.

--
Sho Nakatani

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

sho nakatani <lay.sakura@gmail.com> writes:

>>> But your function doesn't work for some files.
>>
>> What exactly doesn't work?
>
> I meant that after calling `doc-view-fit-slice-width-to-window' the
> image disappeared from the window.

That was the effect of your original function, too.  So you might want
to double-check that no floating point numbers are given to any image
function for :width or 'slice...

> I tested some files written in both English and Japanese.  After that,
> I realized only images written in Japanese sometimes (not always)
> cause this error.
>
> I guess this error is related with font set and ghostscript, or my own
> environment.

I can confirm that ghostscript sometimes has issues with fonts.
However, in that case it would be awkward if fitting works without
slice, but fails with slice...

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[sho nakatani]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Hi!

I finished writing the new patch.
It supports fitting image to window in DocViewMode.
It works even if you set a slices.

Thank you for your advice.
I checked the point.

> I can confirm that ghostscript sometimes has issues with fonts.
> However, in that case it would be awkward if fitting works without
> slice, but fails with slice...

Now it works even with PDF/PS in Japanese!
I found the cause of previous problem in a code I edited.

Please test it and hopefully tell me good results!
Thanks,

-- 
Sho Nakatani

[-- Attachment #2: doc-view-fit-page-to-window-with-slice-support.patch --]
[-- Type: text/x-patch, Size: 4340 bytes --]

=== modified file 'lisp/doc-view.el'
--- old/lisp/doc-view.el	2011-01-25 04:08:28 +0000
+++ new/lisp/doc-view.el	2011-03-30 15:32:54 +0000
@@ -327,6 +327,10 @@
     ;; Zoom in/out.
     (define-key map "+"               'doc-view-enlarge)
     (define-key map "-"               'doc-view-shrink)
+    ;; Fit the image to the window
+    (define-key map "W"               'doc-view-fit-width-to-window)
+    (define-key map "H"               'doc-view-fit-height-to-window)
+    (define-key map "P"               'doc-view-fit-page-to-window)
     ;; Killing the buffer (and the process)
     (define-key map (kbd "k")         'doc-view-kill-proc-and-buffer)
     (define-key map (kbd "K")         'doc-view-kill-proc)
@@ -665,6 +669,78 @@
   (interactive (list doc-view-shrink-factor))
   (doc-view-enlarge (/ 1.0 factor)))
 
+(defun doc-view-fit-width-to-window ()
+  "Fit the image width to the window width."
+  (interactive)
+  (let ((win-width (- (nth 2 (window-inside-pixel-edges))
+                      (nth 0 (window-inside-pixel-edges))))
+        (slice (doc-view-current-slice)))
+    (if (not slice)
+        (let ((img-width (car (image-display-size
+                               (image-get-display-property) t))))
+          (doc-view-enlarge (/ (float win-width) (float img-width))))
+
+      ;; If slice is set
+      (let* ((slice-width (nth 2 slice))
+             (scale-factor (/ (float win-width) (float slice-width)))
+             (new-slice (mapcar (lambda (x) (ceiling (* scale-factor x))) slice)))
+
+        (doc-view-enlarge scale-factor)
+        (setf (doc-view-current-slice) new-slice)
+        (doc-view-goto-page (doc-view-current-page))))))
+
+(defun doc-view-fit-height-to-window ()
+  "Fit the image height to the window height."
+  (interactive)
+  (let ((win-height (- (nth 3 (window-inside-pixel-edges))
+                       (nth 1 (window-inside-pixel-edges))))
+        (slice (doc-view-current-slice)))
+    (if (not slice)
+        (let ((img-height (cdr (image-display-size
+                                (image-get-display-property) t))))
+          ;; When users call 'doc-view-fit-height-to-window',
+          ;; they might want to go to next page by typing SPC
+          ;; ONLY once. So I used '(- win-height 1)' instead of
+          ;; 'win-height'
+          (doc-view-enlarge (/ (float (- win-height 1)) (float img-height))))
+
+      ;; If slice is set
+      (let* ((slice-height (nth 3 slice))
+             (scale-factor (/ (float (- win-height 1)) (float slice-height)))
+             (new-slice (mapcar (lambda (x) (ceiling (* scale-factor x))) slice)))
+
+        (doc-view-enlarge scale-factor)
+        (setf (doc-view-current-slice) new-slice)
+        (doc-view-goto-page (doc-view-current-page))))))
+
+(defun doc-view-fit-page-to-window ()
+  "Fit the image to the window.
+More specifically, this function enlarges image by:
+
+min {(window-width / image-width), (window-height / image-height)} times."
+  (interactive)
+  (let ((win-width (- (nth 2 (window-inside-pixel-edges))
+                      (nth 0 (window-inside-pixel-edges))))
+        (win-height (- (nth 3 (window-inside-pixel-edges))
+                       (nth 1 (window-inside-pixel-edges))))
+        (slice (doc-view-current-slice)))
+    (if (not slice)
+        (let ((img-width (car (image-display-size
+                               (image-get-display-property) t)))
+              (img-height (cdr (image-display-size
+                                (image-get-display-property) t))))
+          (doc-view-enlarge (min (/ (float win-width) (float img-width))
+                                 (/ (float (- win-height 1)) (float img-height)))))
+      ;; If slice is set
+      (let* ((slice-width (nth 2 slice))
+             (slice-height (nth 3 slice))
+             (scale-factor (min (/ (float win-width) (float slice-width))
+                                (/ (float (- win-height 1)) (float slice-height))))
+             (new-slice (mapcar (lambda (x) (ceiling (* scale-factor x))) slice)))
+        (doc-view-enlarge scale-factor)
+        (setf (doc-view-current-slice) new-slice)
+        (doc-view-goto-page (doc-view-current-page))))))
+
 (defun doc-view-reconvert-doc ()
   "Reconvert the current document.
 Should be invoked when the cached images aren't up-to-date."

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

sho nakatani <lay.sakura@gmail.com> writes:

Hi Nakatani,

>> I can confirm that ghostscript sometimes has issues with fonts.
>> However, in that case it would be awkward if fitting works without
>> slice, but fails with slice...
>
> Now it works even with PDF/PS in Japanese!
> I found the cause of previous problem in a code I edited.

Great, I love it when the bugs are not in my code. ;-)

> Please test it and hopefully tell me good results!

I've just tried it, without and with slices, frequently resizing the
emacs window, fitting to width, height, page in all situations I can
think of, and it always did the right thing.  Excellent! :-)

Thanks a lot for your work.  In my opinion, the patch is ready for
inclusion.  I'll apply it as soon as the copyright assignment is in
place.

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[sho nakatani]

Hi Tassilo,

> I've just tried it, without and with slices, frequently resizing the
> emacs window, fitting to width, height, page in all situations I can
> think of, and it always did the right thing.  Excellent! :-)

I'm REALLY happy to hear that :-D

> Thanks a lot for your work.  In my opinion, the patch is ready for
> inclusion.  I'll apply it as soon as the copyright assignment is in
> place.

OK. I already got an email from FSF which says they have sent me
some paper. But it will take a little more time since I live in Japan.

After I finished everything about the copyright assignment, I'll tell you it.

Anyway, thank you for giving me such a nice opportunity and experience.

Bye,

-- 
Sho Nakatani

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Stefan Monnier]

> I'm trying to add `fit-slice-to-window' feature in doc-view.el.

Nice, thanks.  BTW, maybe an even better functionality is
"fit-rectangle-to-window", which would do the same except without
slicing (i.e. move the top-left corner and zoom so only the specified
rectangle is visible, but while keeping the outside visible via
scrolling).


        Stefan

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

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

>> I'm trying to add `fit-slice-to-window' feature in doc-view.el.
>
> Nice, thanks.  BTW, maybe an even better functionality is
> "fit-rectangle-to-window", which would do the same except without
> slicing (i.e. move the top-left corner and zoom so only the specified
> rectangle is visible, but while keeping the outside visible via
> scrolling).

Where's the difference, except that you could scroll the margins if you
wanted to do so?  Implementation-wise, the difference is that Nakatani's
current approach simply uses the image slice for the geometry, your
rectangle approach requires another buffer-local variable.  And since
slices are there anyway, I prefer making fitting functions do the right
thing in that scenario.

You can already zoom and hscroll until you have the visible rectangle
you like to have, and all doc-view navigation commands preserve the
hscroll.

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Stefan Monnier]

> Where's the difference, except that you could scroll the margins if you
> wanted to do so?

I find it handy, yes.

> Implementation-wise, the difference is that Nakatani's
> current approach simply uses the image slice for the geometry, your
> rectangle approach requires another buffer-local variable.

I don't see why you'd need another buffer-local var.  It'd just set the
zoom level and the scrolling.  Unless you mean a new buffer-local var to
remember "keep it fitted", but I don't need that.


        Stefan

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

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

>> Implementation-wise, the difference is that Nakatani's current
>> approach simply uses the image slice for the geometry, your rectangle
>> approach requires another buffer-local variable.
>
> I don't see why you'd need another buffer-local var.  It'd just set
> the zoom level and the scrolling.  Unless you mean a new buffer-local
> var to remember "keep it fitted", but I don't need that.

Oh, right.  So you'd set the rectangle once, which would adjust the zoom
level and hscroll, and since doc-view preserves the hscroll anyway,
there's nothing to remember.

Hm, I can see that this is also handy, although not much different to
slice&fit.  One complication here is that you have to set the hscroll in
terms of columns while the rectangle is pixel-based.

Nakatani, if you want, you could try to implement a
`doc-view-fit-rectangle-to-window' function.  Basically, the right
factor for zooming is exactly the same calculation as for the slices,
except that you read the geometry first by letting the user drag a
rectangle like in `doc-view-set-slice-using-mouse'.  It makes sense to
split this functionality into a separate function and use it then from
these two places.

I'm not sure about the right value to give to `set-window-hscroll',
though.

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[sho nakatani]

Hi.

2011/3/31 Tassilo Horn <tassilo@member.fsf.org>:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Implementation-wise, the difference is that Nakatani's current
>>> approach simply uses the image slice for the geometry, your rectangle
>>> approach requires another buffer-local variable.
>>
>> I don't see why you'd need another buffer-local var.  It'd just set
>> the zoom level and the scrolling.  Unless you mean a new buffer-local
>> var to remember "keep it fitted", but I don't need that.
>
> Oh, right.  So you'd set the rectangle once, which would adjust the zoom
> level and hscroll, and since doc-view preserves the hscroll anyway,
> there's nothing to remember.
>
> Hm, I can see that this is also handy, although not much different to
> slice&fit.  One complication here is that you have to set the hscroll in
> terms of columns while the rectangle is pixel-based.
>
> Nakatani, if you want, you could try to implement a
> `doc-view-fit-rectangle-to-window' function.  Basically, the right

Off course I'm interested in it but unfortunatelly I don't have enough
time. My school will begin soon and I want to give my all energy
to my research and study.

Although it is possible that I start to implement the function after
a month or so, I cannot be certain about it.

So if anyone (including Tassilo :-D ) can try it, it would be better
than just waiting for my implementation.

I feel a bit sorry not to be able to help you ;-(

Bye,

-- 
Sho Nakatani

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

sho nakatani <lay.sakura@gmail.com> writes:

>> Nakatani, if you want, you could try to implement a
>> `doc-view-fit-rectangle-to-window' function.  Basically, the right
>
> Off course I'm interested in it but unfortunatelly I don't have enough
> time. My school will begin soon and I want to give my all energy to my
> research and study.

Of course, that's more important.

> So if anyone (including Tassilo :-D ) can try it, it would be better
> than just waiting for my implementation.

I felt pretty well in my new role of simply delegating the work. ;-)

But I'll give it a try, if I find some time.

> I feel a bit sorry not to be able to help you ;-(

There's nothing to worry about.

Bye,
Tassilo

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Chong Yidong]

> This patch created by Sho Nakatani <lay.sakura@gmail.com> (in Cc) adds a
> feature to fit the current doc to the window height/width.  I already
> tested it, and it works as expected.  The emacs coding standards are
> also met.
>
> I have instructed Nakatani in doing the copyright assignment, and he is
> willing to do so.  When the assignment is confirmed, I'll apply and push
> his changes.

Sho Nakatani's copyright assignment is complete.

bug#8364: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el

[Tassilo Horn]

Chong Yidong <cyd@stupidchicken.com> writes:

>> I have instructed Nakatani in doing the copyright assignment, and he is
>> willing to do so.  When the assignment is confirmed, I'll apply and push
>> his changes.
>
> Sho Nakatani's copyright assignment is complete.

Thank you, I've committed Nakatani's patch.

Bye,
Tassilo