all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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.