Blog RSS
ABCPdf – A Review - 6/16/2010

       ABCPdf is a PDF creation, manipulation library from www.websupergoo.com. I have to say it’s a fantastic piece of software.

First, it’s a standalone library which doesn’t have any third-party dependency for most of its features and all features are contained in two DLLs. This is important because this will greatly simplify the deploy process. And even better, with such a small footprint, ABCPdf managed to support the latest PDF Spec and a lot of great features.

Second, ease of use. We used iTextSharp which is an Open Source PDF library. It’s OK. But it lacks a lot of features and has no PDF rendering capabilities built in. We then tried to use another Open Source library which is xpdf for extracting images. It’s hard to use. E.g., to extracting images, you have to manually manipulate the raw binary data which is of course a pain in almost every language, even more so for C# or other .NET languages. You literally have to use Managed C++ to write a wrapper for xpdf and then call it from .NET. Then we bumped into ABCPdf when we were looking for other choices and it’s really a joyful experience. And we fell in love easily. With less than one hour, I can extract images from PDF files. And it’s just one of the many handy features in ABCPdf. The most important thing is that it’s written in .NET and it has a nicely organized object hierarchy which makes it easy for .NET developers to interact with PDF on no matter what level. You can deal with Page easily with Page API. You can drill deep down to get the raw data if you like. It gives you the ease of use without losing control.

Last, but not least, ABCPdf’s licensing fee is reasonable. For iTextSharp 5.0, with much less features, we have to pay an unbelievable $5000 at minimum for just 1 year license which is of course not affordable for a micro startup like us. But ABCPdf is here to save us. Thanks Websupergoo for producing such a great software. It’s appreciated. 

Comments (0)
iPDF, the Roadmap - 2/24/2010

          With iPDF, we intend to move it along as the rest of the world does. So, this post is going to explain the roadmap for iPDF in about a year or so.

         Immediately follows the 1.0 release, there will be (at least we plan to) an intermediate 1.5 release which will add a slew of features which are not included in the initial release due to the time constraint. When you introduce something new, it takes time to put things together and we have to ship at a certain point. The missing features in 1.0 as we see is batch printing (not just PDF/Office documents, but all kinds of printable formats), session export/import/sharing/sync, parallel processing for certain tasks (which will give a huge boost to the performance), more web services support such as Facebook and of course auto update which seems to be a standard feature of modern application.

         After that is the 3.0 release. Yes, yes, we are going to skip version numbers. 3.0 will be a major one. WPF will be used. We will also take advantage of C# 4.0, MEF (Managed Extensibility Framework), Parallel Extensions in .NET 4.0, and such. Thanks to MEF, extensibility will be vastly improved for sure. We will make leap and jump in terms of performance because of the parallelism support, especially on those many core machines.

         Anyway, that’s the plan. Is there a plan B? Not exactly. But as always, we will change as the situation changes. 

Comments (0)
MEF, Visual Studio 2010, Extensibility and iPDF.Next - 2/24/2010

          In Visual Studio 2010, one of the things which are vastly improved over the previous versions is extensibility. (Let’s hope the price tag of it is not ‘vastly improved’. Fingers crossed!J) Finally, Visual Studio extension developers can focus most of their energy on things they want to achieve instead of cracking Visual Studio out.

Like Anders Hejlsberg said, “You must steal, or else, you will fail!” And that’s what we are going to do next. In next release of iPDF, if that’s still what this app going to be called, we are going to steal from MEF, Visual Studio 2010, and so forth.

Still from Anders Hejlsberg, “Programming is all about exercising absolute control over this little world that does precisely what you want to do. And of course, sometimes it doesn’t. But at the end of the day, it’s your fault. It is not the world. The world just always does what you tell it to do. And it’s up to you to tell it to do the right thing.” Programming extensions against Visual Studio or any other application that’s extensible is similar. You try to control the environment to do what you want it to do. The application you are programming against is just like a beast that you have to tame and master.

Usually, the more powerful the beast is, the more difficult it is to be mastered. Writing extensions for Visual Studio 2008 is way harder than writing extensions for, let’s say, iPDF 1.0. So, if we want iPDF.Next to be a lot more capable, we also have to make it equally more difficult for you to write extensions for. Oh wait, Visual Studio 2010 is way more powerful than Visual Studio 2008 but yet developing extensions for it is much easier than for Visual Studio 2008. What’s going on there? In a sense, what you see there is a paradigm shift. With the VS 2010 release, the VS team has chosen WPF over GDI as the underlying technology to build the IDE. It’s a radical but logical leap. This gave the team flexibility to do things that wouldn’t practical or even possible in the past (Of course, it also gave them significant performance hit  , but that’s another story). As a side effect, the extension development experience is much improved.

iPDF 1.0 is written in WinForm on .NET 2.0. WinForm is wonderful technology. It’s almost 10 years old and still does its job pretty well. But as iPDF moves forward, the underlying technology has to move with it. So, with iPDF.Next, we will go with WPF and C# 4.0, which is just around the corner.

Does that mean we are going to see a dramatic UI change? Probably not. The current UI is already quite up to date. Will you, the iPDF extension developer, be able to do more? With less? Definitely! We certainly hope so. That’s the whole point of this post.

Right now, the capability of iPDF extensions is very limited. You can only add an item in ‘Services Gallery’ on the Publish tab, configure a bit, and when user hits ‘Start’, upload files to the web service that the extension connects to. And that’s it. It's very limited but simple and easy. But that’s only the tip of the iceberg.

With iPDF.Next, you can do a whole lot more such as adding a tab, extending the main grid, manipulating sessions, popping up a window (although modal dialogs are prohibited in general for the sake of UX), showing an notification, adding editing capabilities, scripting it with a language that’s similar to BOO, etc. In essence, you will gain much more control and much more understanding of this little beast, iPDF. Of course it’s going to be quite different to develop extensions for iPDF.Next from today. But by leveraging MEF(Managed Extensibility Framework), C# 4.0, specifically the dynamic features, parallel capabilities in .NET 4.0, we believe it’s not going to be any more difficult. We hope to deliver a powerful but joyful extension developing experience with iPDF.Next so you can extend it to a level that we can only dream of today. Stay with us if you will. And stay tuned by subscribing this blog. We’ll be posting on a regular basis to keep you informed about what’s happening with iPDF.

Comments (0)
Developing iPDF Plugin Part II – Best Practices - 2/22/2010

         To know the basics of developing iPDF plugin, head on to Developing iPDF Plugin Part I – the Basics

         iPDF uses .NET reflection API to load plugins and as you know,  reflection can be very slow. So for performance’s sake, you probably should not build one giant assembly and put it into the ‘Services’ folder. Nor you should create a bunch of small assemblies and put them all in the ‘Services’ folder because that would pollute the ‘Services’ folder because that would pollute the ‘Services’ folder, thus will extend the process of loading ‘Services'.

         Instead, it is preferred that you create a stub assembly which inherits the CloudService class, do some basic stuff and put all the heavy work in other assemblies and reference them from your stub assembly. And then you only put your stub assembly in the ‘Services’ folder of iPDF and put the rest of your assemblies which the stub assembly depends on into GAC or wherever you like. This way, iPDF can loads your plugin pretty fast because your stub assembly is small and simple. It also gives you flexibility which is good I think.

         Ok, that’s it. And you can download our sample plugin. It is well commented and well organized. At least we think so. On a side note, the sample plugins are actually the ones gets preloaded in iPDF 1.0. It’s a dirty little secret we hope you all can keep to yourselves only. 

 

Comments (0)
Developing iPDF Plugin Part I – the Basics - 2/22/2010

         This post is, obviously, for developers out there looking for next big opportunity, more specific, for .net developers because iPDF is developed in C# - our favored language.

         Essentially, iPDF is not yet another office productivity app. It's a platform. A third party developer, which literally means you, can develop plugins to extend its capabilities. iPDF provides the infrastructures like the ribbon user interface, adding items to the data grid, processing them, notifying user when done, etc. You only have to focus on specific functionality you intend to implement.

         In  iPDF 1.0, third party developer can only add web service to the services gallery on the Publish tab. With next release, which is due out in August, you will be able to add tabs, add galleries, pop up a notification to user, add your own column to the data grid, scripting iPDF using a BOO like language, and more. Oh, one side note, we are going to use MEF (Managed Extensibility Framework). Stay tuned.

         Okay, enough for the next release. This post is primarily about how to develop a web service plugin for the Services gallery on the Publish tab. Let's get started!

         First, let's dive into how iPDF loads those web services plugins. On startup, iPDF scan the 'Services' folder in the iPDF installation directory for DLL files in a background thread. For each dll, iPDF uses .net reflection API to determine if it contains one class which inherits from a certain class called CloudService. If it does, then iPDF will instantiate one instance of that class, adds it to the services gallery with an icon supplied by that class. And when user does a certain action on the Publish tab, the action will be delegated to the current selected service instance to do something about. And that's pretty much it.

         You probably are wondering what this CloudService class looks like. Well, read on.

         The below is how it looks like in .NET Reflector. Of course, I decorated it a bit.

      public abstract class CloudService : IDisposable

      {

      //Methods

      //return if a folder with a given name exists. optional

      public virtual bool ContainsFolder(string folderName);

      //return if a folder with a given name exists in a group of folders. optional

      public virtual bool ContainsFolder(string folderName,  IEnumerable<object> folders);

      public virtual void Dispose();

      //login. required

      protected abstract void Login(NetworkCredential token);

      //logout. required

      public virtual void Logout();

      //make a new folder with the cloud service. optional

      public virtual void MakeNewFolder(string folderName);

      //reload all folders. optional

      public void ReloadFolders();

      //search a keyword in the folders. optional

      public virtual List<object> SearchFolders(string keyword);

      //upload file. required

      public virtual void Upload(string fileName);

 

 

      // Properties

      //access control level of the web service. optional

      public AccessControl AccessControlLevel {  get;  set; }

      //the web url of the web service

      public Uri CloudUrl {  get; protected  set; }

      //the user credential of a certain user. required

      public NetworkCredential Credential { get; set; }

      // the folders of a certain user on the web service. optional

      public virtual object[] Folders {  get; protected  set; }

      //the icon of the web service

      public virtual Image Icon {  get; protected  set; }

      //indicate whether the current user is logged in the web service

      protected bool LoggedIn {  get;  set; }

      //the name of the web service

      public string Name {  get; protected  set; }

             //the user selected folder to upload files into

      public object SelectedFolder {  get;  set; }

             //indicate whether the plugin supports access control

      public bool SupportAccessControl {  get;  set; }

      //indicate whether folder is supported by the plugin

      public bool SupportFolder {  get; protected  set; } 

      //indicate whether the web service supports making new folder

                    public bool SupportNewFolder {  get; protected  set; }

      //the file formats supported by the web service

      public List<FileFormat> SupportedFormats {  get; protected  set; }

      //the validator to validate if a password is valid for the web service. optional. If omitted,

      //the default one is used

            public virtual IValidator UsernameValidator { get; }

       //the validator to validate if a password is valid for the web service. optional. If omitted,

             //the default one is used

                    public virtual IValidator PasswordValidator { get; }

      }

         As a plugin developer, you have to implement a class that inherits from the CloudService and plug into iPDF by placing your assembly in the 'Service'  folder. And that's it.

Comments (0)
iPDF - Tips and Tricks - 2/21/2010

         There is an old saying: there is more than meets the eye. This is especially true with iPDF.  

         Adding items to iPDF can never be easier. You can drag files, folders, or even files and folders into iPDF. Then iPDF will automatically search those folders and the sub folders of those folders for eligible files and add them into the data grid. This might be trivial, but it can save you lots of time sometimes. You can add thousands of files to iPDF and it makes no difference to iPDF except the processing time. 

         As always, the combination, the whole, is greater than the sum of its parts individually. As for iPDF, you can combine different tabs to do interesting stuff. For example, let’s say that you want to merge a bunch of images into one single PDF, how? There is no single tab in iPDF that lets you do this. Well, don’t panic. First, you can use the Image tab to convert all those images into PDF formats.  Then, simply switch to the Merge tab. You will soon notice that all converted PDF files are preserved in the grid. This is handy, huh. Then simply hit the Start button and you are all set. The converted PDF files will be merged into one single PDF. For your convenience, it automatically opens after the mergence. Even better, if you check the bookmark checkbox, iPDF will automatically adds bookmarks for you using the name of each file. 

         Do you have other tricks up your sleeve that we don’t know yet? If you do, surprise us by commenting. Or you can email to us and we will post them on this blog.  

Comments (0)
iPDF – New Efficiency - 2/21/2010

         Have you been adding watermark to your PDF documents one by one? Have you been encrypting PDF documents manually? Have you been uploading files to Scribd via the fundamentally flawed browse file button and wondering why on earth I can only upload one single file each time? Have you been murmuring that it should not be you – the knowledge worker defined by the great Peter Ferdinand Drucker – to do these kinds of chores? Ok, you are definitely right. It should not be you. It should be the software instead. It’s the software which is designed to do all those chores quickly and accurately. And you should be the one who is authoring strategic reports, analyzing critical data, listening to end users’ complaining, making important decisions, etc. Come on, you are the knowledge worker. You are entitled.

         Well, that’s exactly the design tenet of iPDF – Free you from chores so you, the knowledge worker, can focus on creating ground-breaking things.

         iPDF does everything in batch mode. A typical scenario is you just drag a bunch of folders into iPDF and iPDF then scan those folders for eligible files in them. After that, you hit the ‘Start’ button; it will start digesting all those files which you fed it, quietly. Then you can pretty much leave it alone and do other things. You will be notified when done.

         Office 2010 is coming. iPDF supports office 2007 & 2010 beta. Even better, iPDF features an UI which is almost identical to Office 2010 Ribbon interface. Like office 2010, all commands can be found in one single place – a beautiful, nicely organized Ribbon. iPDF uses Ribbon Gallery + Live Preview to visualize commands, same as Office 2007 & 2010.

         Anyway, iPDF 1.0 is here. It’s a whole new efficiency. Wait no more, grab it from our download page. Trust me, you won’t be disappointed. 

         Also, you can view and download our product in many other website such as download.com, softpedia.com and brothersoft.com.

Comments (0)