bug#37159: 26.1; svg images in eww

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Hi,

If trying to render mathematics in wikipedia articles, they appear as
small, black images on dark grey background. Virtually unreadable. These
are svg images. The theme used (background colour in particular) has no
influence on this behaviour.

Is there a way to make the svg images scalable and appear in the same
colour as the text they are embedded in?

Kind regards,

Tomasz Piotrowski


In GNU Emacs 26.1 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-08-02 built on localhost.localdomain
Windowing system distributor 'Fedora Project', version 11.0.12004000
System Description:	Fedora release 29 (Twenty Nine)

Recent messages:
Loading /home/metalipa/.emacs.d/tmtxt-async-tasks.el (source)...done
Loading /home/metalipa/.emacs.d/tmtxt-dired-async.el (source)...done
Loading /home/metalipa/.emacs.d/settings.el (source)...done
Loaded /home/metalipa/.emacs.d/settings.el
Turning on magit-auto-revert-mode...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
completing-read-default: Command attempted to use minibuffer while in minibuffer
Mark set
[mu4e] Started mu4e with 72565 messages in store

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 THREADS
LCMS2

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

Major mode: mu4e:main

Minor modes in effect:
  global-magit-file-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  dired-omit-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  display-time-mode: t
  desktop-environment-mode: t
  image-diredx-async-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  overwrite-mode: overwrite-mode-binary

Load-path shadows:
/home/metalipa/.emacs.d/elpa/chess-2.0.4/chess-pgn hides /home/metalipa/localliza/configs/emacs/emacs_res/chess-pgn
/home/metalipa/.emacs.d/elpa/cyberpunk-theme-20190717.1509/cyberpunk-theme hides /home/metalipa/localliza/configs/emacs/emacs_res/cyberpunk-theme
/home/metalipa/.emacs.d/elpa/eww-lnum-20150102.1512/eww-lnum hides /home/metalipa/localliza/configs/emacs/emacs_res/eww-lnum
/home/metalipa/.emacs.d/elpa/symon-20170224.833/symon hides /home/metalipa/localliza/configs/emacs/emacs_res/symon
/home/metalipa/.emacs.d/elpa/persistent-scratch-20190128.1843/persistent-scratch hides /home/metalipa/localliza/configs/emacs/emacs_res/persistent-scratch
/home/metalipa/localliza/configs/emacs/emacs_res/flyspell hides /usr/local/share/emacs/26.1/lisp/textmodes/flyspell
/home/metalipa/.emacs.d/elpa/seq-20151028.759/seq hides /usr/local/share/emacs/26.1/lisp/emacs-lisp/seq
/home/metalipa/.emacs.d/elpa/let-alist-1.0.6/let-alist hides /usr/local/share/emacs/26.1/lisp/emacs-lisp/let-alist
/home/metalipa/localliza/configs/emacs/emacs_res/longlines hides /usr/local/share/emacs/26.1/lisp/obsolete/longlines

Features:
(shadow sort mail-extr emacsbug ox-md ox-beamer ox-odt rng-loc rng-uri
rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns
nxml-enc xmltok nxml-util ox-latex ox-icalendar ox-html table ox-ascii
ox-publish ox ob-csharp ediff-merg ediff-wind ediff-diff ediff-mult
ediff-help ediff-init ediff-util ediff scimax-org-babel-python chess-pgn
chess-database chess-display chess-var chess-random chess-module
chess-game chess-input chess-fen chess-algebraic chess-ply chess-pos
chess-message tmtxt-dired-async tmtxt-async-tasks mu4e-alert ht s alert
log4e rx notifications gntp powerline powerline-separators color
powerline-themes magit-bookmark magit-submodule magit-obsolete
magit-popup magit-blame magit-stash magit-reflog magit-bisect magit-push
magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode
magit-core magit-autorevert autorevert filenotify magit-margin
magit-transient magit-process magit-mode git-commit recentf tree-widget
magit-git magit-section benchmark magit-utils pcase which-func imenu crm
log-edit pcvs-util add-log with-editor async-bytecomp async subr-x
dired-x ibuffer ibuffer-loaddefs sourcerer-theme color-theme reporter
ob-matlab ob-octave ob-C ob-latex ob-gnuplot ob-python ob-R org-bullets
gnus-dired pdf-tools compile cus-edit cus-start cus-load pdf-view
bookmark pp pdf-cache pdf-info tq pdf-util term disp-table ehelp
matlab-load php-mode etags xref project cc-langs cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
tramp tramp-compat tramp-loaddefs trampver ucs-normalize shell
dired-fixups ls-lisp cl mu4e desktop frameset mu4e-speedbar speedbar
sb-image ezimage dframe mu4e-main mu4e-view browse-url gnus-art mm-uu
mml2015 mm-view mml-smime smime dig mailcap mu4e-headers mu4e-compose
mu4e-context mu4e-draft mu4e-actions rfc2368 smtpmail sendmail mu4e-mark
mu4e-message flow-fill mu4e-proc mu4e-utils mu4e-lists mu4e-vars hl-line
mu4e-meta git-timemachine transient dash vc-git diff-mode
multiple-cursors mc-hide-unmatched-lines-mode mc-separate-operations
rectangular-region-mode mc-mark-pop mc-mark-more thingatpt
mc-cycle-cursors mc-edit-lines multiple-cursors-core rect djvu edmacro
time exwm-systemtray xcb-systemtray xcb-xembed exwm-config ido 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 use-package-ensure
use-package-core desktop-environment dbus xml finder-inf image-dired+
image-dired info package url-handlers url-parse auth-source eieio
eieio-core eieio-loaddefs url-vars flyspell cl-macs ispell elec-pair
cl-extra help-mode org-rmail org-mhe org-irc org-info org-gnus nnir
gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source tls gnutls utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range message rmc puny seq byte-opt gv bytecomp byte-compile cconv
rfc822 mml mml-sec password-cache epa derived epg epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
gnus-win gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045
ietf-drums mail-utils mm-util mail-prsvr wid-edit org-docview doc-view
jka-compr image-mode dired dired-loaddefs org-bibtex bibtex org-bbdb
org-w3m org-element cl-seq avl-tree generator org advice org-macro
org-footnote org-pcomplete pcomplete org-list org-faces org-entities
noutline outline easy-mmode org-version ob-emacs-lisp ob ob-tangle
org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint comint
ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs
format-spec find-func cal-menu easymenu calendar cal-loaddefs
cl-loaddefs cl-lib time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame 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 charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 991747 66994)
 (symbols 48 69738 1)
 (miscs 40 178 407)
 (strings 32 219926 4328)
 (string-bytes 1 6588308)
 (vectors 16 109709)
 (vector-slots 8 2509581 22826)
 (floats 8 718 623)
 (intervals 56 1108 128)
 (buffers 992 15))

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:

> If trying to render mathematics in wikipedia articles, they appear as
> small, black images on dark grey background. Virtually unreadable. These
> are svg images. The theme used (background colour in particular) has no
> influence on this behaviour.
>
> Is there a way to make the svg images scalable and appear in the same
> colour as the text they are embedded in?

Do you have an example URL that displays the problem?

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

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

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

Hi Lars,

Many thanks for your reply. 

All wikipedia's URLs containing mathematics would fit. I attach a
sample screenshot.

Best wishes,

Tomasz



Lars Ingebrigtsen writes:

> Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:
>
>> If trying to render mathematics in wikipedia articles, they appear as
>> small, black images on dark grey background. Virtually unreadable. These
>> are svg images. The theme used (background colour in particular) has no
>> influence on this behaviour.
>>
>> Is there a way to make the svg images scalable and appear in the same
>> colour as the text they are embedded in?
>
> Do you have an example URL that displays the problem?


[-- Attachment #2: eww.png --]
[-- Type: image/png, Size: 142178 bytes --]

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:

> Many thanks for your reply. 
>
> All wikipedia's URLs containing mathematics would fit. I attach a
> sample screenshot.

If you supply an URL (as requested), it's easier for the maintainers to
reproduce the problem.

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

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Hi Lars,

Here it is:

https://en.wikipedia.org/wiki/Banach_fixed-point_theorem

It is a sample URL with this problem, all Wikipedia's entries with
mathematics have this issue.

Best wishes,

Tomasz



Lars Ingebrigtsen writes:

> Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:
>
>> Many thanks for your reply. 
>>
>> All wikipedia's URLs containing mathematics would fit. I attach a
>> sample screenshot.
>
> If you supply an URL (as requested), it's easier for the maintainers to
> reproduce the problem.

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Tomasz Piotrowski <tpiotrowski@is.umk.pl>
> Date: Sun, 25 Aug 2019 08:21:23 +0200
> Cc: 37159@debbugs.gnu.org
> 
> Hi Lars,
> 
> Here it is:
> 
> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
> 
> It is a sample URL with this problem, all Wikipedia's entries with
> mathematics have this issue.

Does this require an Emacs with ImageMagick?  Because otherwise, I
don't see a single SVG image when I go to that address.

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

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

Hi Eli,

URL (page attached):
https://en.wikipedia.org/wiki/Banach_fixed-point_theorem

Source of the first equation in this article:
<img
src="https://wikimedia.org/api/rest_v1/media/math/render/svg/fd383888ebcfccb33956072ffbebf9b1d29ce90b"
class="mwe-math-fallback-image-inline" aria-hidden="true"
style="vertical-align: -0.838ex; width:24.148ex; height:2.843ex;"
alt="d(T(x),T(y))\leq qd(x,y)">

(Chrome allows to save it as svg)

All equations in wikipedia's articles are dark grey on black background. The theme used does not
inflence this behaviour. I use Emacs with
ImageMagick. I have sent all the details regarding my setup in the first
mail in the thread #37159.

Best wishes,

Tomasz




Eli Zaretskii writes:

>> From: Tomasz Piotrowski <tpiotrowski@is.umk.pl>
>> Date: Sun, 25 Aug 2019 08:21:23 +0200
>> Cc: 37159@debbugs.gnu.org
>> 
>> Hi Lars,
>> 
>> Here it is:
>> 
>> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
>> 
>> It is a sample URL with this problem, all Wikipedia's entries with
>> mathematics have this issue.
>
> Does this require an Emacs with ImageMagick?  Because otherwise, I
> don't see a single SVG image when I go to that address.


[-- Attachment #2: eww.png --]
[-- Type: image/png, Size: 142178 bytes --]

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Tomasz Piotrowski <tpiotrowski@is.umk.pl>
> Cc: larsi@gnus.org, 37159@debbugs.gnu.org
> Date: Sun, 25 Aug 2019 10:10:24 +0200
> 
> URL (page attached):
> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
> 
> Source of the first equation in this article:
> <img
> src="https://wikimedia.org/api/rest_v1/media/math/render/svg/fd383888ebcfccb33956072ffbebf9b1d29ce90b"
> class="mwe-math-fallback-image-inline" aria-hidden="true"
> style="vertical-align: -0.838ex; width:24.148ex; height:2.843ex;"
> alt="d(T(x),T(y))\leq qd(x,y)">
> 
> (Chrome allows to save it as svg)
> 
> All equations in wikipedia's articles are dark grey on black background. The theme used does not
> inflence this behaviour.

On my system, the background color is white and I don't see any
images.  (I also don't see any of these images in the screenshot you
posted.)  I guess that means EWW displays them with identical
foreground and background colors?

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Yes, the equations are unreadable. I would be very happy if you can resolve it, so I would be able to work more efficiently and be distracted less by having to switch to Chrome and see all these JS powered distractions...

Best,

Tomasz


Wiadomość napisana przez Eli Zaretskii <eliz@gnu.org> w dniu 25.08.2019, o godz. 10:20:

>> From: Tomasz Piotrowski <tpiotrowski@is.umk.pl>
>> Cc: larsi@gnus.org, 37159@debbugs.gnu.org
>> Date: Sun, 25 Aug 2019 10:10:24 +0200
>> 
>> URL (page attached):
>> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
>> 
>> Source of the first equation in this article:
>> <img
>> src="https://wikimedia.org/api/rest_v1/media/math/render/svg/fd383888ebcfccb33956072ffbebf9b1d29ce90b"
>> class="mwe-math-fallback-image-inline" aria-hidden="true"
>> style="vertical-align: -0.838ex; width:24.148ex; height:2.843ex;"
>> alt="d(T(x),T(y))\leq qd(x,y)">
>> 
>> (Chrome allows to save it as svg)
>> 
>> All equations in wikipedia's articles are dark grey on black background. The theme used does not
>> inflence this behaviour.
> 
> On my system, the background color is white and I don't see any
> images.  (I also don't see any of these images in the screenshot you
> posted.)  I guess that means EWW displays them with identical
> foreground and background colors?

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

PS. On the page I attached, the equations are actually visible, but barely: they are dark grey on black background. In any case, not what we need.

Tomasz



> Wiadomość napisana przez Tomasz Piotrowski <tpiotrowski@is.umk.pl> w dniu 25.08.2019, o godz. 12:12:
> 
> Yes, the equations are unreadable. I would be very happy if you can resolve it, so I would be able to work more efficiently and be distracted less by having to switch to Chrome and see all these JS powered distractions...
> 
> Best,
> 
> Tomasz
> 
> 
> Wiadomość napisana przez Eli Zaretskii <eliz@gnu.org> w dniu 25.08.2019, o godz. 10:20:
> 
>>> From: Tomasz Piotrowski <tpiotrowski@is.umk.pl>
>>> Cc: larsi@gnus.org, 37159@debbugs.gnu.org
>>> Date: Sun, 25 Aug 2019 10:10:24 +0200
>>> 
>>> URL (page attached):
>>> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
>>> 
>>> Source of the first equation in this article:
>>> <img
>>> src="https://wikimedia.org/api/rest_v1/media/math/render/svg/fd383888ebcfccb33956072ffbebf9b1d29ce90b"
>>> class="mwe-math-fallback-image-inline" aria-hidden="true"
>>> style="vertical-align: -0.838ex; width:24.148ex; height:2.843ex;"
>>> alt="d(T(x),T(y))\leq qd(x,y)">
>>> 
>>> (Chrome allows to save it as svg)
>>> 
>>> All equations in wikipedia's articles are dark grey on black background. The theme used does not
>>> inflence this behaviour.
>> 
>> On my system, the background color is white and I don't see any
>> images.  (I also don't see any of these images in the screenshot you
>> posted.)  I guess that means EWW displays them with identical
>> foreground and background colors?

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> On my system, the background color is white and I don't see any
> images.  (I also don't see any of these images in the screenshot you
> posted.)  I guess that means EWW displays them with identical
> foreground and background colors?

Hm, that's odd.  Does the SVG renderer in your Emacs default to using a
white foreground colour?  In my "emacs -Q" on Debian, I get black text
on white background in the SVG images (and this is without ImageMagick).

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

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Hi Lars,

As I wrote earlier on, this behaviour (dark grey backround and black equations) is independent of the theme selected on my system (I use EXWM as window manager). 

It would be nice to have eww working with backgrounds other than white, indeed, but it is not going to solve a problem in this case.

Tomasz



> Wiadomość napisana przez Lars Ingebrigtsen <larsi@gnus.org> w dniu 26.08.2019, o godz. 06:56:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> On my system, the background color is white and I don't see any
>> images.  (I also don't see any of these images in the screenshot you
>> posted.)  I guess that means EWW displays them with identical
>> foreground and background colors?
> 
> Hm, that's odd.  Does the SVG renderer in your Emacs default to using a
> white foreground colour?  In my "emacs -Q" on Debian, I get black text
> on white background in the SVG images (and this is without ImageMagick).
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Eli reported white equations on white background, so I assume the problem exhibits itself differently on different machines. 

Tomasz



> Wiadomość napisana przez Tomasz Piotrowski <tpiotrowski@is.umk.pl> w dniu 26.08.2019, o godz. 07:33:
> 
> Hi Lars,
> 
> As I wrote earlier on, this behaviour (dark grey backround and black equations) is independent of the theme selected on my system (I use EXWM as window manager). 
> 
> It would be nice to have eww working with backgrounds other than white, indeed, but it is not going to solve a problem in this case.
> 
> Tomasz
> 
> 
> 
>> Wiadomość napisana przez Lars Ingebrigtsen <larsi@gnus.org> w dniu 26.08.2019, o godz. 06:56:
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>> On my system, the background color is white and I don't see any
>>> images.  (I also don't see any of these images in the screenshot you
>>> posted.)  I guess that means EWW displays them with identical
>>> foreground and background colors?
>> 
>> Hm, that's odd.  Does the SVG renderer in your Emacs default to using a
>> white foreground colour?  In my "emacs -Q" on Debian, I get black text
>> on white background in the SVG images (and this is without ImageMagick).
>> 
>> -- 
>> (domestic pets only, the antidote for overdose, milk.)
>>  bloggy blog: http://lars.ingebrigtsen.no

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Tomasz Piotrowski <tpiotrowski@is.umk.pl>,  37159@debbugs.gnu.org
> Date: Mon, 26 Aug 2019 06:56:58 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > On my system, the background color is white and I don't see any
> > images.  (I also don't see any of these images in the screenshot you
> > posted.)  I guess that means EWW displays them with identical
> > foreground and background colors?
> 
> Hm, that's odd.  Does the SVG renderer in your Emacs default to using a
> white foreground colour?  In my "emacs -Q" on Debian, I get black text
> on white background in the SVG images (and this is without ImageMagick).

I don't think I understand what that means.  Which SVG images are you
talking about here?  Can you point me to an example of such an SVG
image file?

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Hm, that's odd.  Does the SVG renderer in your Emacs default to using a
>> white foreground colour?  In my "emacs -Q" on Debian, I get black text
>> on white background in the SVG images (and this is without ImageMagick).
>
> I don't think I understand what that means.  Which SVG images are you
> talking about here?  Can you point me to an example of such an SVG
> image file?

All the equations on this page are SVG images:

https://en.wikipedia.org/wiki/Banach_fixed-point_theorem

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

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tpiotrowski@is.umk.pl,  37159@debbugs.gnu.org
> Date: Mon, 26 Aug 2019 09:50:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Hm, that's odd.  Does the SVG renderer in your Emacs default to using a
> >> white foreground colour?  In my "emacs -Q" on Debian, I get black text
> >> on white background in the SVG images (and this is without ImageMagick).
> >
> > I don't think I understand what that means.  Which SVG images are you
> > talking about here?  Can you point me to an example of such an SVG
> > image file?
> 
> All the equations on this page are SVG images:
> 
> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem

For those I see empty rectangles on my display.  I have no idea what
that means, it could be that the image is displayed with white on
white, or it could be some other issue with SVG images specific to
MS-Windows.

Btw, why does EWW break the text line when it encounters an image?

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> All the equations on this page are SVG images:
>> 
>> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
>
> For those I see empty rectangles on my display.  I have no idea what
> that means, it could be that the image is displayed with white on
> white, or it could be some other issue with SVG images specific to
> MS-Windows.

The SVG images wikipedia uses for the math are kinda special: They
specify neither the foreground colour nor the background colour.  So
perhaps the svg libraries just choose a random colour for either, and
that's black-on-background in Linux and white-on-background in Windows.

The colours are instead set via CSS, which is why they're legible in
most browsers.

I'm not quite sure what a solution here would be.  shr could parse the
SVG data (it's just XML, after all) and insert a stroke (i.e.,
foreground) colour if none is specified, and one that's sufficiently
different from the background colour that the image would be kinda-sorta
readable.

But is it worth it just to display these unusually degenerate SVG
images?

> Btw, why does EWW break the text line when it encounters an image?

When doing the layout, in general the dimensions of the images isn't
known -- the images are fetched asynchronously after displaying the
text.

There's also a historical reason -- the code was written before shr did
pixel-based layouts, so even if it knew the dimensions, it couldn't do
anything about it.  That could be fixed now (so that if the <img> has a
width attribute, the layout engine could use it and insert the
placeholder there).

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

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tpiotrowski@is.umk.pl,  37159@debbugs.gnu.org
> Date: Tue, 27 Aug 2019 08:59:20 +0200
> 
> I'm not quite sure what a solution here would be.  shr could parse the
> SVG data (it's just XML, after all) and insert a stroke (i.e.,
> foreground) colour if none is specified, and one that's sufficiently
> different from the background colour that the image would be kinda-sorta
> readable.
> 
> But is it worth it just to display these unusually degenerate SVG
> images?

I don't know enough to have an opinion that matters.

> > Btw, why does EWW break the text line when it encounters an image?
> 
> When doing the layout, in general the dimensions of the images isn't
> known -- the images are fetched asynchronously after displaying the
> text.
> 
> There's also a historical reason -- the code was written before shr did
> pixel-based layouts, so even if it knew the dimensions, it couldn't do
> anything about it.  That could be fixed now (so that if the <img> has a
> width attribute, the layout engine could use it and insert the
> placeholder there).

Something to work on in the future, I think.

Thanks.

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Well, my opinion on this is that either I have to keep switching to Chrome to use wikipedia, or I could use eww for my work. I don’t know how many others have the same issue, but it is a serious flaw in eww from my point of view. Many thanks to Lars for pinpointing the reason of certain svg images not rendering properly in eww.

Tomasz



Wiadomość napisana przez Eli Zaretskii <eliz@gnu.org> w dniu 27.08.2019, o godz. 09:47:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: tpiotrowski@is.umk.pl,  37159@debbugs.gnu.org
>> Date: Tue, 27 Aug 2019 08:59:20 +0200
>> 
>> I'm not quite sure what a solution here would be.  shr could parse the
>> SVG data (it's just XML, after all) and insert a stroke (i.e.,
>> foreground) colour if none is specified, and one that's sufficiently
>> different from the background colour that the image would be kinda-sorta
>> readable.
>> 
>> But is it worth it just to display these unusually degenerate SVG
>> images?
> 
> I don't know enough to have an opinion that matters.
> 
>>> Btw, why does EWW break the text line when it encounters an image?
>> 
>> When doing the layout, in general the dimensions of the images isn't
>> known -- the images are fetched asynchronously after displaying the
>> text.
>> 
>> There's also a historical reason -- the code was written before shr did
>> pixel-based layouts, so even if it knew the dimensions, it couldn't do
>> anything about it.  That could be fixed now (so that if the <img> has a
>> width attribute, the layout engine could use it and insert the
>> placeholder there).
> 
> Something to work on in the future, I think.
> 
> Thanks.

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Hi,

What are the plans regarding resolving this bug?

Tomasz




Tomasz Piotrowski writes:

> Well, my opinion on this is that either I have to keep switching to Chrome to use wikipedia, or I could use eww for my work. I don’t know how many others have the same issue, but it is a serious flaw in eww from my point of view. Many thanks to Lars for pinpointing the reason of certain svg images not rendering properly in eww.
>
> Tomasz
>
>
>
> Wiadomość napisana przez Eli Zaretskii <eliz@gnu.org> w dniu 27.08.2019, o godz. 09:47:
>
>>> From: Lars Ingebrigtsen <larsi@gnus.org>
>>> Cc: tpiotrowski@is.umk.pl,  37159@debbugs.gnu.org
>>> Date: Tue, 27 Aug 2019 08:59:20 +0200
>>> 
>>> I'm not quite sure what a solution here would be.  shr could parse the
>>> SVG data (it's just XML, after all) and insert a stroke (i.e.,
>>> foreground) colour if none is specified, and one that's sufficiently
>>> different from the background colour that the image would be kinda-sorta
>>> readable.
>>> 
>>> But is it worth it just to display these unusually degenerate SVG
>>> images?
>> 
>> I don't know enough to have an opinion that matters.
>> 
>>>> Btw, why does EWW break the text line when it encounters an image?
>>> 
>>> When doing the layout, in general the dimensions of the images isn't
>>> known -- the images are fetched asynchronously after displaying the
>>> text.
>>> 
>>> There's also a historical reason -- the code was written before shr did
>>> pixel-based layouts, so even if it knew the dimensions, it couldn't do
>>> anything about it.  That could be fixed now (so that if the <img> has a
>>> width attribute, the layout engine could use it and insert the
>>> placeholder there).
>> 
>> Something to work on in the future, I think.
>> 
>> Thanks.

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

I found a workaround for this bug on my system: the default theme (with white
background) is able to render Wikipedia's pages with SVG equations
properly. Then, using "heaven-and-hell" package for theme toggling, I
switch to the default theme when using eww. For those experiencing the
same problem, here is the relevant configuration snippet (my default
theme is "sourcerer", and I use <f1> to toggle themes):

  (setq heaven-and-hell-theme-type 'dark)
  (setq heaven-and-hell-themes
        '((light) (dark . sourcerer)))
  (setq heaven-and-hell-load-theme-no-confirm t)
  (add-hook 'after-init-hook 'heaven-and-hell-init-hook)
  (global-set-key (kbd "<f1>") 'heaven-and-hell-toggle-theme)

Tomasz




Tomasz Piotrowski writes:

> Hi,
>
> What are the plans regarding resolving this bug?
>
> Tomasz
>
>
>
>
> Tomasz Piotrowski writes:
>
>> Well, my opinion on this is that either I have to keep switching to Chrome to use wikipedia, or I could use eww for my work. I don’t know how many others have the same issue, but it is a serious flaw in eww from my point of view. Many thanks to Lars for pinpointing the reason of certain svg images not rendering properly in eww.
>>
>> Tomasz
>>
>>
>>
>> Wiadomość napisana przez Eli Zaretskii <eliz@gnu.org> w dniu 27.08.2019, o godz. 09:47:
>>
>>>> From: Lars Ingebrigtsen <larsi@gnus.org>
>>>> Cc: tpiotrowski@is.umk.pl,  37159@debbugs.gnu.org
>>>> Date: Tue, 27 Aug 2019 08:59:20 +0200
>>>> 
>>>> I'm not quite sure what a solution here would be.  shr could parse the
>>>> SVG data (it's just XML, after all) and insert a stroke (i.e.,
>>>> foreground) colour if none is specified, and one that's sufficiently
>>>> different from the background colour that the image would be kinda-sorta
>>>> readable.
>>>> 
>>>> But is it worth it just to display these unusually degenerate SVG
>>>> images?
>>> 
>>> I don't know enough to have an opinion that matters.
>>> 
>>>>> Btw, why does EWW break the text line when it encounters an image?
>>>> 
>>>> When doing the layout, in general the dimensions of the images isn't
>>>> known -- the images are fetched asynchronously after displaying the
>>>> text.
>>>> 
>>>> There's also a historical reason -- the code was written before shr did
>>>> pixel-based layouts, so even if it knew the dimensions, it couldn't do
>>>> anything about it.  That could be fixed now (so that if the <img> has a
>>>> width attribute, the layout engine could use it and insert the
>>>> placeholder there).
>>> 
>>> Something to work on in the future, I think.
>>> 
>>> Thanks.

bug#37159: 26.1; svg images in eww

[Alan Third]

On Tue, Aug 27, 2019 at 08:59:20AM +0200, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> All the equations on this page are SVG images:
> >> 
> >> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
> >
> > For those I see empty rectangles on my display.  I have no idea what
> > that means, it could be that the image is displayed with white on
> > white, or it could be some other issue with SVG images specific to
> > MS-Windows.
> 
> The SVG images wikipedia uses for the math are kinda special: They
> specify neither the foreground colour nor the background colour.  So
> perhaps the svg libraries just choose a random colour for either, and
> that's black-on-background in Linux and white-on-background in Windows.
> 
> The colours are instead set via CSS, which is why they're legible in
> most browsers.
> 
> I'm not quite sure what a solution here would be.  shr could parse the
> SVG data (it's just XML, after all) and insert a stroke (i.e.,
> foreground) colour if none is specified, and one that's sufficiently
> different from the background colour that the image would be kinda-sorta
> readable.

I don’t know if the way GTK works would be helpful:

    https://gitlab.gnome.org/GNOME/gtk/issues/1471
    
I guess you can just set some default CSS in the wrapper and if the
SVG overrides it then it doesn’t matter.
-- 
Alan Third

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> I don’t know if the way GTK works would be helpful:
>
>     https://gitlab.gnome.org/GNOME/gtk/issues/1471
>
> I guess you can just set some default CSS in the wrapper and if the
> SVG overrides it then it doesn’t matter.

Which is:

<svg ...>
  <style>
    ... extra styling here ...
  </style>
  <xi:include href="... original SVG encoded as a data: URL ..."/>
</svg>

That's an interesting approach.  As you say, it would probably solve
these problems, and my guess is that all the SVG libraries we support
would probably handle this construction fine.  The styling properties we
could inject here could be, for instance, a stroke colour that the same
as the foreground colour of the default face, and a background colour
that's the same as the background colour of the current buffer.

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

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> That's an interesting approach.  As you say, it would probably solve
> these problems, and my guess is that all the SVG libraries we support
> would probably handle this construction fine.  The styling properties we
> could inject here could be, for instance, a stroke colour that the same
> as the foreground colour of the default face, and a background colour
> that's the same as the background colour of the current buffer.

I've now done this, and it works for me on GNU/Linux with whatever svg
libraries I have.

Could people try

https://en.wikipedia.org/wiki/Banach_fixed-point_theorem

again and see whether the equations are displayed better now (i.e., not
as blank images).

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

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tpiotrowski@is.umk.pl,  Eli Zaretskii <eliz@gnu.org>,
>   37159@debbugs.gnu.org
> Date: Sat, 14 Sep 2019 16:49:48 +0200
> 
> > That's an interesting approach.  As you say, it would probably solve
> > these problems, and my guess is that all the SVG libraries we support
> > would probably handle this construction fine.  The styling properties we
> > could inject here could be, for instance, a stroke colour that the same
> > as the foreground colour of the default face, and a background colour
> > that's the same as the background colour of the current buffer.
> 
> I've now done this, and it works for me on GNU/Linux with whatever svg
> libraries I have.
> 
> Could people try
> 
> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
> 
> again and see whether the equations are displayed better now (i.e., not
> as blank images).

They do display much better here (on MS-Windows), thanks.

bug#37159: 26.1; svg images in eww

[Alan Third]

On Sat, Sep 14, 2019 at 04:49:48PM +0200, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > That's an interesting approach.  As you say, it would probably solve
> > these problems, and my guess is that all the SVG libraries we support
> > would probably handle this construction fine.  The styling properties we
> > could inject here could be, for instance, a stroke colour that the same
> > as the foreground colour of the default face, and a background colour
> > that's the same as the background colour of the current buffer.
> 
> I've now done this, and it works for me on GNU/Linux with whatever svg
> libraries I have.
> 
> Could people try
> 
> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
> 
> again and see whether the equations are displayed better now (i.e., not
> as blank images).

Works here on macOS.

-- 
Alan Third

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> Works here on macOS.

Eli, Alan, thanks for checking.  I'm closing this bug report, but if
there are other regressions (I've checked a couple of other SVG images
and they seem fine), we may reopen.

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

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Hi Lars,

Could you please detail the steps needed to apply this solution?

I use Fedora Linux.

Thanks a lot,

Tomasz



Lars Ingebrigtsen writes:

> Alan Third <alan@idiocy.org> writes:
>
>> Works here on macOS.
>
> Eli, Alan, thanks for checking.  I'm closing this bug report, but if
> there are other regressions (I've checked a couple of other SVG images
> and they seem fine), we may reopen.

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:

> Could you please detail the steps needed to apply this solution?

If you do a "git pull" in the master branch of Emacs, you should get the
fix.

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

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

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

Thanks. I compiled the following version of Emacs:

GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)

shr contains now the fix on my system (Fedora 30). The equations (SVG images) are visible now, which is
great. However, most of them are only partially visible, as if the text
above and under the equations overlapped with them.

Tomasz



Lars Ingebrigtsen writes:

> Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:
>
>> Could you please detail the steps needed to apply this solution?
>
> If you do a "git pull" in the master branch of Emacs, you should get the
> fix.


[-- Attachment #2: shr_svg_fedora.png --]
[-- Type: image/png, Size: 166924 bytes --]

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

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

Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:

> great. However, most of them are only partially visible, as if the text
> above and under the equations overlapped with them.

Looks like whatever library Emacs is using for the svgs are saying that
they're shorter than they should be:

(image-size (create-image "/tmp/d.svg" nil nil :scale 1) t)
=> (12 . 13)

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

[-- Attachment #2: d.svg --]
[-- Type: image/svg+xml, Size: 1527 bytes --]

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

> Looks like whatever library Emacs is using for the svgs are saying that
> they're shorter than they should be:
>
> (image-size (create-image "/tmp/d.svg" nil nil :scale 1) t)
> => (12 . 13)
What would be a solution to this?

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:

>> Looks like whatever library Emacs is using for the svgs are saying that
>> they're shorter than they should be:
>>
>> (image-size (create-image "/tmp/d.svg" nil nil :scale 1) t)
>> => (12 . 13)
> What would be a solution to this?

I do not know.

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

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

>>> Looks like whatever library Emacs is using for the svgs are saying that
>>> they're shorter than they should be:
>>>
>>> (image-size (create-image "/tmp/d.svg" nil nil :scale 1) t)
>>> => (12 . 13)
>> What would be a solution to this?
>
> I do not know.
If the patch lines are commented out in shr.el:

    ;; SVG images often do not have a specified foreground/background
    ;; color, so wrap them in styles.
    ;; (when (eq content-type 'image/svg+xml)
    ;;   (setq data (svg--wrap-svg data)))
    (list data content-type)))

(defun svg--wrap-svg (data))
  ;; "Add a default foreground colour to SVG images."
  ;; (with-temp-buffer
  ;;   (insert "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" "
  ;;           "xmlns:xi=\"http://www.w3.org/2001/XInclude\" "
  ;;           "style=\"color: "
  ;;           (face-foreground 'default) ";\">"
  ;;           "<xi:include href=\"data:image/svg+xml;base64,"
  ;;           (base64-encode-string data t)
  ;;           "\"></xi:include></svg>")
  ;;   (buffer-string)))

then the equations (SVG images) are not overlapping with surrounding
text. 

bug#37159: 26.1; svg images in eww

[Alan Third]

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

On Thu, 19 Sep 2019, 09:21 Tomasz Piotrowski, <tpiotrowski@is.umk.pl> wrote:

> >>> Looks like whatever library Emacs is using for the svgs are saying that
> >>> they're shorter than they should be:
> >>>
> >>> (image-size (create-image "/tmp/d.svg" nil nil :scale 1) t)
> >>> => (12 . 13)
> >> What would be a solution to this?
> >
> > I do not know.
> If the patch lines are commented out in shr.el:
>
>     ;; SVG images often do not have a specified foreground/background
>     ;; color, so wrap them in styles.
>     ;; (when (eq content-type 'image/svg+xml)
>     ;;   (setq data (svg--wrap-svg data)))
>     (list data content-type)))
>
> (defun svg--wrap-svg (data))
>   ;; "Add a default foreground colour to SVG images."
>   ;; (with-temp-buffer
>   ;;   (insert "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" "
>   ;;           "xmlns:xi=\"http://www.w3.org/2001/XInclude\" "
>   ;;           "style=\"color: "
>   ;;           (face-foreground 'default) ";\">"
>   ;;           "<xi:include href=\"data:image/svg+xml;base64,"
>   ;;           (base64-encode-string data t)
>   ;;           "\"></xi:include></svg>")
>   ;;   (buffer-string)))
>
> then the equations (SVG images) are not overlapping with surrounding
> text.
>

Hmm, it looks like GTK explicitly sets the width and height of the wrapper
to match the SVG file. I don't know how practical that is for us, does it
mean loading the file twice: once to get the size and once to wrap it?

>

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

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> Hmm, it looks like GTK explicitly sets the width and height of the wrapper to
> match the SVG file. I don't know how practical that is for us, does it mean
> loading the file twice: once to get the size and once to wrap it?

Yup.  I've now done this change on the trunk and it seems to make the
test page render better.

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

bug#37159: 26.1; svg images in eww

[Alan Third]

On Thu, Sep 19, 2019 at 03:59:16PM +0200, Lars Ingebrigtsen wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > Hmm, it looks like GTK explicitly sets the width and height of the wrapper to
> > match the SVG file. I don't know how practical that is for us, does it mean
> > loading the file twice: once to get the size and once to wrap it?
> 
> Yup.  I've now done this change on the trunk and it seems to make the
> test page render better.

Looks better here too.
-- 
Alan Third

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

Could you please share the solution?

Thanks,
Tomasz

> Wiadomość napisana przez Alan Third <alan@idiocy.org> w dniu 20.09.2019, o godz. 20:56:
> 
>> On Thu, Sep 19, 2019 at 03:59:16PM +0200, Lars Ingebrigtsen wrote:
>> Alan Third <alan@idiocy.org> writes:
>> 
>>> Hmm, it looks like GTK explicitly sets the width and height of the wrapper to
>>> match the SVG file. I don't know how practical that is for us, does it mean
>>> loading the file twice: once to get the size and once to wrap it?
>> 
>> Yup.  I've now done this change on the trunk and it seems to make the
>> test page render better.
> 
> Looks better here too.
> -- 
> Alan Third

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:

> Could you please share the solution?

If you do a "git pull" on the Emacs trunk, you'll get the fix...

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

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

If I am not missing anything, pulling whole emacs means building and recompiling it. I would think a better way to have the fix tested is to point to location of the change, so one can simply add it to shr.el (say), byte-compile and test it.

Or, do I miss something and there is no need to rebuild and recompile emacs? I use it as my desktop environment through EXWM, so it is a little tiresome to rebuild each time.

Tomasz


> Wiadomość napisana przez Lars Ingebrigtsen <larsi@gnus.org> w dniu 20.09.2019, o godz. 21:18:
> 
> Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:
> 
>> Could you please share the solution?
> 
> If you do a "git pull" on the Emacs trunk, you'll get the fix...
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Tomasz Piotrowski <tpiotrowski@is.umk.pl>
> Date: Fri, 20 Sep 2019 21:22:56 +0200
> Cc: Alan Third <alan@idiocy.org>, Eli Zaretskii <eliz@gnu.org>,
>  37159@debbugs.gnu.org
> 
> If I am not missing anything, pulling whole emacs means building and recompiling it. I would think a better way to have the fix tested is to point to location of the change, so one can simply add it to shr.el (say), byte-compile and test it.
> 
> Or, do I miss something and there is no need to rebuild and recompile emacs? I use it as my desktop environment through EXWM, so it is a little tiresome to rebuild each time.

The change is here:

   http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7156b0efc714eaaab5bcf42138752f698e57b5ad

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

> The change is here:
>
>    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7156b0efc714eaaab5bcf42138752f698e57b5ad
Thanks a lot Eli. I will try it and make effort to make it work on my
system. Many thanks for your kind help.

Tomasz

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Tomasz Piotrowski <tpiotrowski@is.umk.pl>
> Cc: larsi@gnus.org, alan@idiocy.org, 37159@debbugs.gnu.org
> Date: Fri, 20 Sep 2019 22:48:55 +0200
> 
> > The change is here:
> >
> >    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7156b0efc714eaaab5bcf42138752f698e57b5ad
> Thanks a lot Eli. I will try it and make effort to make it work on my
> system. Many thanks for your kind help.

You are welcome.  My point is that, for any recent change done to the
Emacs development sources, you can find that change by browsing
http://git.savannah.gnu.org/cgit/emacs.git/log/, where you will find
the log of the changes in reverse chronological order; clicking on any
change will then show the diffs.

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

>> > The change is here:
>> >
>> >    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7156b0efc714eaaab5bcf42138752f698e57b5ad
>> Thanks a lot Eli. I will try it and make effort to make it work on my
>> system. Many thanks for your kind help.
>
> You are welcome.  My point is that, for any recent change done to the
> Emacs development sources, you can find that change by browsing
> http://git.savannah.gnu.org/cgit/emacs.git/log/, where you will find
> the log of the changes in reverse chronological order; clicking on any
> change will then show the diffs.
This is very good to know, thanks a lot.

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:

> If I am not missing anything, pulling whole emacs means building and
> recompiling it.

If you're on a GNU/Linux system (and have a workeable network
connection), building Emacs is trivial:

sudo apt build-dep emacs
git clone git://git.savannah.gnu.org/emacs.git
cd emacs
make
./src/emacs &

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

bug#37159: 26.1; svg images in eww

[Lars Ingebrigtsen]

Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:

> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem

In Emacs 27 with -Q, that page displays without any problems for me, and
the SVG equations look like normal.  However, if you have an Emacs with
a black background, they're displayed as black-on-black (since there's
no background colour defined).

I'm not quite sure what the right solution here would be.  eww currently
fetches no external CSS resources, so that it doesn't know that the
background colour of that page is supposed to be white (which would also
have fixed the problem).

Fetching external CSS would be an option, but would slow down normal
operations for very little gain (as shr ignores 99.7% of CSS).  But in
this case it would probably have gotten the background colour right,
which would be nice.

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

bug#37159: 26.1; svg images in eww

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 26 Aug 2019 06:54:41 +0200
> Cc: 37159@debbugs.gnu.org
> 
> Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:
> 
> > https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
> 
> In Emacs 27 with -Q, that page displays without any problems for me, and
> the SVG equations look like normal.

Is your Emacs compiled with or without ImageMagick?  Mine is without.

bug#37159: 26.1; svg images in eww

[Tomasz Piotrowski]

In my case, compiled with ImageMagick.

Tomasz



Wiadomość napisana przez Eli Zaretskii <eliz@gnu.org> w dniu 26.08.2019, o godz. 09:46:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Mon, 26 Aug 2019 06:54:41 +0200
>> Cc: 37159@debbugs.gnu.org
>> 
>> Tomasz Piotrowski <tpiotrowski@is.umk.pl> writes:
>> 
>>> https://en.wikipedia.org/wiki/Banach_fixed-point_theorem
>> 
>> In Emacs 27 with -Q, that page displays without any problems for me, and
>> the SVG equations look like normal.
> 
> Is your Emacs compiled with or without ImageMagick?  Mine is without.

bug#37159: 26.1; svg images in eww

[Jordan Wilson]

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

I use a black background colour, and this problem appears for me with
PNG images where black is on a transparent background. I'm on 26.2.90 on
Windows 10, with the relevant image support (no ImageMagick though).

See the attached screenshots of https://www.gnu.org/software/emacs/ (one
with a black background showing the problem, and one with a white
background to contrast).


[-- Attachment #2: gnu-logo-black-background.PNG --]
[-- Type: image/png, Size: 28144 bytes --]

[-- Attachment #3: gnu-logo-white-background.PNG --]
[-- Type: image/png, Size: 44495 bytes --]

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


The image shown is
https://www.gnu.org/software/emacs/images/gnu.transparent.png

The problem is not exclusive to eww, though. If I download the image and
open it in image-mode, it's invisible on the background like above.

-- 
Jordan Wilson
    Sent from Gnus v5.13, GNU Emacs 26.2.90 on WINDOWS-NT