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.
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
> 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.
> 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.
> 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
