bug#59075: 29.0.50; Image transforms not applied to svg images

bug#59075: 29.0.50; Image transforms not applied to svg images

[Evgeny Zajcev]

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

On MacOS Ventura with new librsvg (version 2.54.5) I've got nasty
problem, resulting in non-working image transforms for `svg' image
type.  Here is the screenshot
http://lgarc.narod.ru/pics/screenshot-svg-transforms.jpg

If I simply change `svg' image type to `png' (not changing image's
filename), then image transforms starts working.

This looks like Emacs bug, thanks

In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin22.1.0, NS
 appkit-2299.00 Version 13.0 (Build 22A380)) of 2022-11-03 built on
 air.local
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.0

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
 --infodir=/opt/homebrew/Cellar/emacs-plus@29/29.0.50/share/info/emacs
 --prefix=/opt/homebrew/Cellar/emacs-plus@29/29.0.50 --with-xml2
 --with-gnutls --without-compress-install --without-dbus
 --without-imagemagick --with-modules --with-rsvg --with-ns
 --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
 -mmacosx-version-min=13
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
 -DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
 'CPPFLAGS=-I/opt/homebrew/opt/icu4c/include
 -I/opt/homebrew/opt/openssl@1.1/include
 -I/opt/homebrew/opt/readline/include -isystem/opt/homebrew/include
 -F/opt/homebrew/Frameworks
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk'
 'LDFLAGS=-L/opt/homebrew/opt/icu4c/lib
 -L/opt/homebrew/opt/openssl@1.1/lib -L/opt/homebrew/opt/readline/lib
 -L/opt/homebrew/lib -F/opt/homebrew/Frameworks
 -Wl,-headerpad_max_install_names
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS
PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM ZLIB

Important settings:
  value of $LANG: ru_RU.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ◁Root[autofill]

Minor modes in effect:
  hl-line-mode: t
  tracking-mode: t
  telega-adblock-mode: t
  global-telega-mnz-mode: t
  global-telega-url-shorten-mode: t
  telega-stories-mode: t
  telega-root-auto-fill-mode: t
  telega-active-locations-mode: t
  telega-my-location-mode: t
  telega-patrons-mode: t
  global-telega-squash-message-mode: t
  telega-autoplay-mode: t
  telega-appindicator-mode: t
  telega-mode-line-mode: t
  cursor-sensor-mode: t
  reverse-im-mode: t
  mlscroll-mode: t
  desktop-save-mode: t
  save-place-mode: t
  pyvenv-mode: t
  which-function-mode: t
  shell-dirtrack-mode: t
  global-paren-face-mode: t
  display-time-mode: t
  global-undo-tree-mode: t
  icomplete-mode: t
  disable-mouse-global-mode: t
  override-global-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/zevlg/.emacs.d/elpa/circe-20210717.1041/shorten hides
/Users/zevlg/.emacs.d/elpa/tracking-20210713.1609/shorten
/Users/zevlg/.emacs.d/elpa/circe-20210717.1041/tracking hides
/Users/zevlg/.emacs.d/elpa/tracking-20210713.1609/tracking
~/dev/emacs-libvterm/vterm hides
/Users/zevlg/.emacs.d/elpa/vterm-20211226.817/vterm
/Users/zevlg/.emacs.d/elpa/cmake-mode-20210104.1831/cmake-mode hides
/opt/homebrew/share/emacs/site-lisp/cmake/cmake-mode
/Users/zevlg/.emacs.d/elpa/transient-20220112.1305/transient hides
/opt/homebrew/Cellar/emacs-plus@29
/29.0.50/share/emacs/29.0.50/lisp/transient
/Users/zevlg/.emacs.d/elpa/eglot-20220115.1248/eglot hides
/opt/homebrew/Cellar/emacs-plus@29
/29.0.50/share/emacs/29.0.50/lisp/progmodes/eglot

Features:
(shadow sort mail-extr cc-awk fortran cc-mode cc-fonts cc-guess cc-menus
cc-styles cc-align apropos dash image-converter rust-utils rust-mode
rust-rustfmt rust-playpen rust-compile rust-cargo language-detection
thai-util thai-word kinsoku dabbrev skeleton vterm bookmark face-remap
term disp-table ehelp vterm-module term/xterm xterm rect cl-print
misearch multi-isearch descr-text hl-line tracking shorten
telega-obsolete telega-adblock telega-mnz ol-telega telega-url-shorten
telega-stories telega-dashboard telega telega-tdlib-events
telega-webpage visual-fill-column telega-match telega-root telega-info
telega-chat telega-modes image-mode exif telega-company telega-emoji
telega-user telega-notifications notifications telega-voip telega-msg
telega-tme telega-sticker telega-i18n telega-vvnote bindat telega-ffplay
telega-sort telega-filter telega-ins telega-folders telega-inline
telega-util telega-media telega-tdlib rainbow-identifiers org-element
avl-tree dired-aux telega-server telega-core cursor-sensor
telega-customize svg dom emacsbug add-log vc-git company-oddmuse
company-keywords company-etags company-gtags company-dabbrev-code
company-dabbrev company-files company-clang company-cmake
company-semantic company-template company-bbdb reverse-im avy quail
mlscroll dockerfile-mode sh-script smie executable dashboard
dashboard-widgets all-the-icons all-the-icons-faces data-material
data-weathericons data-octicons data-fileicons data-faicons
data-alltheicons recentf tree-widget cider cider-debug cider-browse-ns
cider-mode cider-find cider-inspector cider-completion cider-profile
cider-eval cider-jar arc-mode archive-mode cider-repl-history pulse
cider-repl cider-resolve cider-test cider-overlays cider-stacktrace
cider-doc cider-browse-spec cider-clojuredocs cider-eldoc cider-client
cider-common cider-connection cider-util cider-popup sesman-browser
nrepl-client queue nrepl-dict spinner sesman vc vc-dispatcher
clojure-mode lisp-mnt align parseedn parseclj-parser parseclj-lex
parseclj-alist desktop frameset gnus-demon nntp gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
gnus-spec gnus-win nnoo gnus-int gnus-range message sendmail yank-media
puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus nnheader
gnus-util mail-utils range mm-util mail-prsvr autoinsert saveplace
cython-mode company-capf company-posframe posframe company pcase
help-fns radix-tree elpy elpy-rpc pyvenv eshell esh-cmd esh-ext esh-opt
esh-proc esh-io esh-arg esh-module esh-groups esh-util elpy-shell
elpy-profile elpy-django s elpy-refactor diff-mode python grep etags
fileloop generator xref python-mode info-look tramp-sh tramp
tramp-loaddefs trampver tramp-integration cus-edit cus-load wid-edit
files-x tramp-compat parse-time ls-lisp which-func imenu edebug shell
hideshow hippie-exp flymake-proc flymake project warnings thingatpt ert
pp ewoc debug backtrace compile text-property-search cc-cmds cc-engine
cc-vars cc-defs paren-face dot-mode gist-org server time
google-translate google-translate-default-ui google-translate-core-ui
facemenu color popup google-translate-core google-translate-tk
google-translate-backend whitespace undo-tree diff ido icomplete avoid
disable-mouse page-break-lines ibuffer-vc ibuf-ext ibuffer
ibuffer-loaddefs org-bullets org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-footnote org-src ob-comint org-pcomplete pcomplete
comint ansi-osc ansi-color ring org-list org-faces org-entities noutline
outline icons org-version ob-emacs-lisp ob-core ob-eval org-table
oc-basic bibtex iso8601 time-date ol org-keys oc org-compat org-macs
org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs
edmacro kmacro advice browse-kill-ring delsel cl-extra help-mode
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core finder-inf tex-site rx
easy-mmode 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 cyril-util rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win 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 kqueue cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 3468488 782371)
 (symbols 48 53263 1)
 (strings 32 479529 126521)
 (string-bytes 1 36631575)
 (vectors 16 302026)
 (vector-slots 8 3049828 506071)
 (floats 8 168687 6923)
 (intervals 56 487412 13858)
 (buffers 984 68))


-- 
lg

[-- Attachment #2: Type: text/html, Size: 10351 bytes --]

bug#59075: 29.0.50; Image transforms not applied to svg images

[Eli Zaretskii]

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Sun, 6 Nov 2022 13:16:29 +0300
> 
> On MacOS Ventura with new librsvg (version 2.54.5) I've got nasty
> problem, resulting in non-working image transforms for `svg' image
> type.  Here is the screenshot
> http://lgarc.narod.ru/pics/screenshot-svg-transforms.jpg
> 
> If I simply change `svg' image type to `png' (not changing image's
> filename), then image transforms starts working.
> 
> This looks like Emacs bug, thanks

If this is caused by upgrading to a newer librsvg, why are you certain
that it's an Emacs bug and not a librsvg bug?

bug#59075: 29.0.50; Image transforms not applied to svg images

[Evgeny Zajcev]

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

вс, 6 нояб. 2022 г. в 14:02, Eli Zaretskii <eliz@gnu.org>:

> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
> > Date: Sun, 6 Nov 2022 13:16:29 +0300
> >
> > On MacOS Ventura with new librsvg (version 2.54.5) I've got nasty
> > problem, resulting in non-working image transforms for `svg' image
> > type.  Here is the screenshot
> > http://lgarc.narod.ru/pics/screenshot-svg-transforms.jpg
> >
> > If I simply change `svg' image type to `png' (not changing image's
> > filename), then image transforms starts working.
> >
> > This looks like Emacs bug, thanks
>
> If this is caused by upgrading to a newer librsvg, why are you certain
> that it's an Emacs bug and not a librsvg bug?
>

Newer librsvg is known to have few bugs that we have already reported to
the librsvg community.
However, in this particular case I'm not sure this is caused by librsvg
side, why transforms starts to apply after changing image type in the image
spec?

-- 
lg

[-- Attachment #2: Type: text/html, Size: 1572 bytes --]

bug#59075: 29.0.50; Image transforms not applied to svg images

[Eli Zaretskii]

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Sun, 6 Nov 2022 14:52:17 +0300
> Cc: 59075@debbugs.gnu.org
> 
>  If this is caused by upgrading to a newer librsvg, why are you certain
>  that it's an Emacs bug and not a librsvg bug?
> 
> Newer librsvg is known to have few bugs that we have already reported to the librsvg community.
> However, in this particular case I'm not sure this is caused by librsvg side, why transforms starts to apply
> after changing image type in the image spec?

I don't know.  I'm not sure it's a librsvg bug, I'm just saying it
could be theirs as well as ours.  We need a librsvg expert to tell.
Anyone?

bug#59075: 29.0.50; Image transforms not applied to svg images

[Stephen Berman]

On Sun, 06 Nov 2022 14:33:30 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Evgeny Zajcev <lg.zevlg@gmail.com>
>> Date: Sun, 6 Nov 2022 14:52:17 +0300
>> Cc: 59075@debbugs.gnu.org
>>
>>  If this is caused by upgrading to a newer librsvg, why are you certain
>>  that it's an Emacs bug and not a librsvg bug?
>>
>> Newer librsvg is known to have few bugs that we have already reported to the
>> librsvg community.
>> However, in this particular case I'm not sure this is caused by librsvg
>> side, why transforms starts to apply
>> after changing image type in the image spec?
>
> I don't know.  I'm not sure it's a librsvg bug, I'm just saying it
> could be theirs as well as ours.  We need a librsvg expert to tell.
> Anyone?

I'm no librsvg expert, but I don't see the OP's problem on master
running under GNU/Linux with librsvg 2.54.5, GTK+ 3.24.34, cairo 1.17.6.

Steve Berman

bug#59075: 29.0.50; Image transforms not applied to svg images

[Evgeny Zajcev]

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

вс, 6 нояб. 2022 г. в 16:02, Stephen Berman <stephen.berman@gmx.net>:

> On Sun, 06 Nov 2022 14:33:30 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
> >> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> >> Date: Sun, 6 Nov 2022 14:52:17 +0300
> >> Cc: 59075@debbugs.gnu.org
> >>
> >>  If this is caused by upgrading to a newer librsvg, why are you certain
> >>  that it's an Emacs bug and not a librsvg bug?
> >>
> >> Newer librsvg is known to have few bugs that we have already reported
> to the
> >> librsvg community.
> >> However, in this particular case I'm not sure this is caused by librsvg
> >> side, why transforms starts to apply
> >> after changing image type in the image spec?
> >
> > I don't know.  I'm not sure it's a librsvg bug, I'm just saying it
> > could be theirs as well as ours.  We need a librsvg expert to tell.
> > Anyone?
>
> I'm no librsvg expert, but I don't see the OP's problem on master
> running under GNU/Linux with librsvg 2.54.5, GTK+ 3.24.34, cairo 1.17.6.
>

Possibly svg image with defined viewBox should be used to trigger this.
Could you please try original image I've used -
http://lgarc.narod.ru/pics/github-octocat.svg

Try also applying `:scale` transformer along with the `:height' as in my
example

-- 
lg

[-- Attachment #2: Type: text/html, Size: 2153 bytes --]

bug#59075: 29.0.50; Image transforms not applied to svg images

[Stephen Berman]

On Sun, 6 Nov 2022 19:07:17 +0300 Evgeny Zajcev <lg.zevlg@gmail.com> wrote:

> вс, 6 нояб. 2022 г. в 16:02, Stephen Berman <stephen.berman@gmx.net>:
>
>  On Sun, 06 Nov 2022 14:33:30 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>  >> From: Evgeny Zajcev <lg.zevlg@gmail.com>
>  >> Date: Sun, 6 Nov 2022 14:52:17 +0300
>  >> Cc: 59075@debbugs.gnu.org
>  >>
>  >>  If this is caused by upgrading to a newer librsvg, why are you certain
>  >>  that it's an Emacs bug and not a librsvg bug?
>  >>
>  >> Newer librsvg is known to have few bugs that we have already reported to the
>  >> librsvg community.
>  >> However, in this particular case I'm not sure this is caused by librsvg
>  >> side, why transforms starts to apply
>  >> after changing image type in the image spec?
>  >
>  > I don't know.  I'm not sure it's a librsvg bug, I'm just saying it
>  > could be theirs as well as ours.  We need a librsvg expert to tell.
>  > Anyone?
>
>  I'm no librsvg expert, but I don't see the OP's problem on master
>  running under GNU/Linux with librsvg 2.54.5, GTK+ 3.24.34, cairo 1.17.6.
>
> Possibly svg image with defined viewBox should be used to trigger
> this.  Could you please try original image I've used -
> http://lgarc.narod.ru/pics/github-octocat.svg
>
> Try also applying `:scale` transformer along with the `:height' as in my example

I downloaded the image and evaluated the following:

(insert-image '(image :type svg :file "~/temp/github-octocat.svg" :ascent center :height 16))

(insert-image '(image :type svg :file "~/temp/github-octocat.svg" :ascent center :height 16 :scale 1))

(insert-image '(image :type svg :file "~/temp/github-octocat.svg" :ascent center :height 16 :scale 2))

(insert-image '(image :type svg :file "~/temp/github-octocat.svg" :ascent center :height 16 :scale 0.5))

(insert-image '(image :type svg :file "~/temp/github-octocat.svg" :ascent center :scale 1))

(insert-image '(image :type svg :file "~/temp/github-octocat.svg" :ascent center :scale 2))

(insert-image '(image :type svg :file "~/temp/github-octocat.svg" :ascent center :scale 0.5))

and in each case the image was displayed correctly sized according to
the image specs.

Steve Berman

bug#59075: 29.0.50; Image transforms not applied to svg images

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

My suspicion is that librsvg is not being used to display SVGs at all,
on Mac OS 13.  What happens if you build without native image APIs?

bug#59075: 29.0.50; Image transforms not applied to svg images

[Evgeny Zajcev]

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

пн, 7 нояб. 2022 г. в 03:26, Po Lu <luangruo@yahoo.com>:

> My suspicion is that librsvg is not being used to display SVGs at all,
> on Mac OS 13.  What happens if you build without native image APIs?
>

Works perfectly without native image API!  Resulting svg image gets correct
size after applying `:height',
and if I change image type to png, image is not displayed at all as
expected.

-- 
lg

[-- Attachment #2: Type: text/html, Size: 827 bytes --]

bug#59075: 29.0.50; Image transforms not applied to svg images

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Evgeny Zajcev <lg.zevlg@gmail.com> writes:

> пн, 7 нояб. 2022 г. в 03:26, Po Lu <luangruo@yahoo.com>:
>
>  My suspicion is that librsvg is not being used to display SVGs at all,
>  on Mac OS 13.  What happens if you build without native image APIs?
>
> Works perfectly without native image API!  Resulting svg image gets
> correct size after applying `:height', and if I change image type to
> png, image is not displayed at all as expected.

I can't see why ns_image_set_transform was not called in your case, and
I don't know how to investigate this problem further on Mac OS.

To the Mac experts out there: is there any reason an SVG image loaded by
[NSImage initByReferencingFile:] would not respect the transform set
with [NSAffineTransform concat]?

bug#59075: 29.0.50; Image transforms not applied to svg images

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Evgeny Zajcev <lg.zevlg@gmail.com> writes:

> пн, 7 нояб. 2022 г. в 03:26, Po Lu <luangruo@yahoo.com>:
>
>  My suspicion is that librsvg is not being used to display SVGs at all,
>  on Mac OS 13.  What happens if you build without native image APIs?
>
> Works perfectly without native image API!  Resulting svg image gets correct size after applying `:height',
> and if I change image type to png, image is not displayed at all as expected.

Scratch what I said earlier.  Does this fix the problem?

diff --git a/src/nsimage.m b/src/nsimage.m
index 9cb5090dd0..dd8768664a 100644
--- a/src/nsimage.m
+++ b/src/nsimage.m
@@ -74,8 +74,10 @@ Updated by Christian Limpach (chris@nice.ch)
     imageType = @"com.compuserve.gif";
   else if (EQ (type, Qtiff))
     imageType = @"public.tiff";
+#ifndef HAVE_RSVG
   else if (EQ (type, Qsvg))
     imageType = @"public.svg-image";
+#endif
   else if (EQ (type, Qheic))
     imageType = @"public.heic";
 

If rsvg is present, there is no point in using native image APIs, as
they do not scale SVG images nearly as well.  And this part of
image_set_transform gets in the way:

#ifdef HAVE_RSVG
  /* SVGs are pre-scaled to the correct size.  */
  if (EQ (image_spec_value (img->spec, QCtype, NULL), Qsvg))
    {
      width = img->width / FRAME_SCALE_FACTOR (f);
      height = img->height / FRAME_SCALE_FACTOR (f);
    }
  else
#endif

bug#59075: 29.0.50; Image transforms not applied to svg images

[Evgeny Zajcev]

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

пн, 7 нояб. 2022 г. в 15:24, Po Lu <luangruo@yahoo.com>:

> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>
> > пн, 7 нояб. 2022 г. в 03:26, Po Lu <luangruo@yahoo.com>:
> >
> >  My suspicion is that librsvg is not being used to display SVGs at all,
> >  on Mac OS 13.  What happens if you build without native image APIs?
> >
> > Works perfectly without native image API!  Resulting svg image gets
> correct size after applying `:height',
> > and if I change image type to png, image is not displayed at all as
> expected.
>
> Scratch what I said earlier.  Does this fix the problem?
>
> diff --git a/src/nsimage.m b/src/nsimage.m
> index 9cb5090dd0..dd8768664a 100644
> --- a/src/nsimage.m
> +++ b/src/nsimage.m
> @@ -74,8 +74,10 @@ Updated by Christian Limpach (chris@nice.ch)
>      imageType = @"com.compuserve.gif";
>    else if (EQ (type, Qtiff))
>      imageType = @"public.tiff";
> +#ifndef HAVE_RSVG
>    else if (EQ (type, Qsvg))
>      imageType = @"public.svg-image";
> +#endif
>    else if (EQ (type, Qheic))
>      imageType = @"public.heic";
>
>
>
Adding this code fixes the problem!  However, if I specify `png' image type
instead of `svg' when svg image is in use, no error is triggered in
contrast with Emacs without native images.

If this code does not break anything on older MacOS I think it should be
added to Emacs.

If rsvg is present, there is no point in using native image APIs, as
> they do not scale SVG images nearly as well.  And this part of
> image_set_transform gets in the way:
>
> #ifdef HAVE_RSVG
>   /* SVGs are pre-scaled to the correct size.  */
>   if (EQ (image_spec_value (img->spec, QCtype, NULL), Qsvg))
>     {
>       width = img->width / FRAME_SCALE_FACTOR (f);
>       height = img->height / FRAME_SCALE_FACTOR (f);
>     }
>   else
> #endif
>


-- 
lg

[-- Attachment #2: Type: text/html, Size: 2802 bytes --]

bug#59075: 29.0.50; Image transforms not applied to svg images

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Evgeny Zajcev <lg.zevlg@gmail.com> writes:

> Adding this code fixes the problem!  However, if I specify `png' image
> type instead of `svg' when svg image is in use, no error is triggered
> in contrast with Emacs without native images.

I don't know how to fix that with the Mac OS image API?  Anyone else know?

> If this code does not break anything on older MacOS I think it should
> be added to Emacs.

+1.

bug#59075: 29.0.50; Image transforms not applied to svg images

[Evgeny Zajcev]

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

сб, 12 нояб. 2022 г. в 14:04, Po Lu <luangruo@yahoo.com>:

> Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>
> > Adding this code fixes the problem!  However, if I specify `png' image
> > type instead of `svg' when svg image is in use, no error is triggered
> > in contrast with Emacs without native images.
>
> I don't know how to fix that with the Mac OS image API?  Anyone else know?
>
> > If this code does not break anything on older MacOS I think it should
> > be added to Emacs.
>
> +1.
>

This code won't break anything, because native SVG support has been added
only in Ventura.  It is safe to merge this change.
Also, this patch fixes breakage of `:base_uri` API in Vertura, because
native SVG does not support `:base_uri` API, only librsvg does.

-- 
lg

[-- Attachment #2: Type: text/html, Size: 1302 bytes --]

bug#59075: 29.0.50; Image transforms not applied to svg images

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Evgeny Zajcev <lg.zevlg@gmail.com> writes:

> сб, 12 нояб. 2022 г. в 14:04, Po Lu <luangruo@yahoo.com>:
>
>  Evgeny Zajcev <lg.zevlg@gmail.com> writes:
>
>  > Adding this code fixes the problem!  However, if I specify `png' image
>  > type instead of `svg' when svg image is in use, no error is triggered
>  > in contrast with Emacs without native images.
>
>  I don't know how to fix that with the Mac OS image API?  Anyone else know?
>
>  > If this code does not break anything on older MacOS I think it should
>  > be added to Emacs.
>
>  +1.
>
> This code won't break anything, because native SVG support has been added only in Ventura.  It is safe to merge this change.
> Also, this patch fixes breakage of `:base_uri` API in Vertura, because native SVG does not support `:base_uri` API, only librsvg does.

Now done, so I'm closing this bug.

Thanks for testing.