I have an SVG with two images. These images have feComponentTransfer applied to them.
For these images, color-interpolation-filters is set to linearRGB and sRGB, correspondingly:
http://jsfiddle.net/9eU37/6/
Here's how it renders in Safari and Chrome:
(linearRGB on the left, sRGB on the right)
Here's how PhantomJS renders it:
(linearRGB on the left, sRGB on the right)
As you can see, PhantomJS seems to ignore color-interpolation-filters (there is no difference between the two images). Another odd thing is that the resulting image matches neither sRGB nor linearRGB browser version.
Is there anything I can do it make it render SVG like the browser does, and respect the setting?
You can do your own gamma correction manually by using an feComponentTransfer type=gamma. Usually a 2.2 for the exponent will do it.
Related
I am trying to animate the SVG2 Geometry Property r, the radius property of a Circle Element.
I read that the property can be used as CSS property in browsers supporting SVG2 (see Resizing SVG Circle Radius Using CSS Animation).
Now I notice that animating r does only seem to work in Firefox if I express values as percentages. If I use absolute values, the circle is not being animated, see minimum reproduction CodeSandbox.
Does Firefox lack SVG2 support here?
As pointed out, stating lengths in pixel does the job.
The spec indeed says that absolute lenths must be given in physical units.
Omiting them will Chrome use px as fallback unit, while Firefox won't.
I have this inline SVG element. Some of its sub elements use image patterns. (In the attached photo, the SVG object is on the left and the image with correct color is on the right). A very strange greenish hue is affecting all image patterns and images in the SVG which have patches of white in the original images used. What could be the reason? I've already checked this both in Firefox and Chrome. Same problem shows in both browsers. I used SVG transforms (rotate, scale, translate) to manipulate the images but never a command to change the colors..
EDIT 2017-09-24 (screenshot in Safari) - Safari displays the correct color
I'm using several libraries to generate SVG images in-browser, which can be bounced off the server through svgexport to generate PNGs or JPEGs at user-specified resolutions. (This works as expected.)
I'd like to offer the user the option of downloading the SVG that gets fed into the conversion, with the resolution used to set the width and height attributes. When I do that, the viewbox is not scaled to the specified width and height, but is padded so that the image occupies the original size area in the upper left.
While looking for solutions, I found images in the W3C documentation that illustrate the problem. If you open these images in Chrome and use the inspector to change the width and height properties,
ViewBox.svg will expand to fill the width and height (linked from here)
PreserveAspectRatio.svg will be padded to stay in the upper left (linked from here)
This does not appear related the presence or value of thepreserveAspectRatio property, or the nesting of svg tags. My files are rendered as padded rather than scaled in Chrome/Chromium, Firefox, Safari/WebKit, Opera, Inkscape, and Gapplin.
How do I ensure that my SVG is scaled rather than padded to fill the width and height?
The viewbox is not scaled when it's entered as viewbox rather than viewBox; svg attribute names are case sensitive.
The second link does not have a viewBox attribute, and adding a viewbox (lowercase) attribute has no effect.
Does webkit/wkhtmltopdf not support icc-color profiles in fill colours in SVG images?
I have an image that has the colour defined as:
#e22e27 icc-color(U.S.-Web-Coated--SWOP--v2, 0.0558938, 0.95947204, 0.98716716, 0.00204471)
Which is supposed to come out red (and does in inkscape)
However, chrome (and other browsers) just open it as black (I'm guessing because it can't get the fill colour?) and also wkhtmltopdf also comes out as black.
Is there any way of doing this? Or more specifically is there any way of defining a device spot colour in the SVG so that the final PDF can have a spot red (rather than a composite of RGB)?
Thanks
if you open the SVG in Inkscape 0.92 after removing the sRGB value #e22e27 I expect you will see black instead of red. This is because even when using the CMYK colour picker, Inkscape reads and writes fallback sRGB values from/to the SVG file. Native CMYK support is still in Inkscape's future, as far as I can tell.
Among the open source PDF renderers, mPDF supports defining spot colours by CMYK values and also supports embedding a subset of SVG in HTML, suggesting that it can read some SVG syntax natively. This would be a better starting point for a fully open source solution than wkhtmltopdf which does not support CMYK output at all, according to issue #39 on its GitHub project.
Of the proprietary renderers, PDFreactor supports passing CMYK values from an SVG directly to the renderer as long as they are not rasterised, although the syntax does not appear to match the W3C SVG spec and there is no sRGB fallback, so each SVG has to be specially crafted. This is quite easy for simple graphics originated in Inkscape; just replace for example in your SVG:
style="fill:#e22e27 icc-color(U.S.-Web-Coated--SWOP--v2, 0.0558938, 0.95947204, 0.98716716, 0.00204471);fill-opacity:1;fill-rule:nonzero;stroke:none"
with the C, M, Y, K values only:
style="fill:cmyk(0.0558938, 0.95947204, 0.98716716, 0.00204471);fill-opacity:1;fill-rule:nonzero;stroke:none"
I've recently used this technique in an attempt to match colours between SVGs and CMYK values specified in CSS for the document, for example between logos and font colours. See CSS Color Module Level 4 for the emerging device-cmyk syntax; in the meantime PDFreactor uses the non-standard cmyk syntax for CSS, as shown in the SVG example above.
In general, I'm wondering about the value of embedding a colour profile in a natively CMYK SVG. Perhaps the assumption is that we are starting from an sRGB value and need an approximation of it, but in my workflow I'm starting from CMYK values. I'd welcome clarification on that. Besides, it would be rather time-consuming to re-create every SVG file just because the printing machine, continent or paper has changed.
I've placed an image on top of a div. I'm trying to blend the image into the div (The div is a solid color). In Google Chrome, it looks great! The colors blend perfectly. In IE 7, however, the colors show a hard line even though they should be the same color! After some examination (a print screen put into paint.net to check the actual RGB values), IE 7 is actually lightning up my image.
The blend has to look seamless. Google Chrome was fine with this thus far. Any ideas why IE 7 wont display the color right?
The two browsers are using different rendering engines. There are minor differences between them in how they render graphics, particularly jpegs.
The differences are minor but unavoidable.
Most of the time it goes unnoticed; it only makes an appearance in cases like yours when you try to position it against an element with a solid background colour that is supposed to be the same.
You may be able to resolve the issue by using a different image format. Try saving the image as a PNG. PNGs tend to be rendered more accurately between the browsers than jpegs, so that might be enough to solve your problem.
If that doesn't solve your problem, you could try using PNGs alpha transparency feature to produce an image with a fade to transparent at the edge, and then overlap the background colour behind it. This will definitely give you a smooth transition, but is a bit more technical, so harder to achieve. It will also give you problems with older versions of IE (IE6 for sure, I think you'll be okay with IE7), as they had some major bugs with PNG transparency. (If this is an issue for you, there are work-arounds for this; google IEPNGFix for more)