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.
Related
he following banner is an example of what i want:
https://top.gg/api/widget/535064930727100427.svg
https://top.gg/api/widget/698275428976164945.svg
It's automatically generated and contains dynamic text which causes the "background color" to automatically adjust its size to it as well as have a border radius.
The text and shapes are all paths when I look at the source.
I would like to know how this has been accomplished as SVG itself does not support a dynamic border radius and background color by default.
Somewhere in the SVG source of the links above it showsid="surface19" and I did some research to see what piece of software or library provides such ID's. The text also seems to automatically be converted to paths, so it's not a hand-written SVG that gets modified programmatically from what it seems.
I did a lot of research before asking this question.
we are building an web application to design print products online. There are also some special finishes available for print. For example gold foil. There for we have to define the color in the final PDF in a specific way. It has to be a spot color with 100% magenta (c0 m100 y0 k0) and th color name "goldfoil".
In the design tool we are using a color with a hex code that is looking similar to gold in the browser (#9C9475). Our application is creating SVG that is converted via ghostscript to the PDF.
What I now want to achieve is to define a fallback or exchange color for specific hex colors like in this example #9C9475 that will convert this color in the PDF to the above described spot color.
Will this be possible? I found an article that svg 1.1 and above is supporting ICC Profiles and can produce CMYK and ICC named colors. In the documentation it says that I can define spot color in this way:
<color-profile name=„ISOcoated_v2_eci" xlink:href="http://swatches.example.com/ISOcoated_v2_eci.icc"/>
<circle fill=„#9C9475 icc-color(ISOcoated_v2_eci, Goldfolie"/>
But then I am missing the CMYK values.
Can somebody help me in this case?
Here is an SVG image I want to convert to PNG with librsvg in my program.
This is a PNG version of the SVG exported from Inkscape:
This is a bitmap of the same SVG exported with librsvg:
Only the white portions of the image are exported. The black portions, despite being well-defined in the background, appear transparent.
This problem occurs whether I use the librsvg API or the program rsvg-convert. You can use the W3 validator to see that the SVG's markup is valid.
I notice the same thing happens in the thumbnails of the SVGs in my file browser. Perhaps they're using librsvg?
Upon digging into the files I discovered that, for some reason, the fill of the black portion was set to "fill:currentColor". I don't know where that came from, but changing it to "fill:#000000" fixed the problem.
I know nothing about SVG. Even less about SVG fonts. However, I need to use them in my web project.
I've created a custom font with fontello and analyzed the format of the SVG file in a text editor. Then I opened an SVG file created with Inkscape (saved as plain SVG) and used its d attribute to create a new glyph in the font.
I couldn't believe that it actually worked ... well, almost ... the glyph appears flipped vertically. I have tried flipping it in Inskcape. However, when I save the file, the original d attribute is left as it was. It just adds a transform with a matrix that flips the coordinate system, but which does now work in the <glyph> tag.
Is there any way I could apply this transformation in the font file, or in Inkscape, to change the d attibute?
Thanks.
I found that, in Inkscape, ungrouping and then grouping the object applies the transformation to the coordinates.
I have an application that needs to apply some transformations to text (including non-affine transformations). Does anyone know of a toolkit (or group of tools) that would let me bring in a True Type or Postscript Font, get the glyphs as outlines, then apply transformations to the outlines and render it as a bitmap or svg file ? Flash won't do non-affine transformations so it is out. Illustrator has a function which converts text to outlines, but Illustrator scripting is very unstable so I can't really use it for this. Thanks for any help.
You could use the Batik TTF to SVG Font converter. The SVG font format uses the same path data format that the SVG <path> element uses.
For example, this is the output from converting Gentium Basic Regular using the above tool. With the right coordinate system, you can just grab out the path data, transform it however you like, and then draw it with a <path>. Note though that the glyph coordinate system in SVG fonts is actually inverted, with the (0,0) at the bottom left corner of the glyph cell box, compared to the regular SVG canvas which has (0,0) at the top left corner. So don't forget to flip the glyph, e.g. by putting transform="scale(1,-1)" on the <path> you use to render the glyph.
Once you have the SVG document that renders the glyphs as shapes you can convert it to a bitmap using your favourite tool. (Batik can do that too.)
While Batik is a good answer, it will convert only TrueType fonts to SVG Fonts. If you have OpenType fonts, and they more and more dominate now, you can use FontForge to get an SVG Font for these. Another advantage of using OpenType is that the produced SVG uses not only quadratic but also cubic Beziers in the path which is more effective.