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:Flag_of_Europe.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.
I really need to see this addressed. I'm trying to use Illustrator to create SVG paths for my laser engraving software, but all svg files saved or exported out of Illustrator need to be scaled to 125% in order to engrave at the correct size. CorelDRAW and Inkscape are both able to produce files which open at the correct size in my laser software.
Allow us to set the resolution of SVG files saved (and make the default 96), and give us the option to set the svg dimensions to real units (mm/in).
Why has it taken 6 years to correct this simple issue?
Brennan Young commented
I've just been converting some SVG text to foreignObject (so we can have reflow, text spacing, superscripts, lists and whatnot). It occurs to me that if Illustrator is going to support the SVG standard "fully", it will also need to handle foreignObject, i.e. it will need to have some kind of HTML renderer/editor. (In theory, foreignObject can use "any" markup namespace). I consider HTML editing in Illustrator extremely unlikely to appear. But if Illustrator would just keep its fingers out of any foreignObject that would be nice. Further down the line, if there was a way to paste in some HTML markup, and have it come out as foreignObject in the SVG that would be even better, but it's been over five years since full SVG support was requested here.
Julie Galaise commented
What is the latest update on this situation?
Melanie Bass Pollard commented
This problems has needed solving for many years. None of my Adobe Stock Subscription images that use filters such as blur, drop shadow, gaussian blur, will export as SVG without rasterzing. which means they are useless for clean, responsive web design. Using the SVG filters that are available in the default is very limited and requires coding abilities within the effects panel since it is missing UI design. Even with the SVG filters defaults, often they still display with bitmapped effects that are not usable. I do not code and am not able to add that to my training list.
My only alternative is to simplify the design in Adobe XD OR train in free shareware Inkscape which has native SVG filters. Even if an entirely new Adobe program is created for SVG design, manipulation and export of the filters will be desirable. My other alternative is to migrate to Figma which has successful Neumorphic/filter effect success. I chose XD for the dev team because of the integrated Adobe products which I use daily (Illustrator, Photoshop, InDesign, Bridge and Acrobat). This vital Adobe requirement to provide robust tools for responsive web design is a must. Can Adobe please update the status? It appears to have stalled in 2018.
It is almost *THREE YEARS* since this thread was started. It's *TWO YEARS* since LM first commented about the SVG scaling problem caused by Illustrator's prehistoric adherence to using 72 ppi, which continues to erode the credibility of the program. So have any of these issues been fixed yet? Has everyone switched to Inkscape?
This sample SVG is not displayed correctly in AI:
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="375pt" height="374.999991pt" viewBox="0 0 375 374.999991" version="1.2">
<symbol overflow="visible" id="glyph0-6">
<path style="stroke:none;" d="M 0.0976562 -30.53125 L 0.0976562 -35.960938 L 15.363281 -35.960938 L 15.363281 -30.53125 L 10.371094 -30.53125 L 10.371094 0 L 5.089844 0 L 5.089844 -30.53125 Z M 0.0976562 -30.53125 "/>
<use xlink:href="#glyph0-6" x="112.089728" y="250.251688"/>
<use xlink:href="#glyph0-6" x="129.89876" y="250.251688"/>
It should look like TT, but only first T is displayed
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.