bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Matsievskiy S.V.]

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

When buffer contains SVG overlay with Unicode characters, changing font
size via `text-scale-increase` and `text-scale-decrease` causes these
Unicode characters to change size unproportionally to the Latin
characters. Their size changes faster: they shrink faster then Latin
characters and they grow faster then Latin characters.
Example of the math equation containing Unicode characters with
different scale is showin in picture https://imgur.com/3Ul8i74.

Way to reproduce:
1. In a new buffer insert some text
  ```
  1234567890
  ```
2. Add SVG overlay by evaluating command (Alt+Shift+:)
  ```elisp
  (let ((o (make-overlay 0 11)))
  (overlay-put o 'display
               (list (cons 'image
                           (list :type 'svg
                                 :data "<svg
xmlns:xlink=\"http://www.w3.org/1999/xlink\" width=\"15.639ex\"
height=\"5.343ex\" style=\"vertical-align: -2.171ex;\" viewBox=\"0 -
1365.4 6733.3 2300.3\" role=\"img\" focusable=\"false\"
xmlns=\"http://www.w3.org/2000/svg\" aria-labelledby=\"MathJax-SVG-1-
Title\">
<title id=\"MathJax-SVG-1-
Title\">\\newcommand{textup}[1]{#1}x^a_b\\quad
x^б_ю\\quad\\frac{a}{а}\\quad\\frac{a}{Ì}</title>
<defs aria-hidden=\"true\">
<path stroke-width=\"1\" id=\"E1-MJMATHI-78\" d=\"M52 289Q59 331 106
386T222 442Q257 442 286 424T329 379Q371 442 430 442Q467 442 494 420T522
361Q522 332 508 314T481 292T458 288Q439 288 427 299T415 328Q415 374 465
391Q454 404 425 404Q412 404 406 402Q368 386 350 336Q290 115 290 78Q290
50 306 38T341 26Q378 26 414 59T463 140Q466 150 469 151T485 153H489Q504
153 504 145Q504 144 502 134Q486 77 440 33T333 -11Q263 -11 227 52Q186 -
10 133 -10H127Q78 -10 57 16T35 71Q35 103 54 123T99 143Q142 143 142
101Q142 81 130 66T107 46T94 41L91 40Q91 39 97 36T113 29T132 26Q168 26
194 71Q203 87 217 139T245 247T261 313Q266 340 266 352Q266 380 251
392T217 404Q177 404 142 372T93 290Q91 281 88 280T72 278H58Q52 284 52
289Z\"></path>
<path stroke-width=\"1\" id=\"E1-MJMATHI-61\" d=\"M33 157Q33 258 109
349T280 441Q331 441 370 392Q386 422 416 422Q429 422 439 414T449 394Q449
381 412 234T374 68Q374 43 381 35T402 26Q411 27 422 35Q443 55 463
131Q469 151 473 152Q475 153 483 153H487Q506 153 506 144Q506 138 501
117T481 63T449 13Q436 0 417 -8Q409 -10 393 -10Q359 -10 336 5T306 36L300
51Q299 52 296 50Q294 48 292 46Q233 -10 172 -10Q117 -10 75 30T33
157ZM351 328Q351 334 346 350T323 385T277 405Q242 405 210 374T160
293Q131 214 119 129Q119 126 119 118T118 106Q118 61 136 44T179 26Q217 26
254 59T298 110Q300 114 325 217T351 328Z\"></path>
<path stroke-width=\"1\" id=\"E1-MJMATHI-62\" d=\"M73 647Q73 657 77
670T89 683Q90 683 161 688T234 694Q246 694 246 685T212 542Q204 508 195
472T180 418L176 399Q176 396 182 402Q231 442 283 442Q345 442 383 396T422
280Q422 169 343 79T173 -11Q123 -11 82 27T40 150V159Q40 180 48 217T97
414Q147 611 147 623T109 637Q104 637 101 637H96Q86 637 83 637T76 640T73
647ZM336 325V331Q336 405 275 405Q258 405 240 397T207 376T181 352T163
330L157 322L136 236Q114 150 114 114Q114 66 138 42Q154 26 178 26Q211 26
245 58Q270 81 285 114T318 219Q336 291 336 325Z\"></path>
</defs>
<g stroke=\"currentColor\" fill=\"currentColor\" stroke-width=\"0\"
transform=\"matrix(1 0 0 -1 0 0)\" aria-hidden=\"true\">
 <use xlink:href=\"#E1-MJMATHI-78\" x=\"0\" y=\"0\"></use>
 <use transform=\"scale(0.707)\" xlink:href=\"#E1-MJMATHI-61\"
x=\"809\" y=\"498\"></use>
 <use transform=\"scale(0.707)\" xlink:href=\"#E1-MJMATHI-62\"
x=\"809\" y=\"-463\"></use>
<g transform=\"translate(2046,0)\">
 <use xlink:href=\"#E1-MJMATHI-78\" x=\"0\" y=\"0\"></use>
<g transform=\"translate(572,648)\">
<text font-family=\"monospace\" stroke=\"none\"
transform=\"scale(50.74127551116547) matrix(1 0 0 -1 0 0)\">б</text>
</g>
<g transform=\"translate(572,-445)\">
<text font-family=\"monospace\" stroke=\"none\"
transform=\"scale(50.74127551116547) matrix(1 0 0 -1 0 0)\">ю</text>
</g>
</g>
<g transform=\"translate(4150,0)\">
<g transform=\"translate(120,0)\">
<rect stroke=\"none\" width=\"551\" height=\"60\" x=\"0\"
y=\"220\"></rect>
 <use transform=\"scale(0.707)\" xlink:href=\"#E1-MJMATHI-61\"
x=\"125\" y=\"639\"></use>
<g transform=\"translate(60,-554)\">
<text font-family=\"monospace\" stroke=\"none\"
transform=\"scale(50.74127551116547) matrix(1 0 0 -1 0 0)\">а</text>
</g>
</g>
</g>
<g transform=\"translate(5942,0)\">
<g transform=\"translate(120,0)\">
<rect stroke=\"none\" width=\"551\" height=\"60\" x=\"0\"
y=\"220\"></rect>
 <use transform=\"scale(0.707)\" xlink:href=\"#E1-MJMATHI-61\"
x=\"125\" y=\"639\"></use>
<g transform=\"translate(60,-554)\">
<text font-family=\"monospace\" stroke=\"none\"
transform=\"scale(50.74127551116547) matrix(1 0 0 -1 0 0)\">Ì</text>
</g>
</g>
</g>
</g>
</svg>")))))
  ```
3. Change font size calling functions `text-scale-increase` and
`text-scale-decrease` repeatedly and observe unproportional size change

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.30, cairo version 1.16.0)
 of 2021-12-17 built on KILLINGMACHINE
Repository revision: cf33ece31016828ceeeee1154a4fc057957eefbc
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version
11.0.12013000
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure --prefix=/opt/emacs28 --with-all --with-xaw3d
 --with-xwidgets --with-imagemagick --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2
M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XPM
XWIDGETS GTK3 ZLIB

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

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/opt/emacs28/share/emacs/29.0.50/lisp/emacs-lisp/eieio-compat hides
/opt/emacs28/share/emacs/29.0.50/lisp/obsolete/eieio-compat

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map
text-property-search time-date seq gv subr-x byte-opt bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils iso-transl tooltip
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 cl-generic 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 simple abbrev obarray
cl-preloaded nadvice button 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
xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-
toolkit
x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 66356 11011)
 (symbols 48 6846 1)
 (strings 32 21253 3113)
 (string-bytes 1 764511)
 (vectors 16 14490)
 (vector-slots 8 275786 14211)
 (floats 8 26 103)
 (intervals 56 351 0)
 (buffers 992 13))

-- 
С Уважением,
С.В. Мациевский


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Eli Zaretskii]

> From: "Matsievskiy S.V." <seregaxvm.main@gmail.com>
> Date: Sat, 18 Dec 2021 14:50:41 +0300
> 
> When buffer contains SVG overlay with Unicode characters, changing font
> size via `text-scale-increase` and `text-scale-decrease` causes these
> Unicode characters to change size unproportionally to the Latin
> characters. Their size changes faster: they shrink faster then Latin
> characters and they grow faster then Latin characters.
> Example of the math equation containing Unicode characters with
> different scale is showin in picture https://imgur.com/3Ul8i74.
> 
> Way to reproduce:

Could you please post the Lisp code as an attachment, not inline, and
not in Org or Markdown format, but as plain Lisp code?  I tried to
reproduce the problem, but the NBSP characters and probably something
else in your mail made the image unreadable, so I couldn't
investigate.

Thanks.

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Matsievskiy S.V.]

[-- Attachment #1.1: Type: text/plain, Size: 1082 bytes --]

Attaching ELisp code

-- 
Best regards,
Sergey Matsievskiy


On Sat, 2021-12-18 at 14:04 +0200, Eli Zaretskii wrote:
> > From: "Matsievskiy S.V." <seregaxvm.main@gmail.com>
> > Date: Sat, 18 Dec 2021 14:50:41 +0300
> > 
> > When buffer contains SVG overlay with Unicode characters, changing
> > font
> > size via `text-scale-increase` and `text-scale-decrease` causes
> > these
> > Unicode characters to change size unproportionally to the Latin
> > characters. Their size changes faster: they shrink faster then
> > Latin
> > characters and they grow faster then Latin characters.
> > Example of the math equation containing Unicode characters with
> > different scale is showin in picture https://imgur.com/3Ul8i74.
> > 
> > Way to reproduce:
> 
> Could you please post the Lisp code as an attachment, not inline, and
> not in Org or Markdown format, but as plain Lisp code?  I tried to
> reproduce the problem, but the NBSP characters and probably something
> else in your mail made the image unreadable, so I couldn't
> investigate.
> 
> Thanks.

[-- Attachment #1.2: svgoverlay.el --]
[-- Type: text/x-emacs-lisp, Size: 4083 bytes --]

(let ((o (make-overlay 0 11)))
  (overlay-put o 'display
               (list (cons 'image
                           (list :type 'svg
                                 :data "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" width=\"15.639ex\" height=\"5.343ex\" style=\"vertical-align: -2.171ex;\" viewBox=\"0 -1365.4 6733.3 2300.3\" role=\"img\" focusable=\"false\" xmlns=\"http://www.w3.org/2000/svg\" aria-labelledby=\"MathJax-SVG-1-Title\">
<title id=\"MathJax-SVG-1-Title\">\\newcommand{textup}[1]{#1}x^a_b\\quad x^б_ю\\quad\\frac{a}{а}\\quad\\frac{a}{Ì}</title>
<defs aria-hidden=\"true\">
<path stroke-width=\"1\" id=\"E1-MJMATHI-78\" d=\"M52 289Q59 331 106 386T222 442Q257 442 286 424T329 379Q371 442 430 442Q467 442 494 420T522 361Q522 332 508 314T481 292T458 288Q439 288 427 299T415 328Q415 374 465 391Q454 404 425 404Q412 404 406 402Q368 386 350 336Q290 115 290 78Q290 50 306 38T341 26Q378 26 414 59T463 140Q466 150 469 151T485 153H489Q504 153 504 145Q504 144 502 134Q486 77 440 33T333 -11Q263 -11 227 52Q186 -10 133 -10H127Q78 -10 57 16T35 71Q35 103 54 123T99 143Q142 143 142 101Q142 81 130 66T107 46T94 41L91 40Q91 39 97 36T113 29T132 26Q168 26 194 71Q203 87 217 139T245 247T261 313Q266 340 266 352Q266 380 251 392T217 404Q177 404 142 372T93 290Q91 281 88 280T72 278H58Q52 284 52 289Z\"></path>
<path stroke-width=\"1\" id=\"E1-MJMATHI-61\" d=\"M33 157Q33 258 109 349T280 441Q331 441 370 392Q386 422 416 422Q429 422 439 414T449 394Q449 381 412 234T374 68Q374 43 381 35T402 26Q411 27 422 35Q443 55 463 131Q469 151 473 152Q475 153 483 153H487Q506 153 506 144Q506 138 501 117T481 63T449 13Q436 0 417 -8Q409 -10 393 -10Q359 -10 336 5T306 36L300 51Q299 52 296 50Q294 48 292 46Q233 -10 172 -10Q117 -10 75 30T33 157ZM351 328Q351 334 346 350T323 385T277 405Q242 405 210 374T160 293Q131 214 119 129Q119 126 119 118T118 106Q118 61 136 44T179 26Q217 26 254 59T298 110Q300 114 325 217T351 328Z\"></path>
<path stroke-width=\"1\" id=\"E1-MJMATHI-62\" d=\"M73 647Q73 657 77 670T89 683Q90 683 161 688T234 694Q246 694 246 685T212 542Q204 508 195 472T180 418L176 399Q176 396 182 402Q231 442 283 442Q345 442 383 396T422 280Q422 169 343 79T173 -11Q123 -11 82 27T40 150V159Q40 180 48 217T97 414Q147 611 147 623T109 637Q104 637 101 637H96Q86 637 83 637T76 640T73 647ZM336 325V331Q336 405 275 405Q258 405 240 397T207 376T181 352T163 330L157 322L136 236Q114 150 114 114Q114 66 138 42Q154 26 178 26Q211 26 245 58Q270 81 285 114T318 219Q336 291 336 325Z\"></path>
</defs>
<g stroke=\"currentColor\" fill=\"currentColor\" stroke-width=\"0\" transform=\"matrix(1 0 0 -1 0 0)\" aria-hidden=\"true\">
 <use xlink:href=\"#E1-MJMATHI-78\" x=\"0\" y=\"0\"></use>
 <use transform=\"scale(0.707)\" xlink:href=\"#E1-MJMATHI-61\" x=\"809\" y=\"498\"></use>
 <use transform=\"scale(0.707)\" xlink:href=\"#E1-MJMATHI-62\" x=\"809\" y=\"-463\"></use>
<g transform=\"translate(2046,0)\">
 <use xlink:href=\"#E1-MJMATHI-78\" x=\"0\" y=\"0\"></use>
<g transform=\"translate(572,648)\">
<text font-family=\"monospace\" stroke=\"none\" transform=\"scale(50.74127551116547) matrix(1 0 0 -1 0 0)\">б</text>
</g>
<g transform=\"translate(572,-445)\">
<text font-family=\"monospace\" stroke=\"none\" transform=\"scale(50.74127551116547) matrix(1 0 0 -1 0 0)\">ю</text>
</g>
</g>
<g transform=\"translate(4150,0)\">
<g transform=\"translate(120,0)\">
<rect stroke=\"none\" width=\"551\" height=\"60\" x=\"0\" y=\"220\"></rect>
 <use transform=\"scale(0.707)\" xlink:href=\"#E1-MJMATHI-61\" x=\"125\" y=\"639\"></use>
<g transform=\"translate(60,-554)\">
<text font-family=\"monospace\" stroke=\"none\" transform=\"scale(50.74127551116547) matrix(1 0 0 -1 0 0)\">а</text>
</g>
</g>
</g>
<g transform=\"translate(5942,0)\">
<g transform=\"translate(120,0)\">
<rect stroke=\"none\" width=\"551\" height=\"60\" x=\"0\" y=\"220\"></rect>
 <use transform=\"scale(0.707)\" xlink:href=\"#E1-MJMATHI-61\" x=\"125\" y=\"639\"></use>
<g transform=\"translate(60,-554)\">
<text font-family=\"monospace\" stroke=\"none\" transform=\"scale(50.74127551116547) matrix(1 0 0 -1 0 0)\">Ì</text>
</g>
</g>
</g>
</g>
</svg>")))))

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Eli Zaretskii]

> From: "Matsievskiy S.V." <seregaxvm.main@gmail.com>
> Cc: 52599@debbugs.gnu.org
> Date: Sat, 18 Dec 2021 15:13:15 +0300
> 
> Attaching ELisp code

Thanks.

In my testing, the size of the font in the image doesn't change at all
when I increase or decrease the text scale in the buffer.

I think whether the font changes is up to librsvg and the font backend
it uses, and Emacs does not necessarily have a way of controlling
that.  But I'm not an expert on SVG and the library, so perhaps
someone else could chime in.

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Matsievskiy S.V.]

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

I've downgraded librsvg from 2.50.7 to 2.50.3 and got the same result.

-- 
Best regards,
Sergey Matsievskiy


On Sat, 2021-12-18 at 14:51 +0200, Eli Zaretskii wrote:
> > From: "Matsievskiy S.V." <seregaxvm.main@gmail.com>
> > Cc: 52599@debbugs.gnu.org
> > Date: Sat, 18 Dec 2021 15:13:15 +0300
> > 
> > Attaching ELisp code
> 
> Thanks.
> 
> In my testing, the size of the font in the image doesn't change at
> all
> when I increase or decrease the text scale in the buffer.
> 
> I think whether the font changes is up to librsvg and the font
> backend
> it uses, and Emacs does not necessarily have a way of controlling
> that.  But I'm not an expert on SVG and the library, so perhaps
> someone else could chime in.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Alan Third]

On Sat, Dec 18, 2021 at 02:51:30PM +0200, Eli Zaretskii wrote:
> > From: "Matsievskiy S.V." <seregaxvm.main@gmail.com>
> > Cc: 52599@debbugs.gnu.org
> > Date: Sat, 18 Dec 2021 15:13:15 +0300
> > 
> > Attaching ELisp code
> 
> Thanks.
> 
> In my testing, the size of the font in the image doesn't change at all
> when I increase or decrease the text scale in the buffer.
> 
> I think whether the font changes is up to librsvg and the font backend
> it uses, and Emacs does not necessarily have a way of controlling
> that.  But I'm not an expert on SVG and the library, so perhaps
> someone else could chime in.

I *think* what's going on here is that the image size is defined in
terms of "ex", but when using librsvg < 2.52 we have no idea what the
ex height should be, so we use a fall-back mechanism to calculate the
image size.

Additionally most of the text is vector paths, not text, so it doesn't
scale with the font size change, but some of it *is* text, so it
*does* scale.

So what we end up with is that the text scales directly according to
the font size and the paths scale according to whatever nonsense
librsvg returns for the image size.

You could work around this by hard-coding the font size in the SVG or
pass in some CSS to over-ride Emacs's default. I'd suggest hard-coding
it in the image if possible as the default CSS contains colour
information too.

(Or we could try and work out the real ex height, but we would
probably have to copy how librsvg calculates ex height, which I have a
suspicion will be some constant fraction of an em instead of the
font's real ex height.)

-- 
Alan Third

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Matsievskiy S.V.]

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

> So what we end up with is that the text scales directly according to
> the font size and the paths scale according to whatever nonsense
> librsvg returns for the image size. 

Aren't these characters associated with the svg overlay? If so, it
should be possible to apply image scaling rules to them, or is it too
much work?

-- 
Best regards,
Sergey Matsievskiy


On Mon, 2021-12-20 at 16:31 +0000, Alan Third wrote:
> On Sat, Dec 18, 2021 at 02:51:30PM +0200, Eli Zaretskii wrote:
> > > From: "Matsievskiy S.V." <seregaxvm.main@gmail.com>
> > > Cc: 52599@debbugs.gnu.org
> > > Date: Sat, 18 Dec 2021 15:13:15 +0300
> > > 
> > > Attaching ELisp code
> > 
> > Thanks.
> > 
> > In my testing, the size of the font in the image doesn't change at
> > all
> > when I increase or decrease the text scale in the buffer.
> > 
> > I think whether the font changes is up to librsvg and the font
> > backend
> > it uses, and Emacs does not necessarily have a way of controlling
> > that.  But I'm not an expert on SVG and the library, so perhaps
> > someone else could chime in.
> 
> I *think* what's going on here is that the image size is defined in
> terms of "ex", but when using librsvg < 2.52 we have no idea what the
> ex height should be, so we use a fall-back mechanism to calculate the
> image size.
> 
> Additionally most of the text is vector paths, not text, so it
> doesn't
> scale with the font size change, but some of it *is* text, so it
> *does* scale.
> 
> So what we end up with is that the text scales directly according to
> the font size and the paths scale according to whatever nonsense
> librsvg returns for the image size.
> 
> You could work around this by hard-coding the font size in the SVG or
> pass in some CSS to over-ride Emacs's default. I'd suggest hard-
> coding
> it in the image if possible as the default CSS contains colour
> information too.
> 
> (Or we could try and work out the real ex height, but we would
> probably have to copy how librsvg calculates ex height, which I have
> a
> suspicion will be some constant fraction of an em instead of the
> font's real ex height.)
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Alan Third]

On Tue, Dec 21, 2021 at 03:15:44PM +0300, Matsievskiy S.V. wrote:
> > So what we end up with is that the text scales directly according to
> > the font size and the paths scale according to whatever nonsense
> > librsvg returns for the image size. 
> 
> Aren't these characters associated with the svg overlay? If so, it
> should be possible to apply image scaling rules to them, or is it too
> much work?

To just use image scaling rules set the css to "". That way increasing
the font size won't change the font size in the image and this problem
won't rear it's ugly head.

I suspect this should be considered a bug in the mathjax output. It's
relying on the default font being a specific size, and when it's not
then the scaling goes all wonky. I guess this means they expect that
all SVG renderers always use the exact same font size?

Or is there some custom mathjax CSS that's supposed to be applied?
I've had a quick look at the mathjax documentation and it doesn't look
like it. They say that SVG output doesn't use text directly so is
unaffected by font problems. 😒

I don't think we want to change our default CSS to not set the font
size as that would make using SVGs in-line with text more complicated.
-- 
Alan Third

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Matsievskiy S.V.]

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

> Or is there some custom mathjax CSS that's supposed to be applied?

I ended up exposing ex size configuration to customize.

I'm fine with leaving things as they are now and just wait for MathJax
to add more fonts in future releases.

-- 
Best regards,
S.V. Matsievskiy

On Tue, 2021-12-21 at 20:55 +0000, Alan Third wrote:
> On Tue, Dec 21, 2021 at 03:15:44PM +0300, Matsievskiy S.V. wrote:
> > > So what we end up with is that the text scales directly according
> > > to
> > > the font size and the paths scale according to whatever nonsense
> > > librsvg returns for the image size. 
> > 
> > Aren't these characters associated with the svg overlay? If so, it
> > should be possible to apply image scaling rules to them, or is it
> > too
> > much work?
> 
> To just use image scaling rules set the css to "". That way
> increasing
> the font size won't change the font size in the image and this
> problem
> won't rear it's ugly head.
> 
> I suspect this should be considered a bug in the mathjax output. It's
> relying on the default font being a specific size, and when it's not
> then the scaling goes all wonky. I guess this means they expect that
> all SVG renderers always use the exact same font size?
> 
> Or is there some custom mathjax CSS that's supposed to be applied?
> I've had a quick look at the mathjax documentation and it doesn't
> look
> like it. They say that SVG output doesn't use text directly so is
> unaffected by font problems. 😒
> 
> I don't think we want to change our default CSS to not set the font
> size as that would make using SVGs in-line with text more
> complicated.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> I don't think we want to change our default CSS to not set the font
> size as that would make using SVGs in-line with text more complicated.

Re-skimming this thread, if I understand correctly, there's nothing here
that can be fixed on the Emacs side -- we're scaling the characters, but
not the non-characters, which leads to odd effects.  But we don't want
to stop doing that, either, so it should be fixed by the thing that uses
these SVGs.  So I'm closing this bug report; if there's more that can be
done, please respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Lars Ingebrigtsen]

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

"Matsievskiy S.V." <seregaxvm.main@gmail.com> writes:

> When buffer contains SVG overlay with Unicode characters, changing font
> size via `text-scale-increase` and `text-scale-decrease` causes these
> Unicode characters to change size unproportionally to the Latin
> characters. Their size changes faster: they shrink faster then Latin
> characters and they grow faster then Latin characters.
> Example of the math equation containing Unicode characters with
> different scale is showin in picture https://imgur.com/3Ul8i74.

The SVG seems to be very odd without changing the font size.  When I
eval the test case, I get:


[-- Attachment #2: Type: image/png, Size: 7327 bytes --]

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


Is it supposed to look this way?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Matsievskiy S.V.]

[-- Attachment #1.1: Type: text/plain, Size: 976 bytes --]

You've probably set your frame font size. Running with emacs -Q
produces image emacs.png. Firefox produces almost the same image
firefox.png.

-- 
Best regards,
Sergey Matsievskiy


On Sun, 2021-12-19 at 12:15 +0100, Lars Ingebrigtsen wrote:
> "Matsievskiy S.V." <seregaxvm.main@gmail.com> writes:
> 
> > When buffer contains SVG overlay with Unicode characters, changing
> > font
> > size via `text-scale-increase` and `text-scale-decrease` causes
> > these
> > Unicode characters to change size unproportionally to the Latin
> > characters. Their size changes faster: they shrink faster then
> > Latin
> > characters and they grow faster then Latin characters.
> > Example of the math equation containing Unicode characters with
> > different scale is showin in picture https://imgur.com/3Ul8i74.
> 
> The SVG seems to be very odd without changing the font size.  When I
> eval the test case, I get:
> 
> 
> Is it supposed to look this way?
> 

[-- Attachment #1.2: emacs.png --]
[-- Type: image/png, Size: 2054 bytes --]

[-- Attachment #1.3: firefox.png --]
[-- Type: image/png, Size: 1996 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Lars Ingebrigtsen]

"Matsievskiy S.V." <seregaxvm.main@gmail.com> writes:

> You've probably set your frame font size. Running with emacs -Q
> produces image emacs.png. Firefox produces almost the same image
> firefox.png.

I did my test with "emacs -Q" (on Debian/bookworm).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Stephen Berman]

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

On Sun, 19 Dec 2021 12:15:19 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> "Matsievskiy S.V." <seregaxvm.main@gmail.com> writes:
>
>> When buffer contains SVG overlay with Unicode characters, changing font
>> size via `text-scale-increase` and `text-scale-decrease` causes these
>> Unicode characters to change size unproportionally to the Latin
>> characters. Their size changes faster: they shrink faster then Latin
>> characters and they grow faster then Latin characters.
>> Example of the math equation containing Unicode characters with
>> different scale is showin in picture https://imgur.com/3Ul8i74.
>
> The SVG seems to be very odd without changing the font size.

I can reproduce the problem:


[-- Attachment #2: svg.png --]
[-- Type: image/png, Size: 40751 bytes --]

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


This is with Emacs 29.0.50, librsvg-2.50.6, GTK+ 3.24.29, cairo 1.17.4

Steve Berman

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Lars Ingebrigtsen]

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

> I can reproduce the problem:

Perhaps HiDPI settings also have an influence on how the characters are
scaled (I'm using a 4K 14" screen)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay

[Stephen Berman]

On Sun, 19 Dec 2021 13:13:26 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> I can reproduce the problem:
>
> Perhaps HiDPI settings also have an influence on how the characters are
> scaled (I'm using a 4K 14" screen)?

Could be.  I have a 27" screen with (according xdpyinfo) 2560x1440
pixels and 96x96 DPI.

Steve Berman