SVG is a file format for scalable vector graphics. SVG 1.1 files may be opened by Ortelius directly from the Finder window, or imported through the Image Browser. SVG files are converted into Ortelius native files upon opening.
In the Image Browser, drag-and-drop SVG graphic to your drawing canvas just like you would an image. The SVG is added to the existing drawing and converted into an editable Ortelius graphic object(s).
HINT: The SVG may need ungrouped one or more times after import.
Open SVG Files Directly
Do one of the following:
- Choose ‘File > Open’ from the main menu and select and SVG file to open, or
- In Finder, right-click an SVG file and choose ‘Open With > Ortelius.app’ from the contextual menu.
Notes About SVG
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 more so 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 our 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 our 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 as a file icon.
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 maximize 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. If 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.