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

Previous Next

Full log

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

Previous Next

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