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.