Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support context-fill / context-stroke for external SVG, used as object <image... /> #767

Open
Dimon-II opened this issue May 30, 2024 · 15 comments

Comments

@Dimon-II
Copy link

I would like to be able to control the color of external SVG icons.
Currently, the image (containing a single path) is not displayed if fill="context-fill" is used in this file.

@RazrFalcon
Copy link
Owner

Is this even allowed by the spec?

@LaurenzV
Copy link
Contributor

I don't remember the spec mentioning anything like that.

@Dimon-II
Copy link
Author

I don’t know about the specification, but this is the only option where it is really in demand.
What should the color be if I don’t explicitly specify it in the file or use context-fill? Logic: "default" color - corresponds to "context-fill".
Why black now?

A similar point exists only in the special SVG specification for color fonts fill="currentColor"

@LaurenzV
Copy link
Contributor

LaurenzV commented May 30, 2024

It's not black, the default color is none, as mandated by the spec:

The context-fill and context-stroke values are a reference to the paint layers generated for the fill or stroke property, respectively, of the context element of the element being painted. The context element of an element is defined as follows:

  • If the element is within a ‘marker’, and is being rendered as part of that marker due to being referenced via a marker property, then the context element is the element referencing that ‘marker’.
  • If the element is within a sub-tree that is instantiated with a ‘use’ element, then the context element is that ‘use’ element.
    Otherwise, there is no context element.
  • If there is no context element and these keywords are used, then no paint is applied.

There's no mention about it applying to nested SVGs in image.

The current release of resvg does not have proper support for context-fill and context-stroke IIRC, that's why it shows up as black. It was only implemented recently, and it's available on main, but not on crates.io yet. If you run it from main, then no paint should be applied at all if there is no appropriate context element.

So while I understand your use case, I don't think we can just deviate from what the specification mandates.

@Dimon-II
Copy link
Author

This is not a deviation from specification. Content can be specified through any parent group.
It’s just that <image...> does not assume a fill/stroke, and calling an external SVG via <use...> is not implemented.

@LaurenzV
Copy link
Contributor

Oh, sorry. For some reason I assumed that you wanted to embed it via <image>. Yes, I guess if you include the file via use it should work. So the main blocker here seems to be that loading external files via use is not supported. Not sure if there is a reason for that.

@yisibl
Copy link
Contributor

yisibl commented May 30, 2024

@Dimon-II Have you tested it in Chrome Canary?

@Dimon-II
Copy link
Author

@Dimon-II Have you tested it in Chrome Canary?

In general, exact adherence to SVG specifications is not important to me. I use RESVG as a rendering engine in my project: a new feature appeared and I tried to use it, saw the restrictions and asked about the possibility of circumventing them...

@LaurenzV
Copy link
Contributor

I think it should be relatively straightforward to add support for loading files via use, since the infrastructure already exists for image. It's just I don't know why it wasn't implemented in the first place, either because simply no one has done it yet, or maybe there was a good reason. Only @RazrFalcon will know I guess.

@RazrFalcon
Copy link
Owner

RazrFalcon commented May 30, 2024

I'm not sure you can link an SVG file via use. You can link an element from an external file, but not the file itself. You are suppose to use image for that.

There reason why linking external SVG elements via use isn't implemented is simply because no one done it. And I'm sure it would require some extensive testing. It's way to easy too introduce recursion this way.

Basically, if it works in Chrome - then we should probably implement it as well. If not - then no one cares. The SVG spec is pointless anyway.

@Dimon-II
Copy link
Author

Dimon-II commented May 30, 2024

There reason why linking external SVG elements via use isn't implemented is simply because no one done it. And I'm sure it would require some extensive testing. It's way to easy too introduce recursion this way.

The previous engine (rsvg-convert.exe) I used supported <use...> references to external SVG parts (xlink:href="clipart.svg#Star"), but had other problems. Due to the rework on resvg, I was forced to create my own mechanism for embedding the SVG clipart into the main file at the time of rendering with renaming the links. With more recent support for external SVGs, this has been partially simplified, but it is often this color control that is missing.

It looks like this is a completely new feature in Chrome, I’m not sure if it works fully.
https://chromestatus.com/feature/5146558556536832

@RazrFalcon
Copy link
Owner

Just to clarify, are you expecting context-fill to works with SVGs inside <image/> or with external SVG elements referenced via use?

@Dimon-II
Copy link
Author

Dimon-II commented May 30, 2024

Just to clarify, are you expecting context-fill to works with SVGs inside <image/> or with external SVG elements referenced via use?

None of the options require changes to my program - just recommendations on how to use the icons more conveniently.

image - now supported in resvg, use of external SVG is not yet available. Therefore, all existing projects only use image. Additionally, it is easier for the end user to have individual SVG files in the clipart folder (and see them in the catalog preview) rather than confusingly combining them into clipart.
It may be required to use the entire SVG file, without accessing its elements - ready-made icons from the Internet are also one by file, not necessarily with named elements.

In addition, the image file is much more convenient due to automatic width/height scaling.

In my case, this is a simplification of the template. Right now I'm translating Lorcana game cards and I had to create separate black and white SVG files of the same icon and make different macros for them because can't share the color from the surrounding text / parent group.

@Dimon-II
Copy link
Author

I asked a question to one of the authors(Cameron McCormack) of the SVG specification - at the moment this task out of the specification.

Question:
Can I ask for clarification of the SVG specification?
I'm currently communicating with the developers of the rendering library. Situation - external SVG is displayed as an image.
I would like to be able to control the color of external SVG icons.
Currently, the image (containing a single path) is not displayed if fill="context-fill" is used in this file.
Is it possible to control its color? For use objects, context-fill / context-stroke support is provided.
Should this support be extended to SVG image? The image object itself does not specify a color, but the content can be obtained through a parent group.

Answer:
_context-fill and context-stroke were designed to take colors (or other paints like gradients) from outside and apply them inside the SVG. These were initially created for SVG glyphs in OpenType fonts, but the idea was that in the future they could also be used for other situations like e.g. SVG , or maybe even SVG images in HTML or CSS background-image. But the specification does not currently make these keywords work in those contexts.

So in summary: we (the SVG WG) wanted to support this use case, but we didn't get around to it yet. If an implementation did apply context-fill / context-stroke in these situations, that is not currently supported by the spec.

In good news, the SVG WG is being rechartered soon, so there will be a venue for requests to work on features like this._

@RazrFalcon
Copy link
Owner

Good. So everything is working as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants