On Wed, 29 Dec 2021 23:14:24 +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Dec 2021 21:54:47 +0900
> Akira Yokosawa <akiyks@xxxxxxxxx> escreveu:
>
>> [+Cc: linux-media, -Cc: lkml]
>>
>> Hi Mauro,
>>
>> In case you are wondering what is going on in the update of
>> selection.svg, here is a status report.
>>
>> On Mon, 13 Dec 2021 16:53:07 +0900, Akira Yokosawa wrote:
>>> On Mon, 13 Dec 2021 07:33:27 +0100, Mauro Carvalho Chehab wrote:
>> [...]
>>>> No matter if this is merged or not, if you find an issue at the images
>>>> at the media docs, please send them to linux-media@xxxxxxxx.
>>>
>>> OK. I'll compose a proper change log for it and post it later this
>>> week or next.
>>> (I'm not a type of person who is good at doing several things in
>>> parallel.)
>>
>> I started the patch preparation, but I found the patch would be
>> quite large in size (~500kB).
>>
>> This is because current selection.svg consists of pretty high-
>> resolution raster images.
>
> No, it is not a raster image. That's why it scales so well.
Ah, I was confused by the behavior of Inkscape.
Looking at the SVG source, which I am not that familiar with, it
has a ton of very long <path ...> objects.
I must have been more careful.
Sorry for the false blaming... :-/
> Btw, the basis for this image is on this commit:
>
> commit 8032b526d1a3bd91ad633dd3a3b5fdbc47ad54f1
> Author: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
> Date: Mon Mar 16 09:05:07 2009 +1030
>
> linux.conf.au 2009: Tuz
So this logo.svg has the same issue when displayed in a browser.
I'm wondering if you could ask Rusty for some advice on this issue.
>
>> I see you had done several attempts to reduce the complexity of
>> the SVG, but it is still large (> 200kB)
>
> One of the reasons why it is big is that the same vector image is added
> there twice: the original one on the left, plus a second copy of it that
> is scaled and has a clip group that hides the elements of it that aren't
> visible at the image on the right.
>
>> and conversion to PDF by
>> convert(1) generates a PDF of more than 1MB!
>> Even inkscape(1) generates a larger PDF (>1.3MB) with embedded
>> raster images.
>
> It doesn't matter the size of the output, provided that the image is
> properly displayed on pdf and html.
Well, I have noticed sluggish behavior of both browsers and PDF
viewers when this figure is displayed. Not a big deal, though.
>
>> I don't believe what the figure wants to explain deserves such
>> a large size.
>> So, from my POV, adding another bitmap image to the SVG for the
>> sake of browser compatibility is *not* the right thing to do.
>
> I actually used a Tux-based svg image as basis because:
>
> 1. Tux (or Tuz, in this case) is well-known Linux image;
> 2. It is a nice image;
> 3. It was committed by another Kernel developer that already
> took care on having it properly licensed;
> 4. As this was merged to the Kernel already, it is under GPLv2.
> 5. It scales well on both html and pdf.
>
> It could have used any other image, or I could have drawn a
> random image, but, as I'm not good on drawing things and finding
> something that won't cause a potential licensing and/or trade mark
> headache could be tricky, I opted to use an already-merged Linux
> image as basis.
>
>> Instead, my suggestion would be to get rid of the embedded raster
>> images and to draw some simple vector-graphics-based figure
>> instead.
>
> There were another image before selection.svg that used a simple
> figure, but the cropped version didn't represent too well (IMHO).
> That's why I opted to use a real figure, where you can see the
> details of the image at the crop region.
>
> I wouldn't mind replacing it with something else, but it should
> be something that it won't cause licensing issues and will still
> properly represent what selection does: crop, compose and scale.
So I have no strong opinion WRT the figure.
I'm not going to post any updates for selection.svg.
Thanks, Akira
>
>> Am I missing something here?
>>
>> Thanks, Akira
>>
>>>
>>> And the most easy fix is to install Inkscape on your system for
>>> the daily build.
>>> Then, convert(1) picks inkscape(1) for SVG rendering and you will
>>> see right ones (of raster images, though).
>>>
>>> You know, ImageMagick prefers inkscape over rsvg-convert.
>>> I think it is the right thing to do in kfigure.py as well.
>>>
>> [...]
>
>
>
> Thanks,
> Mauro
>
