Subject: Re: bug#37159: 26.1; svg images in eww

From: Tomasz Piotrowski <[email-masked]>
Date: Wed, 04 Sep 2019 17:04:33 +0200

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 <[email-masked]> w dniu 27.08.2019, o godz. 09:47:
>
>>> From: Lars Ingebrigtsen <[email-masked]>
>>> Cc: [email-masked],  [email-masked]
>>> 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.