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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8364 in the body.
You can then email your comments to 8364 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: bug-gnu-emacs <at> gnu.org
Cc: Sho Nakatani <lay.sakura <at> gmail.com>
Subject: 24.0.9999; PATCH: Fit to width/height/page for doc-view.el
Date: Mon, 28 Mar 2011 12:08:18 +0200

This patch created by Sho Nakatani <lay.sakura <at> 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---

Message #8 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: Acknowledgement (24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el)
Date: Mon, 28 Mar 2011 12:38:56 +0200

Here's a corresponding ChangeLog entry:

--8<---------------cut here---------------start------------->8---
2011-03-28  Sho Nakatani <lay.sakura <at> 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---

Message #11 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: Sho Nakatani <lay.sakura <at> gmail.com>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Mon, 28 Mar 2011 10:36:30 -0400

> This patch created by Sho Nakatani <lay.sakura <at> 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

Message #14 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Mon, 28 Mar 2011 17:28:33 +0200

sho nakatani <lay.sakura <at> 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

Message #17 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: sho nakatani <lay.sakura <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Tassilo Horn <tassilo <at> member.fsf.org>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Mon, 28 Mar 2011 23:56:14 +0900

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 <at> gmail.com>

Message #20 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: sho nakatani <lay.sakura <at> gmail.com>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Tue, 29 Mar 2011 00:58:42 +0900

2011/3/29 Tassilo Horn <tassilo <at> 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

Message #23 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Mon, 28 Mar 2011 19:35:02 +0200

sho nakatani <lay.sakura <at> 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

Message #26 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: Tassilo Horn <tassilo <at> member.fsf.org>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Mon, 28 Mar 2011 11:17:27 -0400

>> 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

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: joakim <at> verona.se
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Tue, 29 Mar 2011 11:32:16 +0200

Stefan Monnier <monnier <at> 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

Message #32 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: sho nakatani <lay.sakura <at> gmail.com>
To: 8364 <at> debbugs.gnu.org
Cc: Tassilo Horn <tassilo <at> member.fsf.org>
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 18:10:05 +0900

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 <at> member.fsf.org>:
> sho nakatani <lay.sakura <at> 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

Message #35 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 12:20:37 +0200

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

Message #38 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: sho nakatani <lay.sakura <at> gmail.com>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 19:43:21 +0900

[Message part 1 (text/plain, inline)]

Hi Tassilo,

> 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'.

Wow! Thank you for the report. I didn't realized.

But your function doesn't work for some files.
I attached an example PDF file (written in Japanse).

(If you cannot see the attachment, download it from:
 https://github.com/laysakura/TheoryOfComputation/raw/master/main.pdf )

> 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?

It's easy! I'm making a new function just for a test purpose.
So soon after we get perfectly working function, I'll combine this feature
to `doc-view-fit-(width|height|page)-to-window' .

> 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. ;-)

That's because your code have rigid basic functions :-)

Anyway, please tell me the result of test for the attachment
and give me any advice.

--
Sho Nakatani

[main.pdf (application/pdf, attachment)]

Message #41 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 15:18:15 +0200

sho nakatani <lay.sakura <at> 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

Message #44 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: sho nakatani <lay.sakura <at> gmail.com>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 23:35:51 +0900

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

Message #47 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: Tassilo Horn <tassilo <at> member.fsf.org>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 10:42:27 -0400

> 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

Message #50 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: sho nakatani <lay.sakura <at> gmail.com>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 17:08:52 +0200

Stefan Monnier <monnier <at> 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

Message #53 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 17:17:00 +0200

sho nakatani <lay.sakura <at> 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

Message #56 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: sho nakatani <lay.sakura <at> gmail.com>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Thu, 31 Mar 2011 00:49:47 +0900

[Message part 1 (text/plain, inline)]

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

[doc-view-fit-page-to-window-with-slice-support.patch (text/x-patch, attachment)]

Message #59 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 19:07:28 +0200

sho nakatani <lay.sakura <at> 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

Message #62 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: sho nakatani <lay.sakura <at> gmail.com>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Thu, 31 Mar 2011 02:13:54 +0900

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

Message #65 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: sho nakatani <lay.sakura <at> gmail.com>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Wed, 30 Mar 2011 17:07:34 -0400

> 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

Message #68 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: sho nakatani <lay.sakura <at> gmail.com>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Thu, 31 Mar 2011 08:32:27 +0200

Stefan Monnier <monnier <at> 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

Message #71 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: sho nakatani <lay.sakura <at> gmail.com>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Thu, 31 Mar 2011 15:57:11 +0900

Hi.

2011/3/31 Tassilo Horn <tassilo <at> member.fsf.org>:
> Stefan Monnier <monnier <at> 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

Message #74 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: sho nakatani <lay.sakura <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Thu, 31 Mar 2011 09:47:01 +0200

sho nakatani <lay.sakura <at> 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

Message #77 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Fri, 08 Apr 2011 12:18:47 -0400

> This patch created by Sho Nakatani <lay.sakura <at> 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.

Message #80 received at 8364 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Sho Nakatani <lay.sakura <at> gmail.com>, 8364 <at> debbugs.gnu.org
Subject: Re: bug#8364: 24.0.9999;
	PATCH: Fit to width/height/page for doc-view.el
Date: Fri, 08 Apr 2011 22:12:28 +0200

Chong Yidong <cyd <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.