Fully support the SVG standard
Illustrator can not read every SVG file. Some it doesn't read at all, some are imported only halfway or just completely messed up. There are issues with <use>, especially when used in herarchies. e.g. this file: https://de.wikipedia.org/wiki/Europaflagge#/media/File:FlagofEurope.svg There are issues with groups and masks and there are issues when units are missing e.g. from stroke widths. Also: SVG can have several attributes which Illustrator will delete when opening. Fully supporting the standard will enable people to have a workflow based on SVG files.
Just a general status update. We are currently and will continuously improve SVG import support in Adobe Illustrator. We are currently working on solving the issues mentioned in this report. Please feel free to open new bug reports here on uservoice if you are experiencing additional/untracked issues.
Alec Rivers commented
I haven't fully read the thread so apologies if this was covered before, but:
>> If you have different proposals how to support 96 ppi CSS pixels not described above, let me know as well.
The way other applications support unambiguous units is to define the root <svg>'s width and height using "real" units (e.g. in or mm) and use the viewBox to remap that to whatever you want. E.g.,
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="8.5in" height="11in" viewBox="0 0 612 792">
<rect x="0" y="0" width="72" height="72" />
In this case having the real units in width/height and the user units specified by viewBox makes it absolutely unambiguous, and this file should display a 1" square on all programs regardless of their "native" DPI. I've arbitrarily used 72 user units per inch here, but it could be 72, 96, or 123, and still be unambiguous in terms of real measurements.
Inkscape now (since v. 0.92) writes SVGs using this approach by default. It seems to me that if Illustrator started exporting SVGs this way too, it wouldn't break any existing files, and it would make importing those files into other programs, or back into Illustrator itself, also work correctly. Dirk, do you think that would work?
Brennan Young commented
Regarding the use of AI as a dedicated SVG editor, and the possible compromises for other AI features, I would draw attention to the way that Photoshop can operate in various color modes (e.g CMYK, grayscale, RGB...) and in each mode, various editing features are disabled, or modified.
Crucially, if you open an image with a CLUT, Photoshop puts the GUI into indexed color mode automagically. When opening certain file types, Photoshop even asks the user to clarify how the image should be handled.
I know SVG-in-AI is a little different, but my point is that the idea that the GUI can be in a format-specific editing mode is already a precedent which graphics professionals (and creative cloud users) will be familiar with, so it need not be a huge paradigm shift
Perhaps a way to constrain the illustrator UI to SVG-native features would help? e.g. if you open a SVG, you're in SVG mode, or perhaps you check a 'SVG mode' checkbox somewhere, then if you try to apply a non-SVG feature AI warns that it may not turn out as expected unless you save as an AI file. Something like that.
yang xiaobai commented
It is known problem with adobe products to have buggy SVG support. I suggest you trying opensource inkscape to open it in vector and export in any kind of formats .
Several years ago I took time out from photography to learn about & work with Illustrator . I made about 100 vectors, most of which are on my port.
If you has a decent computer with illustration software Illustrator / inkscape , you can use a XP-Pen Graphics Tablet ( https://www.xp-pen.com) .
Even though you can define text alignment to center or right in Illustrator, problem is when exporting SVG, the alignment setting will be removed and replaced with absolute transform/translate position (using the default text alignment) instead of being converted to text-anchor property of SVG specification. This leads to misalignment of text which is supposed to be aligned to center or right after uploading to Wikimedia because the fallback font has different font metrics than the pre-defined font in the SVG file and the fact that text rendered by librsvg usually looks misaligned when scaled.
This issue is not an excuse to convert text to outline because of the inconvenience of localization for other contributors.
Adobe Illustrator doesn't export text alignment attribute to SVG at all.
Text-anchor setting (left, middle or right aligned) does not come through and it is always left aligned, although the position might seem like it is middle or right aligned. Once you choose a different font or font-size, or will try to add some new text - the mismatch between the original text align and what Illustrator has made of it becomes very apparent and cant be adjusted. Just manually. Coding and calculating an axis shift in SVG file with text editor...
Wold be great if Ai starts to export text with FULL attributes and with coordinates according to text align mode in Paragraph menu.
Lets type any text - just "11"
x axis coordinates for example 1542,35 text align: Center.
Lets Save as SVG and...
In svg file there is NO alignment attribute at all, and x coordinate is 1535.7031 instead of 1542,35
<path id="path13" style="fill:none;" d="M1470.5,667.6H1615v68.2h-144.5V667.6z"/>
<text id="text15" transform="matrix(1 0 0 1 1535.7031 714.1688)" style="font-family:'GraphikLCG-Regular'; font-size:33.0px;">11</text>
JL Garcia commented
Hi Mr. Dirk Schulze, I read what you said about SVG and ppi at 96px below:
"Illustrator treats both, pixels and points, as 72 ppi. Illustrator has been around for more than 30 years."
and I would like to solicit if I can, adding a selection for the ppi, not just 96 or 72, but another number like 100 or something else. I understand that pixels have no meaning when using vectors, but sometimes we need to export some vector format and it would be fantastic to be able to choose the resolution we are working on inside illustrator since the beginning.
Seriously, simply opening an pre-created SVG file in Illustrator, bloats the code! Illustrator destroys the ovals/circles of SVG code. There must be an enormous refinement of the SVG code Illustrator exports, especially if you're giving the SVGs to developers (who will mock the SVG code Illustrator creates).
Thanks a lot for the feedback Nick! We will review it and add it to our backlog.
Yes, I think a simple adjustment of the dimensions written into the file would suffice as a first-step solution.
Here is the header from an SVG exported from an AI file containing a 4in x 4in artboard:
x="0px" y="0px" width="288px" height="288px" viewBox="0 0 288 288" style="enable-background:new 0 0 288 288;"
Importing this into Madcap Flare results in an image being placed that is only 3" x 3" (i.e. 72/96 of the correct size). A quick test, by manually editing the SVG file, suggests it is the "width" and "height" values that must be scaled by 96/72 (=384). So entering 384 as the width and height causes the SVG to be placed/presented correctly as a 4" x 4" image in Madcap Flare. Changing these "presentation" dimensions in the header does not affect any of the numerical dimensions (absolute or relative to each other) of the actual drawing objects within the SVG file.
If we provide the option to scale the content to 96ppi, would you be hostile to the idea to simply adjust the viewBox attribute to match the 96ppi from a CSS pixel?
As said, beside reopening an SVG file into Ai, the main concern is about rounding fractions of horizontal or vertical dimension values like path segment coordinates, x, y, width, height and so on. If we adjust the viewBox, this issue would not rise.
Dirk: Many thanks for looking into this problem.
Firstly, I think many people who have noticed the 72/96 ppi issue will also understand that exporting from Illustrator AI to SVG is a one-way process. As with any file type, we do not expect to preserve every detail or feature if we choose to export the file to a different format. Personally, I always keep my source files in AI format, and export to SVG for my target application (Madcap Flare).
With this in mind, the first and most important step is to provide a scaling option in the SVG output dialog. It might provide radio-button options like this:
* 72 ppi: Maintains precision if SVG is re-imported into Illustrator.
* 96 ppi: Compatibile with modern applications, but loses precision if re-imported into Illustrator.
I believe this option would satisfy the demands of most users facing the 72/96 scaling issue. Illustrator would use 96 instead of 72 to calculate (or modify/rewrite) the bounding box dimensions written into the SVG file. It would be important that the 72/96 selection was remembered by the SVG output dialog, just like the other settings.
As for the ability to "round-trip" SVG files through Illustrator, I guess people who need to work purely in SVG format, and the CSS standard of 96ppi, will have to select a more modern tool such as Inkscape, which uses 96ppi as its default.
@LM @NickA is right that there is a difference between 72 ppi (CSS points) and 96 ppi (CSS pixels). It is not as easy to fix the issue as it seems at first though.
Illustrator treats both, pixels and points, as 72 ppi. Illustrator has been around for more than 30 years. Far longer than CSS which introduced this difference. There is a lot of content that either uses pixels or points as document/font units. We can not simply support 96 ppi pixels internally and one reason is the huge amount of existing .ai content.
At the same time we want to support SVG as good and as interoperable as possible. And here again, there is a lot of content that gets exported to SVG but never targets other applications or use cases than Illustrator. All documents that get saved/exported as SVG may get imported again. As a matter of fact, a lot of users want to import SVG documents back into Illustrator.
Should we support 96 ppi CSS pixels on export we may need to treat content (and CSS pixels) with 96 ppi on import as well and transform them to the 72 ppi Illustrator space. This introduces a couple of problems:
* Numbers get stripped on export and precision gets lost. This may be most noticable when 2 shapes get drawn right next to each other. Gaps might start appearing between the two space that haven't been there before. Or shapes start overlapping.
* We can not distinguish between previously generated SVG content that assumes 72 ppi and new content that assumes 96 ppi. Either the 96 ppi asuming content or the 72 ppi assuming content will get imported incorrectly.
* Transforming from 72 ppi to 96 ppi on export will create fractions on all length values (x, y, width, height, cx, rx, ...) and path segments. So 17pt get to 22.8959...px. Customers previously told us that this is not acceptable.
* Transforming from 72 ppi to 96 ppi on export and back to 72 ppi on import will not necessarily give the same values back after import because of rounding issues described above. Especially on text you will start noticing differences where text chunks are not aligned vertical correctly anymore or kerning betwen characters will start looking weird.
At the end, SVG is a vector format and can get scaled into any bounding box. Since units in Illustrator are consistent within the document, the exported SVG file work as expected in web content. That is why the majority of web developers do not notice the difference today.
Please let me know if, despite the issues explained which will affect all application workflows as well (even Illustrator <-> InkScape), you would still be interested into exporting with SVG at 96 ppi for pixels.
If you have different proposals how to support 96 ppi CSS pixels not described above, let me know as well.
M. H. van der Velde commented
I noticed that when using SVG generated outside of Illustrator, it seems not to be allowed to use "link" as a class name and target for styling. Re-naming class of my line-elements to 'edge' solved the issue.
I believe there is a series of rules on class-names Illustrator needs for CSS to function. It's slightly off-topic, but is there such a list of rules available?
@McKillip: From my own investigation, I can confirm that Illustrator sets the bounding box pixel dimensions (the first dimensions seen in the SVG file) using a 72 ppi scaling. So a 10" wide artboard will produce an SVG file with the first width setting in the SVG set to 720px. This is a silly and very old-fashioned default scaling, since most other modern applications display/scale SVGs using 96 dpi . This means each SVG produced by Illustrator appears to shrink when imported into almost any other modern application. It would be ridiculously easy for Adobe to add a 72/96 ppi option in the SVG export options so it does its calculation correctly - with the default set to 96!
Hi @Dirk! This thread of comments seems to be pretty detailed, and I'm not sure if the problem I'm having is covered under it or not.
My issue is that when I save a file as an SVG, send it to someone else, and they open it in Inkscape- it doesn't open to the correct size.
I tried both "save as" to SVG and "export as" SVG, and the results are the same. Also tried checking and unchecking the "responsive" box since some people online suggested that to make a difference.
But no matter, it always opened 33% smaller in Inkscape than it was supposed to.
The only resolution in the end was that I had to re-save all my files in illustrator to be 33% larger before sending them.
Then, when opening them in Inkscape, they shrunk 33% to the correct original size.
I've searched online, and found no solutions, but there are some old threads where some people have tried to explain it as being a dpi problem, or say it's generally just un-solvable.
But- I remember saving svgs and sending to Inkscape for some projects a few years ago (maybe around 2014) and I don't recall having this issue.
I looked through the reported bugs and couldn't find one that sounded like this issue, but if it's something that hasn't been flagged yet, I'm happy to post an official request.
Hi Monika, Martin, Francisco, Ruth, Alec and others,
I am answering to some of the comments below. In general, please open separate issues for individual issues you see in Adobe Illustrator. Even if they all are related to SVG.
@Monika The Adobe Illustrator 2019 release fixes the issue that you see with the linked SVG example. The one with the flag of the EU. There should no longer be warnings about maximum nesting levels and the layer tree should look much flatter than it used to. We also fixed a few issues with masks.
@Alec The Adobe Illustrator 2019 release has support for the fill-rule property of SVG. Your example should import correctly now. We still have some work to do with masks though we did fixes here as well. Gradient and pattern transforms should import in general though we will improve support even more in future releases.
@Rith and @Martin Adobe Illustrator does not draw strokes in the coordinate space of the object as defined by Postscript or SVG. This causes the difference between the stroke width that you see in Adobe Illustrator on import and other SVG viewers. We will continue to improve the import further in future releases.. In general, the rendering model differs which causes the visual differences at the moment.
@Francisco Adobe Illustrator does not support import of images in SVG of formats other than raster images. Neither for embedded images with dataURLs nor linked images.
SVG support is terrible, we create SVGs in Affinity Designer & Sketch in our studio - both programs play nice with each other, and can open and edit SVGs created by the other. Illustrator on the other hand does not.
Francisco Isidori commented
Illustrator does not support my SVG file that contains SVG Image elements.
<image id="Asset-1" xlink:href="asset-1.svg" ...></image>
<image id="Asset-1" xlink:href="data:image/svg+xml;base64,PD94bWwgd.......></image>
It just doesn't show the images that are .svg (works with png). Other SVG viewers don't have problems with this.
Martin Schoch commented
regarding SVG I encountered the following issue in Adobe Illustrator: When defining a pen with a “stroke-width” in the “style” section of the SVG transformation are not applied to “stroke width”.
Definition of Pen:
<g transform="matrix(3.12112 0 0 3.12884 165.161 945.581)">
<path d="M512.705,258.049 A184.000,241.500 0.000 1,0 512.724,740.951" fill-rule="nonzero" class="Pen0"/>
<polyline points="502,258 998,258" class="Pen0"/>
This issue does not occur in other SVG viewers or Web browsers. There the stroke-width is transformed / scaled correctly.
Don’t hesitate to contact me if you require test files to reproduce the issue.
Thanks a lot for your feedback Ruth! It would be great to hear more about the stroke-width issue that you run into. I tested this minimal example:
<rect x="10" y="10" width="100" height="100" style="stroke:black;fill:none;"/>
<rect x="120" y="10" width="100" height="100" style="stroke:black;fill:none;stroke-width:1"/>
<rect x="230" y="10" width="100" height="100" style="stroke:black;fill:none;stroke-width:1px"/>
<rect x="120" y="120" width="100" height="100" style="stroke:black;fill:none;stroke-width:10"/>
<rect x="230" y="120" width="100" height="100" style="stroke:black;fill:none;stroke-width:10px"/>
but all stroke-width values compute correctly after opening in Adobe Illustrator. Could you please post a short example here? Or, for bigger files, it is also possible to use firstname.lastname@example.org
Thanks a lot in advance!
Ruth Ivimey-Cook commented
For me, the stroke-width issue has caused much wasted time. The svg file has a sequence of <g> elements, none nested, and no complex transforms, but nevertheless lines are imported massively over-wide. I know PostScript can do all these transforms and more; why is it so hard for Illustrator to support import.
Re Dirk: for me, the requirement is just that the graphic imports with properties correct and, if there are aspects of the import that cannot be imported properly I am informed in a useful way. Eg:
File X.svg has been imported with the following issues:
* Repolarising the crystals is not supported, line 203
* Transparency cannot be combined in groups, line 554
* Comments in the source have been ignored, first-line 2