bug#59802: 30.0.50; Checkbox button not rendered

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Hi,

Most of the time, checkbox button (for instance in customize) are not
rendered correctly.  I have a message saying:
--8<---------------cut here---------------start------------->8---
"Invalid image size (see ‘max-image-size’)"
--8<---------------cut here---------------end--------------->8---

These seems to have a display text property with an SVG image and I have
support for SVG compiled.  I can reproduce this bug with "emacs -Q" and
what is strange is that it sometimes work after restarting emacs.


In GNU Emacs 30.0.50 (build 1, x86_64-unknown-openbsd7.2, cairo version
 1.17.6) of 2022-12-02 built on computer
Repository revision: 8049623748483343aff392345f17f0b66368a57d
Repository branch: mgi/menubar
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: OpenBSD computer 7.2 GENERIC.MP#859 amd64

Configured using:
 'configure --prefix=/home/manuel/emacs --bindir=/home/manuel/bin
 --with-x-toolkit=no --without-sound --without-compress-install
 CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBXML2 MODULES NOTIFY KQUEUE OLDXMENU PDUMPER PNG RSVG
SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Custom

Minor modes in effect:
  display-time-mode: t
  display-battery-mode: t
  server-mode: t
  shell-dirtrack-mode: t
  global-so-long-mode: t
  repeat-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/manuel/.emacs.d/elpa/ef-themes-0.10.0/theme-loaddefs hides /home/manuel/emacs/share/emacs/30.0.50/lisp/theme-loaddefs
/home/manuel/.emacs.d/elpa/transient-0.3.7/transient hides /home/manuel/emacs/share/emacs/30.0.50/lisp/transient

Features:
(shadow sort mail-extr emacsbug pulse descr-text tmm cus-start paredit
edmacro time battery exwm-randr xcb-randr exwm-config exwm exwm-input
xcb-keysyms xcb-xkb exwm-manage exwm-floating xcb-cursor xcb-render
exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xproto
xcb-types xcb-debug kmacro server stimmung-themes modus-operandi-theme
modus-themes ytdious osm mingus libmpdee reporter edebug debug backtrace
transmission diary-lib diary-loaddefs color calc-bin calc-ext calc
calc-loaddefs rect calc-macs w3m-load mu4e mu4e-org mu4e-main mu4e-view
mu4e-headers mu4e-compose mu4e-draft mu4e-actions smtpmail mu4e-search
mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message flow-fill mule-util
hl-line mu4e-contacts mu4e-update mu4e-folders mu4e-server mu4e-context
mu4e-vars mu4e-helpers mu4e-config bookmark ido supercite regi
ebdb-message ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail
yank-media puny rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range
mm-util mail-prsvr ebdb-mua ebdb-com crm ebdb-format ebdb mailabbrev
eieio-opt cl-extra help-mode speedbar ezimage dframe eieio-base pcase
timezone org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-src ob-comint org-pcomplete org-list org-footnote org-faces
org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table ol
org-fold org-fold-core org-keys oc org-loaddefs find-func cal-menu
calendar cal-loaddefs org-version org-compat org-macs visual-basic-mode
cl web-mode derived disp-table erlang-start smart-tabs-mode skeleton
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs slime-asdf grep slime-tramp tramp tramp-loaddefs
trampver tramp-integration cus-edit cus-load wid-edit files-x
tramp-compat rx shell pcomplete parse-time iso8601 time-date ls-lisp
format-spec slime-fancy slime-indentation slime-cl-indent cl-indent
slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree advice slime-scratch slime-presentations
bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context
slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl slime-parse slime
compile text-property-search etags fileloop generator xref project
arc-mode archive-mode noutline outline icons pp comint ansi-osc
ansi-color ring hyperspec thingatpt slime-autoloads dired-aux dired-x
dired dired-loaddefs so-long notifications dbus xml repeat easy-mmode
rust-mode-autoloads stimmung-themes-autoloads ebdb-autoloads
magit-autoloads debbugs-autoloads git-commit-autoloads
magit-section-autoloads ef-themes-autoloads with-editor-autoloads
paredit-autoloads dash-autoloads ytdious-autoloads
transmission-autoloads transient-autoloads exwm-autoloads
hyperbole-autoloads detached-autoloads info package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind kqueue lcms2 dynamic-setting system-font-setting
font-render-setting cairo xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 540146 45948)
 (symbols 48 63298 3)
 (strings 32 205853 3955)
 (string-bytes 1 6042479)
 (vectors 16 85212)
 (vector-slots 8 1544662 77300)
 (floats 8 490 96)
 (intervals 56 625 0)
 (buffers 992 14))

-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Date: Sat, 03 Dec 2022 11:40:05 +0100
> 
> Most of the time, checkbox button (for instance in customize) are not
> rendered correctly.  I have a message saying:
> --8<---------------cut here---------------start------------->8---
> "Invalid image size (see ‘max-image-size’)"
> --8<---------------cut here---------------end--------------->8---
> 
> These seems to have a display text property with an SVG image and I have
> support for SVG compiled.  I can reproduce this bug with "emacs -Q" and
> what is strange is that it sometimes work after restarting emacs.

I think it would be useful if you could post a complete recipe, and perhaps
also catch this error in a debugger, so you could show the full image spec
including the allegedly invalid size.

Thanks.

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> I think it would be useful if you could post a complete recipe,

The recipe is this one (lots of checkboxes):
--8<---------------cut here---------------start------------->8---
emacs -Q --eval="(customize-face 'default)"
--8<---------------cut here---------------end--------------->8---

> and perhaps also catch this error in a debugger, so you could show the
> full image spec including the allegedly invalid size.

There is no real error, but SVG checkboxes not showing (most of the
time).  How could I catch this?

Thanks.
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 59802@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 15:47:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [...]
> 
> > I think it would be useful if you could post a complete recipe,
> 
> The recipe is this one (lots of checkboxes):
> --8<---------------cut here---------------start------------->8---
> emacs -Q --eval="(customize-face 'default)"
> --8<---------------cut here---------------end--------------->8---

If so, I see no errors here with that recipe.

> > and perhaps also catch this error in a debugger, so you could show the
> > full image spec including the allegedly invalid size.
> 
> There is no real error, but SVG checkboxes not showing (most of the
> time).  How could I catch this?

Does "M-x describe-text-properties RET" tell you what properties are there
at the place where the checkboxes were supposed to be?  If so, request the
details of the image that is the value of the 'display' property.

Another possibility is to run under GDB with a breakpoint in svg_load, and
then look at img->spec and the details of the image.

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Does "M-x describe-text-properties RET" tell you what properties are there
> at the place where the checkboxes were supposed to be?  If so, request the
> details of the image that is the value of the 'display' property.
>
> Another possibility is to run under GDB with a breakpoint in svg_load, and
> then look at img->spec and the details of the image.

Now this is strange.  Here is what I get at the svg_load break point for
img:

--8<---------------cut here---------------start------------->8---
(gdb) p img
$2 = (struct image *) 0x10980e87d0
(gdb) p img->spec
Cannot access memory at address 0x10980e8860
--8<---------------cut here---------------end--------------->8---
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 59802@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 19:16:51 +0100
> 
> Now this is strange.  Here is what I get at the svg_load break point for
> img:
> 
> --8<---------------cut here---------------start------------->8---
> (gdb) p img
> $2 = (struct image *) 0x10980e87d0
> (gdb) p img->spec
> Cannot access memory at address 0x10980e8860
> --8<---------------cut here---------------end--------------->8---

If you step till this line:

  /* If IMG->spec specifies a file name, create a non-file spec from it.  */
  file_name = image_spec_value (img->spec, QCfile, NULL);  <<<<<<<<<<<<<<<

is img still garbled and GDB cannot display img->spec?

If so, I suggest to go up the callstack and look for the reason why 'img' is
garbled.

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Another possibility is to run under GDB with a breakpoint in svg_load, and
> then look at img->spec and the details of the image.

Sorry my bad, img was not yet set at breakpoint (I guess).  Here is what
I have:

--8<---------------cut here---------------start------------->8---
(gdb) xpr img->spec
Lisp_Cons
$3 = (struct Lisp_Cons *) 0x939593f6130
{
  u = {
    s = {
      car = XIL(0x8f40),
      u = {
        cdr = XIL(0x939593f61f3),
        chain = 0x939593f61f3
      }
    },
    gcaligned = 0x40
  }
}
--8<---------------cut here---------------end--------------->8---

-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 59802@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 19:24:17 +0100
> 
> (gdb) xpr img->spec
> Lisp_Cons
> $3 = (struct Lisp_Cons *) 0x939593f6130
> {
>   u = {
>     s = {
>       car = XIL(0x8f40),
>       u = {
>         cdr = XIL(0x939593f61f3),
>         chain = 0x939593f61f3
>       }
>     },
>     gcaligned = 0x40
>   }
> }

OK, then do this:

 (gdb) pp img->spec

If GDB says it doesn't know a command named "pp", you need to load the
.gdbinit file:

 (gdb) source /path/to/emacs/src/.gdbinit

And then issue the pp command again.

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> OK, then do this:
>
>  (gdb) pp img->spec

Here is what it print on the output:
(image :type svg :file "/home/manuel/emacs-repo/etc/images/checked.svg"
:scale 1 :transform-smoothing t :ascent center)

Everything seems fine so I think, I'll have to investigate what happen
into svg_load_image then.
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 59802@debbugs.gnu.org
> Date: Sat, 03 Dec 2022 22:32:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [...]
> 
> > OK, then do this:
> >
> >  (gdb) pp img->spec
> 
> Here is what it print on the output:
> (image :type svg :file "/home/manuel/emacs-repo/etc/images/checked.svg"
> :scale 1 :transform-smoothing t :ascent center)
> 
> Everything seems fine so I think, I'll have to investigate what happen
> into svg_load_image then.

Yes, that's the logical next step.

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

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

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> Here is what it print on the output:
>> (image :type svg :file "/home/manuel/emacs-repo/etc/images/checked.svg"
>> :scale 1 :transform-smoothing t :ascent center)
>> 
>> Everything seems fine so I think, I'll have to investigate what happen
>> into svg_load_image then.
>
> Yes, that's the logical next step.

Hi,

I've tried to tackle this bug but without success so far.  I cannot the
reproduce the "image_size_error ();" when debugging (even with -Og) but
I have other issue with those rendered checkboxes:

[-- Attachment #2: wshot.png --]
[-- Type: image/png, Size: 68449 bytes --]

[-- Attachment #3: Type: text/plain, Size: 499 bytes --]


When using a bigger default font, the checkboxes start to disappear
under the baseline.  The "down.svg" does not have this issue.  I've
start to wonder if it is a bug in librsvg on my system but I can see
that it is used by blender, gimp, vlc… So I think I would have seen this
bug elsewhere.

Maybe it is a bug that arise with the combination of "checked.svg" and
librsvg?  But I think it is not something that shows on Linux.  What do
you think I could test, now?
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 59802@debbugs.gnu.org
> Date: Fri, 09 Dec 2022 13:26:56 +0100
> 
> When using a bigger default font, the checkboxes start to disappear
> under the baseline.  The "down.svg" does not have this issue.  I've
> start to wonder if it is a bug in librsvg on my system but I can see
> that it is used by blender, gimp, vlc… So I think I would have seen this
> bug elsewhere.
> 
> Maybe it is a bug that arise with the combination of "checked.svg" and
> librsvg?  But I think it is not something that shows on Linux.  What do
> you think I could test, now?

What happens if you manually create a buffer with the checkbox and
text following it -- does the problem happen in that case as well?

bug#59802: 30.0.50; Checkbox button not rendered

[Stephen Berman]

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

On Fri, 09 Dec 2022 14:35:18 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: 59802@debbugs.gnu.org
>> Date: Fri, 09 Dec 2022 13:26:56 +0100
>> 
>> When using a bigger default font, the checkboxes start to disappear
>> under the baseline.  The "down.svg" does not have this issue.  I've
>> start to wonder if it is a bug in librsvg on my system but I can see
>> that it is used by blender, gimp, vlc… So I think I would have seen this
>> bug elsewhere.
>> 
>> Maybe it is a bug that arise with the combination of "checked.svg" and
>> librsvg?  But I think it is not something that shows on Linux.  What do
>> you think I could test, now?
>
> What happens if you manually create a buffer with the checkbox and
> text following it -- does the problem happen in that case as well?

It does for me: the attached image shows four buffers containing the
checkbox.svg and checkbox.xpm images from /etc/images.  The leftmost
buffer shows the default font size, the other buffers show increases of
the font size successively by two steps with `C-x C-+'.

(The rightmost buffer shows another oddity: the line number is
supposedly 47.  This number appears when the cursor moves from 'T' to
'e'.  This also happens in the other buffers, but only those with
increased font size show line number 47; in the leftmost buffer, it
shows line number 27.)

Steve Berman


[-- Attachment #2: checkbox.png --]
[-- Type: image/png, Size: 8830 bytes --]

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

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

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> Maybe it is a bug that arise with the combination of "checked.svg" and
>> librsvg?  But I think it is not something that shows on Linux.  What do
>> you think I could test, now?
>
> What happens if you manually create a buffer with the checkbox and
> text following it -- does the problem happen in that case as well?

Here is my recipe and a short video on what it does for me.
--8<---------------cut here---------------start------------->8---
(set-frame-font "Mono-12")

(let ((text "XfooX"))
  (put-text-property 0 1 'display '(image :type svg :file "/home/manuel/emacs/share/emacs/30.0.50/etc/images/checked.svg" :scale 1 :transform-smoothing t :ascent center) text)
  (put-text-property 4 5 'display '(image :type svg :file "/home/manuel/emacs/share/emacs/30.0.50/etc/images/down.svg" :scale 1 :transform-smoothing t :ascent center) text)
  (newline)
  (insert text))

(set-frame-font "Inconsolata-20")
(set-frame-font "Ttyp0-16")
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: svg.mp4 --]
[-- Type: video/mp4, Size: 237569 bytes --]

[-- Attachment #3: Type: text/plain, Size: 18 bytes --]

-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Stephen Berman <stephen.berman@gmx.net> writes:

> It does for me: the attached image shows four buffers containing the

Good to know, I'm not alone :-)  Do you happen to use Linux?  With a
gtk3 build?
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Stephen Berman]

On Fri, 09 Dec 2022 15:07:50 +0100 Manuel Giraud <manuel@ledu-giraud.fr> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> It does for me: the attached image shows four buffers containing the
>
> Good to know, I'm not alone :-)  Do you happen to use Linux?  With a
> gtk3 build?

Yes, gtk 3.24.34 and librsvg 2.54.5

Steve Berman

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 59802@debbugs.gnu.org
> Date: Fri, 09 Dec 2022 14:57:13 +0100
> 
> > What happens if you manually create a buffer with the checkbox and
> > text following it -- does the problem happen in that case as well?
> 
> Here is my recipe and a short video on what it does for me.
> --8<---------------cut here---------------start------------->8---
> (set-frame-font "Mono-12")
> 
> (let ((text "XfooX"))
>   (put-text-property 0 1 'display '(image :type svg :file "/home/manuel/emacs/share/emacs/30.0.50/etc/images/checked.svg" :scale 1 :transform-smoothing t :ascent center) text)
>   (put-text-property 4 5 'display '(image :type svg :file "/home/manuel/emacs/share/emacs/30.0.50/etc/images/down.svg" :scale 1 :transform-smoothing t :ascent center) text)
>   (newline)
>   (insert text))
> 
> (set-frame-font "Inconsolata-20")
> (set-frame-font "Ttyp0-16")
> --8<---------------cut here---------------end--------------->8---

I don't have these fonts.  When I try other fonts with different
sizes, I don't see any problems.

And playing the video shows an empty screen here.

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  59802@debbugs.gnu.org
> Date: Fri, 09 Dec 2022 14:41:27 +0100
> 
> > What happens if you manually create a buffer with the checkbox and
> > text following it -- does the problem happen in that case as well?
> 
> It does for me: the attached image shows four buffers containing the
> checkbox.svg and checkbox.xpm images from /etc/images.  The leftmost
> buffer shows the default font size, the other buffers show increases of
> the font size successively by two steps with `C-x C-+'.
> 
> (The rightmost buffer shows another oddity: the line number is
> supposedly 47.  This number appears when the cursor moves from 'T' to
> 'e'.  This also happens in the other buffers, but only those with
> increased font size show line number 47; in the leftmost buffer, it
> shows line number 27.)

I couldn't reproduce any of this.  But since you didn't say how you
created that display, exactly, it's possible that I tried something
different.

Can you show the Lisp which you used?

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> And playing the video shows an empty screen here.

Oups.  I don't know why.  I've just re-download it from this mailing
list and it works for me.

Anyway, I have spotted one difference between `svg_load_image' on
"down.svg" (a correctly rendered svg) and "checked.svg" (an incorrectly
rendered one).

In the case of "down.svg", the call to
rsvg_handle_get_intrinsic_size_in_pixels (at image.c line 11281) is a
success and we directly have the viewbox size.

In the case of "checked.svg", this call returns 0 (no viewbox) so we
rely on another method to have the viewbox size.  This second method
does not work either because iwidth is in unit RSVG_UNIT_PERCENT so
width end up being zero.  So we rely on a third method to get the method
to get "checked.svg" viewbox.  This last one seems to work, but I just
wanted to state this difference and it might ring a bell to someone.
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Stephen Berman]

On Sat, 10 Dec 2022 15:49:21 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  59802@debbugs.gnu.org
>> Date: Fri, 09 Dec 2022 14:41:27 +0100
>>
>> > What happens if you manually create a buffer with the checkbox and
>> > text following it -- does the problem happen in that case as well?
>>
>> It does for me: the attached image shows four buffers containing the
>> checkbox.svg and checkbox.xpm images from /etc/images.  The leftmost
>> buffer shows the default font size, the other buffers show increases of
>> the font size successively by two steps with `C-x C-+'.
>>
>> (The rightmost buffer shows another oddity: the line number is
>> supposedly 47.  This number appears when the cursor moves from 'T' to
>> 'e'.  This also happens in the other buffers, but only those with
>> increased font size show line number 47; in the leftmost buffer, it
>> shows line number 27.)
>
> I couldn't reproduce any of this.  But since you didn't say how you
> created that display, exactly, it's possible that I tried something
> different.
>
> Can you show the Lisp which you used?

I create buffer "a" by typing this (with emacs -Q):

C-x b a
M-: (insert-image-file "path/to/emacs/etc/images/checked.svg")
C-f
M-: (insert-image-file "path/to/emacs/etc/images/checked.xpm")
C-f
Test

To create buffer "+2" I type `C-x h M-w' in buffer "a", and then type
`C-x b +2 C-y'.  However, this results in only the image checked.svg
being displayed in "+2", but with point not before but after the image,
so then I insert the image checked.xpm and the string "Test" as above.
Then I typed `C-x C-+' twice.  I create buffers "+4" and "+6" likewise
(typing `C-x C-+' four and six times, respectively).

Concerning the line number display, after inserting checked.svg in
buffer "a" and typing `C-f' the mode line displays "L1".  After
inserting checked.xpm as above, the mode line displays "L7", and after
typing `C-f T' it displays "L27" and remains like that while and after
typing "est".  After typing `C-y' in buffer "+2" (which displays only
checked.svg), the mode line displays "L27" and stays like that after
inserting checked.xpm and typing `C-f'.  But as soon as I type "T" the
mode line displays "L47".  (So I was mistaken in saying the line number
display changes by changing the font size.)

Steve Berman

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: manuel@ledu-giraud.fr,  59802@debbugs.gnu.org
> Date: Sat, 10 Dec 2022 17:24:14 +0100
> 
> On Sat, 10 Dec 2022 15:49:21 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman@gmx.net>
> >> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  59802@debbugs.gnu.org
> >> Date: Fri, 09 Dec 2022 14:41:27 +0100
> >>
> >> > What happens if you manually create a buffer with the checkbox and
> >> > text following it -- does the problem happen in that case as well?
> >>
> >> It does for me: the attached image shows four buffers containing the
> >> checkbox.svg and checkbox.xpm images from /etc/images.  The leftmost
> >> buffer shows the default font size, the other buffers show increases of
> >> the font size successively by two steps with `C-x C-+'.
> >>
> >> (The rightmost buffer shows another oddity: the line number is
> >> supposedly 47.  This number appears when the cursor moves from 'T' to
> >> 'e'.  This also happens in the other buffers, but only those with
> >> increased font size show line number 47; in the leftmost buffer, it
> >> shows line number 27.)
> >
> > I couldn't reproduce any of this.  But since you didn't say how you
> > created that display, exactly, it's possible that I tried something
> > different.
> >
> > Can you show the Lisp which you used?
> 
> I create buffer "a" by typing this (with emacs -Q):
> 
> C-x b a
> M-: (insert-image-file "path/to/emacs/etc/images/checked.svg")
> C-f
> M-: (insert-image-file "path/to/emacs/etc/images/checked.xpm")
> C-f
> Test
> 
> To create buffer "+2" I type `C-x h M-w' in buffer "a", and then type
> `C-x b +2 C-y'.  However, this results in only the image checked.svg
> being displayed in "+2", but with point not before but after the image,
> so then I insert the image checked.xpm and the string "Test" as above.
> Then I typed `C-x C-+' twice.  I create buffers "+4" and "+6" likewise
> (typing `C-x C-+' four and six times, respectively).
> 
> Concerning the line number display, after inserting checked.svg in
> buffer "a" and typing `C-f' the mode line displays "L1".  After
> inserting checked.xpm as above, the mode line displays "L7", and after
> typing `C-f T' it displays "L27" and remains like that while and after
> typing "est".  After typing `C-y' in buffer "+2" (which displays only
> checked.svg), the mode line displays "L27" and stays like that after
> inserting checked.xpm and typing `C-f'.  But as soon as I type "T" the
> mode line displays "L47".  (So I was mistaken in saying the line number
> display changes by changing the font size.)

We are still discussing the problem with misalignment of images, are
we?  Because most of what you describe is unrelated to that.  (If
those other aspects bother you or surprise you, we can talk about that
as well.)

As for the misalignment, I'm guessing that your librsvg is newer than
mine, so it supports scaling the SVG images as you scale text.  My
librsvg doesn't support that, and so the SVG image remains aligned
with the XPM one, slightly lower than the baseline of the text (which
could probably controlled by the :ascent property of the image, if
that is a problem).

Manuel, if this is what you see, then try playing with :ascent.  E.g.,
did you try to use ":ascent 'center"?

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> We are still discussing the problem with misalignment of images, are
> we?  Because most of what you describe is unrelated to that.  (If
> those other aspects bother you or surprise you, we can talk about that
> as well.)

Yes I think that this line numbering problem is something else (maybe).

> As for the misalignment, I'm guessing that your librsvg is newer than
> mine, so it supports scaling the SVG images as you scale text.  My
> librsvg doesn't support that, and so the SVG image remains aligned
> with the XPM one, slightly lower than the baseline of the text (which
> could probably controlled by the :ascent property of the image, if
> that is a problem).

You might be onto something here.  What is your librsvg version?  Mine
is 2.54.2.

> Manuel, if this is what you see, then try playing with :ascent.  E.g.,
> did you try to use ":ascent 'center"?

The display text property for those checkboxes already have an ":ascent
'center":
--8<---------------cut here---------------start------------->8---
(image :type svg :file
"/home/manuel/emacs/share/emacs/30.0.50/etc/images/checked.svg" :scale
1.1094117647058823 :transform-smoothing t :ascent center)
--8<---------------cut here---------------end--------------->8---

FWIW, I once have played a bit with the background of those svg by
replacing 0xFFFFFF by 0xEFEFEF at image.c:11419 and the background is in
its right place but the image is off.
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Stephen Berman <stephen.berman@gmx.net>,  59802@debbugs.gnu.org
> Date: Sat, 10 Dec 2022 18:57:50 +0100
> 
> > As for the misalignment, I'm guessing that your librsvg is newer than
> > mine, so it supports scaling the SVG images as you scale text.  My
> > librsvg doesn't support that, and so the SVG image remains aligned
> > with the XPM one, slightly lower than the baseline of the text (which
> > could probably controlled by the :ascent property of the image, if
> > that is a problem).
> 
> You might be onto something here.  What is your librsvg version?  Mine
> is 2.54.2.

I use 2.40.1.

> > Manuel, if this is what you see, then try playing with :ascent.  E.g.,
> > did you try to use ":ascent 'center"?
> 
> The display text property for those checkboxes already have an ":ascent
> 'center":
> --8<---------------cut here---------------start------------->8---
> (image :type svg :file
> "/home/manuel/emacs/share/emacs/30.0.50/etc/images/checked.svg" :scale
> 1.1094117647058823 :transform-smoothing t :ascent center)
> --8<---------------cut here---------------end--------------->8---

And if you use :ascent 0 does it have any effect?

bug#59802: 30.0.50; Checkbox button not rendered

[Stephen Berman]

On Sat, 10 Dec 2022 19:04:17 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: manuel@ledu-giraud.fr,  59802@debbugs.gnu.org
>> Date: Sat, 10 Dec 2022 17:24:14 +0100
[...]
>> I create buffer "a" by typing this (with emacs -Q):
>>
>> C-x b a
>> M-: (insert-image-file "path/to/emacs/etc/images/checked.svg")
>> C-f
>> M-: (insert-image-file "path/to/emacs/etc/images/checked.xpm")
>> C-f
>> Test
>>
>> To create buffer "+2" I type `C-x h M-w' in buffer "a", and then type
>> `C-x b +2 C-y'.  However, this results in only the image checked.svg
>> being displayed in "+2", but with point not before but after the image,
>> so then I insert the image checked.xpm and the string "Test" as above.
>> Then I typed `C-x C-+' twice.  I create buffers "+4" and "+6" likewise
>> (typing `C-x C-+' four and six times, respectively).
>>
>> Concerning the line number display, after inserting checked.svg in
>> buffer "a" and typing `C-f' the mode line displays "L1".  After
>> inserting checked.xpm as above, the mode line displays "L7", and after
>> typing `C-f T' it displays "L27" and remains like that while and after
>> typing "est".  After typing `C-y' in buffer "+2" (which displays only
>> checked.svg), the mode line displays "L27" and stays like that after
>> inserting checked.xpm and typing `C-f'.  But as soon as I type "T" the
>> mode line displays "L47".  (So I was mistaken in saying the line number
>> display changes by changing the font size.)
>
> We are still discussing the problem with misalignment of images, are
> we?  Because most of what you describe is unrelated to that.  (If
> those other aspects bother you or surprise you, we can talk about that
> as well.)

Yes, that was just a parenthetical aside.  (And what I observed does
surprise me but I haven't encountered this issue in code I've used, so
it hasn't bothered me yet.  But maybe I'll file a separate bug about
this.)

> As for the misalignment, I'm guessing that your librsvg is newer than
> mine, so it supports scaling the SVG images as you scale text.  My
> librsvg doesn't support that, and so the SVG image remains aligned
> with the XPM one, slightly lower than the baseline of the text (which
> could probably controlled by the :ascent property of the image, if
> that is a problem).

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.)

Steve Berman

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> 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.)

I guess someone who understand how SVG images are rescaled should look
into this.

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> 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.

bug#59802: 30.0.50; Checkbox button not rendered

[Stephen Berman]

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

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

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

Hi Eli and Stephen,

I tried to understand the different librsvg APIs (which is quite a mess)
and AFAIU, rsvg_handle_get_geometry_for_layer use a viewport as input to
render the SVG.  See, here:
https://gnome.pages.gitlab.gnome.org/librsvg/Rsvg-2.0/method.Handle.get_geometry_for_layer.html

So in the case we have already read a viewbox, I'm using it as the
viewport rectangle.  I don't know if it is the best way but at least it
works for me (i.e the image does not disappear below the baseline)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-SVG-scaling-for-certain-files-with-librsvg-2.52-.patch --]
[-- Type: text/x-patch, Size: 1676 bytes --]

From 3531a0e8515bc7499fa1e1f123b46841c7f2e9fc Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Mon, 12 Dec 2022 11:56:25 +0100
Subject: [PATCH] Fix SVG scaling for certain files with librsvg > 2.52
 (bug#59802)

* src/image.c (svg_load_image): Initialize viewport before calling
rsvg_handle_get_geometry_for_layer.
---
 src/image.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/image.c b/src/image.c
index 2436f78ac3..7db6c9d2fc 100644
--- a/src/image.c
+++ b/src/image.c
@@ -11290,7 +11290,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
     }
   else
     {
-      RsvgRectangle zero_rect, viewbox, out_logical_rect;
+      RsvgRectangle viewport, viewbox, out_logical_rect;
 
       /* Try the intrinsic dimensions first.  */
       gboolean has_width, has_height;
@@ -11332,10 +11332,19 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
 
       if (! (0 < viewbox_width && 0 < viewbox_height))
 	{
+	  /* Computed viewbox sizes are not correct but we may have
+	     read a correct viewbox so use it as the viewport.  */
+	  if (has_viewbox) {
+	    viewport.x = viewbox.x;
+	    viewport.y = viewbox.y;
+	    viewport.width = viewbox.width;
+	    viewport.height = viewbox.height;
+	  }
+
 	  /* We haven't found a usable set of sizes, so try working out
 	     the visible area.  */
 	  rsvg_handle_get_geometry_for_layer (rsvg_handle, NULL,
-					      &zero_rect, &viewbox,
+					      &viewport, &viewbox,
 					      &out_logical_rect, NULL);
 	  viewbox_width = viewbox.x + viewbox.width;
 	  viewbox_height = viewbox.y + viewbox.height;
-- 
2.38.1


[-- Attachment #3: Type: text/plain, Size: 18 bytes --]

-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

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

Hi (again),

Here is another patch that IMHO does a better job (at least in this use
case: a button with a label).  I also attach a little video that shows
its behaviour (hope you could read it).  WDYT?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-another-test.patch --]
[-- Type: text/x-patch, Size: 900 bytes --]

From 54f00f61a56f97fcf80214d303b3a806a4fc0484 Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Mon, 12 Dec 2022 17:39:57 +0100
Subject: [PATCH] another test

---
 src/image.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/image.c b/src/image.c
index 7db6c9d2fc..d190e8f98a 100644
--- a/src/image.c
+++ b/src/image.c
@@ -11157,9 +11157,13 @@ svg_css_length_to_pixels (RsvgLength length, double dpi, int font_size)
       value *= font_size;
       break;
 #endif
+    case RSVG_UNIT_PERCENT:
+      /* We use percent of the font_size.  */
+      value *= font_size;
+      break;
     default:
-      /* Probably ex or %.  We can't know what the pixel value is
-         without more information.  */
+      /* Probably ex.  We can't know what the pixel value is without
+         more information.  */
       value = 0;
     }
 
-- 
2.38.1


[-- Attachment #3: video.mp4 --]
[-- Type: video/mp4, Size: 459594 bytes --]

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

-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Stephen Berman]

On Mon, 12 Dec 2022 17:56:38 +0100 Manuel Giraud <manuel@ledu-giraud.fr> wrote:

> Hi (again),
>
> Here is another patch that IMHO does a better job (at least in this use
> case: a button with a label).  I also attach a little video that shows
> its behaviour (hope you could read it).  WDYT?

AFAICT, the second patch by itself fixes the reported alignment and
scaling problems with SVG images.  Well done, and thanks!

Steve Berman

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Stephen Berman <stephen.berman@gmx.net>,  59802@debbugs.gnu.org
> Date: Mon, 12 Dec 2022 17:56:38 +0100
> 
> Here is another patch that IMHO does a better job (at least in this use
> case: a button with a label).  I also attach a little video that shows
> its behaviour (hope you could read it).  WDYT?

I don't have anything intelligent to say here, and I cannot test this
because my librsvg is older than 2.46.

If this fixes the issue, I'm okay with installing this on the release
branch, but please make sure RSVG_UNIT_PERCENT was indeed introduced
in librsvg 2.46.0, and if it was introduced later, please add a
necessary LIBRSVG_CHECK_VERSION guard.

Thanks.

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: manuel@ledu-giraud.fr,  59802@debbugs.gnu.org
> Date: Sun, 11 Dec 2022 23:40:38 +0100
> 
> 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>

You are using "pp" (a.k.a. "pretty-print") incorrectly: it is intended
for Lisp objects, not for normal C variables.  For the latter, use just
"p", which is short for "print".

bug#59802: 30.0.50; Checkbox button not rendered

[Stephen Berman]

On Mon, 12 Dec 2022 19:42:40 +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 23:40:38 +0100
>>
>> 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>
>
> You are using "pp" (a.k.a. "pretty-print") incorrectly: it is intended
> for Lisp objects, not for normal C variables.  For the latter, use just
> "p", which is short for "print".

Oops, thanks for the correction.  Since Manuel Giraud found a fix, I
guess it's not worth pursuing this further, but for the record, here are
the outputs I got for the initial display and then after each `C-x C-+'
(up to +5) in the *Customize Face: bold* buffer in Emacs, both without
and with Manuel's fix:

(gdb) p it->ascent
$1 = 13
(gdb) p it->descent
$2 = 3
(gdb) p it->ascent
$3 = 14
(gdb) p it->descent
$4 = 2
(gdb) p it->ascent
$5 = 15
(gdb) p it->descent
$6 = 1
(gdb) p it->ascent
$7 = 16
(gdb) p it->descent
$8 = 0
(gdb) p it->ascent
$9 = 18
(gdb) p it->descent
$10 = -2
(gdb) p it->ascent
$11 = 19
(gdb) p it->descent
$12 = -3

The ascent values are the same as what was displayed in the *locals of
emacs* buffer for glyph_ascent.  A difference between the outputs
without and with Manuel's fix is in the values for struct glyph_slice:
without the fix, width and height switched back and forth between 15 and
16, as I noted previously, while with the fix, these values continually
increased with each `C-x C-+'.

Steve Berman

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

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

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> If this fixes the issue, I'm okay with installing this on the release
> branch, but please make sure RSVG_UNIT_PERCENT was indeed introduced
> in librsvg 2.46.0, and if it was introduced later, please add a
> necessary LIBRSVG_CHECK_VERSION guard.

Hi,

Here is yet another version that is longer but I think is more correct.
The previous patch fixes a percentage dimension as a percentage of
"font_size".  This works for our case here but might not always be
correct.

This new patch calculate the unknown percentage dimension with the other
known dimension.  It should work the same on our examples (maybe Stephen
you could check that).


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-SVG-scaling-bug-59802.patch --]
[-- Type: text/x-patch, Size: 2056 bytes --]

From e2d827b02b0ca9f383d44a1cc51fc2aacdcae2df Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Tue, 13 Dec 2022 10:10:03 +0100
Subject: [PATCH] Fix SVG scaling (bug#59802)

Fix SVG scaling with librsvg>2.52 and SVG file with only one known
dimension.

* src/image.c (svg_load_image): Compute a percentage dimension with
the other known dimension.
---
 src/image.c | 32 +++++++++++++++++++++++++-------
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/src/image.c b/src/image.c
index 2436f78ac3..a084143c41 100644
--- a/src/image.c
+++ b/src/image.c
@@ -11332,13 +11332,31 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
 
       if (! (0 < viewbox_width && 0 < viewbox_height))
 	{
-	  /* We haven't found a usable set of sizes, so try working out
-	     the visible area.  */
-	  rsvg_handle_get_geometry_for_layer (rsvg_handle, NULL,
-					      &zero_rect, &viewbox,
-					      &out_logical_rect, NULL);
-	  viewbox_width = viewbox.x + viewbox.width;
-	  viewbox_height = viewbox.y + viewbox.height;
+	  /* From the previous calculation, maybe one dimension is
+	     zero and in percent unit.  So calculate this dimension
+	     with the other.  */
+	  if (! (0 < viewbox_width) && (iwidth.unit == RSVG_UNIT_PERCENT) &&
+	      has_height && (0 < viewbox_height))
+	    {
+	      viewbox_width = (viewbox_height * viewbox.width / viewbox.height)
+		* iwidth.length;
+	    }
+	  else if (! (0 < viewbox_height) && (iheight.unit == RSVG_UNIT_PERCENT) &&
+		   has_width && (0 < viewbox_width))
+	    {
+	      viewbox_height = (viewbox_width * viewbox.height / viewbox.width)
+		* iheight.length;
+	    }
+	  else
+	    {
+	      /* We haven't found a usable set of sizes, so try working out
+		 the visible area.  */
+	      rsvg_handle_get_geometry_for_layer (rsvg_handle, NULL,
+						  &zero_rect, &viewbox,
+						  &out_logical_rect, NULL);
+	      viewbox_width = viewbox.x + viewbox.width;
+	      viewbox_height = viewbox.y + viewbox.height;
+	    }
 	}
     }
 #else
-- 
2.38.1


[-- Attachment #3: Type: text/plain, Size: 18 bytes --]

-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Stephen Berman]

On Tue, 13 Dec 2022 10:21:47 +0100 Manuel Giraud <manuel@ledu-giraud.fr> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> [...]
>
>> If this fixes the issue, I'm okay with installing this on the release
>> branch, but please make sure RSVG_UNIT_PERCENT was indeed introduced
>> in librsvg 2.46.0, and if it was introduced later, please add a
>> necessary LIBRSVG_CHECK_VERSION guard.
>
> Hi,
>
> Here is yet another version that is longer but I think is more correct.
> The previous patch fixes a percentage dimension as a percentage of
> "font_size".  This works for our case here but might not always be
> correct.
>
> This new patch calculate the unknown percentage dimension with the other
> known dimension.  It should work the same on our examples (maybe Stephen
> you could check that).

I confirm this patch works for me just as good as the last one.

Steve Berman

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: stephen.berman@gmx.net,  59802@debbugs.gnu.org
> Date: Tue, 13 Dec 2022 10:21:47 +0100
> 
> This new patch calculate the unknown percentage dimension with the other
> known dimension.  It should work the same on our examples (maybe Stephen
> you could check that).

I'm not sure I understand the reason for "else if".  Isn't possible
that both conditions could be true?  If so, why not use both
dimensions in that case, instead of arbitrarily preferring one of
them?

Which of the 3 possible branches get executed in the recipe of this
bug?  IOW, which dimension was unknown?

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> I'm not sure I understand the reason for "else if".  Isn't possible
> that both conditions could be true?

True for both conditions is unlikely because we are into a "if (! (0 <
viewbox_width && 0 < viewbox_height))" so either viewbox_height is zero
or viewbox_width is zero.

> If so, why not use both dimensions in that case, instead of
> arbitrarily preferring one of them?

The "both dimension" case is already handled at "if (has_width &&
has_height)" line 11305.

> Which of the 3 possible branches get executed in the recipe of this
> bug?  IOW, which dimension was unknown?

In my case, it is the first branch because "etc/images/checked.svg" does
not have a width attribute so it is considered 100% by
rsvg_handle_get_intrinsic_dimensions and end up being zero.
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: stephen.berman@gmx.net,  59802@debbugs.gnu.org
> Date: Tue, 13 Dec 2022 17:16:28 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [...]
> 
> > I'm not sure I understand the reason for "else if".  Isn't possible
> > that both conditions could be true?
> 
> True for both conditions is unlikely because we are into a "if (! (0 <
> viewbox_width && 0 < viewbox_height))" so either viewbox_height is zero
> or viewbox_width is zero.

Perhaps this means you need to reshuffle the code so that the case
where both dimensions are non-zero comes the first.  Then you will
have fewer negations in the conditions and the code will be easier to
read and understand.

Thanks.

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

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

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Perhaps this means you need to reshuffle the code so that the case
> where both dimensions are non-zero comes the first.  Then you will
> have fewer negations in the conditions and the code will be easier to
> read and understand.

You're right.  What do you think of this?

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-SVG-scaling-bug-59802.patch --]
[-- Type: text/x-patch, Size: 1294 bytes --]

From 73d58b9d631dce8d84965cb842f3a831c24187af Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Tue, 13 Dec 2022 10:10:03 +0100
Subject: [PATCH] Fix SVG scaling (bug#59802)

Fix SVG scaling with librsvg>2.52 and SVG file with only one known
dimension.

* src/image.c (svg_load_image): Compute a percentage dimension with
the other known dimension.
---
 src/image.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/src/image.c b/src/image.c
index 2436f78ac3..b881e43e95 100644
--- a/src/image.c
+++ b/src/image.c
@@ -11309,6 +11309,15 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
 						    img->face_font_size);
 	  viewbox_height = svg_css_length_to_pixels (iheight, dpi,
 						     img->face_font_size);
+
+	  /* Here one dimension could be zero because in percent unit.
+	     So calculate this dimension with the other.  */
+	  if (! (0 < viewbox_width) && (iwidth.unit == RSVG_UNIT_PERCENT))
+	    viewbox_width = (viewbox_height * viewbox.width / viewbox.height)
+	      * iwidth.length;
+	  else if (! (0 < viewbox_height) && (iheight.unit == RSVG_UNIT_PERCENT))
+	    viewbox_height = (viewbox_width * viewbox.height / viewbox.width)
+	      * iheight.length;
 	}
       else if (has_width && has_viewbox)
 	{
-- 
2.38.1


[-- Attachment #3: Type: text/plain, Size: 18 bytes --]

-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: stephen.berman@gmx.net,  59802@debbugs.gnu.org
> Date: Tue, 13 Dec 2022 18:15:56 +0100
> 
> 
> > Perhaps this means you need to reshuffle the code so that the case
> > where both dimensions are non-zero comes the first.  Then you will
> > have fewer negations in the conditions and the code will be easier to
> > read and understand.
> 
> You're right.  What do you think of this?

Looks better.

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Hi Eli,

Do you think this needs some rework?  If not, maybe it could go into 29.
-- 
Manuel Giraud

bug#59802: 30.0.50; Checkbox button not rendered

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  stephen.berman@gmx.net,
>   59802@debbugs.gnu.org
> Date: Fri, 16 Dec 2022 09:27:50 +0100
> 
> Hi Eli,
> 
> Do you think this needs some rework?  If not, maybe it could go into 29.

Thanks for the reminder, I've now installed this on the emacs-29
branch, and I'm closing the bug.

bug#59802: 30.0.50; Checkbox button not rendered

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Thanks for the reminder, I've now installed this on the emacs-29
> branch, and I'm closing the bug.

Thanks Eli and Stephen.
-- 
Manuel Giraud