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.