Scalable Vector Graphics (SVG) is an open-standard vector image format for two-dimensional graphics. SVG graphics are available from many sources, and here we show how to import and edit a graphic from OpenClipArt.org, a free and public domain source of SVG clip art (Mapdiva is not affiliated with OpenClipArt.org).
The Image Browser provides quick access to your iPhoto, Pictures folder, and Smart folders, and you can attach other folders as desired. Import PNG, JPG, non-editable PDF, and TIFF images as well as vector SVG files into your Artboard drawings. Imported SVG are fully editable vector graphics.
Images can be masked, cropped, scaled, enhanced, and more! See Working With Images for details.
To Open the Image Browser:
Do one of the following:
- Click the Image Browser icon in the toolbar.
- Choose File > Image Browser from the menu.
To Import Images from the Image Browser:
- Drag images from the Image Browser directly to your drawing canvas. If an image is larger than the drawing canvas size, it will be scaled to fit the canvas (though can be rescaled in the Geometry panel).
- Select a root folder or iPhoto folder to browse images.
- To add folders, click the “+” button and navigate to the folder to browse, or to remove a folder from the list, select it and click the ‘-‘ button.
SVG 1.1 files are editable vector graphic that can be ungrouped and edited in any way you wish. Objects can be saved as clip art and/or symbols.
To Open SVG Files:
In addition to the native file format, SVG 1.1 files are now supported. SVG files are converted into native files upon opening and can be saved as such.
So one of the following:
- Choose File > Open from the main menu and select and SVG file to open.
- In Finder, right-click an SVG file and choose Open With > (app) from the contextual menu.
To Import SVG Files:
- Similar to images, simply drag editable vector SVG 1.1 files from the Image Browser to your drawing canvas.
- Ungroup as needed to edit.
Important Notes About SVG Import:
It is important to understand how the SVG 1.1 standard is implemented, since in some cases results may differ from another product.
Mapdiva’s concept of graphic styles is rich and deep – substantially moreso than the classic “stroke and fill” concept of Postscript, which SVG largely mimics. Thus when importing SVG, we need to build graphic styles that match as closely as possible this simpler concept. By and large there isn’t much difficulty, but in some cases results will differ, because of a mismatch between the two approaches. This is most evident with gradient fills and pattern fills. Usually, these will work as expected and the visual result will be what you expect, but as we don’t strictly support the concept of SVG’s “global” (user space) gradients, for example, when we encounter such a style, we do our best to translate it to something meaningful that gives similar visual results.
The SVG 1.1 standard is implemented, and ignores any and all non-standard comments that other applications frequently use to “help out” when parsing SVG. This can be another source of discrepancy between interpretation of an SVG file, and another application’s. This is particularly problematic with files created by Inkscape, a popular open source application, since that heavily salts its SVG files with comments only it understands, and are not part of the SVG standard. The resulting files may fail to open entirely as expected, though in practice we find we do get good results most of the time.
Mac OS X includes an SVG parser as part of WebKit and QuickLook uses this to preview SVG graphics in the Finder and elsewhere. We don’t rely on this parser, but implement our own in order to convert SVG objects to equivalent vector objects and styles, not simply to render the graphics as an image. In some cases, the QuickLook parser fails to render an image at all, yet the file will import just fine. At other times, the small differences in rendering mentioned above may be evident.
The Image Browser uses its own parser to render the thumbnail previews for SVG files, so what you see in the Image Browser is what you get when you import the file. Our parser is not just rendering the graphics however, it is converting them to objects, then creating the image. This makes it slower than a pure SVG renderer such as QuickLook. The Image Browser therefore creates each thumbnail image asynchronously using a background thread, and as each conversion is completed it “pops” into view. Subsequently the image is cached on disk and will be displayed quickly. Therefore expect a folder full of SVG graphics added to the Image Browser to take a while to process the thumbnails at first. We also recommend keeping the number of files in a folder down to something reasonable (a few hundred, say) to avoid the thumbnail generation going on for extended periods which could interfere with your workflow.
Sometimes an SVG file may fail to import. This can be for many reasons, such as bad data in the SVG, unsupported elements, missing external resources, or simply because the import takes too long due to the file being very complex. In the Image Browser, you’ll see such failed imports displayed with an Error icon.
About SVG Import Errors:
Such failed imports are reattempted next time the Image Browser is shown. When dragging and dropping an SVG into your drawing, a failed import will cause the drag to “spring back”. When opening a file using Open…, an error message is shown.
Imports that timeout may sometimes succeed if tried again. Usually a timed-out import indicates a graphic that would be too complex to give reasonable performance subsequently. There are several possible reasons for this:
• A very large number of paths
• Paths having extremely large numbers of points
• Heavy use of blur filters
• Heavy use of shadows.
When creating SVG graphics, it is very easy to assume that objects can be duplicated and reused at will. Unfortunately, that is often not the case. We have seen many cases of SVG artwork where objects have been repeatedly duplicated and yet effectively contribute nothing to the finished graphic. If such hidden objects have blur filters applied, or shadows, then a huge performance penalty is being incurred for no good reason.
Frequently, paths can be combined into a single object and have a shadow or blur applied just once in order to maximise performance. Giving performance some thought when creating graphics can make life much easier later.
An occasional source of difference between our applications and another SVG application is with text rendering. SVG does not embed the fonts it refers to, so if an SVG file references a font that is not available on your system, we will substitute Helvetica of the same size. Other SVG parsers sometimes just give up or skip the text when this font problem is encountered. While we try to plough on, obviously the results may not be what you expected. I you want to use a fancy font in a graphic, it is good practice, once you’re done editing the text, to convert it to a path so that this font problem won’t be an issue. Note that this does not apply to PDF export, since PDF does embed the fonts it references.
When we import SVG text elements, we convert them to a graphic, for best visual fidelity. That means the text can’t be edited as text, though the graphical paths can be.