Ryan,

The interesting thing about SVG is that it can be used for both web and print graphics design without a need for conversion. The main lack for print graphics design are CMYK and spot colour support in SVG 1.1, which if I'm correct should be addressed in SVG 2.0. Unfortunately SVG 2.0 is dropping support for SVG fonts, which would have been the nail in the coffin of PDF otherwise. For a brief moment SVG was bound to be the choice of archiving around the world, but that was not in the interests of the companies that contributed to the standard. Just link your 14 MB hanyul opentype font for those 20 characters of Chinese to load or generate a separate font file for every page rather than embed it into the document (or maybe that can be done using base64 encoding). Sadly SMIL got dropped likewise. CSS animation is the bomb,... duh or javascript (if not blocked by the users that are fed up with agressive ads and CSS bloat).

However, the SVG standard still allows to be used for a single document type work flow for all 2d graphics design types. Multi page document types would be a great addition and to my idea could be fairly easily be incorporated by adding objects in page groups like is now done with layers. I guess that having layers and page groups would be more of a hassle as each page would need to have those layers embedded into their group and during saving as standard SVG they need to get separated into single pages as SVG doesn't do multi page docs. It's a pity I'm a lousy coder though if I'd started 8 years ago with it it might have been implemented by now and I been a better coder (I would think).

I can imagine that making links to pages and clicking them might unhide this page layer while hiding the active layer. Wonderful visions of multiple documents opened in one instance of Inkscape (joy) that can be tabbed, viewed in multiple open windows so you could select links on the other page etc.

CMYK is a nastier problem because as I understand it Cairo (the renderer) doesn't support that. I believe that the only feasible way is to make things in Inkscape, export a bitmap, import it into Scribus (because it doesn't support SVG filters) and have the 32 bit .png be converted to CMYK .tif if you actually need black (~140MB for A4 at 200 dpi). I'm not sure what happens to CMYK info that gets exported from Inkscape to PDF, though my business cards look pretty good, so it may actually retain the CMYK info. It may also have been converted by the printer, but as they were Chinese I didn't discuss much with them.

Both aspects have been a long standing wish from the graphics designers user base of Inkscape, but they are considered hard to implement or just not that sexy or both.

Personally, I've been using Inkscape for the past 8 years as a single work flow tool to create both print and web graphics. What is lost to many is that this is an enormous time saver for designers and it allows for a higher productivity. Or at least ideally. If anything I consider full CMYK support the main issue. If I only could sent my Inkscape document straight to a output device, I could dramatically cut my production time. In print, where many things need to be completed before the customer enters your office that would greatly improve the usability.