Svg changes

[IsaacPimentel73]

Converting jpg images into svg.

[vitormattos]

At cover images is necessary to be jpeg, but we need to apply image compression at all jpeg images, or maybe we can use PNG with compression.

SVG is only to vectorial images like a logo with curves.

SVG images also should be compressed to be used at web context.

Maybe @Zagaz could have a good opinion about usage PNG or jpeg as format of cover images. https://duckduckgo.com/?q=use+jpg+or+png+to+web+images

A suggestion of to-do list to this issue:

• compress all jpg images. https://duckduckgo.com/?q=compress+png+for+web+linux&t=ffab&ia=web
• Compress svg images

Other suggestion to compress image is searching for online websites that do this. By example, search by "online png compression" or "online svg compression".

[vitormattos]

Are we using this image?

I think that is pending to remove this image, right?!

source/assets/images/posts/advanced-security/cover1.svg

[vitormattos]

SVG is vetorial images. Isn't necessary and isn't good to convert pictures to SVG.
Images that make sense to be a SVG are logos:
https://github.com/LibreSign/site/blob/main/source/assets/images/icon/somoscoop.png
https://github.com/LibreSign/site/blob/main/source/assets/images/logo/logo-libresign-large.png
https://github.com/LibreSign/site/blob/main/source/assets/images/logo/logo_libresign-small.png
But i s necessary to check the places that those images are used and what will be the impact.

Photos need to be maintained as JPG.
Important points about photos:

• Check if all photos used to posts have the same size and if the size is the same that is necessary to be displayed (not bigger and not lower than the necessary).
• Compress the jpeg images without losing resolution.

Every when we change an url, is important to check if the URL was indexed at internet to don't break the referred links.

Other important point is to fix the DCO issue.

[SethFalco]

[This is largely context for the original author so they have a better understanding of what's wrong here. It seems the maintainers know what's up! Though I would recommend closing this PR and maybe creating an issue if you want to track compressing assets?]

It really wouldn't be a good idea to merge this PR.

These are mostly "fake SVGs". If you read the SVG content it's just the JPEG but base64 encoded and inlined into the SVG. They aren't real SVGs, but just very inefficiently formed JPEGs.

It is generally a good idea to use SVGs instead of JPEGs for works where the style allows (i.e., simple shapes, cell shading, etc.), and where there isn't a technical limitation to prevent its use.

For example, for SVGO.dev, we gravitate towards SVGs, but for our Open Graph banner, we use JPEG too. (It doesn't look like this is the same reason JPEG isn't acceptable here, but it's just one example of why SVGs aren't always feasible.)

Even if we presumed SVGs were technically allowed, let's look at at three of these images:

File	Original Size	SVG Size
source/assets/images/posts/advanced-security/cover.jpg	170 KB	14.5 MB
source/assets/images/posts/hybrid-signatures/cover.jpg	164 KB	867 KB
source/assets/images/posts/qr-code/cover.jpg	156 KB	91.3 KB

On average, it makes the images larger, and then the browser still needs to still build the image from the markup anyway, so it'll take longer to render even once downloaded.

The only arguable improvement is the QR Code banner, but even that includes inline/base64 JPEG.

The idea doesn't really make sense for advanced-security. It could make sense for hybrid-signatures but just wasn't performed correctly.

[vitormattos]

Hi @SethFalco, would you like to submit a new PR with your fix to this?

[vitormattos]

Do you know LibreSign?

Here is the main repository:

https://github.com/libresign/libresign

We also will like a more star at main LibreSign repository :-)

[SethFalco]

would you like to submit a new PR with your fix to this?

Ahh, my point was actually more that this isn't something that needed fixing!

We also will like a more star at main LibreSign repository :-)

😉