librsvg issueshttps://gitlab.gnome.org/GNOME/librsvg/-/issues2024-03-28T04:28:04Zhttps://gitlab.gnome.org/GNOME/librsvg/-/issues/1070Get librsvg accepted into OSS-Fuzz2024-03-28T04:28:04ZcorrectmostGet librsvg accepted into OSS-Fuzz## Issue Summary
As part of the larger fuzzing efforts in #1018, I will submit a PR to get librsvg accepted into the [OSS-Fuzz repo + program](https://github.com/google/oss-fuzz/tree/master).
The [instructions](https://google.github.io...## Issue Summary
As part of the larger fuzzing efforts in #1018, I will submit a PR to get librsvg accepted into the [OSS-Fuzz repo + program](https://github.com/google/oss-fuzz/tree/master).
The [instructions](https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/) require the following information:
- Homepage
- `https://gitlab.gnome.org/GNOME/librsvg/`
- Main repository URL
- `https://gitlab.gnome.org/GNOME/librsvg.git`
- Primary language
- `rust`
- Primary contact
- **TBD: This field requires a Google account and will require informal email verification**
- Note: The email address will be public in the oss-fuzz repo
- CC contacts
- **TBD: This field also requires Google accounts and will require informal email verifications**
- Note: The email addresses will be public in the oss-fuzz repo
- I would like to add myself to this list to help with improvements to fuzz targets
I can submit the PR once I have an email address for the primary contact (and any CC contacts). Let me know if you'd like me to change any of the other proposed values too. Thanks!https://gitlab.gnome.org/GNOME/librsvg/-/issues/1069Test installed artifacts2024-03-26T18:09:34ZFederico Mena QuinteroTest installed artifactsThe CI doesn't have a test for installed artifacts, i.e. whether the stuff that happens during `meson install` is complete and makes sense:
* "Distro builds" generally want to enable most features, e.g. the upcoming !953, plus documenta...The CI doesn't have a test for installed artifacts, i.e. whether the stuff that happens during `meson install` is complete and makes sense:
* "Distro builds" generally want to enable most features, e.g. the upcoming !953, plus documentation, gobject-introspection, gdk-pixbuf loader, etc. Test that those things get installed, that pkg-config works, header files are in the right place, the library has the correct soname.
* Allow testing different configurations. You turn on the AVIF option - can librsvg indeed load AVIF files? Etc.2.59.0https://gitlab.gnome.org/GNOME/librsvg/-/issues/1068Update devel-docs for meson2024-03-26T17:46:07ZFederico Mena QuinteroUpdate devel-docs for mesonThe devel-docs mention autotools in some places, especially `compiling.rst`. These should be updated for Meson.
I think this is a good time to document the meson_options that the build system makes available.The devel-docs mention autotools in some places, especially `compiling.rst`. These should be updated for Meson.
I think this is a good time to document the meson_options that the build system makes available.2.59.0https://gitlab.gnome.org/GNOME/librsvg/-/issues/1067Disable logging when fuzzing is active2024-03-25T20:17:26ZFederico Mena QuinteroDisable logging when fuzzing is activeAs part of #1018, the [hongfuzz-rs docs](https://github.com/rust-fuzz/honggfuzz-rs?tab=readme-ov-file#conditional-compilation) recommend disabling logging so the fuzzer will have fewer paths to try to reach. Logging [is done here](https...As part of #1018, the [hongfuzz-rs docs](https://github.com/rust-fuzz/honggfuzz-rs?tab=readme-ov-file#conditional-compilation) recommend disabling logging so the fuzzer will have fewer paths to try to reach. Logging [is done here](https://gitlab.gnome.org/GNOME/librsvg/-/blob/e09c63c41a103b9b32831a4c897d3bc1ce29ee26/rsvg/src/log.rs#L5-14).
CC @correctmosthttps://gitlab.gnome.org/GNOME/librsvg/-/issues/1066Create an index.html landing page for GitLab pages2024-03-15T17:05:40ZFederico Mena QuinteroCreate an index.html landing page for GitLab pagesThe `pages` job in CI creates stuff that is available under https://gnome.pages.gitlab.gnome.org/librsvg/, but there is no landing page at that specific URL. We should have one that links to all the stuff we publish there (C API docs, R...The `pages` job in CI creates stuff that is available under https://gnome.pages.gitlab.gnome.org/librsvg/, but there is no landing page at that specific URL. We should have one that links to all the stuff we publish there (C API docs, Rust API docs, development guide, anything else?).https://gitlab.gnome.org/GNOME/librsvg/-/issues/1063reftest regression with pango 1.52.12024-03-23T19:25:07ZSimon McVittiereftest regression with pango 1.52.1## Issue Summary
After Debian upgraded pango from 1.52.0 to 1.52.1, we're seeing a reftest failure for `rsvg/tests/fixtures/reftests/rtl-tspan.svg`.
## Example SVG
`rsvg/tests/fixtures/reftests/rtl-tspan.svg` from librsvg 2.57.92:
![...## Issue Summary
After Debian upgraded pango from 1.52.0 to 1.52.1, we're seeing a reftest failure for `rsvg/tests/fixtures/reftests/rtl-tspan.svg`.
## Example SVG
`rsvg/tests/fixtures/reftests/rtl-tspan.svg` from librsvg 2.57.92:
![rtl-tspan.svg](/uploads/71796ffbcb2cec09db8880ddf5bf9a25/rtl-tspan.svg)
Expected rendering, `rsvg/tests/fixtures/reftests/rtl-tspan-ref.png`:
![rtl-tspan-ref](/uploads/1c1f10fc2b199b36d6c2c9e55082d009/rtl-tspan-ref.png)
Actual rendering, `tests/output/rtl-tspan-out.png`: `rtl-tspan: 2655 pixels changed with maximum difference of 112`
![rtl-tspan-out](/uploads/26cf1c8682ab69a7568ff391c485886f/rtl-tspan-out.png)
Emphasized diff, `tests/output/rtl-tspan-diff.png`:
![rtl-tspan-diff](/uploads/19634e5608427f8019bf8a955114d22e/rtl-tspan-diff.png)
## Librsvg Version
2.57.92
## Platform
Debian unstable (development/rolling release)https://gitlab.gnome.org/GNOME/librsvg/-/issues/1061Disallow unsupported image formats from image-rs2024-03-06T19:28:30ZFederico Mena QuinteroDisallow unsupported image formats from image-rs#1060 has a fuzzed PNM as a `data:` URI. In theory librsvg should only allow PNG/JPEG/GIF/WEBP per `image_format()` in `document.rs`, but that check only happens if the `data:` URI actually specifies a content-type. In this case, it do...#1060 has a fuzzed PNM as a `data:` URI. In theory librsvg should only allow PNG/JPEG/GIF/WEBP per `image_format()` in `document.rs`, but that check only happens if the `data:` URI actually specifies a content-type. In this case, it doesn't, and the code falls back to the sniffing that image-rs does.
We should only allow supported formats even for sniffed ones.https://gitlab.gnome.org/GNOME/librsvg/-/issues/1058[2.57] svg1_1_filters_conv_02_f_svg and svg1_1_filters_conv_04_f_svg failed o...2024-02-29T12:51:09ZSébastien Bacher[2.57] svg1_1_filters_conv_02_f_svg and svg1_1_filters_conv_04_f_svg failed on some achitecturesWe updated librsvg to 2.57.91 in Debian and Ubuntu but those tests are failing on several (for Ubuntu https://launchpad.net/ubuntu/+source/librsvg/2.57.91+dfsg-1 it is arm64 ppc64el at least)
Example build log on arm64
https://launchpad...We updated librsvg to 2.57.91 in Debian and Ubuntu but those tests are failing on several (for Ubuntu https://launchpad.net/ubuntu/+source/librsvg/2.57.91+dfsg-1 it is arm64 ppc64el at least)
Example build log on arm64
https://launchpadlibrarian.net/716669919/buildlog_ubuntu-noble-arm64.librsvg_2.57.91+dfsg-1_BUILDING.txt.gz
```
failures:
---- tests::svg1_1_filters_conv_02_f_svg stdout ----
filters-conv-02-f: 4024 pixels changed with maximum difference of 66
out: /<<PKGBUILDDIR>>/tests/output/filters-conv-02-f-out.png
diff: /<<PKGBUILDDIR>>/tests/output/filters-conv-02-f-diff.png
thread 'tests::svg1_1_filters_conv_02_f_svg' panicked at rsvg/src/test_utils/reference_utils.rs:85:25:
surfaces are too different
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- tests::svg1_1_filters_conv_04_f_svg stdout ----
filters-conv-04-f: 4193 pixels changed with maximum difference of 59
out: /<<PKGBUILDDIR>>/tests/output/filters-conv-04-f-out.png
diff: /<<PKGBUILDDIR>>/tests/output/filters-conv-04-f-diff.png
thread 'tests::svg1_1_filters_conv_04_f_svg' panicked at rsvg/src/test_utils/reference_utils.rs:85:25:
surfaces are too different
```
and attaching the corresponding images
![filters-conv-02-f-diff](/uploads/aa827264237d1eb667653250984e9a83/filters-conv-02-f-diff.png)
![filters-conv-02-f-out](/uploads/1a78e41819f9a16a3003a4c41b159b1e/filters-conv-02-f-out.png)
![filters-conv-04-f-diff](/uploads/d72d2816fbd8e88260562ae3e630638b/filters-conv-04-f-diff.png)
![filters-conv-04-f-out](/uploads/8613bf94a36071108c51942d70d090c4/filters-conv-04-f-out.png)https://gitlab.gnome.org/GNOME/librsvg/-/issues/1054Update gnomeos jobs for 2.58 / GNOME 462024-03-28T10:56:13ZFederico Mena QuinteroUpdate gnomeos jobs for 2.58 / GNOME 46From https://gitlab.gnome.org/GNOME/librsvg/-/issues/1043#note_2003322:
> We should also remove the Nightly CI tests when branching, and bump the stable images to 46. Images should get pushed once we branch 46.Beta.
@alatiera can we ha...From https://gitlab.gnome.org/GNOME/librsvg/-/issues/1043#note_2003322:
> We should also remove the Nightly CI tests when branching, and bump the stable images to 46. Images should get pushed once we branch 46.Beta.
@alatiera can we have a `rules` so that the jobs for rust-nightly don't get run on stable branches? I think we can just test the branch name for `main`?https://gitlab.gnome.org/GNOME/librsvg/-/issues/1053Update C dependencies before 2.582024-02-08T21:46:38ZFederico Mena QuinteroUpdate C dependencies before 2.58Continuing from #1043 - let's update cairo/pango/etc. as needed.Continuing from #1043 - let's update cairo/pango/etc. as needed.2.58.0https://gitlab.gnome.org/GNOME/librsvg/-/issues/1051Optimize the alpha-only code paths2024-01-30T15:19:34ZFederico Mena QuinteroOptimize the alpha-only code pathsThe code coverage report indicates that the `if self.is_alpha_only() {` block in `ImageSurface::convolve()` is never used:
![image](/uploads/ef04aab3c3609a865951f48d23cdd528/image.png)
This is only called from `gaussian_blur.rs:gaussia...The code coverage report indicates that the `if self.is_alpha_only() {` block in `ImageSurface::convolve()` is never used:
![image](/uploads/ef04aab3c3609a865951f48d23cdd528/image.png)
This is only called from `gaussian_blur.rs:gaussian_blur()`. The intent is that blurring an alpha-only surface will only process a single channel. However, I think all alpha-only surfaces are actually full ARGB. From `ImageSurface::extract_alpha()`:
```rust
pub fn extract_alpha(&self, bounds: IRect) -> Result<SharedImageSurface, cairo::Error> {
let mut output_surface =
cairo::ImageSurface::create(cairo::Format::ARgb32, self.width, self.height)?;
let output_stride = output_surface.stride() as usize;
{
let mut output_data = output_surface.data().unwrap();
for (x, y, Pixel { a, .. }) in Pixels::within(self, bounds) {
let output_pixel = Pixel {
r: 0,
g: 0,
b: 0,
a,
};
output_data.set_pixel(output_stride, output_pixel, x, y);
}
}
SharedImageSurface::wrap(output_surface, SurfaceType::AlphaOnly)
}
```
That function could very well output a `cairo::Format::A8`. I don't know if the rest of the code is equipped to handle that (we assume ARGB in a lot of places), but it's worth finding where it's not handled and fixing it.https://gitlab.gnome.org/GNOME/librsvg/-/issues/1049Add python example to the docs2024-01-26T22:27:23ZFederico Mena QuinteroAdd python example to the docsThe documentation should have an example of how to use librsvg from Python. This works; we can probably make it nicer:
```python
import cairo
import gi
gi.require_version('Rsvg', '2.0')
from gi.repository import Rsvg
surf = cairo.Im...The documentation should have an example of how to use librsvg from Python. This works; we can probably make it nicer:
```python
import cairo
import gi
gi.require_version('Rsvg', '2.0')
from gi.repository import Rsvg
surf = cairo.ImageSurface(cairo.FORMAT_ARGB32, 1000, 1000)
cr = cairo.Context(surf)
handle = Rsvg.Handle.new_from_file("hello.svg")
viewport = Rsvg.Rectangle()
viewport.x = 0
viewport.y = 0
viewport.width = 1000
viewport.height = 1000
handle.render_document(cr, viewport)
surf.write_to_png("hello.png")
```https://gitlab.gnome.org/GNOME/librsvg/-/issues/1047Usability improvements for the "make me a development environment" script2024-01-25T14:31:41ZFederico Mena QuinteroUsability improvements for the "make me a development environment" scriptThe current recommended way of developing librsvg is to use its container image:
```
$ sh ci/pull-container-image.sh
full_tag="x86_64-1.75.0-2024-01-21.0-main"
pulling image registry.gitlab.gnome.org/gnome/librsvg/opensuse/tumbleweed:x...The current recommended way of developing librsvg is to use its container image:
```
$ sh ci/pull-container-image.sh
full_tag="x86_64-1.75.0-2024-01-21.0-main"
pulling image registry.gitlab.gnome.org/gnome/librsvg/opensuse/tumbleweed:x86_64-1.75.0-2024-01-21.0-main
Trying to pull registry.gitlab.gnome.org/gnome/librsvg/opensuse/tumbleweed:x86_64-1.75.0-2024-01-21.0-main...
Getting image source signatures
Copying blob 2e6cd7154f99 done |
Copying blob f8a15d2c5000 done |
Copying config be1c83c410 done |
Writing manifest to image destination
be1c83c410840419f73c8be49b93ef89614a30cfb91702f232ec0a8aac421511
You can now run this:
podman run --rm -ti --cap-add=SYS_PTRACE -v $(pwd):/srv/project -w /srv/project registry.gitlab.gnome.org/gnome/librsvg/opensuse/tumbleweed:x86_64-1.75.0-2024-01-21.0-main
Don't forget to run this once inside the container:
source ci/env.sh
source ci/setup-dependencies-env.sh
```
@maco reports that it's easy to forget exactly where that script is located. Also, it mentions a bit too many steps (run podman, then two `source` lines).
I think I cargo-culted that podman command-line from the one @alatiera gave me ages ago, when I was first learning to use containers. It works pretty well, but we can totally encapsulate it in a friendlier script.
Maybe we can have a `start-development-container.sh` script in the toplevel, that handles all the magic underneath. We can probably set up the environment variables in the container in a more automated fashion.https://gitlab.gnome.org/GNOME/librsvg/-/issues/1045Follow-up from "ci: Add builds with GNOME OS images"2024-01-23T17:58:41ZJordan PetridisFollow-up from "ci: Add builds with GNOME OS images"The following discussion from !907 should be addressed:
- [ ] @alatiera started a [discussion](https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/907#note_1962834):
> I am not sure if we wanna do both stable and nightly and w...The following discussion from !907 should be addressed:
- [ ] @alatiera started a [discussion](https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/907#note_1962834):
> I am not sure if we wanna do both stable and nightly and what will happen when we need changes for one that will break the other.
>
> However there two things to keep in mind here:
>
> * Dependencies are managed from gnome-build-meta, but we can add anything we want on top and/or overwrite things.
>
> * The image will be built once, and then will need to update the tag to rebuilt/update the base, so even the nightly image will always be working and require explicit bumps.
>
> * we might want to make one of them allowed to fail
>
> * We should probably be using /usr prefix with the gnomeos images, and then also doing `make install` just to make sure the system rsvg is always overwritten and doesn't get used by accidenthttps://gitlab.gnome.org/GNOME/librsvg/-/issues/1044Rsvg-convert handles Cairo's "empty bounds" incorrectly when extracting elements2024-01-20T01:59:02ZFederico Mena QuinteroRsvg-convert handles Cairo's "empty bounds" incorrectly when extracting elementsSee #1037 and #1041 for example files.
Cairo returns an all-zeros rectangle (i.e. a point at the origin) when an path has an empty bounding box for fill or stroke. Those issues are about catching those cases and using `None`, which the...See #1037 and #1041 for example files.
Cairo returns an all-zeros rectangle (i.e. a point at the origin) when an path has an empty bounding box for fill or stroke. Those issues are about catching those cases and using `None`, which the rest of the bounding-box machinery in librsvg is supposed to handle correctly.
However, I am not convinced that this handles the following case correctly. Consider a vertical or horizontal `<polyline>` or `<line>`. It has no fillable area, so *those* bounds are fine to represent as `None`. But it *does* have a stroke bounding box, and definitely a path-extents even if it is an infinitely thin line. Librsvg should handle this correctly, so that rsvg-convert's `--export-id` option is able to compute the bounds of that single element correctly.https://gitlab.gnome.org/GNOME/librsvg/-/issues/1041Handle bounding box when cairo.stroke_extents returns 0, 0, 0, 02024-01-20T01:59:08ZHenrik NilssonHandle bounding box when cairo.stroke_extents returns 0, 0, 0, 0## Description
This ticket is is similar to #1037
Bounding box incorrectly calculated when cairo.stroke_extents return a zero rectangle. This in turns causes problem if rsvg_handle_render_element is used to render a single element.
`c...## Description
This ticket is is similar to #1037
Bounding box incorrectly calculated when cairo.stroke_extents return a zero rectangle. This in turns causes problem if rsvg_handle_render_element is used to render a single element.
`compute_stroke_and_fill_extents` function doesn't handle the situation where an empty rectangle is returned from `stroke_extents`.
## Steps to reproduce
Save this as bug.svg:
```
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" id="svg2779" width="4628" height="2510" version="1.1" viewBox="0 0 1224.5 664.1">
<g id="heart_2" transform="translate(.00130771 -.0073965)">
<path id="path107864" d="m106.38 275.58c0-1.895-1.409-3.326-3.309-3.326-1.836 0-3.245 1.56-3.245 3.586 0 1.17.506 1.914 1.298 1.914.697 0 1.108-.52 1.108-1.32 0-1.504-1.108-1.114-1.108-2.118 0-.78.76-1.579 1.472-1.579 1.014 0 1.568.948 1.568 2.564 0 3.55-2.39 5.147-4.655 9.588v.594c.317-.13.491-.167.665-.167h5.589c.206 0 .395.037.775.167l.333-4.756h-.665l-.127.78c-.142.91-.237 1.208-.348 1.32-.142.092-.174.092-1.06.11h-3.135c1.361-2.062 4.844-3.92 4.844-7.357z" fill="#e83630" stroke="#e83630" stroke-linejoin="round" stroke-width=".25"/>
</g>
</svg>
```
rsvg-convert.exe -w 1024 -h 1024 -i "#heart_2" bug.svg -o heart_2.png
## Version
rsvg-convert version 2.57.1https://gitlab.gnome.org/GNOME/librsvg/-/issues/1040Incorrect rasterization when width is above 4k2024-01-04T12:50:43ZNikolajs ArhipovsIncorrect rasterization when width is above 4k## Issue Summary
When rasterized, with increased width the pattern is shifted to the right until the resulting png is a black rectangle
This rasterizes correctly:
```
rsvg-convert --width 4000 ./2f82fdb7-8f79-4077-bda9-0a149d5a77ea.svg...## Issue Summary
When rasterized, with increased width the pattern is shifted to the right until the resulting png is a black rectangle
This rasterizes correctly:
```
rsvg-convert --width 4000 ./2f82fdb7-8f79-4077-bda9-0a149d5a77ea.svg >| out-4000.png
```
The pattern shifted to the right:
```
rsvg-convert --width 4500 ./2f82fdb7-8f79-4077-bda9-0a149d5a77ea.svg >| out-4500.png`
```
Black png:
```
rsvg-convert --width 5000 ./2f82fdb7-8f79-4077-bda9-0a149d5a77ea.svg >| out-5000.png`
```
## Example SVG
![2f82fdb7-8f79-4077-bda9-0a149d5a77ea.svg](/uploads/f51da6a1fcc9d95ab8452b52dd4b83f3/2f82fdb7-8f79-4077-bda9-0a149d5a77ea.svg)
## Librsvg Version
Tried 2.57.1 from Archlinux (https://gitlab.archlinux.org/archlinux/packaging/packages/librsvg/-/blob/0feee3161b989684e548ef78a0b6b61a6a23c0d9/PKGBUILD) as well as building Librsvg from main, cairo version is 1.18.0.
## Platform
Archlinuxhttps://gitlab.gnome.org/GNOME/librsvg/-/issues/1039Image with mask is rasterized as an empty png2024-01-04T13:08:06ZNikolajs ArhipovsImage with mask is rasterized as an empty png## Issue Summary
The SVG's provided in the examples are seemingly incorrectly truncated (compared to firefox, chrome and inkscape).
```
rsvg-convert --width 100 ./f4066d7c-82a6-46fe-a061-a12376eac857.svg >| out.png
```
## Example SVG...## Issue Summary
The SVG's provided in the examples are seemingly incorrectly truncated (compared to firefox, chrome and inkscape).
```
rsvg-convert --width 100 ./f4066d7c-82a6-46fe-a061-a12376eac857.svg >| out.png
```
## Example SVG
![f4066d7c-82a6-46fe-a061-a12376eac857.svg](/uploads/efcae8c1050cf27eecd1668bf4824b3b/f4066d7c-82a6-46fe-a061-a12376eac857.svg)
## Librsvg Version
Tried 2.57.1 from Archlinux (https://gitlab.archlinux.org/archlinux/packaging/packages/librsvg/-/blob/0feee3161b989684e548ef78a0b6b61a6a23c0d9/PKGBUILD) as well as building Librsvg from main, cairo version is 1.18.0.
## Platform
Archlinux
## Additional logs
<!--
Debug logs are quite helpful, use `RSVG_LOG=1 <some program or rsvg-convert>` to get them.
Then surround it with ``` at the top and bottom for formatting.
-->https://gitlab.gnome.org/GNOME/librsvg/-/issues/1038SVG rasterizes as blank after a specific size2024-01-04T12:53:11ZNikolajs ArhipovsSVG rasterizes as blank after a specific size
## Issue Summary
This rasterizes correctly:
```
rsvg-convert --width 2242 ./pattern.svg >| out.png
```
While this yields a blank png:
```
rsvg-convert --width 2243 ./pattern.svg >| out.png
```
## Example SVG
![pattern.svg](/uploads...
## Issue Summary
This rasterizes correctly:
```
rsvg-convert --width 2242 ./pattern.svg >| out.png
```
While this yields a blank png:
```
rsvg-convert --width 2243 ./pattern.svg >| out.png
```
## Example SVG
![pattern.svg](/uploads/8259250e29fb3be9c1c7c2bffe78eb17/pattern.svg)
## Librsvg Version
Tried 2.57.1 from Archlinux (https://gitlab.archlinux.org/archlinux/packaging/packages/librsvg/-/blob/0feee3161b989684e548ef78a0b6b61a6a23c0d9/PKGBUILD) as well as building Librsvg from main, cairo version is 1.18.0.
## Platform
Archlinuxhttps://gitlab.gnome.org/GNOME/librsvg/-/issues/1035Doesn't support colors with Adobe's (or any, idk) CMS in SVG2023-12-23T02:31:07ZMaksym HazevychDoesn't support colors with Adobe's (or any, idk) CMS in SVG<!--
Thanks for getting in touch with the Image Viewer (Loupe) project
Please select one of the issue templates above.
For questions, please use the "Issue" template.
-->
I know no better way to phrase the title, as I barely understan...<!--
Thanks for getting in touch with the Image Viewer (Loupe) project
Please select one of the issue templates above.
For questions, please use the "Issue" template.
-->
I know no better way to phrase the title, as I barely understand this myself. Basically, when opening an SVG which elements have their color selected with "CMS" of value "Adobe-RGB-1998", they will render colorless in Loupe.
![image](/uploads/fc2f86b1cce5ff35da3681657dfc82f5/image.png)
But when you open Inkscape and change the value of CMS to "none", it jumps you to "HSL", and everything's fine thereafter.
You can test this by downloading [an archive with this image](https://www.freepik.com/free-vector/car-rental-concept-illustration_28910727.htm#page=3&query=car%20illustraition&position=13&from_view=search&track=ais&uuid=4db2465c-a04a-4bc3-a308-4fa6ca5fcbff), opening the `.ai` file in the archive with Inkscape, and saving it as SVG.