bug#12245: 24.2.50; Image height scaled to fill whole line

bug#12245: 24.2.50; Image height scaled to fill whole line

[Ivan Andrus]

A fairly recent change (in the past few weeks) changed preview-latex in an
interesting way.  I would bisect it, but I have never been able to get
`bzr bisect` to work.

What happens, is that the image heights are stretched to fill the full
height of the current line.  If the image is larger, however, it is not
shrunk.  This leads to problems reading the short images like those
produced from $x$, when they are on a line with a tall equation like a
sum.  

The problem can be see without preview-latex.  Start from `emacs -Q` and
evaluate the code below.  Notice that both images are the same height
(larger than a normal line--this works for me with the default font
size).  Then delete the second image and notice that the first image
shrinks.  In fact the image should be even smaller.

    (progn (insert (propertize "1" 'display
                               (create-image "/* XPM */
    static char * arrow_right[] = {
    \"12 5 2 1\",
    \".	c grey60\",
    \" 	c None\",
    \".           \",
    \"..          \",
    \"...         \",
    \"....        \",
    \".....       \",
    \"......      \",
    \".......     \",
    \"........    \",
    \".........   \",
    \".........   \",
    \"........    \",
    \".......     \",
    \"......      \",
    \".....       \",
    \"....        \",
    \"...         \",
    \"..          \",
    \".           \"};"
                                             'xpm t)))
           (insert (propertize "1" 'display
                               (create-image "/* XPM */
    static char * arrow_right[] = {
    \"12 24 2 1\",
    \".	c grey60\",
    \" 	c None\",
    \".           \",
    \"..          \",
    \"...         \",
    \"....        \",
    \".....       \",
    \"......      \",
    \".......     \",
    \"........    \",
    \".........   \",
    \".........   \",
    \".........   \",
    \".........   \",
    \".........   \",
    \".........   \",
    \".........   \",
    \".........   \",
    \"........    \",
    \".......     \",
    \"......      \",
    \".....       \",
    \"....        \",
    \"...         \",
    \"..          \",
    \".           \"};"
                                             'xpm t))))

                                         


In GNU Emacs 24.2.50.2 (i386-apple-darwin10.8.0, NS apple-appkit-1038.36)
of 2012-08-20 on oroszlan.local
Bzr revision: 109700 jlf@foxtail.org-20120820160851-cooolx696cb26xc0
Windowing system distributor `Apple', version 10.3.1038
Configured using:
`configure '--with-ns''

Important settings:
  value of $LC_CTYPE: UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
s-x r e M-x r e p o <tab> r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
kill-region: The mark is not set now, so there is no region
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils help-mode easymenu time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process ns multi-tty emacs)

bug#12245: 24.2.50; Image height scaled to fill whole line

[Glenn Morris]

Ivan Andrus wrote:

> I would bisect it, but I have never been able to get `bzr bisect` to
> work.

You could try this then, if you can work git's bisect:

http://savannah.gnu.org/git/?group=emacs

bug#12245: 24.2.50; Image height scaled to fill whole line

[Eli Zaretskii]

> From: Ivan Andrus <darthandrus@gmail.com>
> Date: Tue, 21 Aug 2012 12:20:09 +0200
> 
> I would bisect it, but I have never been able to get `bzr bisect` to
> work.

What did you try, and how did it not work for you?

bug#12245: 24.2.50; Image height scaled to fill whole line

[Ivan Andrus]

On Aug 21, 2012, at 8:05 PM, Eli Zaretskii wrote:

>> From: Ivan Andrus <darthandrus@gmail.com>
>> Date: Tue, 21 Aug 2012 12:20:09 +0200
>> 
>> I would bisect it, but I have never been able to get `bzr bisect` to
>> work.
> 
> What did you try, and how did it not work for you?

I couldn't find my notes on it, and so I tried again.  Of course this time it worked.  Last time I was trying to use it on the emacs24 branch which perhaps was the problem.  

Anyway, I got it figured out and it was introduced by revision 109331:

$ bzr log -r 109331
------------------------------------------------------------
revno: 109331
committer: Jan D. <jan.h.d@swipnet.se>
branch nick: trunk
timestamp: Tue 2012-07-31 18:19:03 +0200
message:
  Fix compiler and run time warnings in nsmenu.m and nsterm.m
  
  *  nsfns.m, nsmenu.m, msterm.m: Adopt to struct frame/FVAR changes.
  
  * nsmenu.m (update_frame_tool_bar): Change key from NSObject* to id.
  
  * nsterm.m (ns_draw_fringe_bitmap, ns_dumpglyphs_image): Use drawInRect
  instead of compositeToPoint.
  (applicationShouldTerminate): Pass NS String literal to NSRunAlertPanel.


-Ivan

bug#12245: 24.2.50; Image height scaled to fill whole line

[Jan Djärv]

Hello.

I don't quite follow your description of the problem.
Is the bug that when the two images are shown, they are too large, or that 
when one is deleted the other is not shrunk enough?

Can you provide screenshots of the correct behaviour?

Thanks,

	Jan D.

bug#12245: 24.2.50; Image height scaled to fill whole line

[Ivan Andrus]

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

On Sep 22, 2012, at 7:01 PM, Jan Djärv wrote:

> Hello.
> 
> I don't quite follow your description of the problem.
> Is the bug that when the two images are shown, they are too large, or that when one is deleted the other is not shrunk enough?

> Can you provide screenshots of the correct behaviour?


I have included screen shots of correct and incorrect behaviour.  I should note that the green bar is from hl-line-mode.  Anyway, the bug is that a "small" image is stretched.  "Large" images are not stretched or shrunk.  


[-- Attachment #2: correct.png --]
[-- Type: image/png, Size: 7309 bytes --]

[-- Attachment #3: incorrect.png --]
[-- Type: image/png, Size: 7121 bytes --]

[-- Attachment #4: Type: text/plain, Size: 414 bytes --]



This may or may not be related to the fact that opening wide pdfs in docview mode causes the width to be shrunk to fit on the screen.  The height, however, is not affected.  I haven't filed a bug about that since I hadn't noticed it before.  If it's not resolved with the fix to this bug (or if you just prefer it), then I'll open another bug about it.

I'm on 10.6 in case I haven't mentioned that.

-Ivan

bug#12245: 24.2.50; Image height scaled to fill whole line

[Ivan Andrus]

On Sep 22, 2012, at 9:02 PM, Ivan Andrus wrote:
> On Sep 22, 2012, at 7:01 PM, Jan Djärv wrote:
> 
>> Hello.
>> 
>> I don't quite follow your description of the problem.
>> Is the bug that when the two images are shown, they are too large, or that when one is deleted the other is not shrunk enough?
> 
>> Can you provide screenshots of the correct behaviour?
> 
> 
> I have included screen shots of correct and incorrect behaviour.  I should note that the green bar is from hl-line-mode.  Anyway, the bug is that a "small" image is stretched.  "Large" images are not stretched or shrunk.  

I should say, since I didn't make it clear, that large images shouldn't
be shrunk.  At least IMO, the size of the image should never be changed.

-Ivan

bug#12245: 24.2.50; Image height scaled to fill whole line

[Jan Djärv]

Hello.

22 sep 2012 kl. 21:02 skrev Ivan Andrus <darthandrus@gmail.com>:

> On Sep 22, 2012, at 7:01 PM, Jan Djärv wrote:
> 
>> Hello.
>> 
>> I don't quite follow your description of the problem.
>> Is the bug that when the two images are shown, they are too large, or that when one is deleted the other is not shrunk enough?
> 
>> Can you provide screenshots of the correct behaviour?
> 
> 
> I have included screen shots of correct and incorrect behaviour.  I should note that the green bar is from hl-line-mode.  Anyway, the bug is that a "small" image is stretched.  "Large" images are not stretched or shrunk.  


Thanks, this has been fixed in trunk now.

	Jan D.