Tuesday, October 27, 2009
New Silverlight PDF Library
Our friend Greg Salzman from Aleyant Systems has created an open source Silverlight PDF library project. SilverPDF is based on two excellent open source projects: PdfSharp and iTextSharp. Download and contribute to the project at on Codeplex, here.
Wednesday, August 12, 2009
Mimeo and SlideRocket: Printing In The Cloud
A great example of Rich Internet Printing is the collaboration between my company, Mimeo.com, and SlideRocket. In this case, our two companies had to work together to invent a way that Sliderocket presentations could be professionally printed by Mimeo. SlideRocket is part of this new generation of RIAs. It is a Web 2.0 online presentation application that allows users to produce slideshows that have some advantages over creating presentations in desktop applications like Microsoft PowerPoint. SlideRocket runs in a web browser, instead of requiring the installation of software on your computer. It features collaboration tools that let users share slides and other assets (like graphics and movies) between presentations. Because the application is Internet-based, these users can be geographically dispersed and still share nicely. This collaboration, and user-generated content sharing, is what makes SlideRocket a unique and powerful Web 2.0 application. The company recently announced that Chuck Dietrich, former VP GM at Salesforce.com, joined the company as CEO, see the TechCrunch article here.
The SlideRocket relationship with Mimeo involved the use of the MimeoConnect SOAP API technology. This is a set of Web Services that let partners submit files, define product intent, get quotes and proofs, and submit orders, recipient addresses, shipping methods and payments. This technology solves the problem of delivering content files and placing orders; primarily the communication between our two applications in the cloud (i.e., cloud to cloud).
With that connectivity in hand, we then needed to solve how SlideRocket would take their rich content (screen-based Flash presentations) and turn it into PDF files to send to Mimeo (this was a Mimeo requirement, due to our automated PDF-based production workflow). Finally, we needed to create a way to let the non-technical SlideRocket user to specify the product intent to communicate to Mimeo for manufacturing.
To solve the former problem, SlideRocket created a server-based application that “printed” the “slide deck” to a PDF file. To solve the latter problem, Mimeo created a special interface designed to reside within the SlideRocket Flash application. When the user chooses “Print” from the SlideRocket menu, they can either choose to print on their local printer, or print “high quality with finishing options” via Mimeo.
The interface we built incorporates a subset of Mimeo’s new photo-realistic document viewer. We call it MimeoProof, because it is about as close as one can get to holding a print product in their hands by viewing it as an image on the screen. The Sliderocket version lets the user see their presentation, visually depicting paper stocks, covers and binding choices. This is an important part of helping the non-technical user specify product intent, it gives them the confidence they need to proceed with the order.
Once the user places their order on the SlideRocket site, e-commerce and print-specific transactions flow: we are sent a PDF file containing the slides, and an XML transaction containing the order information (desired quantity of books, destination, shipping method, etc.) The next day, or at some point in the near future depending on the user’s choice, a beautiful bound version of the Sliderocket slides shows up on the user’s doorstep in whatever quantity they specified.
The SlideRocket relationship with Mimeo involved the use of the MimeoConnect SOAP API technology. This is a set of Web Services that let partners submit files, define product intent, get quotes and proofs, and submit orders, recipient addresses, shipping methods and payments. This technology solves the problem of delivering content files and placing orders; primarily the communication between our two applications in the cloud (i.e., cloud to cloud).
With that connectivity in hand, we then needed to solve how SlideRocket would take their rich content (screen-based Flash presentations) and turn it into PDF files to send to Mimeo (this was a Mimeo requirement, due to our automated PDF-based production workflow). Finally, we needed to create a way to let the non-technical SlideRocket user to specify the product intent to communicate to Mimeo for manufacturing.
To solve the former problem, SlideRocket created a server-based application that “printed” the “slide deck” to a PDF file. To solve the latter problem, Mimeo created a special interface designed to reside within the SlideRocket Flash application. When the user chooses “Print” from the SlideRocket menu, they can either choose to print on their local printer, or print “high quality with finishing options” via Mimeo.
The interface we built incorporates a subset of Mimeo’s new photo-realistic document viewer. We call it MimeoProof, because it is about as close as one can get to holding a print product in their hands by viewing it as an image on the screen. The Sliderocket version lets the user see their presentation, visually depicting paper stocks, covers and binding choices. This is an important part of helping the non-technical user specify product intent, it gives them the confidence they need to proceed with the order.
Once the user places their order on the SlideRocket site, e-commerce and print-specific transactions flow: we are sent a PDF file containing the slides, and an XML transaction containing the order information (desired quantity of books, destination, shipping method, etc.) The next day, or at some point in the near future depending on the user’s choice, a beautiful bound version of the Sliderocket slides shows up on the user’s doorstep in whatever quantity they specified.
Sunday, July 12, 2009
A Visit to Google Makes Us Think...
David and I recently went to a breakfast at Google’s cool offices in NYC, at Chelsea Market. Here is some good info on the Google presence in NYC.
The event focused on Google Enterprise Apps, co-sponsored by venerable NYC IT consultants BlueWolf. Kristin Shevis, Google’s Director Northeast Google Enterprise presented, along with several other Google and BlueWolf staffers. Really good turnout, looked to me like about 100 companies present. Obviously a hot topic. A couple of excellent case studies were presented, with a focus primarily on cost savings. In addition to the formal case studies, during Q and A, several members of the audience actually answered questions from other attendees, primarily about enterprise Google mail services. It didn’t appear that anyone in the room had actually deployed non-email apps on an enterprise basis (i.e., instead of Microsoft Office)… but there was great interest. The applications are still pretty basic, but for a lot of uses, they are quite adequate.
Google documents are about collaboration. As an outside observer, beyond the cost savings, this is the primary advantage in using Google Apps. Google documents can be edited by more than one person simultaneously (actually, up to 10 people, according to Google); Spreadsheets can be edited by up to 50 people simultaneously; they can also be shared with up to 200 collaborators and viewers. Presentations can be edited by 10 people simultaneously, out of a total of 200 who can be either collaborators or viewers.
Which led David and I, during our fifteen-block power walk back to Mimeo’s NYC headquarters, to discuss some of the challenges that might be faced in professionally printing Google documents, which are “dynamic” for lack of a better word. How do you print a dynamic, collaborative document? It is clear that while the Google apps are not particularly competitive with “desktop” applications right now, someday they will be, and in the foreseeable future. Formatting is pretty weak in Google Apps right now. Control of printing is even weaker, which is somewhat surprising because it does appear in other areas that Google has some sophisticated technology for handling PDF files. I hope someone is thinking about this at Google, because there clearly will be a need for professional printing in years to come, it isn’t going to be eliminated by these collaboration tools— demand will increase for many document types coming out of these apps.
Furthermore, what does the new document model look like? I ask this because Google is not the only company working hard to put document creation, collaboration and management “in the Cloud.” There is, of course, the upcoming Microsoft Office 2010, which recently got some splash in the media and apparently, according to hype, will be a focus at WPC09, Microsoft’s Worldwide Partner Conference, which begins on Monday July 13th, in New Orleans; click here for the details.
Online office suite developer Zoho announced a couple of weeks ago that they have created a seamless API integration with Microsoft SharePoint, which I haven’t had a chance to look at in depth yet.
We will be looking at all of this very closely here, and would love to hear your thoughts on these new developments.
The event focused on Google Enterprise Apps, co-sponsored by venerable NYC IT consultants BlueWolf. Kristin Shevis, Google’s Director Northeast Google Enterprise presented, along with several other Google and BlueWolf staffers. Really good turnout, looked to me like about 100 companies present. Obviously a hot topic. A couple of excellent case studies were presented, with a focus primarily on cost savings. In addition to the formal case studies, during Q and A, several members of the audience actually answered questions from other attendees, primarily about enterprise Google mail services. It didn’t appear that anyone in the room had actually deployed non-email apps on an enterprise basis (i.e., instead of Microsoft Office)… but there was great interest. The applications are still pretty basic, but for a lot of uses, they are quite adequate.
Google documents are about collaboration. As an outside observer, beyond the cost savings, this is the primary advantage in using Google Apps. Google documents can be edited by more than one person simultaneously (actually, up to 10 people, according to Google); Spreadsheets can be edited by up to 50 people simultaneously; they can also be shared with up to 200 collaborators and viewers. Presentations can be edited by 10 people simultaneously, out of a total of 200 who can be either collaborators or viewers.
Which led David and I, during our fifteen-block power walk back to Mimeo’s NYC headquarters, to discuss some of the challenges that might be faced in professionally printing Google documents, which are “dynamic” for lack of a better word. How do you print a dynamic, collaborative document? It is clear that while the Google apps are not particularly competitive with “desktop” applications right now, someday they will be, and in the foreseeable future. Formatting is pretty weak in Google Apps right now. Control of printing is even weaker, which is somewhat surprising because it does appear in other areas that Google has some sophisticated technology for handling PDF files. I hope someone is thinking about this at Google, because there clearly will be a need for professional printing in years to come, it isn’t going to be eliminated by these collaboration tools— demand will increase for many document types coming out of these apps.
Furthermore, what does the new document model look like? I ask this because Google is not the only company working hard to put document creation, collaboration and management “in the Cloud.” There is, of course, the upcoming Microsoft Office 2010, which recently got some splash in the media and apparently, according to hype, will be a focus at WPC09, Microsoft’s Worldwide Partner Conference, which begins on Monday July 13th, in New Orleans; click here for the details.
Online office suite developer Zoho announced a couple of weeks ago that they have created a seamless API integration with Microsoft SharePoint, which I haven’t had a chance to look at in depth yet.
We will be looking at all of this very closely here, and would love to hear your thoughts on these new developments.
Monday, June 15, 2009
Flash/Flex: Printing to the Cloud
When David and I were doing the research for a paper we recently wrote, I came across the Adobe online documentation for Flex printing, which can be found here.
There are several classes discussed there: FlexPrintJob, which prints one or more objects and can split large objects for printing on multiple pages and scales the output to fit the page size. PrintDataGrid is subclass of the DataGrid control with a default appearance that is customized for printing. The class includes properties and a method that provide additional sizing and printing features. PrintAdvancedDataGrid is a subclass of the AdvancedDataGrid control with a default appearance that is customized for printing. The class includes properties and a method that provide additional sizing and printing features. FlexPrintJobScaleType defines constants used in the FlexPrintJob addObject() method.
These classes give the Flash/Flex developer control over how print can be generated from within the application. As one would expect from Adobe products, the output is designed to be directed to PostScript and "non-PostScript" printers.
While there is no native way direct the resulting print stream to the cloud, David and one of Mimeo's developers, a Flash/Flex guru Brad Johnson, came up with a way to accomplish this. An efficient and powerful (as well as simplified) way to print from the Flash/Flex platform would be to enable the developer to use the same mechanism and code path to print to the cloud as they can use to print locally today (e.g., like in the above example and described in Adobe documentation). In Flex 3 (at this writing, the latest iteration of the technology), the developer simply uses an instance of a PrintJob class, to start(), then uses addObject() one or more times, and finally employs send() print output to the OS for local printing.
To address printing in the cloud, a more universal (or web service) version of the PrintJob class would be created, perhaps called UniversalPrintJob that inherits it interface and capabilities from PrintJob but that adds the capabilities necessary for formatting and redirection of the output to the PSP. This class could provide an alternate implementation of PrintJob that would directly create a PDF or some other portable format from any Flex object added to the print job through the addObject method providing a great solution to the problem of creating an appropriate printable format.
Continuing this idea there could be additional properties, methods or parameters that could provide the additional information needed when the Send method is invoked to submit the content to a RESTful webservice. By simply providing a URL, additional job information and order data formatted as XML or JSON the send method could use the internal Flex HTTPService and/or WebService classes to seamlessly send this print job to a web enabled PSP.
There are several classes discussed there: FlexPrintJob, which prints one or more objects and can split large objects for printing on multiple pages and scales the output to fit the page size. PrintDataGrid is subclass of the DataGrid control with a default appearance that is customized for printing. The class includes properties and a method that provide additional sizing and printing features. PrintAdvancedDataGrid is a subclass of the AdvancedDataGrid control with a default appearance that is customized for printing. The class includes properties and a method that provide additional sizing and printing features. FlexPrintJobScaleType defines constants used in the FlexPrintJob addObject() method.
These classes give the Flash/Flex developer control over how print can be generated from within the application. As one would expect from Adobe products, the output is designed to be directed to PostScript and "non-PostScript" printers.
While there is no native way direct the resulting print stream to the cloud, David and one of Mimeo's developers, a Flash/Flex guru Brad Johnson, came up with a way to accomplish this. An efficient and powerful (as well as simplified) way to print from the Flash/Flex platform would be to enable the developer to use the same mechanism and code path to print to the cloud as they can use to print locally today (e.g., like in the above example and described in Adobe documentation). In Flex 3 (at this writing, the latest iteration of the technology), the developer simply uses an instance of a PrintJob class, to start(), then uses addObject() one or more times, and finally employs send() print output to the OS for local printing.
To address printing in the cloud, a more universal (or web service) version of the PrintJob class would be created, perhaps called UniversalPrintJob that inherits it interface and capabilities from PrintJob but that adds the capabilities necessary for formatting and redirection of the output to the PSP. This class could provide an alternate implementation of PrintJob that would directly create a PDF or some other portable format from any Flex object added to the print job through the addObject method providing a great solution to the problem of creating an appropriate printable format.
Continuing this idea there could be additional properties, methods or parameters that could provide the additional information needed when the Send method is invoked to submit the content to a RESTful webservice. By simply providing a URL, additional job information and order data formatted as XML or JSON the send method could use the internal Flex HTTPService and/or WebService classes to seamlessly send this print job to a web enabled PSP.
Tuesday, June 2, 2009
Silverlight and Printing
Microsoft had an amazing opportunity for Silverlight to provide the most robust printing support of any RIA platform, based on XAML and XPS technologies. Unfortunately there isn’t even a native ability to robustly support local printing in Silverlight 2. They will probably address these issues eventually (and maybe sooner rather than later, but apparently not in Silverlight 3.)
To print from Silverlight to a local printer, you basically have to control HTML/CSS in browser and print via browser to local printer (good enough output, some challenges to implement.) Jonas Follesoe has provided great detail regarding Silverlight printing, here on his blog: jonas.follesoe.no
Our interest here is Printing to the Cloud (i.e., to an Internet-based print service provider like our company Mimeo.com), more than printing to a local printer-- although you have to start somewhere, and the desktop is a good place to begin! Since Silverlight basically uses XAML as its imaging model and XPS is a subset of XAML it would seem to make sense that one could create methods for converting Silverlight content to XPS, then send this data to the Cloud for processing and/or printing. XPS is not (yet) universally accepted, but then again neither is Silverlight. That said, it is just as feasible to generate PDF from Silverlight as it is from Flex.
To print from Silverlight to a local printer, you basically have to control HTML/CSS in browser and print via browser to local printer (good enough output, some challenges to implement.) Jonas Follesoe has provided great detail regarding Silverlight printing, here on his blog: jonas.follesoe.no
Our interest here is Printing to the Cloud (i.e., to an Internet-based print service provider like our company Mimeo.com), more than printing to a local printer-- although you have to start somewhere, and the desktop is a good place to begin! Since Silverlight basically uses XAML as its imaging model and XPS is a subset of XAML it would seem to make sense that one could create methods for converting Silverlight content to XPS, then send this data to the Cloud for processing and/or printing. XPS is not (yet) universally accepted, but then again neither is Silverlight. That said, it is just as feasible to generate PDF from Silverlight as it is from Flex.
Monday, April 13, 2009
The Premise Behind RIP
RIAs (Rich Internet Applications) and their HTML/AJAX counterparts provides the ability for developers to offer “rich” user-interface functionality which is not possible with only HTML and standard browser-based Web applications. The result is the RIA approaches the sophisticated look and feel of desktop software. This, along with the benefits associated with Software as a Service (Saas) and Web 2.0 applications, has resulted in growing popularity of this development paradigm. It's really a whole new, emerging computing platform.
Technology giants Adobe and Microsoft are leading the pure RIA charge with their respective Flash (and its Flex development technology) and Silverlight technologies, followed closely by a global cadre of developers, independently and in standards bodies, enhancing HTML and adding AJAX (Asynchronous Javascript and XML) to create such apps without the need to embed proprietary software.
With the focus inarguably on the computer screen, and on multi-media applications (think YouTube), little priority has been given by developers to generating professional hard copy output. At this writing, there is no ability to print application-controlled, formatted content contained in RIAs anywhere but from the desktop computer, and generally only to a simple network-connect output device.
The challenge is that all three of the aforementioned technologies can print to a "local" printer in a rudimentary way, with basic controls, but cannot print with any sophistication from a server. As these technologies gain in popularity, they will contain large volumes of the world’s information, much of it suitable and desirable for print output. As individuals and employees in corporations inevitably adopt “Web 2.0 technologies” to replace applications that are today done with desktop software, solutions must be created to enable Rich Internet Printing (RIP).
The opportunity is to allow the developer of an internet application, whether they are using HTML/AJAX, Flash or Silverlight, to print in a graphically rich way, based on standards, from/to the “cloud”. One solution would be to create a new kind of “print driver,” that uses a standardized way to model the print stream, taking advantage of the richness of the platform it is installed on, but directing the stream out of the app/platform.
Friday, April 10, 2009
Welcome to Rich Internet Printing
Late last year, Mimeo founder and CTO David Uyttendaele and I began a project to explore the newest and best ways to print from emerging web technologies. The concept we began with is that there is a lot of content suitable for professional printing that is natively generated in web 2.0 (as opposed to coming from desktop applications software). This is user generated content, and it's going to continue to be an incredibly important part of the publishing and printing world.
We learned a tremendous amount, some of which we presented in a paper at delivered at the Technical Association of the Graphic Arts Annual Technical Conference in New Orleans in March 2009. Even as we were finishing the paper, we continued to find new, important and useful information. As we've shared the paper with colleagues and friends, we've learned even more.
That brings us to the Rich Internet Printing blog, which we've built to share and discuss this important and fascinating topic.
We learned a tremendous amount, some of which we presented in a paper at delivered at the Technical Association of the Graphic Arts Annual Technical Conference in New Orleans in March 2009. Even as we were finishing the paper, we continued to find new, important and useful information. As we've shared the paper with colleagues and friends, we've learned even more.
That brings us to the Rich Internet Printing blog, which we've built to share and discuss this important and fascinating topic.
Subscribe to:
Posts (Atom)
