From: Stephen Berman <stephen.berman@gmx.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: manuel@ledu-giraud.fr, 59802@debbugs.gnu.org
Subject: bug#59802: 30.0.50; Checkbox button not rendered
Date: Sun, 11 Dec 2022 23:40:38 +0100 [thread overview]
Message-ID: <87sfhlpnrt.fsf@gmx.net> (raw)
In-Reply-To: <83k02yszqf.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 11 Dec 2022 17:54:00 +0200")
On Sun, 11 Dec 2022 17:54:00 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: manuel@ledu-giraud.fr, 59802@debbugs.gnu.org
>> Date: Sun, 11 Dec 2022 14:12:09 +0100
>>
>> When I visit the SVG image file the image scales without any display
>> problem, so the problem apparently only arises with text scaling. And
>> not just via face-remapping with text-scale-mode: when I evaluate
>> (set-face-attribute 'default nil :height 200) and then insert
>> emacs/etc/images/checked.svg with insert-image-file, the bottom half of
>> the image is truncated like in the "+4" buffer in the screenshot I
>> attached to my first post in this thread. (When the image is displayed
>> via put-text-property, explicitly passing `:ascent center' does correct
>> the initial alignment, but on increasing the font size with `C-x C-+'
>> the image still gets pushed down just like in the screenshot I posted.)
>
> In the Custom buffers, we already use ":ascent center" for images, so
> they should scale correctly. If they don't, the place to look is in
> the produce image_glyph function: look at the values of ascent and
> descent computed there. Maybe something goes wrong there when the SVG
> images are scaled.
Here's what I tried and the output I got:
I started gdb with `M-x gdb' and set a breakpoint at xdisp.c:30795,
which is the first line after these two lines:
it->ascent = it->phys_ascent = glyph_ascent = image_ascent (img, face, &slice);
it->descent = slice.height - glyph_ascent;
Then I started emacs -Q, typed `M-x customize-face RET bold RET' and hit
the breakpoint. Now the *locals of emacs* buffer displayed this:
struct it * it 0x7fffffff8a70
struct it * it@entry 0x7fffffff8a70
struct image * img 0x5555563f5fb0
struct face * face 0x555555e5ca10
int glyph_ascent 13
int crop <optimized out>
struct glyph_slice slice { x = 0, y = 0, width = 16, height = 16 }
In the *gud-emacs* buffer I typed `pp it->ascent' and then `pp
it->descent' and the *input/output of emacs* buffers displayed this:
#<INVALID_LISP_OBJECT 0x0000000d>
#<INVALID_LISP_OBJECT 0x00000003>
In the *gud-emacs* buffer I typed `c', which immediately hit the
breakpoint again. I then kept typing RET until the Emacs being debugged
became accessible, now showing the *Customize Face: Bold* buffer. Now
the *locals of emacs* buffer displayed this:
struct it * it 0x7fffffff8a70
struct it * it@entry 0x7fffffff8a70
struct image * img 0x5555569f4dd0
struct face * face 0x555555e5ca10
int glyph_ascent 12
int crop <optimized out>
struct glyph_slice slice { x = 0, y = 0, width = 15, height = 15 }
In the *Customize Face: Bold* buffer I typed `C-x C-+' and hit the
breakpoint again, and the *locals of emacs* buffers now displayed this:
struct it * it 0x7fffffff8a70
struct it * it@entry 0x7fffffff8a70
struct image * img 0x5555560bcc00
struct face * face 0x5555562f4110
int glyph_ascent 14
int crop <optimized out>
struct glyph_slice slice { x = 0, y = 0, width = 16, height = 16 }
In the *gud-emacs* buffer I again typed `pp it->ascent' and then `pp
it->descent', which added the following to *input/output of emacs*:
3
0
I repeated the above steps for a few more iterations, getting similar
output: glyph_ascent ranged from 12 to 19; width and height switched
back and forth between 15 and 16; the following values of it->ascent and
it->descent were added to *input/output*:
#<INVALID_LISP_OBJECT 0x00000001>
#<INVALID_LISP_OBJECT 0x0000000f>
#<INVALID_LISP_OBJECT 0x00000001>
#<INVALID_LISP_OBJECT 0x0000000f>
#<INVALID_LISP_OBJECT 0x00000001>
#<INVALID_LISP_OBJECT 0x0000000f>
#<INVALID_LISP_OBJECT 0x00000001>
#<INVALID_LISP_OBJECT 0x00000010>
nil
4
-1
#<INVALID_LISP_OBJECT 0x00000013>
#<INVALID_LISP_OBJECT 0xfffffffffffffffd>
At this point the latter two values repeated for two iterations, then
when the *Customize* buffer became accessible again, with text scaling
at +5, I could now type `C-x C-+' without hitting the breakpoint. I
went as far as +12, then typed `C-x C--' and when the scaling got back
down to +6 again, that hit the breakpoint again. Now the values
returned by `pp it->ascent' and `pp it->descent' were again the last two
above.
If this isn't isn't useful, please advise me what to do.
Steve Berman
next prev parent reply other threads:[~2022-12-11 22:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-03 10:40 bug#59802: 30.0.50; Checkbox button not rendered Manuel Giraud
2022-12-03 11:29 ` Eli Zaretskii
2022-12-03 14:47 ` Manuel Giraud
2022-12-03 17:44 ` Eli Zaretskii
2022-12-03 18:16 ` Manuel Giraud
2022-12-03 18:22 ` Eli Zaretskii
2022-12-03 18:24 ` Manuel Giraud
2022-12-03 18:49 ` Eli Zaretskii
2022-12-03 21:32 ` Manuel Giraud
2022-12-04 7:02 ` Eli Zaretskii
2022-12-09 12:26 ` Manuel Giraud
2022-12-09 12:35 ` Eli Zaretskii
2022-12-09 13:41 ` Stephen Berman
2022-12-09 14:07 ` Manuel Giraud
2022-12-09 14:14 ` Stephen Berman
2022-12-10 13:49 ` Eli Zaretskii
2022-12-10 16:24 ` Stephen Berman
2022-12-10 17:04 ` Eli Zaretskii
2022-12-10 17:57 ` Manuel Giraud
2022-12-10 18:38 ` Eli Zaretskii
2022-12-11 13:12 ` Stephen Berman
2022-12-11 14:47 ` Eli Zaretskii
2022-12-11 15:54 ` Eli Zaretskii
2022-12-11 22:40 ` Stephen Berman [this message]
2022-12-12 17:42 ` Eli Zaretskii
2022-12-12 23:38 ` Stephen Berman
2022-12-12 12:33 ` Manuel Giraud
2022-12-12 16:56 ` Manuel Giraud
2022-12-12 17:25 ` Stephen Berman
2022-12-12 17:38 ` Eli Zaretskii
2022-12-13 9:21 ` Manuel Giraud
2022-12-13 10:16 ` Stephen Berman
2022-12-13 12:49 ` Eli Zaretskii
2022-12-13 16:16 ` Manuel Giraud
2022-12-13 16:40 ` Eli Zaretskii
2022-12-13 17:15 ` Manuel Giraud
2022-12-13 17:36 ` Eli Zaretskii
2022-12-16 8:27 ` Manuel Giraud
2022-12-16 15:51 ` Eli Zaretskii
2022-12-16 16:09 ` Manuel Giraud
2022-12-09 13:57 ` Manuel Giraud
2022-12-10 13:47 ` Eli Zaretskii
2022-12-10 14:26 ` Manuel Giraud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfhlpnrt.fsf@gmx.net \
--to=stephen.berman@gmx.net \
--cc=59802@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=manuel@ledu-giraud.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.