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.