I just moved from Windows/Visio to Macbook/OmniGraffle believing the hype that it was a Visio equivalent. Though happy with the UI, I am very surprised and dissapointed that no vector import SVG is supported; and the EPS when brought in has no transparent BG. This impacts my wireframing design process significantly! Please provide this support soon!
This was true until we shipped OmniGraffle 7.0 last month, which added support for basic SVG import:
- Basic SVG Import — SVG is now a supported file type that OmniGraffle can Open, Place, or drag onto the canvas. You can even paste SVG code directly on the canvas and OmniGraffle will convert it to the appropriate shape.
SVG is a huge spec, and we’re continually improving that basic support to encompass more and more of it. This week we shipped OmniGraffle 7.1 with these enhancements:
- Additional SVG support — Support for
<use>,<defs>,<transform>, stroke linecaps, groups, and corner radius attributes.
If you have feedback about which SVG features we should prioritize next, please let us know!
2 Likes
Me too felt the same. I think no matter what company/product is good or bad, Microsoft products do have best UI in the whole world. There is no harm in learning and applying.
I am a long time user of OmniGraffle and use it because it blows anything else out the water (including and especially, Visio).
The support for SVG is very poor (as of release 7.5) and I find that the majority of my SVG files do not import/export successfully into/out of OG 7.5. My recommendation is to use a vector PDF format which has worked very well for me in all cases. I exchange to/from Affinity Designer as PDF vector and it works flawlessly. I have also used others like Inkscape and it works very well also.
I try to avoid the bitmapped formats like PNG and friends in case I need to scale them.
Bottom line: SVG import/export is not yet ready for prime time. Don’t use it.
Ken, I like this offer except…
… I don’t think users can actually do this: They don’t know what the features are but rather what SVG files won’t render right.
I think you’re better off getting a basket of test cases that won’t render properly.
I’d gladly send in
- The raw SVG that wouldn’t render.
- A bitmap of how Omnigraffle rendered it.
- A bitmap of how it should look.
I really think we need to motor fast on improving the SVG import - as today it’s (sadly) not a terribly credible feature. And, as others have said, people are spending money on it.
Yes, I concur. I’m actually more concerned about the Export to SVG. I may be wrong but it definitely seems worse than 1 or 2 years ago. Fortunately I also have Affinity Designer but I forgot about @mattheys trick. I used it yesterday (export SVG from OG, clean up SVG by exporting from Designer) and all went well! So it’s definitely doable, but not by OG at at the moment.
@kcase Where I run into the biggest problems is with text. Actually I rarely/never run into problems with non-text. I’ve contacted support before and they confirmed problems with some fonts. But in a latest project I changed my font, exported, and still had some text problems. These are almost always spacing problems: too much space between 2 characters in some cases, too little in a much smaller number of cases. And this is using a generic font like Helvetica. But, again, if I export that SVG from Graffle, import into Designer, and then export as SVG again all works fine.
1 Like
That would be great, too. Thank you!
[quote=“mitchellm, post:6, topic:27853, full:true”]
Yes, I concur. I’m actually more concerned about the Export to SVG. […]
@kcase Where I run into the biggest problems is with text. Actually I rarely/never run into problems with non-text. I’ve contacted support before and they confirmed problems with some fonts. But in a latest project I changed my font, exported, and still had some text problems. These are almost always spacing problems: too much space between 2 characters in some cases, too little in a much smaller number of cases.[/quote]
That’s really good feedback, and it’s good news because I think we’ll be able to address most of those text issues with a single bug fix.
I believe most of these text problems stem from a single underlying issue. OmniGraffle currently goes through each “lay” of text (each portion of text that can be rendered without switching fonts and without adjusting text positions, i.e. for kerning or baseline adjustments) and draws those lays independently—because it wants to make sure each lay is positioned exactly where it was positioned in OmniGraffle.
There was a time where that might have made sense (it certainly made SVG output look better on early SVG renderers, which couldn’t kern the text themselves), but I don’t believe it makes sense anymore. Instead, we should just export the text as a single logical unit (with appropriate annotations for font changes, baseline adjustments, etc.) and let the renderer do its own positioning based on the font it actually ends up rendering with. This will also make the output respond much better in each target rendering context, where the exact text positioning may depend on the target device’s dpi (Retina screen or not), etc.
We’ll be working on this and other SVG improvements for OmniGraffle 7.7, which we’ll start working on in a few weeks and hope to have available for testing in early January.
1 Like
Then the best course of action is probably to test this to death in the 7.7 beta.
Remind us to do just that - as we might forget what we’re supposed to be testing. :-)
Ken: Thanks for the explanation. That helps a lot. I’m looking forward to the new and improved SVG export in 7.7. I do a lot of web design, and Graffle is perfect for creating certain kinds of SVGs (visual models, tables, etc.) so having it perform reliably on export would be fantastic.
Until then I’ll use the dynamic duo of Graffle and Affinity Designer.
As Ken mentioned, we’ve made some significant changes to SVG for OmniGraffle 7.7 and we’d love to know if these changes fix the issues you’ve had. OmniGraffle 7.7 is available as a public test build here: https://omnistaging.omnigroup.com/omnigraffle/
Dan: Thanks for the news re: the update. I have briefly tested it out. Overall the SVG export seems to be working much better. I will do more thorough testing next week.
However, I found one scenario where I’m consistently getting bad results: when bold text is used with plain text. In these cases the spacing ends up wrong. I’m attaching/uploading screenshots as I can’t upload the SVG itself. In some cases bold followed by plain text ends up with the space between eliminated. In other cases it seems a space or two is added inbetween.
I hope this helps a bit. Many many thanks for working on this! Already many Graffles I could not convert before (without going through Affinity Designer also) now work just fine.
How about now? Text with mixed style should work much better in build OmniGraffle v7.7 test (r303550) or later.
Dan: It is much better now! I also got a direct email from Omni support and provided more details but here’s a summary:
I am noticing now some smaller problems with bold text.
- In the document Course Schedule there is an extra space in this bottom text “Essentials for Teaching in Higher Education”
- In the document Statistical Significance under each of two tables look at “Note” in bold. It then has an extra space, something that looks like a colon (and should be a colon). The problem is the extra space between end of bold text and colon.
All put differently, the SVG export is now very useable for me. I really appreciate the improvement. But there are also some cases where it has slight problems.
I sent in example Graffle documents to the Omni support team. It really is quite useable now, though there are some edge cases where it doesn’t work well with bold text followed by plain text: Extra spacing instead of no spacing
Great! Thanks for the example documents!
I have plenty of SVG files, which looks great in quick look at Finder, but importing ugly to OmniGraffle!
