Illustrator Limitations and Workarounds

Top  Previous  Next

(Note: This topic needs to be brought up-of-date. Some of what's described here may not apply to more recent versions of Illustrator.)

 

I've noticed several issues with Illustrator's functions for reading and writing SVG's. All are annoyances that are easily worked around. They are listed below in order of decreasing significance.

 

Illustrator makes a distinction between layers and groups, whereas SVG doesn't. Consequently, a named layer or sublayer exported  to SVG  will always be brought back into Illustrator as a named group whether or not it was processed by Walls. Some Illustrator users might find this awkward because groups and layers behave differently. Fortunately, there are two solutions to this problem. For details, see Converting Groups to Layers.
Illustrator doesn't interpret a clipping region correctly when importing an SVG. The result is an image with the Y-axis reversed in direction. (Version CS2 doesn't reverse the Y-axis but a new unacceptable behavior is that it discards objects not entirely within the clipping region.) If it weren't for this limitation, all SVGs exported from Walls could be opened in Illustrator without difficulty. The simple workaround is to always turn on the adjustable option when exporting SVGs intended for Illustrator. The Y-axis reversal actually serves as a handy reminder in case you've forgotten to select this option when it was appropriate. For more details, see a note about this issue.
When reading an SVG, Illustrator CS2 is unable to properly handle symbols that are composed of other symbols. The result is missing or badly scaled symbol instances. Until Adobe fixes this, the workaround is to avoid such compound symbols, or to replace existing ones with new symbols that are fully "expanded" versions of the former. Since this affects only symbol definitions, file size shouldn't increase significantly. (Versions 10 and CS1 don't have this problem.)
Illustrator can write different variations of the SVG format as specified in the "SVG Options" dialogs. Unfortunately, if you open an SVG, make some changes, and then simply "Save" the file (which you shouldn't be doing anyway), you're not presented with this dialog; the original SVG is simply overwritten with a new SVG, one that reflects your current option settings and possibly having the wrong type. (See the above suggested settings.) A related issue, more a bug than a design flaw, is that if you open a compressed SVG file with extension .svgz, make changes and again simply "Save" it, the new version of the file will still have extension .svgz, but will be uncompressed. The workaround for both problems is to always write SVGs using the "Save a Copy" command on the file menu. Version affected: v10 (other versions not tested).
At least the CS1 version of Illustrator (not version 10) has a bug that causes symbol definitions and their instances to possibly be corrupted when an SVG is imported. The problem is that some attributes of a symbol, such as scale and rotation, are taken from the first-encountered instance rather than the symbol's actual definition. Therefore, to prevent this from happening with an adjustable SVG exported from Walls, a special layer (w2d Symbols) containing untransformed symbol instances is included so that Illustrator will properly reconstruct the symbol definitions. After opening the SVG you can safely delete the w2d Symbols layer while in Illustrator.
Some effects, like brush strokes and path-aligned text, will display correctly when an exported SVG is viewed. Walls will also adjust them properly. Unfortunately, such objects have a more primitive form in the SVG. When an SVG file is read back into Illustrator, whether or not it was processed by Walls, some objects may be in an "expanded" form with links to associated paths broken. This means that on the occasions where objects need to be edited (dome and drop lines, for example) you may want to either recreate them or copy them from the original AI source so their definitions can be easily tweaked. This issue is discussed under Adjustment of Brushed Strokes.
Path-aligned text exported as SVG and read directly back into Illustrator will also be transformed incorrectly (characters not rotated) due to a bug in the import function.  As a result, Walls not only adjusts but also reformats such text so that Illustrator can properly handle it. It's no longer editable as path-aligned text, but it should still look fine over the course of future roundtrippings. Although version CS2 offers a new export option, which is to save path-aligned text as SVG <textPath> elements, it's useless for roundtripping since Illustrator can't read these elements back in without "flattening" the text to individual, improperly aligned characters. For now you should avoid that option since it inhibits the Walls reformatting feature.
Illustrator CS1 (not  version10 or CS2) has a problem exporting text efficiently. By default it tries to position each character precisely using superfluous kerning adjustments, resulting in very long sequences of <tspan> elements that break up the text arbitrarily. The Walls merge/export routine tries to eliminate most of this by combining <tspan> elements into a fewer number of <text> elements. Another way to correct this in Illustrator, however, is to "select all", then open the Character palette (Window | Type | Character) and make sure that the kerning setting is "0" instead of "Auto". Version CS2 offers still another alternative, which is to select the new export option, "Output Fewer TSPAN Elements."
If the even-odd fill rule is set for a compound path in Illustrator, an exported SVG will have this style correctly specified. If Illustrator reads back the SVG, however, the style reverts to the default non-zero winding, which may or may not cause features containing compound paths to be displayed incorrectly. Since path directions can cause non-zero winding fills to have the same appearance as even-odd fills, the user might not notice this style change.  Illustrator versions affected: v10 (CS1 and CS2 not tested).
When reading an SVG file, Illustrator (v10 or CS1, but not CS2) unnecessarily increases the group nesting of certain elements, particularly symbol definitions. This means that successive exports and imports of Illustrator's own SVG files can create ever-deepening hierarchies of nested groups. (This is another reason to avoid opening Illustrator's own SVG files.) To counter this problem, Walls removes the extra nesting when processing symbol definitions in a source SVG. Also, with version 10 (not CS1 or CS2), simply opening an SVG file will add an outer top-level layer in addition to those created by earlier imports. Since Walls will preserve this extra layer, I prefer to remove it prior to saving the SVG from Illustrator 10. You can easily do this by targeting the superfluous sublayer and selecting Object | Ungroup.
This is not so much a program flaw as it is something to be aware of when you're assigning names to groups in the Layers Palette. In SVG, all names given to objects must be unique, regardless of their positions in the grouping hierarchy. This is not enforced while you edit a document in Illustrator. Therefore, when Illustrator saves your document to SVG format, it will append characters (e.g., "_1_") to any name that would match a previously encountered name. To avoid this, be sure to use unique names.
An item of interest only: The SVG files written by Illustrator versions 10 and CS reference to an undefined entity, ns_graph, in the header. This in turn causes version CS2 not to accept them: "This SVG is invalid. Validate it before opening." When such files are used as source SVGs, however, Walls will ignore this defect. This is all we require since as explained above we'll not be using Illustrator to open its own raw SVGs.

 

The following Illustrator issues might interest SVG users and developers in general, if not the Walls user:

 

The names of layers, groups, and most objects, including paths, are saved as XML id's during roundtripping. Any names assigned to text elements, however, are discarded by Illustrator (version 10 at least) when reading or writing an SVG. In an adjustable SVG export, Walls gets around this limitation by placing each text element (note or label) inside a named group.
Sometimes Illustrator inserts "garbage" in exported SVGs in the form of empty paths -- paths consisting of just a beginning point. Since these are never displayed, Walls ignores them when the files are read during merged exports. (There is also a command in Illustrator for cleaning these up.)
The SVG standard allows for a very efficient "dot" object in the form of a 2-point path whose points have the same coordinates. Dot thickness and shape are then determined by stroke style. Unfortunately, Illustrator "optimizes" them away by turning them into 1-point paths that are not rendered at all. As far as I know, the most space-efficient way to visibly mark a location in Illustrator's SVGs is to use a filled 4-point closed path. Walls uses this as the default marker symbol.
There is a problem with units (see note) that becomes an issue only when Illustrator's exported SVGs are shared with another drawing program.