On Wed, 29 Dec 2021 23:14:24 +0100, Mauro Carvalho Chehab wrote:

Em Wed, 29 Dec 2021 21:54:47 +0900
Akira Yokosawa [off-list ref] escreveu:

quoted

[+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:

quoted

On Mon, 13 Dec 2021 07:33:27 +0100, Mauro Carvalho Chehab wrote:  

[...]

quoted

quoted

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@vger.org.  

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 [off-list ref]
    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.

quoted

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.

quoted

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.

quoted

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.

quoted

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

quoted

Am I missing something here?

        Thanks, Akira

quoted

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