* bug#12245: 24.2.50; Image height scaled to fill whole line
@ 2012-08-21 10:20 Ivan Andrus
2012-08-21 18:02 ` Glenn Morris
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Ivan Andrus @ 2012-08-21 10:20 UTC (permalink / raw
To: 12245
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)
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12245: 24.2.50; Image height scaled to fill whole line
2012-08-21 10:20 bug#12245: 24.2.50; Image height scaled to fill whole line Ivan Andrus
@ 2012-08-21 18:02 ` Glenn Morris
2012-08-21 18:05 ` Eli Zaretskii
2012-09-22 17:01 ` Jan Djärv
2 siblings, 0 replies; 8+ messages in thread
From: Glenn Morris @ 2012-08-21 18:02 UTC (permalink / raw
To: Ivan Andrus; +Cc: 12245
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12245: 24.2.50; Image height scaled to fill whole line
2012-08-21 10:20 bug#12245: 24.2.50; Image height scaled to fill whole line Ivan Andrus
2012-08-21 18:02 ` Glenn Morris
@ 2012-08-21 18:05 ` Eli Zaretskii
2012-08-22 8:39 ` Ivan Andrus
2012-09-22 17:01 ` Jan Djärv
2 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2012-08-21 18:05 UTC (permalink / raw
To: Ivan Andrus; +Cc: 12245
> 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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12245: 24.2.50; Image height scaled to fill whole line
2012-08-21 18:05 ` Eli Zaretskii
@ 2012-08-22 8:39 ` Ivan Andrus
0 siblings, 0 replies; 8+ messages in thread
From: Ivan Andrus @ 2012-08-22 8:39 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 12245
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12245: 24.2.50; Image height scaled to fill whole line
2012-08-21 10:20 bug#12245: 24.2.50; Image height scaled to fill whole line Ivan Andrus
2012-08-21 18:02 ` Glenn Morris
2012-08-21 18:05 ` Eli Zaretskii
@ 2012-09-22 17:01 ` Jan Djärv
2012-09-22 19:02 ` Ivan Andrus
2 siblings, 1 reply; 8+ messages in thread
From: Jan Djärv @ 2012-09-22 17:01 UTC (permalink / raw
To: Ivan Andrus, 12245
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12245: 24.2.50; Image height scaled to fill whole line
2012-09-22 17:01 ` Jan Djärv
@ 2012-09-22 19:02 ` Ivan Andrus
2012-09-22 19:22 ` Ivan Andrus
2012-09-23 8:35 ` Jan Djärv
0 siblings, 2 replies; 8+ messages in thread
From: Ivan Andrus @ 2012-09-22 19:02 UTC (permalink / raw
To: Jan Djärv; +Cc: 12245
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12245: 24.2.50; Image height scaled to fill whole line
2012-09-22 19:02 ` Ivan Andrus
@ 2012-09-22 19:22 ` Ivan Andrus
2012-09-23 8:35 ` Jan Djärv
1 sibling, 0 replies; 8+ messages in thread
From: Ivan Andrus @ 2012-09-22 19:22 UTC (permalink / raw
To: Ivan Andrus; +Cc: 12245
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12245: 24.2.50; Image height scaled to fill whole line
2012-09-22 19:02 ` Ivan Andrus
2012-09-22 19:22 ` Ivan Andrus
@ 2012-09-23 8:35 ` Jan Djärv
1 sibling, 0 replies; 8+ messages in thread
From: Jan Djärv @ 2012-09-23 8:35 UTC (permalink / raw
To: Ivan Andrus; +Cc: 12245-done
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-09-23 8:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-21 10:20 bug#12245: 24.2.50; Image height scaled to fill whole line Ivan Andrus
2012-08-21 18:02 ` Glenn Morris
2012-08-21 18:05 ` Eli Zaretskii
2012-08-22 8:39 ` Ivan Andrus
2012-09-22 17:01 ` Jan Djärv
2012-09-22 19:02 ` Ivan Andrus
2012-09-22 19:22 ` Ivan Andrus
2012-09-23 8:35 ` Jan Djärv
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.