NiXPS

Create XpsDocument From NOPackage Using MemoryStream

2011-01-14T10:39:00.001+01:00

A customer asked for a way to create an XpsDocument in .NET using the NiXPS Library. This is the code you need:


public static void test_XPSDocumentFromMemoryBuffer()
{
    string pIn = "../../examples/testfiles/catalog.xps";
    NOPackage lPackage = NOPackage.readPackageFromFile(pIn);
    UInt32 lBufferSize = 1000 * 1000;   // 1000 kb = 1M
    byte[] lBuffer = new byte[lBufferSize];
    uint lFileSize = 0;
    lPackage.writePackageToBuffer(lBuffer, lBufferSize, ref lFileSize); 
    MemoryStream lStream = new MemoryStream(lBuffer, 0, (int)lFileSize);

    string inMemoryPackageName = "memorystream://myXps.xps";
    Uri packageUri = new Uri(inMemoryPackageName);

    Package lXPSPackage = Package.Open(lStream);

    //Add package to PackageStore
    PackageStore.AddPackage(packageUri,lXPSPackage);

    XpsDocument xpsDoc = new XpsDocument(lXPSPackage,
				CompressionOption.Maximum,
				inMemoryPackageName);
    FixedDocumentSequence fixedDocumentSequence = 
				xpsDoc.GetFixedDocumentSequence();

    // Do operations on xpsDoc here
    // Note: Please note that you must keep the Package object
    // in PackageStore until you are completely done with it since
    // certain operations on XpsDocument can trigger delayed
    // resource loading from the package.

    PackageStore.RemovePackage(packageUri);

    xpsDoc.Close();
}

When you download our SDK you can paste this test in. However you will need to change the threading model of the Main method to STAThread. You can do this by adding [STAThread] just before the Main method like so:


[STAThread]
public static void Main(string[] args)
{
	// ... rest of code
}

Hope this helps.

WPF visual to PDF - control page size

2010-11-05T16:45:00.002+01:00

With our NiPDF library it is very easy to build PDF based on WPF visuals. It is literally a few lines of code which you can find documented on our website.

This week I got the question from a customer who wanted to influence the page size.

This is fairly easy to do by means of the PrintTicket class.
In line with the example on our website, the second step becomes:


// STEP 2: Convert this WPF Visual to an XPS Document
MemoryStream lMemoryStream = new MemoryStream();
{ 
  Package package = Package.Open(lMemoryStream, FileMode.Create); 
 XpsDocument doc = new XpsDocument(package);
 XpsDocumentWriter writer = XpsDocument.CreateXpsDocumentWriter(doc); 
  //Create PrintTicket for document and set its page size to the proper custom page size
 PrintTicket printTicket = new PrintTicket(); 
  //Set the page size to a custom 3.5" x 2.5" page
 printTicket.PageMediaSize = new PageMediaSize(3.5 * 96.0, 2.5 * 96.0);
 writer.Write(visual,printTicket); 
 doc.Close();
 package.Close();
}

Easy to do, provided you know how to do it - as always!

Experimental NiPDF.JS PDF Browser update

2010-10-27T11:45:00.004+02:00

We have updated our client-side Javascript PDF browser. When it encounters a flate/zip stream, it will deflate it. And binary stuff is now presented in a much more useful way:

Give it try at http://nixps.com/nipdf/pdfbrowse.html.

NiPDF.NET: update to text searching for PDF

2010-10-14T08:38:00.003+02:00

A customer flagged that the PDFs generated with NiPDF weren't text searchable.
Previous versions of the NiPDF library didn't output the ToUnicode character mapping in the PDF, this has been fixed.

If you go to http://nipdf.com and download the NiPDF SDK you will generate fully searchable PDFs!

PDF library in Client-Side Javascript - Adventures in Javascript

2010-10-12T11:37:00.004+02:00

The computer industry is in constant evolution.
One of the recent exciting developments is the fact that the web browser is becoming a lot more powerful than a few years back.
Chrome entered the browser landscape, Safari is going strong, Firefox as alternative browser is a big success, and Microsoft is catching up now with a massive technical leap in their upcoming Internet Explorer 9.

These recent, powerful changes are not about web pages.
This is all about web applications.

With the recent HTML5 developments, the browser is becoming a viable platform to host applications. Applications that do not need a server backend.

Think about it: in the very near future everyone will have access to a HTML5 browser.
This HTML5 browser will be able to run HTML5 applications, independent of the underlying platform.
This means no configuration management issues, and instant installation, as these apps can be server directly from a bog standard web server.

There are more advantages: scaling. A regular client-server application needs more power at the server, when the client base grows.
Pure in browser applications do not need a server for processing, pure elastic scaling, no additional investments server side.
And the extra beauty of it: a better use of the available processing power at the client, as in a lot of cases these system are very capable, but running idle.

So at NiXPS are a big believer in this, and we also think that software developers will start looking for tools and components for this new world. And for this we have started to support our software 100% natively in Javascript.

We are working on a 100% native Javascript NiPDF library, and as a demo we have build a tool that allows you to look structured at the innards of a PDF file.
You need a browser that supports the HTML5 FileReader object, so currently this means FireFox 3.6+ of Chrome 7.0 beta. Other are catching up soon.

Take a look at: http://nixps.com/nipdf/tools/pdfbrowse.html
It is experimental, but all your feedback is very welcome at info@nixps.com!

NiXPS launches NiPDF v1.0

2010-09-21T20:38:00.003+02:00

After many months of work I'm pleased to announce a new product we are launching today: NiPDF v1.0.

This product is a direct result of our experiences with customers all over the world working in .NET and wanting to generate PDF.
We have learned that generating PDF in .NET is cumbersome and downright painful - and our aim is to put our technology to work to alleviate the pain and simplify this.

.NET front and center
A lot of PDF solutions out there are not really .NET.
They are a thin veil of .NET around a big body of native code.
Our NiXPS SDK has exactly the same architecture.
This works, and is often very efficient, but it kind of defeats the purpose of working with managed code.
Often there is a requirement to only work with managed code assemblies.
With our NiPDF v1.0 we introduce a 100% managed code library.
No native code dependency.
NiPDF is a lean and mean, 100% native, PDF library that allows you to efficiently generate PDF in .NET.

No special API to learn, no vendor lock-in
Another drag in today's PDF SDK's is the fact that in order to generate PDF, one needs to code against an API that the third party has defined.
This introduces a learning curve, and introduces vendor lock-in, as your code will depend on the third-party's API.
Thanks to our XPS heritage we are able to offer an innovative solution for this.
Via the .NET built-in ability to convert WPF visuals (and FixedDocuments) to XPS, you can code agains the default WPF API, and in 1-2-3 generate a PDF from this with a minumum of calls into our NiPDF library!

High quality, keeping text and vectors intact
The NiPDF PDF output keeps text and vectors intact, resulting a small, high quality, fully searchable PDFs.

NiPDF SDK and NiXPS Converter SDK, brothers in arms
NiPDF is premier choice for quick and easy PDF generation for .NET.
We continue to develop our NiXPS Converter SDK, which thanks to its native architecture, offers a better alternative for performance critical applications, has a more versatile feature set (f.i. PDF/A generation) and has supports C/C++ and OSX.

Take a look at the NiPDF product site at http://nipdf.com and download the trial.

Example: create XPS and add hyperlink using NiXPS SDK

2010-07-08T12:23:00.003+02:00

A customer asked me for a code sample to illustrate the creation of an XPS document, and the ability to make content link to a hyperlink.

It might be of interst to others, so I am posting it on the blog.
This sample works with NiXPS SDK 2.6.6, and uses .NET.

First: create an XPS package with a document:


NOPackage lPackage=NOPackage.createPackage(1,"out.xps");

Now: create a page and add content using the document model.
We do this by getting the root FixedPage, create a Canvas inside, and store a Glyphs element which can hold a string of text.


{
 NOPage lPage=lPackage.getDocument(0).createPage();
 NOXFixedPage lContent=lPage.getFixedPage();
 lContent.intialize(8.3*96,11.7*96); // A4: 210x297mm or 8.3x11.7inch
 NOXCanvas lCanvas=lContent.createCanvas(0);
 lCanvas.intialize();
 NOXGlyphs lGlyphs=lCanvas.createGlyphs(0);

We also need to create and supply a NOFont to be used. We load this up from disk, where we have stored Arial.ttf, an opentype font we would like to use.
We then fill the Glyphs.


 NOFont lFont=lPage.addFont("../testfiles/Arial.ttf");
 NOString lURI = new NOString("/" + lFont.getPartName());
 lGlyphs.intialize(20, lURI.getHandler(), 300, 50);
 lGlyphs.setFill(new NOString("#FF000000").getHandler());
 lGlyphs.setUnicodeString(new NOString("Take me to http://nixps.com").getHandler());

Next: the link. We name the Glyphs, and add a NavigateURI attribute which gives us the intented behaviour to link to a website.


 lGlyphs.setName(new NOString("page_1").getHandler());
 lGlyphs.setFixedPageNavigateUri(new NOString("http://www.nixps.com").getHandler());
}

Now we're done. So all left is to write out the file and clean-up.


// write out and close
lPackage.writePackageToFile("out.xps");
NOPackage.destroyPackage(ref lPackage);

XAML with databinding to PDF with NiXPS

2010-07-02T09:48:00.003+02:00

A lot of customers ask me how they can go from XAML with databinding to PDF.

Our SDK can be a great part of a solution for this, if you go over XPS.

Here is a great article that outlines how you can go from XAML with databinding to XPS with WPF.

Typography

2010-06-01T14:54:00.002+02:00

Stumled upon this little gem of a picture:

One picture that explains the concepts of ligature + foundry.
They literally used to melt metal to make these glyphs.

XPS on iPhone

2010-05-17T16:58:00.002+02:00

We have send out a press release to celebrate our release of NiXPS View for iPhone, the world's first application for iPhone that allows you to preview XPS files.

You can read our PR here.

We have added an overview on our website, which also covers how you can use the app.

Give it a try and let us know what you think!

NiXPS View for iPhone is now available on the App Store

2010-05-13T00:03:00.001+02:00

Freshly approved by Apple, go get it here.

The upcoming Internet Explorer 9 supports XPS printing

2010-04-29T10:23:00.001+02:00

IE9 moves to the XPS print path, read more about it here.

NiXPS View for iPhone

2010-04-28T13:34:00.005+02:00

We have ported our NiXPS SDK to the iPhone OS 3 platform, and build a viewer application around it.

The viewer allows you to download XPS files from the web and view them.

Thanks to the rich user interface platform that Apple offers on the iPhone, we were able to build a very nice and natural interface to view XPS files.

We have submitted our application for review by Apple last Monday, so we hope to have it available to customers in a few weeks. I'll write more in detail and post more screenshots then.

Optimizing, optimizing, optimizing....

2010-03-26T21:04:00.002+01:00

Spend most of the week swimming with the shark, Apple's great code profiling tool.

Profiling is a humbling experience for a developer - where big ego's, and long runtimes, slowly, but decisively shrink to it's razor sharp essence.

Have a nice weekend!

NiXPS SDK v2.6.6 released!

2010-03-09T16:56:00.002+01:00

We have released NiXPS SDK v2.6.6 today.
This is a maintenance update, free for all current customers who are under maintenance.

We roll out some optimizations in reading, writing and converting very large documents (+1000 pages).
You should see a significant speed boost, and reduced memory usage, when handling these type of files.
The XPS document outline (table of contents) is now also optionally converted into a PDF document outline.
And we have fixed a few minor bugs.

Again a lot of fixes and optimizations were the result of issues reported by our customers.
Your continued feedback allows us to further improve our software and provide a field tested, high quality SDK.
Thank you very much!

You can find the changelog for this v2.6.6 release here.

Download a trial version here.

Palm goes C too

2010-03-08T22:11:00.002+01:00

Palm announces support for native plugins for its WebOS platform (read here).

Android, Chrome OS, iPhone, Symbian, OSX, Windows, ... go native when speed is required.

Speed still matters in the Web 2.0 age.

Photoshop turns 20

2010-02-20T15:08:00.003+01:00

If a product becomes the synonym for what it represents- that is the ultimate definition of success.

This picture is photoshopped. You know what that means.

The software applications blows out 20 candles - much software development respect!

Read its history here.

On Client Platforms

2010-02-13T14:51:00.001+01:00

Suppose you are going to develop your next application that needs to run on an as broad selection of user's client devices or computers, what development platform are you going to target?

There are a lot of client platform possibilities that a developer can choose to develop their application for.
All of these client platforms have their technical and business merits and drawbacks.

In this post I give my take on some of the major possibilities, feel free to comment or send in your thoughts!

Note:
I list the main points is three categories:
The Good: are properties of the technology that are a clear advantage
The Bad: are properties that are limiting or stumbling blocks, and cannot be overcome
The Ugly: are properties that are limiting or stumbling blocks, that can be overcome or mitigated by the developer of the application

1. Native Application
An application that the user installs and runs on their computer/device.
For instance: native Windows application

The Good
-integration in the overall user experience of the OS (or hardware: f.i. iPhone), native look and feel
-performance
-both an on-line and off-line solution
-mature development environments
-large ecosystem of 3rd party library/components

The Bad
-locked to a specific OS/device, for each OS a version needs to be developed
-application needs installation, possible roadblock as sometimes not even allowed (f.i. corporate policy)

The Ugly
-updates: need to be installed each time per user

This platform is mostly pushed by Apple, and Microsoft

2. Flash application
A application that runs on the Adobe Flash runtime in a browser.

The Good
-OS/browser/device independent
-large installed base of Flash runtimes (see: riastats.com), shrinking slightly
-no installation required, if plug-in is available
-updates easy, app is downloaded each time

The Bad
-browser plug-in needed
-some platforms not supported (f.i. iPhone)

The Ugly
-performance
-good integration in OS is challenging (no native look & feel; local file access, etc...)
-technically challenging to implement all required functionality
-development tools are so-so
-lack of large ecosystem of 3rd party library/components
-flash blockers, user apathy

Biggest supporter for this is Adobe.

3. Silverlight application
A application that runs on the Microsoft Silverlight runtime in a browser.

The Good
-OS/browser/device independent
-no installation required, if plug-in is available
-updates easy, app is downloaded each time
-mature underlying technology (.NET subset)

The Bad
-browser plug-in needed
-small installed base, but growing (see: riastats.com)
-some platforms not supported (f.i. iPhone, Linux)

The Ugly
-performance uncertain
-good integration in OS is challenging (no native look & feel; local file access, etc...)
-technically challenging to implement all required functionality
-Silverlight plug-in probably not installed, so user will need to do this
-lack of large ecosystem of 3rd party library/components
-user apathy

This pushed heavily by Microsoft too, but with clear focus on Windows.

4. HTML/Javascript application
A application that runs entirely in a browser, using Javascript and HTML

The Good
-OS/browser/device independent
-only a recent browser needed, virtually available everywhere
-large and growing ecosystem of 3rd party library/components

The Bad
-no local storage of files
-basically an on-line only solution

The Ugly
-performance
-there are technical limitations on what can be accomplished with HTML5/Javascript
-development environments non-existent
-good integration in OS is very challenging
-technically challenging to implement all required functionality
-some popular browsers (Microsoft IE) lack modern Javascript/HTML5, so graceful fallback needed
-Javascript + HTML not so elegant combo from a software development point of view: impact on maintenance, debugging, etc...

This is a methodology that is being pushed by Google.

5. Java applet
A application that runs on the Java runtime in a browser.

The Good
-OS/browser/device independent
-no installation required, if plug-in is available
-updates easy, app is downloaded each time
-mature underlying technology (Java)
-mature development environments
-large ecosystem of 3rd party library/components

The Bad
-browser plug-in needed
-unpredictable installed base
-some platforms not supported (f.i. iPhone)

The Ugly
-good integration in OS is challenging
-Java applets seem to be a dying platform

This was push somewhat by Sun, taken over by Oracle now. New follow-up tech JavaFX didn't catch on.

There are of course various others: Adobe AIR (need specific runtime installed), Java application (also special runtime needed), XBAP, Prism, etc...
But I wanted to focus on the main important ones.

Speed matters

2010-02-05T08:53:00.002+01:00

Facebook uses a lot of PHP, and given the scale of the service, they must be watching performance very closely.
Bandwidth and infrastructure will be their main costs, so it makes economic sense to try to run as much of Facebook on as little infrastructure as possible.
And one of their tools they have announced this week: HipHop.

HipHop is a toolchain that preprocesses PHP into C++, which can subsequently be compiled by a C compiler, and then used with their webservers. Facebook says they are seeing a 50% increase in performance.

This is beautiful engineering: they can now run double the load on the same infrastructure.

Evangelists always cleam that dynamic (or interpreted) languages are a win-win.
You win on ease of use, as a dynamic language is easier to program for, easier to debug and easier to maintain.
And you supposedly win on performance, as they run as quick as compiled code.
The latter is never true in practice, no matter what complicated theoretical explanation they always give to say it really is so.

There are numerous real world examples:

Google wants you to use a Java-like on Android Phones, but if you want it to go fast, use C and compile to binary. (a brilliant video to drive the point home here). Java is not fast, using it on a small phone cpu is a challenge.
Apple supposedly have written their first iPhone widgets (time, weather, stocks, etc...) with javascript/html - but decided to rewrite them in Objective-C because performance was poor
Windows Vista contained a lot of .NET during development, but that was ripped out and changed to native x86 for speed reasons.
Using PHP based Wordpress for a large site is only really doable when you use static caching, and do not run PHP at all for most of the requests.

A lot of the evangelism for dynamic (and interpreted) languages is like marketing propaganda; they sell you a dream, but a lot of dreams do not survive a confrontation with reality.

The fastest and most efficient way to run code is to use the least amount of the best instructions for a given cpu.

Speed matters in the real world.

Microsoft joins SVG working group

2010-01-11T17:08:00.003+01:00

Microsoft announced that they took a seat on the SVG working group.
This good news for the SVG format, as a lot big players are backing it now.

NiXPS has been supporting SVG for almost two years now. It is an interesting technology, but it practice it was being let down by a lot of broken/missing/poor support in various software components (Webkit SVG has a few issues, Internet Explorer support is laky, Adobe has an on/off relationship with SVG, etc...).

It is good news that Microsoft has decided to back the format more officially, it might improve Windows support for it, and make it a much more dependable format for the future.

Here at NiXPS we will keep following it closely.

HP Slate - platforms, platforms and some more platforms

2010-01-07T09:13:00.008+01:00

Microsoft's CEO Steve Ballmer showed a prototype of a new Tablet PC like device designed by HP, and running Windows 7: the HP Slate.
With the rumour mill going in overdrive about an imminent Apple Tablet-like product, and a large part of the industry totally ecstatic about 'touch computing', this is hitting all the right buttons.

I kinda think the device looks very nice - a bit like an oversized iPod Touch, which is a good thing.

The last couple of years a lot of attempts are made to open up a new categories of computing devices:

Smartphones. with poster child Apple, and runners up Nokia and Blackberry - and since a few days also Google with its Nexus One. There is a blurry line between regular mobile phones and smartphones, but I think it would be reasonable to say that smartphones are defined by the fact that it's fairly easy for 3rd parties to develop software for.
Netbooks. Invented by Asus, very popular small laptops. Here the blurry line between netbooks and laptops. But here the defining factors are size and prioce, typically Atom powered.
Smartbooks. A new category - it's a netbook that is not based on an x86, and runs some other os than Windows. Typically ARM and android combo.
E-books. Small computer to read books - typically a special screen technology to make reading more pleasant. People tend to forget, but these machines already exist for 10+ years.
Tablets. Laptop like computers that have a large touch screen, that can mostly be swiveled so that the device looks to be 'only screen'. Also already in existence for 10+ years.

And people still buy desktop PCs (and Macs) and laptops, of course.

I'm not quite sure where to fit in the iPod Touch. It's a touch based, tablet like computer. But it's smaller than your typical tablet. I like it, as it is really portable, but makes more sense in it's iPhone incarnation (if it wasn't for the price).

These are a lot of computing devices, with a lot of different architectures.
Intersting times ahead for small, independent software vendors ;-)

Merry Christmas and a happy 2010

2009-12-24T12:59:00.004+01:00

(download xps here)

EXI

2009-12-13T13:36:00.005+01:00

I've been tied up with a lot of work the last couple of weeks, resulting in too much blog radio silence for my liking.

We have released a v2.6.5, which I will blog about more the coming days.
And we're working heavily on our next major SDK release v3, which will feature some impressive technological advancements.

All new v2.6 SDK customers will receive the v3 for free. All existing v2.6 SDK customers will receive the v3 for free if they are under maintenance.

One thing caught my attention this week: 'Efficient XML Interchange' gets W3C green light. Efficient XML Interchange. First time I heard about that one. This appears to be a binary representation of an XML document, the spec is being drafted by the W3C. I've browsed it lightly, and it seems to be a binary representation that reduces the overhead for XML, and facilitates SAX parsing.
I find it a bit of an odd thing. XML is verbose, but this verbosity helps humans reading, writing and understanding it. And a computer can always zip it. Turning it into a binary format, kind of defeats the purpose, and makes it just another binary format.

I definitely need to study it further. Sharing the parser state, could be an interesting thing to have, but that would only matter for big XML files, I guess. And what if you do not want to be forced in a SAX style arrangement?

But it exists, so I assume it must be scratching an itch!

NiXPS SDK v2.6.4 released!

2009-11-16T15:49:00.001+01:00

We have released NiXPS SDK v2.6.4 today.
This is a maintenance update, free for all current customers who are under maintenance.

This release brings mainly bug fixes, and a few optimizations.
We also ensured that our managed DLL is strong named.

Again a lot of fixes were the result of issues reported by our customers.
The continued feedback we are getting allows us to further improve our software and provide a field tested, high quality SDK.
Thank you very much!

You can find the changelog for this v2.6.4 release here.

Download a trial version here.

Why PDF portofolio's are a bad idea: a user's poor experience

2009-11-15T12:44:00.009+01:00

I bought a new TV yesterday, a Philips 37PFL5604H. Good price, decent quality; chosen as the best buy based on a test of 20+ TVs by local consumer mag Test-Aankoop; but I digress.

It's 2009, and no paper manual to be found in the box.
This is ok, never use them frequently anyway. And they use up limited physical shelve space.

Philips included a sticker where they say that the manual is available on the machine itself via a help menu. Seems like a good idea, but as some other residents of the house were already watching, my suggestion that 'I want to have a look at the manual' were greeted with angry looks.

Ok - on to the Philips website to download an electronic version.
Which was remarkably easy to do, I quickly found a PDF of the manual, and downloaded the file with the prosaic name '37pfl5604h_12_dfu_nld.pdf'.

Opened it on may mac, and I was greeted with:

Oh, the joy! In stead of showing me the manual, I got the invitation to download and install another piece of software, otherwise I would be deprived of the ability to read or print the damn manual.
My regular PDF viewing software, Preview.app, which could be regarded as fairly up to date, was sadly not at liberty to preview this PDF.

So caved in, and installed the latest version of Adobe's Reader, as apparently PDF might be an open, accessibly format, as long as you work with it using Adobe software.

Waiting to be amazed by the sheer progress that portofolio's bring to the concept of an electronic manual, I got this one (after declining an Adobe Updater request to update itself, and another update offer for the software I just downloaded):

?

Ok, just give me that manual already. And I click on the right (Volledige Gebruikshandleiding.pdf), and make an attempt to get it out so I can go back to Preview.app to read it.
Then I get this gem:

Achtung! You dare to save this document, and possibly use non Adobe software with this document! Beware, bad things might happen!!
Or something along those lines.
Anyway, it seems to extract alright, despite the dire warning, and then I have a new pdf, which does open in Preview.app.

But sadly, they have spend so much time and effort in generating a PDF portofolio that can only be opened with some latest version of the Adobe Reader, but failed to include something basic like a clickable table of contents.

Philips should reconsider this: go back to regular PDF (or *gasp* XPS) so anyone can open it, and include links in the manual - they're very useful!

Intelligent words on standards

2009-11-11T15:56:00.002+01:00

Here's a nice article on what (and what not) defines a good standard. Nice read.

Open Government: PDF not so good

2009-11-02T22:24:00.004+01:00

Here's an interesting article which describes the issues one faces with processing information that the government publishes, and why PDF is not such a great format for this.
Note that XPS has the advantage that it is XML based, which allows parsing and processing by XML enabled software.

Software Design Review

2009-10-19T22:04:00.002+02:00

I'm a regular reader of a Philip Greenspun's blog.
He has written an interesting article on the subject of 'Software Design Review'.

The problem he tries to tackle is a classic in the field of software development: how can non-technical management manage a software project. It sounds a bit silly, but it really is a problem.
Small and large software project all over the world fail miserably for years, and still are failing.
From small 'in company' projects, to big government funded undertakings, the reality anno 2009 still is that these projects are delivered not in the given time budget, often perform poorly, do not function properly, etc...

Philip Greenspun's argues that the software development process is too opaque, and that it needs proper third party design review at the start, during and at the end of the project.

It's an interesting proposal, and it it can be seen as having an external technical on-site stakeholder present all the time. This certainly makes sense, as I agree that a lot of projects are suffering from a lack of focus, and regularly a re-calibration of the business goals is healthy to spot problems early on, and deliver on-spec, on-time, on-budget.

However I do taste quite a bit of bureaucracy in the proposal, with al lot of documentation that has to be produces during all the steps.
A lot of outsiders to the field tend to compare software building, with real building (like in a building a house). But this analogy doesn't hold true.
First of all, software is not build from ready made, fully specced, 'parts' Nobody guarantees you anything when talking about 'software parts'. Some have SLA's, but even then a lot of things are 'unknown', 'not tested', 'never tried', 'fixed in next version' etc...
Experience also learns that it is very hard to have a fully fleshed out and final design before construction, as the 'architecture' tends to evolve based on changing requirements. This is why the Agile development practice leads to better results than the Waterfall method.

But I do support the call to lift the practice of software development to a higher level. And being both a software developer and running a business, I also do think that the practice of developing software needs a more formal methodology, and lead to more predictable results.

NiXPS View 3.0 features: XPS Notes

2009-10-14T11:54:00.002+02:00

One of the exciting new features of NiXPS View v3.0 is the ability to add notes to an XPS document.

We invested a lot of time and in effort in this, as we were faced with a few challenges.
Not the least the fact that the XPS specification doesn't have the annotations functionality built-in.
Which either gave us the option to not implement it at all (like competitors do), or work around this limitation.

We feel that notes are a compelling addition to the to the XPS format, especially on Windows, where this brings XPS to a much higher, more usefull level. So technically we are working around the limitations of the XPS spec by putting the notes in the XPS content. This ensures that other, non-notes aware XPS Viewers show the notes information.
In NiXPS View you can manipulate an delete the notes, in other viewers you merely view them.
To counter the effect of not being able to move a note in a non-NiXPS Viewer, we made them transparent, allowing to see what the note covers (in NiXPS View you can hide the notes, or move it).

So in summary: NiXPS View allows you to annotate XPS files, and in such a way that they are visible in every XPS viewer too.

Here is a demo of the notes feature:

NiXPS View v3.0 Notes Demo from nixps on Vimeo.

Adobe recommends disabling JavaScript to avoid PDF hack attack (again)

2009-10-13T12:18:00.003+02:00

Dixit computerweekly.

Ah - the pain of being popular.

Or maybe, because the format got a bit out of hand.
The other day I found this gem: PDF/D
Oh yeah, yet another PDF/something subspec, this time a PDF subspec that is really, really, for documents.
Hence the 'D' - see?
And they have committees and consortium and everything like the real grown-ups have.

I think we're close to having a PDF spec for every letter of the roman alphabet, the joy!

XPS Imposition

2009-09-30T13:00:00.003+02:00

I've written a small example script for NiXPS View v3.0 that implements XPS imposition.

Given a multipage file, it imposes 2 pages on 1 landscape A4 - so a 16 page document will yield an 8 page document, where each page has 2 pages on it.

The script is fairly simple, about 50 lines of code:

First, define our A4 paper size:


// paper size, use A4
lMaxWidth=1056;
lMaxHeight=816;

Then create a new XPS file:


// create a new XPS file, with a single document
lNewXPS=new NOPackage();
lNewXPS=lNewXPS.create(true,"spreads.xps");
lNewDoc=lNewXPS.getDocument(0);

Next, we walk over all the pages is the currently active document, and put 2 pages on each page. We do some RenderTransform magic to position the pages correctly:


// get the doc
lDocument=App.getDocument();
lNumberOfPages=lDocument.getNumberOfPages();

for (i=0; i<lNumberOfPages; i++)
{
 if (i % 2==0)
 {
  // create a new page
  lNewPage=lNewDoc.createPage();
  lNewFixedPage=lNewPage.getFixedPage();
  lNewFixedPage.setWidth(lMaxWidth);
  lNewFixedPage.setHeight(lMaxHeight);
  lOffsetX=0;
  lNum=0;
 } else
 {
  lOffsetX=lMaxWidth/2;
  lNum=1;
 }
 // access the page
 lPage=lDocument.getPage(i);
 lFixedPage=lPage.getFixedPage();
 lPageWidth=lFixedPage.getWidth();
 lPageHeight=lFixedPage.getHeight();

 // calculate the factor
 lFactorWidth=(lMaxWidth/2)/lPageWidth;
 lFactorHeight=lMaxHeight/lPageHeight;
 lFactor=lFactorWidth;
 if (lFactorHeight<lFactor)
  lFactor=lFactorHeight;

 // copy page on top
 lNewPage.copyPageOnTop(lPage);
 lCanvas=lNewFixedPage.getCanvas(lNum);
 lCanvas.setRenderTransform(lFactor+",0,0,"+lFactor+","+lOffsetX+",0");
}

And that's it. Only thing left to do now at this point is give the newly created XPS file to the application, so the user can work with it further.


App.addPackage(lNewXPS);

As you can see you can fairly easy leverage the NiXPS SDK in Javascript this way. It's great for tools and customizations, and also for experimenting, as it is also fairly easy to convert this script to a C-Sharp or C++ source, and use it in conjunction with our SDK.

You can download the script, and find more on scripting on http://nixps.com/scripting
You can read more about our NiXPS SDK here

Fun: Arial or Helvetica?

2009-09-30T09:27:00.003+02:00

For the Typophiles amongst you: so you say 'Helvetica is so much nicer than Arial, everyone can see that'? Prove it!

More background on the Arial/Helvetica debate here.

(via Daring Fireball)

NiXPS View 3.0 features: Scripting

2009-09-29T14:01:00.005+02:00

An exciting new addition to NiXPS View v3.0 is its ability to run scripts.

Granted, this is a fairly technical feature, but it can be very useful to extend the NiXPS View applications with more 'vertical' features.

Scripting is essentially programming, so to a certain degree you need to be a 'computer geek' to be able to grok how to do this. But scripting has a fairly low barrier of entry. Especially if the scripting is based on something relatively ubiquitous Javascript.

Javascript powers virtually all websites around the internet, and chances are that if you ever had a go at building your own website, that you have encountered, and even tried writing, a Javascript.

Fact is: Javascript is fairly easy to learn and use, and if technology is not really your thing, which is very possible, than it isn't hard to find someone with the technical ability required to hack together a decent script.

We leverage our NiXPS SDK in the scripting environment, and together with some hooks for the application, one can build fairly powerful scripts which very little coding.

To aid the development of scripts, we have started a wiki where we give a small introduction to how to get around making scripts for NiXPS View v3.0. You can find this at http://nixps.com/scripting.

We are big proponents of 'learning by example', and for this we are posting example scripts on the wiki. This is a great way to experiment, and get the hang of writing small scripts.
And for technical help you could also post your question on the NiXPS mailing list

One of the first scripts that we are posting in the example section is a script that performs XPS imposition.
I'm going to write a bit more about this in a next blog post.

NiXPS View 3.0 features: UI

2009-09-24T15:26:00.004+02:00

This is the first of a series of posts that takes an in-depth look at our latest NiXPS View release.

The subject of this post is UI, one of the most , if the most, important aspects of a desktop application. I've written before about how important, and how much work it is to get a UI right.
We've invested a lot of time and effort to make the UI of NiXPS View v3.0 more efficient, and aesthetically pleasing.

Toolbar
One of the things that you'll first notice when starting up the application, is the new toolbar:

We have chosen not to fill this up with 'everything but the kitchen sink', like a lot of applications tend to do, but in stead we have opted to only offer the most used features, and put all others on the menu. This makes the application look a lot less complex, which is good, as complexity alienates users. Advanced functionality can be discovered in the menus.

So the toolbar contains:

page down and page up
zoom in and out
the tools: pan, zoom, text select & edit and the note tool
a button to toggle the sidebar
the quick search

These are the most important functions one need when interacting with an electronic document.
We have decided against putting the 'print' in the toolbar, as it would add to the visual clutter, and everyone is accustomed to finding the print feature in the file menu.

Sidebar
The sidebar contains all kinds of 'lists': an optional document outline (aka table of contents), page thumbnails, document thumbnails and the search results. These are very useful lists, but showing them by default make the UI too busy. We chose an approach to only show the sidebar when there is a reason for it (if the document has an outline, it will show by default; if the user searches, the results will be shown), otherwise it is hidden, but can be discovered by the user via the sidebar button.

Quick search
Searching through a document is a very important function; we spend a lot of time speeding it up, and made sure it works well with large documents. The moment you start typing in the quick search control, the app will start searching, without blocking the UI. This is a very natural, and pleasing way to do a search. We also provide extensive feedback during the search, so the user knows what is going on when the search takes a long while, which can be the case for very large documents.

OS specifics
We carefully crafted the application to really 'fit in' the native OS it runs on.
On Windows this means that we start-up with an empty windows, which is a drag target for opening files. Dropping a file on the icon will also open the file.
The application will open documents in separate windows, as this gives a clear 1 file = 1 window metaphor, which we fee is more natural than an MDI interface, which quickly gives a 'cramped' and 'busy' feel.

On OSX we make sure we do not show an empty window on start-up. We also implemented the proxy icon, which is a great way to map a document to it's place in the finder.
Being a document centric app, we also made sure that starting in v3, XPS files can be viewed via QuickLook - all you need is the NiXPS View v3.0 installed on your Mac.

Here's a small demo of our NiXPS View v3.0 running on Windows 7:

NiXPS View v3.0 UI Demo from nixps on Vimeo.

PR online: NiXPS View v3.0 brings annotations, scripting and PDF/A conversion to XPS

2009-09-23T15:00:00.001+02:00

Here's the link to the PR.
Download it in xps format here.

NiXPS View v3.0 released!

2009-09-18T17:36:00.004+02:00

Today we are releasing NiXPS View v3.0!
We have worked hard to make this version the best version ever, and we are introducing a truckload of new and unique features:

Notes can be added on XPS documents
Scripts allow you to automate and extend
We've added a text correction tool
PDF conversion was enhanced, and we now also support PDF/A export
The UI has been reworked and polished, with a much improved Quicksearch and improved document interactivity with the support for links and a more natural pan tool
And much more!

For a short period of time we are offering this fantastic new version at a special launch price of USD 49 (EU 35)!
(Existing v2.6 customers get this version for free.)

Give it a try and let us know what you think!

You can read more about this release here.
You can download a 30-day trial here.
You can buy a license here.

Quick, look!

2009-09-10T17:05:00.002+02:00

We introduced the world's first XPS Macintosh viewer exactly 2 years ago (more here, or here, or here).
We are very committed to the Mac, and to honour this we are introducing QuickLook support in our upcoming NiXPS View 3.0.
Because, we really think you can do more with XPS!

NiXPS SDK powers future products of Dane Prairie Systems LLC

2009-09-07T16:42:00.005+02:00

NiXPS is proud to announce that Dane Prairie Systems LLC has chosen its NiXPS SDK v2.6.3 for inclusion in the next generation of their software products.
Read more here.

Javascript and XPS, a match made in heaven.

2009-09-03T17:55:00.003+02:00

Javascript is pretty ubiquitous these days. Great for quick, usefull scripts.
Like drawing a barcode on top of an XPS, for instance.

Do more with XPS!

Meet our twins

2009-09-02T18:02:00.005+02:00

Same genes, different character, equally loved.
Our upcoming NiXPS View v3.0 for Mac and PC.

Do more with XPS.

NiXPS' offices on a 1611 AD map

2009-08-28T16:51:00.003+02:00

I stumbled upon this gem: a map of low countries from 1611.
It maps large parts of present day Belgium, The Netherlands, Luxembourg and the north of France.

NiXPS is located in the area of Ghent, Belgium. And the town called '7.Eeken' (meaning in English:'7 oak trees'), is currently known as 'Zeveneken', and is about 1 km. from our office.

Here's a detailed view, with our offices marked:

That map is almost 400 years old, and it's pretty detailed. Fascinating.

Do more with XPS!

2009-08-27T14:34:00.003+02:00

PDF files that can only be opened by Adobe Reader

2009-08-20T08:54:00.004+02:00

Apparently it's possible to create PDF files that can only be opened by the latest version of Adobe Reader
More here.

Talk about vendor lock-in.

Desktop UI design

2009-08-16T14:48:00.003+02:00

Here's a nice article that touches some interesting toppics on UI design for desktop applications.

The UI is one of the most important aspects of an application, and designing a UI that let's your user take advantage of all your brilliant code in a non-intrusive, elegant and comprehensible way, is very, very hard.
There is a lot of software out there with horrible user interfaces, and we really do not want to be part of that.
Not a lot is published on the subject of UI design & UI theory, so experience driven information like the one in the article is very helpful in designing a better user interface.

Over at NiXPS we are in the midst of preparing a new release of our NiXPS View application, and we encountering a lot of these conundrums ourselves. We are building a better UI, and we are very happy with how our next release is getting along. I'm going to show you some of this in a next post.

Microsoft and Nokia team up

2009-08-12T20:38:00.002+02:00

Microsoft and Nokia announced a partnership around Office Mobile today.
Microsoft is going to bring the Office Mobile to the Nokia handsets, which are mainly based on the Symbian operating system.

This is interesting, as Microsoft competes against Nokia with their own Windows Phone (former Windows Mobile) OS software.
On the other hand, it is not unusual for Microsoft to port it's software to other operating platforms, Office runs on Mac for years.
Also, Windows doesn't make a phone of their own, as such they are not directly competing against Nokia, which is mainly a handset maker (with a software portfolio - QT springs to mind).

This is again a sign that the mobile computing space is heating up, it's an arena where the big corps are actively playing a lot of chess...

XML issue, NiXPS SDK unaffected

2009-08-06T10:48:00.003+02:00

The Register reports the discovery of an XML flaw that appears to affect a lot of different XML libraries, as such it seems to be more of a design issue with XML, than a regular software bug.

XPS contains a lot of XML, so it's an issue that is of interest to the XPS community.

The details are scarce, but by looking at the references on the CERT advisory it seems to be related to the DTD an XML file can contain; and more specifically related to recursive DTD references.
The Apache software foundation publishes a very popular XML parsing library, Xerces.
They have implemented a fix, and the commit message appears to be: 'Avoid recursion when parsing simply nested DTD structures.' So we can safely assume that DTD recursion is at play here.

Our NiXPS SDK does not contain a third party XML parsing library, as we regarded the XML processing very vital and core to XPS processing, that we decided not to use a third party library for this.

The XML parsing implementation in the NiXPS SDK is immune to this DTD recursion issue.

Accenture chooses the NiXPS SDK

2009-07-29T11:54:00.002+02:00

I do not have the habit of announcing every deal we make here at NiXPS, but last week we have received a purchase order from global consulting giant Accenture. They are doing a project for one of their customers, and after careful evaluation, chose us.

Accenture is one of the biggest customers NiXPS has to date, and we are very pleased that they adopts the NiXPS technology for their XPS processing requirement.

It shows that XPS is becoming a reality for those who are needing and building electronic document solutions.
For NiXPS it is encouraging that we see that we are at the forefront of technolgy for editing, manipulating and converting XPS documents.

PDF: Flashy, but insecure again

2009-07-23T14:08:00.004+02:00

A brand new security exploit in PDF allows an attacker to plant malware on the computer of unsuspecting people receiving PDF documents, read the overview here.

Javascript is not the attack vector this time, it's the embedded Flash runtime mandated by the PDF 1.8 spec that presents itself useful to exploiters.

Oh dear.

OpenXPS approved by ECMA

2009-07-21T13:28:00.002+02:00

ECMA send out a press release where they announce that OpenXPS has been formally approved as a standard: ECMA-388.

It's good to have this vendor neutral standardization of the XPS specification.

Of course, now we have the interesting situation wher all the software that is installed in the field adheres to the original (Microsoft's) XPS specification. Windows Vista en Windows 7 will not generate OpenXPS, but Microsoft's XPS for the time being (read more about Microsoft's stance here).
It is reasonable to assume that OpenXPS will become the defacto standard for XPS over time, but a lot of this depends on the appearance of devices and software that are supporting OpenXPS.

NiXPS has been following the development of OpenXPS closely, and we are working on supporting it in our future products!

Reducing PDF size with NiXPS SDK v2.6.3

2009-07-17T14:38:00.003+02:00

Our latest SDK release has a few options which potentially reduce the size of a converted PDF.

It's all about fonts. In some cases it is allowed in a PDF file not to embed fonts. This is the case for the so called 'Base 14' fonts, a list of 14 fonts that need not to be embedded. A PDF viewing or processing device is required to have this font available as part of its implementation.

For very small, text centric, PDF files, the biggest contributor to file size is the embedded font.

Of course, not embedding the font is potentially problematic, as this defeats the foundation that the document should be portable, and a such contain everything to be able to properly reproduce the document.

Nonetheless, in some cases it is a tradeoff some people like to take, and in v2.6.3 we have a few options which help out.

The first option is the "Base14FontEmbedding" option. If you set its value to "DoNotEmbed", the PDF converter will not embed the font when it is one of the base 14 set.

The second option, "Base14SimilarFonts", goes even a bit further, as it will replace fonts that are similar to the base 14 set, by a base 14 font, and subsequently not embed it.

Setting these options on documents that contain a lot of text in Helvetica, Times or Arial will yield significantly smaller PDF files.

To summarize, use it like this:


 NOPackage lPackage = NOPackage.readPackageFromFile("in.xps");
 
 NOOptions lOptions = new NOOptions();
 lOptions.setOption("Base14FontEmbedding","DoNotEmbed");
 lOptions.setOption("Base14SimilarFonts","DoNotEmbed"); // only if you want to replace similar fonts by a base 14
 
 NOProgressReporter lReporter = new NOProgressReporter();
 lPackage.exportToPDFWithOptions("out.pdf", lReporter, lOptions);
 
 NOPackage.destroyPackage(ref lPackage);

Convert XPS to PDF/A

2009-06-16T15:44:00.002+02:00

Our latest release of NiXPS SDK v2.6.3 features the ability to convert XPS to PDF/A. PDF/A-1b - Level B compliance in Part 1 to be precise.

To enable this, we have introduced a new API call: NOPackage.exportToPDFWithOptions.
It takes in an NOOptions object instance, which is an object that allows you to control aspects of the XPS to PDF conversion process. It contains key/value pairs, which can be set by means of the NOOptions.setOption(key,value) call.

Here is a code sample that demonstrates the conversion to PDF/A:


 NOPackage lPackage = NOPackage.readPackageFromFile("in.xps");
 
 NOOptions lOptions = new NOOptions();
 lOptions.setOption("PDF Conformance","PDF/A-1B");
 
 NOProgressReporter lReporter = new NOProgressReporter();
 lPackage.exportToPDFWithOptions("out.pdf", lReporter, lOptions);
 
 NOPackage.destroyPackage(ref lPackage);

Of course, this is supported in our C/C++ API (Mac OSX & Windows 32/54 bit), but is also available in C#, VB.NET and the other .NET based languages.

If you are working with the Windows Presentation Foundation, it is now very easy to convert your XAML content, via an XPSDocumentWriter, to PDF/A, by means of the NiXPS SDK.

NiXPS SDK v2.6.3 released

2009-06-15T10:56:00.003+02:00

We have released NiXPS SDK v2.6.3 today.
This is a maintenance update, free for all current customers of the NiXPS SDK.

We have invested a lot of time and effort in further optimizing the rendering and conversion, both speed and quality wise.
As a result you'll notice quicker rendering and conversion performance, smaller output files and an overall quality boost.

With v2.6.3 it is now becomes possible to generate PDF files that adhere to the PDF/A-1b ( ISO 19005-1:2005) standard.
This is a PDF substandard intended to limit the scope of the PDF specification to yield PDF files that can be trusted to be archived for long time. Some customers are operating in a setting that have a PDF/A requirement, and this ability will enable them to fulfill this. I am going to run a separate post on how you can setup the NiXPS SDK to generate PDF/A, in stead of 'regular' PDF.

The object API also gets a boost. Text selection operations are further optimized, which can yield speed increases of 5-10 times.

And, being a maintenance update, we are also fixing a few bugs with this release.
Almost all of them were reported by our customers, which I would like to thank again for providing their feedback to us.
A lot of customers are relying on our software in their products or server production setting, and the feedback we are getting allows us to further improve our software and provide a field tested, high quality SDK.

You can find the changelog for this v2.6.3 release here.
You can apply for your trial version here.
You'll receive a link to download the SDK.

Enjoy!

Windows 7 to be shipped in Europe without Internet Explorer

2009-06-12T09:30:00.003+02:00

It has been reported that Windows 7 will be sold without Internet Explorer in the European Union.

This is ridiculous.

The EU closely monitors Microsoft, and rightly so. But this is not a good evolution.
If anything has been proven the last couple of years, it is that even when Microsoft supplies an internet browser with Windows, there is still competition possible. The Firefox rise is a testament to this.

Every OS that comes to the market now has an internet browser. It is like a file explorer, command shell, calculator, text editor, etc... Microsoft should be allowed to innovate in this space, and provide a browser with their OS.

New stuff coming for NiXPS SDK v2.6.3

2009-06-05T15:55:00.005+02:00

Our next NiXPS SDK v2.6.3 will have some new features we have been working on:

PDF/A: it will be possible to convert an XPS file to a PDF that adheres to the PDF/A-1b standard.
The ability to detect, and not subset, base 14 fonts when doing an XPS to PDF conversion. Which potentially reduces the resulting PDF file.
More control over the metadata stored in the resulting PDF.

We also did a lot of work to improve the quality, speed and memory use of the rendering, and the XPS processing in general.

Expect the release next week. At the same time I will post an article on how the new functionality can be used.

Have a nice weekend!

Last one about Adobe

2009-06-05T09:21:00.004+02:00

Adobe has announced the steps it is going to taken with regards to the increasing amount of PDF security issues the world is being exposed to.

Here's the post.

In summary, Adobe is going to do 3 things:

Code Hardening: (aka) From now on Adobe will start releasing code without bugs, really.
Incident Response Process Improvements: (aka) Adobe will not wait weeks and weeks anymore before reacting on the next major security issue that pops with their software.
Regular Security Update: (aka) Start your update engines! Adobe is going preparing an update treadmill so you can have all those valuable security patches quicker, and more regularly.

This last one actually puzzles me a bit, because it's not that the 'Adobe Updater' is a silent app on my machines.

Anyway, it's clear that the horse has left the stable, and Adobe is going in über damage control and starts to chase it.

Fact is: with PDF more security troubles lie ahead, and Adobe admits this.
Adobe says that they will be better prepared to react.
Are you?

(and now I'm going to get off Adobe's/PDF's back for a while)

Has PDF failed as a preferred document distribution format?

2009-06-01T17:56:00.009+02:00

Has PDF failed as a preferred document distribution format?

Yes.

It shows that PDF is ubiquitous and important enough that the bad guys see it as worthwhile to target

No.

MP3, JPG and PNG are examples of equally ubiquitous formats that suffer less exploits.
The PDF format allows Javascript payloads that execute when attempting to view the file, this can be put to use as a formidable vector for exploit code.
PDF v1.8 viewers even contain a virtual machine to run flash programs.
From the e-security perspective, a 'vanilla' PDF document should be treated as an unknown application.

What to do?

Stop using 'plain' PDF, enforce a sub standard like PDF/A, PDF/X or other from the rich PDF patchwork.
Check out alternatives: XPS is a format that keeps behaving like a (fixed) document under all circumstances.

The New Yorker cover painted on an iPhone

2009-05-26T10:17:00.002+02:00

The cover of the New Yorker this week has been painted by an artist using only his phone (read story here). It's nice to see how creative people always use and adapt technology, and use it to create beautiful things.
Here's an animation how you see the picture come to life, because the software used has a 'capture' feature to record the artists work stroke by stroke.
Imagine great masters like Vincent Van Gogh using a device like this, we would have a redo/undo stack of their paintings ;-)

In Belgium nobody can hear you scream (or can they?)

2009-05-21T09:12:00.008+02:00

Belgium is a very small country in Western Europe, internationally it's known for its chocolate, for hosting the capital of the European Union, and having one of the most complicated, yet stable, governmental system known in the Western world.

NiXPS is located in Ghent, Belgium. In the part we call 'Flanders' (like in 'Ned', yeah ;-)).
Bruno Lowagie, the creator and head developer of iText,an open source PDF generating and manipulating library, is also a Belgian resident.
We're both located in the area of Ghent, and I think we even studied at the same university (of Ghent).
I don't know Bruno Lowagie personally, but I'm following his project because it's also software in the document space, and because it's nice to see another local having success with a software project.

Now, Bruno Lowagie is having an encounter with our notorious tax authorities. I've been bitten by them in the past too.
Of course all around the world everyone thinks they are paying too much taxes, and have a reserved attitude towards their respective taxmen. But believe me, Belgium is bad, seriously bad.

Belgium has one of of the highest corporate tax and income tax rates in the world. And a very expensive social security system which lays another large percentage of taxation. It's not unusual to pay up to 60% of your income to tax and social security payments. This is ridiculous, but on the other side there are literally thousand of ways one can apply for subsidies, apply for special reductions, get benefits, etc... to try to offset the tax burden.
As a result the taxation rules are so complex, they are published in a couple of 'yellowpages style' volumes.
You actually need professional tax and legal counsel to work your way through it, and even the tax authorities admit that. Figuratively speaking, by filling a few forms this way, and not the other way, could cost you thousands and thousands of euros.

Now the taxation officials in Belgium are really working overtime to make sure you are bombarded and taxed as much as possible by attempting to 'reclassify' and 'reinterperet' your income, and throw away business expenses, as so you pay as much taxes (and social security payments) as possible. They are also allowed to do this with your income and expenses up to 7 years back in time, so this is a very lucrative business for them, and as a result ensure you never have peace of mind.

This is the context in which you have to read this:
Bruno Lowagie had a visit from the Belgian tax authorities

I feel for him, as I've been there also, having to pay a ridiculous large sum of money that feels like the government is extorting money from you like some regular mob.
I support him in his efforts, and I think it's a nice touch to blacklist all the different Belgian government bodies from enjoying from his work.

This is a great, real-life, testament to how Belgium/Flanders treats it's innovative people.

Good luck, Bruno!

OpenXPS final draft released

2009-05-12T16:34:00.003+02:00

A lot of things are happening around XPS the last couple of weeks:

ECMA has posted the final draft of the OpenXPS specification on its website here.
This will be submitted to the June 2009 ECMA General Assembly for vote.
If this draft will be accepted, then XPS will officially become and independent standard, which is great news for the format!

Microsoft also announced that XPS will be part of Office 2007 Service Pack 2 by default, currently you either have to print to the MXDW or install an after market free plug-in to export XPS directly. No more of that with SP2!

And I'm finally running Windows 7 RC, which has a revamped XPS viewer. It runs by default out of the browser, which I think is a good thing. The default XPS Viewer is a polished nice little app, great for viewing XPS, and raises the bar for NiXPS View.

We are preparing a next version of our NiXPS View, and it's going to be truly fantastic. Very soon I will post some screenshots and an insider's perspective on what we're working on.

Javascript torpedo goes at it again

2009-04-29T15:45:00.002+02:00

No more than 2 months ago, I wrote about how the JavaScript feature of PDF is turning it into a weapon for malware creators (read here).
Adobe patched their reader, but it looks like they will need to plug some more holes, as 2 new security issues have popped up involving again the embedded javascript ability of the the PDF format (info here).

Fair enough, you need to be popular to attract the the attention of virus writers, but still it would be a lot harder for anyone to write a useful exploit, if the PDF wasn't helping so much with it being able to just execute stuff like it is an application.

Follow us on Twitter

2009-04-21T10:13:00.002+02:00

We're always looking to reach out to our customers and prospects. So I thought to give Twitter a go.
Expect the latest updates and ramblings about NiXPS, software development, XPS and generally running a software business.
And do not hesitate to post direct questions, we're here to help.
So if you feel like it: follow NiXPS on Twitter, our name: nixps

RIPs should consume XPS natively

2009-04-10T12:38:00.003+02:00

I'm mailing with someone who has trouble getting his XPS data printed on their digital presses. The RIPs cannot handle the XPS format, and so the customer needs to convert the files to PS via driver sofware, leading to gigantic PS files and more troubles down the flow.

It shouldn't be like that.

XPS is a perfectly fine format for a RIP to take in, it's well specified, and any conversion to an intermediate format like PS is bound to introduce trouble (huge files, slow performance, rendering issues, etc...).

Good to read the EFI has included native support for XPS in the new release of their Micropress RIP, used in a lot of devices on the market (link to brochure).

NiXPS SDK v2.6.2 maintenance update released

2009-03-31T09:19:00.002+02:00

We have release NiXPS SDK v2.6.2, which is a maintenance update.

This is a release with bugfixes, optimizations and a few new features.

One notable new feature is the fact that from now on you can reference the DLL in your .NET project.
You need to reference the binaries that are located in the 'bin/dotnet' directory for this, as these are the only ones that contain the C# classes (the former glue code you could find in the .NET example).
You should not need the C# glue code anymore.

You can find the changelog for this v2.6.2 release here.
You can apply for your trial version here.
You'll receive a link to download the SDK.

NiXPS assembly can now be referenced in .NET

2009-03-19T15:35:00.005+01:00

A lot of our customers are using the NiXPS SDK in a .NET environment.
As our SDK is essentially a 'native' (unmanaged) library, it can be used in .NET via managed/unmanaged interop.
We have shielded this complexity for the user, and provide a C# object model that in its implementation calls further into the native NiXPS dll.

Now, for v2.6.2 we went a step further and are releasing a fully integrated .NET assembly.
This assembly is a class library that contains the object model, and has also the native NiXPS dll embedded.

As a result a .NET developer doesn't need the C# glue objects anymore, he now only needs to reference the NiXPS assembly to be able to work with our SDK.

(This will be part of the upcoming v2.6.2 release; the integrated .NET assemblies can be found in the bin/.net folder in the SDK archive.)

Combine XPS documents: add header and footer

2009-03-17T16:09:00.008+01:00

In a document workflow it is very common that different parts of a document come from separate sources.

The typical example is the document flow of invoices.
Generally invoices are generated by software that is tied to the accountancy department of a company. This invoice is then printed on company letterhead, and send out.

Ideally: to keep documents fully electronic, this last stage, combine invoice and letterhead, needs to be done in software. And both XPS and NiXPS can come to the rescue here.

First of all, getting an XPS version of an invoice out of your accounting software is very easy. With help of the free virtual XPS printer that is delivered with windows you can print from your software to an XPS file.
Of course, in a document flow invoice generation is much more automated. Chances are the accounting software can be customized to print, or even an integration with .NET is possible, so XPS can be generated on the fly.

Then combining this invoice with a company logo and a footer can be done with our upcoming NiXPS SDK v2.6.2 and the new function: copyPageOnTop().

Literally in a few lines of C# it is possible to combine any number of XPS pages, the NiXPS SDK takes care of the housekeeping needed to do this.

Let me walk you through an example for this; We have an invoice (invoice.xps) file, which we will combine with our company logo (logo.xps) and a footer (footer.xps).

First thing to do in the function: open up all our XPS files:


public static void Main(string[] args)
{
    NOPackage lInvoice = NOPackage.readPackageFromFile("../testfiles/invoice.xps");
    NOPackage lLogo = NOPackage.readPackageFromFile("../testfiles/logo.xps");
    NOPackage lFooter = NOPackage.readPackageFromFile("../testfiles/footer.xps");

The logo.xps has the logo in page 1. Our invoice is also a one pager; So to combine them we will copy page 1 of the logo.xps on top of page 1 of invoice.xps.
This will return a handle to a NOXCanvas:


    NOXCanvas lLogoCanvas=lInvoice.getDocument(0).getPage(0).copyPageOnTop(lLogo.getDocument(0).getPage(0));

This NOXCanvas is a handle to the content that was inserted.
This allows to do some customization: in this example we will apply a transformation matrix to scale the logo to 60%, and move it to position (30,30):


    lLogoCanvas.setRenderTransform("0.6,0,0,0.6,30,30");

Same thing for the footer, copy page on top, and transform:


    NOXCanvas lFooterCanvas = lInvoice.getDocument(0).getPage(0).copyPageOnTop(lFooter.getDocument(0).getPage(0));
    lFooterCanvas.setRenderTransform("0.72,0,0,0.72,0,100");

Write out the file and clean-up:


    lInvoice.writePackageToFile("../output/out.xps");

    NOPackage.destroyPackage(ref lInvoice);
    NOPackage.destroyPackage(ref lLogo);
    NOPackage.destroyPackage(ref lFooter);
}

And that's it!

To download the SDK in trial: fill out this form, you'll receive a download link (and no spam).

NiXPS Edit v2.6 reviewed at IT Enquirer

2009-03-10T21:09:00.001+01:00

There's a review of our NiXPS Edit v2.6 XPS editor over at IT Enquirer: here.

XPS: Sense Of Something Coming

2009-02-26T08:43:00.002+01:00

(I was contacted by the nice people over at digitaldocuments.debenu.com to write an article about XPS for their blog. This is the article, it is also published on 4xPDF)

Introduction
We are living in economic turbulent times, and everybody is into Web 2.0 (2.5?), social networking, new cloud services and rich internet application platforms and yet I want to talk about something so relatively low tech as an electronic document format. More specifically about an electronic document format with the boring name 'XML paper specification', or XPS for short.

I understand that you would like to tune out, but hold on for a minute and let me finish my introduction here, and then decide.

We take documents for granted, but look around in your world and notice we still tend to have a lot of paper documents around.
With computers on the desktop came word processing software and printers. We adopted this 'en masse', to the effect that I can easily assume that most of the paper documents in your world are generated on a computer, and printed.
We seem to have moved to electronic document generation almost exclusively. But we still print.

Compared to document generation, using computers to share documents is far less developed. For a lot of good, practical reasons.
We expect a document to stay properly laid out, using correct typography which we have developed over hundreds of years.
Generating this with software is fairly easy, but when shared to others electronically, we cannot be certain that our recipient has the exact same software program, with the exact same configuration so that she will be able to see the document as it is intended.

Everyone knows the irritating issues that come up when sharing native word processing files: changed fonts, text jumping around or other unwanted effects.
To solve this we should move to an electronic document format that is really intended to be an 'electronic representation of a printed document'.
With the focus on correct representation everywhere, instead of on editing.

XPS is such a format. PDF too (more on that one later). Important to understand here is that when I am talking about 'electronic documents', I mean these 'fixed document equivalent to paper' formats, intended to be extremely reliable when it comes to representation. And as you'll see, we are not using these formats nearly enough, and as a result we print, print, print...

XPS
The XML paper specification (XPS for short) is an electronic document format which aims to be a faithful representation of a printed document.
It has a modern, rich graphical model. With full support for advanced typography, full color images, all kinds for graphic primitives, and more.
It was developed by Microsoft, with the aid of print software specialist Global Graphics, and released in 2007 as part of Windows Vista.

This means that you can generate XPS on Vista from any application. Even from an old Windows app from the nineties, it doesn't matter, as it works via a 'virtual printer driver'.
Viewing is also available by default, so if you have Vista, you can view XPS files without needing to install any extra software.
What's more, all components can also be downloaded and installed on Windows XP.

The first implementations, and the specification, originated from Microsoft.
But to allow a healthy ecosystem to develop, it is unacceptable for the format to be proprietary.
To this end the XPS specification was made public by Microsoft, and handed over to the independent standards group ECMA to review, and take control of the further specification process (in ECMA's Technical Committee 46).
This effectively allows XPS to grow into an open specification: nobody needs to pay any royalties to use XPS or to make software or hardware that work with XPS.
It's also up to ECMA to grow the standard.

Microsoft's XPS goals
Of course Microsoft have their own agenda around XPS.
A lot of people seem to think this is to fight Adobe, but I believe there are various goals Microsoft wants to achieve, and that XPS is the key to them all.

First of all it's all about printing on Windows. This was not an area of much innovation in the last couple of Windows releases. Groundwork had been laid down with Windows 95 (if not with Windows 3.1) by using the Graphical Display Interface (GDI) for printing. This means that printing on Windows works more or less the same as putting things on screen, with very similar api's.
This works, but less and less so.
Printers are very high resolution devices with incredible color possibilities, the GDI interface cannot take full advantage of this.
The introduction of GDI+ mitigated the issues somewhat but fact of the matter remained: printing on windows needed major plumbing to become relevant again.

For Vista Microsoft redesigned the printing path based on a very modern filter structure, and on a very powerful, graphically rich intermediate format: XPS.
Do not underestimate this: this has an impact on every printer device manufacturer all over the world. The days of GDI/GDI+ print path are numbered, and the XPS print path is now the way to do printing on Windows.

As an extra benefit, Windows now has something Mac OS X has had for ages with their print to PDF functionality: an electronic print-out format.
Windows can print to an EMF/WMF file but these are very difficult and obscure files to share or archive and have all sorts of downsides.
Starting with Vista, XPS fills this need.

Secondly, it's about a unified description of graphics for applications and print.
One of the few advantages of GDI was that the interface was the same for screen and for print. Microsoft decided that they wanted a similar situation but arranged this on another level. Their new user interface toolkit, Windows Presentation Foundation, drastically improves the graphic capabilities of the Windows platform. WPF works with a resource format, XAML, that amongst others allows the description of a UI. Microsoft chose to keep the XPS syntax very close to the XAML syntax (or vica versa). As a result some of the good things of GDI are kept: what you describe for print can be used on screen.
This time not in the form of a programming interface but in the form of an open, standardized, XML based page description language.

This is a concept that since the days of Next with Display Postscript makes a lot of sense. Printing and UI are fundamentally different things, but basic high level graphical elements are the same for both: text (and fonts), line drawing, images, etc...

The third goal I believe Microsoft wants to achieve is to provide an electronic fixed page format platform for the Windows desktop. This opened a front against Adobe PDF. But then again, given the advantages that XPS brings on the other fronts mentioned, it doesn't make a lot of sense for Microsoft not to bring XPS more to the surface. With features like document outline, embedded links, etc... XPS can become the electronic document of choice for the Windows platform.
And as Microsoft is really a platforms company they position XPS in this context also as a platform to build solutions on. Autodesk has done this with their DWFX format which uses the XPS format as a foundation.

XPS' advantages over PDF
But what would be the advantages for a consumer or business to adopt XPS?
And moreover, with PDF being the de facto fixed format for the desktop, do we really need another format?

The short answer: yes. Let me explain.

XPS is made for print. The format is intended to be used natively by printer software and hardware.
This has a few consequences: no dynamic content, no scripting support, no embedded movies, etc... None of that - XPS is pure for print.

This is fantastic, as this ties the format as close to a printed page as possible. And that is what you really need if you were to throw away your paper documents and rely on the electronic version of it.
You also do not want a lot of conversion to happen with you electronic document before it ends up on paper as every conversion is a risk to changes and loss of quality.
If you for instance print a Word document on a regular non-XPS printer, the following conversions happen with your data:
A .docx file gets converted by Word to GDI calls (conversion 1), then the GDI calls get converted by the printer driver to an EMF (or PCL, or PS) file (conversion 2), which gets converted by the printer to ink/toner on paper (conversion 3).

As XPS printers can take in XPS natively you do away with conversion 1, and the conversion chain becomes:
An .xps file gets converted by the printer to ink/toner on paper (only 1 conversion ).
This is much more reliable. Printers are submitted to rigorous output testing so you can rely on the XPS getting converted to paper correctly.

Note that PDF was not made for print, in fact in 1993 it was all about the web. Granted the format evolved considerably, exploding into a babylonian amount of 'sub standards' like PDF/X, PDF/A, etc... PDF is constantly being made suitable for print.
Only on the very high-end you have output devices that can natively take in PDF, and these are very recent developments typically only possible the last couple of years.
For the most of us printing on the desktop, PDF gets converted like this:
A .pdf gets converted by Adobe Reader to GDI calls (conversion 1), then the GDI calls get converted by the printer driver to an EMF (or PCL, or PS) file (conversion 2), which gets converted by the printer to ink on paper (conversion 3).
This is exactly the same as any other application file format and this is worse than XPS.

XPS is also an open format and technically very modern and sane. It relies on open standards like zip, xml, tiff, png etc...
Generating and parsing XPS is fairly easy, again something that can not be said for PDF.

And to be frank: the main advantage for XPS is its potential ecosystem.
All other qualities like the rich graphic model, the XML foundation, print qualities, etc... are all very important, but the real kicker is the fact that XPS comes along with Windows. Electronic documents are only going to work if we can all generate and view them reliably. Getting the required software to be able to do this in everybody's hands takes ages. Microsoft is uniquely positioned to be able to push XPS generation and viewing capabilities in a lot of people's homes and businesses via Windows. This is huge, and by doing this Microsoft planted the seeds of a very viable ecosystem.

XPS' challenges
Of course there are challenges for the format to become successful.

Vista has not been a success. Only about 20% of the computer using population is running the OS and has the XPS generation and viewing capabilities. Most of them are also consumers and you really need business uptake as these tend to be a lot more document intensive.
However, this is a matter of time. The Windows marketshare may be erroding slightly, chances are that the coming years a lot of people will run Vista, or its successor Windows 7.
Which, from an XPS standpoint, will be the same. As Windows 7 features the same XPS generation and viewing tools, albeit slightly improved (the XPS viewer is a real standalone app in 7, in Vista it is hosted in IE7).

The format is used under the hood for XPS based printers, but the format will only shine when more applications are directly generating XPS.
Starting with Windows 7 Microsoft is making it easier for Win32 developers to take advantage of XPS. A lot is again dependent on the ecosystem. When we will gradually become less dependent on XP and run more Vista or Windows 7, software vendors will be more inclined to take advantage of this new technology.

And of course one of the big challenges is the market's resistance against Microsoft originating technologies.
I get this a lot when talking to various people about XPS.
And I understand the concern, but one needs to look at the facts and plan for the future.
Microsoft knows it operates in a much different market than ten years ago.
Standards need to be open, otherwise they won't be accepted anymore.
Interoperability is important, as people do not want to get locked-in anymore.
But everybody should still welcome a good, sound technology that aims to bring electronic document nirvana closer.

© Nick De Roeck (nick@nixps.com); February 25th, 2009

Executable code in documents leads to trouble

2009-02-23T14:49:00.006+01:00

There's a malformed PDF file going around that takes advantage of a buffer overflow in the Adobe Reader v9 software in combination with the Javascript features of PDF. The result is your PC being taken over (more here).

The advice is to disable Javascript, which prevents the attack. (PDF/-J?)

Supporting programmable code in a document file format is a bad idea, in my opinion. As this effectively transforms something fairly static called 'a document' into something very dynamic called 'an application'.

Please note that in this case a software bug (buffer overrun) gets exploited by the embedded, special crafted JavaScript code. Buffer overruns are sadly very common in released software (unchecked buffers), but they would typically only crash your application. By offering a means for anyone to run a script from inside a PDF file, the attacker could do all kinds of interesting stuff to maximize the damage. For instance the JavaScript in this attack checks which browser you run, so it can adapt its behaviour accordingly.

Documents should not contain any code, or they should be treated like applications (and checked for viruses, etc...).

XPS does not have any script support, so it regularly comes up in discussion as an argument against XPS. This is ridiculous. Not having any programmability in your fixed document format is a feature.

1234567890 is now

2009-02-14T00:31:00.002+01:00

At this current moment, Sat Feb 14 00:31:30 CET 2009 to be precise, the current Unix time is 1234567890.
Unix time is a universal time format that is defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds. It is also returned by the Standard C Library function time().
All very geeky, but if you're a programmer these things are part of the canon.
Now, the extra geeky thing is that if you would ask a computer at this exact moment the Unix time, you would get: 1234567890. Which are all the numbers, in the exact order they can be found, on a keyboard.

Ok - I have to get a life, because I seem to spend it quite a lot of it behind a computer ;-)

Anyway: Happy Valentine's Day!

PR: v2.6.1 releases

2009-02-11T09:41:00.002+01:00

February 10,2009 - NiXPS releases today a new version of its unique, cross platform XPS tools facilitating the use of XPS in professional document management environments. More here...

Update: News media pick-up:

Seybold
Quick Printing
MacTech
Packaging Essentials

NiXPS Edit and View v2.6.1 released

2009-01-28T13:28:00.002+01:00

We released brand new versions of our XPS desktop tools: NiXPS Edit & NiXPS View.

Notable changes:

NiXPS View v2.6.1 now features PDF export.

NiXPS Edit can now export XPS pages to SVG, and has a new interactive text editing tool which greatly facilitates text corrections.

Head over to our website for a trial download!

A Closer Look At The XPS Viewer In Windows 7

2009-01-19T10:25:00.002+01:00

There's quite a bit of buzz about Windows 7, and also about the XPS support in Windows 7.
Windows 7 contains the XPS virtual printer (MXDW) and a reworked XPS Viewer that is now by default a standalone application (in contract of the rather steange choice in Vista to host it always in Internet Explorer).

I'm a regular reader of the Digital Document blog from Debenu. It's primarily focused on PDF, but it holds a healthy, refreshing and open view on other things like XPS.
And great debate: we're now having an exchange about the merits of PDF and XPS when pitched against each other. Follow it here.

NiXPS SDK v2.6.1 update released

2009-01-08T15:10:00.002+01:00

Today we are releasing NiXPS SDK v2.6.1, which is a maintenance update.

Mainly bugfixes in this release, with one notable exception: the inclusion of the NiXPS Printer driver, which in combination with our NiXPS Converter SDK, allows to convert filetypes to XPS.
You can read more about using this printer driver in this blogpost.

You can find the changelog for this v2.6.1 release here.
You can apply for your trial version here.
You'll receive a link to download the SDK.

2009: Out with the old, in with the new!

2008-12-29T17:05:00.003+01:00

The Gregorian Calendar we all love and use (note: shameless Western bias), is yet again forcing us within a few days to add another year to the counter, running the total up to 2009!

Traditionally people tend to look back, evaluate and hope for the best in the future. My - this is very appropriate these days.

2008 was an interesting year for NiXPS. We released tons of new software, travelled around the world to give demo's and we had the chance to meet lot of interesting people and, most importantly, customers!
It is great to see that XPS is slowly making progress, and more an more people are building fantastic products and applications around it. We have yet to see a big uptake of the format on the desktop, but I'm convinced that this will happen, sooner or later.

This brings us to 2009. In more ways than one do we throw out the old and welcome the new!

Not only a new year, but also a new team. NiXPS found a new motivated team of investors, who took the commitment to support NiXPS in continuing and expanding its business. This is fantastic news, and holds great promise for the years to come.
2009 will probably be the year that Windows 7 will be released, which will strengthen the XPS ecosystem, as Windows 7 build upon the XPS foundation laid down with Windows Vista.
There's a good chance that 2009 will also be the year of the formal ECMA approved XPS specification, the people over at TC46 are very busy with that.
NiXPS will continue to improve its current products, and release some more. We have a lot of interesting projects scheduled for 2009, I hope to able to tell you more about this very soon.

And I also hope for the world at large that we we will learn from the crisis that is upon is in 2008, and make a better future for all of us in 2009.

Warm wishes from the NiXPS team to all of you, and may 2009 turn out be a 'Grand Cru' for you!

Convert any File to XPS!

2008-12-15T10:56:00.011+01:00

People have been asking about how to convert all sorts of formats to XPS and now we're pleased to announce there is a way to do so. All you need to do is install a printer driver and make one call to our library.

Any file format that can be printed by a program on your system will be able to generate an XPS file without any user interaction and our library will trigger the necessary calls to do so.

Let me explain what you need to do.

Our next version of the library comes with a printer driver. You need to install this printer driver on the system where you want to generate the XPS files. Download and unzip our library. In the Control Panel for your Printer you "Add a printer".

Add a local printer. When you get the following dialog:

choose to create a new local port for it. Pressing the Next button will prompt you for a suitable name. Choose something like "C:/NiXPS/output.xps"

The prompt appears to choose a printer driver.

Choose Have Disk... and when the dialog appears to insert the manufacturer's installation disk, click on Browse...

Now browse to the place where you just downloaded our library and in the folder driver choose the xdsmpl.inf file.

Click OK and Next and give the printer a name:

You can accept the default to not share the printer. Print a test page or skip that and just click Finish and you're all set:

What you have just done is install a printer driver like the (on Vista) preinstalled Microsoft XPS Document Writer that can print to XPS files. The difference however is that this one is mute. It won't come up and ask where to save the file and it won't open the XPS file afterward.

That way it can be used to generate XPS documents from whatever files are printable on your system. In other words if you have a file format you want to convert to XPS and you have an application that can print the file format you now have a solution to convert that format to XPS.

From our library all it takes is one call:


static public UInt32 convertToXPSViaPrinter(string pSourceFile,
                                            string pDestinationFile,
                                            string pPrinterOutputFile,
                                            string pXPSPrinterDriverName,
                                            UInt32 pTimeOut)

You give it paths to the source file and the resulting destination file, you give it the location of the printers output file which is the one you set up while you were creating the local port and you give it the printer name you just installed. All of that and a timeout in seconds so that when things go horribly wrong your system does not hang. The method returns whether it was successful or not. There is an example that uses this in the sample project in the SDK.

That's it. It should work on Windows XP and Windows Vista, both for 32 and 64 bit applications.

Let us know what you think.
kristof

WPF to PDF

2008-12-02T13:39:00.004+01:00

Update 09/23/2010: We have released a 100% managed SDK called NiPDF v1.0 which makes it even easier to go from WPF to PDF. Take a look at the code sample here

The Windows Presentation Foundation (WPF short) is the UI programming framework that Microsoft introduced with the release of .NET v2.0. It is a very comprehensive, and powerful UI model that seems to be picking up steam in developer cycles.

Creating an XPS file from a WPF visual is very easy; if you combine this with our NiXPS SDK to convert XPS to PDF, you can very quickly add a nice PDF output feature to your WPF application.

As a matter of fact I've gave it a try, and the following code snippit draws a WPF visual, converts it to XPS and then uses the NiXPS SDK to write out a pdf:


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Text;
using System.Runtime.InteropServices;
using System.Windows;
using System.Windows.Media;
using System.IO.Packaging;
using System.IO;
using System.Windows.Xps.Packaging;
using System.Printing;
using System.Windows.Xps;

namespace NiXPSObjects 
{

class WPF2PDF
{

static Visual CreateVisual()
{
    const double Inch = 96;
    DrawingVisual visual = new DrawingVisual();
    DrawingContext dc = visual.RenderOpen();
    Pen bluePen = new Pen(Brushes.Blue, 1);
    dc.DrawRectangle(Brushes.Yellow, bluePen, new Rect(Inch / 2, Inch / 2, Inch * 1.5, Inch * 1.5));
    Brush pinkBrush = new SolidColorBrush(Color.FromArgb(128, 255, 0, 255));
    Pen blackPen = new Pen(Brushes.Black, 1);
    dc.DrawEllipse(pinkBrush, blackPen, new Point(Inch * 2.25, Inch * 2), Inch * 1.25, Inch);
    dc.Close();
    return visual;
}

public static void Main(string[] args)
{
 try
 {
        // create XPS file based on a WPF Visual, and store it in a memorystream
        MemoryStream lMemoryStream = new MemoryStream();
        Package package = Package.Open(lMemoryStream, FileMode.Create);
        XpsDocument doc = new XpsDocument(package);
        XpsDocumentWriter writer = XpsDocument.CreateXpsDocumentWriter(doc);
        writer.Write(CreateVisual());
        doc.Close();
        package.Close();

        // now open this XPS stream in the NiXPS SDK, and export it as pdf
        NOPackage lPackage = NOPackage.readPackageFromBuffer("file.xps", lMemoryStream.GetBuffer(), (uint) lMemoryStream.Length);
        NOProgressReporter lReporter = new NOProgressReporter();
        lPackage.getDocument(0).exportToPDF("file.pdf", lReporter);
        NOPackage.destroyPackage(ref lPackage);
 } catch (NOException e)
 {
  System.Console.Out.WriteLine( "EXCEPTION: 0x" + string.Format("{0:X}", e.getError()) );
 }
}
}
}

As a WPF developer you are getting 2 important benefits here:

You can use the XPS as the printing output of your application. Giving your end-user a higher quality print-out.
Allowing your user to save the output as PDF and/or XPS, which are ideal formats for sharing.

Draw onto an XPS file

2008-11-25T15:28:00.005+01:00

Here's another example of the capabilities of our new NiXPS SDK v2.6.

The NiXPS SDK v2.6 has the ability to do processing on existing XPS files. This means that you can modify, or in this case decorate, XPS files that are coming f.i. from a different source.
In this example I demonstrate how easy it is to get access to the content stream of an XPS page, and as an example draw a red square on the page.
This code could be a nice starting point for an application that would like to add a barcode, draw a watermark, etc...

So, to start off, we are going to process a given XPS file, and write the result out to another location (in C#):


public static void test_open_drawrectangle_save()
{
 string pIn="../../examples/testfiles/Office2007_Powerpoint_Drawing_Fills_Texture.xps";
 string pOut="../../examples/output/open_drawrectangle_save.xps";

Next, read the XPS file, and get a handler to the page, and page content.


 NOPackage lPackage = NOPackage.readPackageFromFile(pIn);
 // get first page
 NOPage lPage = lPackage.getDocument(0).getPage(0);

 // get content stream
 NOXFixedPage lContent = lPage.getFixedPage();

Now, let's do some drawing. We add a path, with a square geometry and in a transparant red


 // append a rectangle
 // a rectangle is a path, we will add this in a seperate canvas (group)
 // and we will put this canvas at the end of the stack, so it will be displayed on top
 NOXPath lPath=lContent.createCanvas(lContent.getNumCanvas()).createPath(0);
 lPath.intialize();

 // geometry: (100,100)-(200,200)
 lPath.setData("M 100,100 L 200,100 L 200,200 L 100,200 Z");

 // color: ARGB - so full red, transparant overlay
 lPath.setFill("#99FF0000");

That's about it. Now save and close:


 // write the XPS file out
 lPackage.writePackageToFile(pOut);

 NOPackage.destroyPackage(ref lPackage);
}

The result is the input file, with a red, transparent square that lies over on the first page.
As the NiXPS SDK uses XPS natively, the only change you'll find in the file is that square, all the rest is exactly the smae as the input document.

HP Laserjet XPS driver

2008-11-20T15:42:00.003+01:00

A lot of printers were released this year that support XPS printing, but most of them were big, 'copier' like, office machines.

This month HP released an XPS driver for their entry level Laserjet P2030 range. At around 175€, a good laser printer for mere mortals.

This shows again that, albeit slowly, XPS is spreading.
Developers will be able to leverage the fantastic new graphic capabilities that XPS brings to the Windows platform, and users will soon be able to take full advantage of the fact that both end-user and printer use the same file format. Resulting in less costly and error-prone document conversions, and true 'what you see is what you get' document printing on Windows.

XPS Export to SVG

2008-11-13T20:25:00.004+01:00

The following short demo video shows how you can write an app in C# in a few minutes that converts XPS file to SVG, using our new NiXPS SDK v2.6.

Using the NiXPS SDK in C#. from nixps on Vimeo.

NiXPS SDK v2.6 Released!

2008-11-12T15:24:00.006+01:00

Today we are releasing a new version of our NiXPS software development kit: NiXPS SDK v2.6 (read the PR here).

As more and more customers are using .NET, we worked really hard in providing a much better C# interface.
We already have a very elegant C++ object model, which allows you to do all kinds of high-level and low-level modifications to an XPS file, but in C# you were left with the base C api. The same power was there, but not very convenient to use.
All of this changes now in the v2.6, as we have invested time and effort in offering the exact same object model for C# users, than the one that is (and keeps being) available for C++ users of the library.

However, there are also goodies for C/C++ developers.

We include a new conversion output: Scalable Vector Graphics (SVG), and made various improvements on the core technology based on feedback we have received from customers.

As we are big proponents of learning by example, we also increased the amount of examples we are supplying in our SDK. We plan on bringing these on-line too.
The examples are available for both C/C++ developers and C# developers.

A lot of these examples are a result of feedback we get from prospects and customers. The information shared between our technical support and customers could benefit everyone working with, or thinking about working with, NiXPS software.
That's why we are setting up a forum with the intentions to share information, experiences, questions, etc... about NiXPS software.
I would like to invite you to join the NiXPS Google group. There is not much content there yet, but I'm sure this will change if more people join over time.

Finally some more info about NiXPS SDK v2.6:
A full overview of this new release, including a feature matrix, can be found here.
You can request a trial version by filling-in this form.
Purchasing information can be found here.

Try it out, and let us know what you think!

PS. This v2.6 release is free for everyone under maintenance.

Happy Election Day!

2008-11-04T08:50:00.004+01:00

XPS in Windows 7

2008-11-03T11:14:00.004+01:00

Last week Microsoft held its Professional Developer Conference (PDC) in Los Angeles.
One of the highlights of the show was Windows 7, Microsoft's Vista sucessor.
Here a NiXPS we're of course interested in Microsoft's roadmap for XPS, and we were able to find some info on this.

Windows 7 will evolve on the foundations that are being layed out by Vista, as such the printing path in 7 will be XPS based, as it is now in Vista.

The XPS Viewer in Windows 7 will get a makeover, Wictor Wilen describes this more in detail in his blog.

Adrian Ford has given an extensive presentation on the PDC about XPS in Windows 7, and how it allows you to bridge the gap between documents an printing. You can watch it here.

Update: the folks over at the XPS blog have published an overview of the new XPS things to be expected for Windows 7.

There are lies, damn lies and benchmarks.

2008-10-15T11:15:00.002+02:00

One of our competitors have published benchmark results regarding their XPS viewing software.
To much of anyone's surprise the study reveals that their solution is superior to every other solution on the market today!
Both in terms of features, and in performance and quality of rendering.

Ok.

The document presents a feature comparison. But it leaves out the numerous features (like pdf conversion, editing, unlimited Zoom, etc...) our competitor's product doesn't have, but some of the other products that were tested do have. (Of course, we need to speculate on this, as the competitor's product is not generally available - it cannot be downloaded for trial, nor purchased from their site).

The document also contains benchmark tests.
It's not very difficult to make sure that your application performs well on a set of test files.
What matters is if you perform well on the files that actual users are generating and sharing. And I seriously doubt that the benchmark in question is a good test for that.

I've been following the XPS market for quite a while now, one thing this market does seem to have in abundance are benchmark suites.

But the thing is, benchmarks really don't tell you anything.

They don't tell you that the tested software runs great on your files.
It tells you it runs great on the test set.
And if a vendor publishes these results, you bet that they will have made sure that their software performs well one these few files.

It's a debatably tactic to discredit competitors.

The relevancy of this to you as a customer I think is not that great.
I wouldn't buy the snake oil.

NiXPS SDK by example: selecting and enumerating objects on an XPS page

2008-10-13T11:49:00.004+02:00

The NiXPS SDK provides a an object model of the XPS page content to its users.
This has the nice effect that objects can be refered to by their ID, and all sorts of other nice things become possible like selections etc...

I would like to illustrate some of these aspects via an example that I've sent to a customer the other day.
This customer is looking for ways to get hold of the geometrics of all the objects on an XPS page, and wants to do further calculations based on that.
This is fairly easy to do with our NiXPS SDK v2.5.3, and I'll describe the example and code here (in C++).

First - some housekeeping: opening a file, and getting a handler to page we're interested in:


void test_walk_content(ostream &os)
{
 NOPackage *lPackage=NOPackage::readPackageFromFile("../testfiles/Virtual_PC_Technical_Overview_2007.xps");
 
 // first document, first page
 NODocument lDoc=lPackage->getDocument(0);
 NOPage lPage=lDoc.getPage(0);

I use a test file here that I pulled from the internet.
Next, we need to make sure that the NiXPS library calculates the geometric information for the particular page.
Currently this is a by-product of rendering, so we instruct the library to render to a very small buffer.
(In v2.6 we are going to decouple geometric calculation from rendering.)


 // render to calculate bounding boxes
 UInt32 lBufferLength = 10 * 10 * 3;
 UInt8 *lBuffer = (UInt8 *) malloc(lBufferLength);
 memset(lBuffer,0,lBufferLength);
 lPage.renderToImage(lBuffer,10,10,true);
 free(lBuffer);

Next we select everything on the page, and get hold of the selections list, which is a NOSelection type:


 // select all content on the page
 lPage.selectAll();
 // get selection
 NOSelection lSelection = lPage.getCopyOfSelection();

With this NOSelection type, we can now enumerate all objects:


 // enumerate the selection, get the boundng box (in XPS document coordinates), and
 // print this out, together with the type of object and its ID
 UInt32 lNumberOfSelectedObjects = lSelection.getNumberOfSelectedObjects();
 UInt32 i=0; for (;i<lNumberOfSelectedObjects;i++)
 {

For every selected object, we get the bounding box


  NOBase lSelectedObject = lSelection.getSelectedObject(i);
  NCommon::doubleRect lRect = lPage.getBoundingBox(lSelectedObject.mID);

And we find out the type, and store that in a string for printing it out later:


  std::string lType="unknown";
  switch (lSelectedObject.mType)
  {
   case xPath:  lType="Path"; break;
   case xGlyphs: lType="Glyphs"; break;
   default:  lType="SomethingElse"; break;
  }

We now summerize everything by printing it out, this is also the end of our loop:


  os << i << ": ID:" << lSelectedObject.mID << " Type:" << lType << " bbox [" << lRect.mTop << "," << lRect.mBottom << "," << lRect.mLeft << "," << lRect.mRight << "]" << std::endl;
 }

and it also concludes our function

There is a lot of powerful functionality like this in our NiXPS SDK, everything is listed in our api documentation.
But an API reference doesn't really have the same illustrative power, as a real code example holds.
That's why we ship code examples in our SDK, and continue to enhance this by adding more samples to the SDK.

NiXPS SDK v2.5.3 released

2008-10-09T08:59:00.003+02:00

We released a maintenance update for our SDK: NiXPS SDK v2.5.3.

The release contains mainly bug fixes, but also a new API call to generate a PDF file from a multi-document XPS package in one go. This was requested by a customer, and we felt that it makes a lot of sense to add a such a convenience call to the API.

You can find the changelog for this v2.5.3 release here.
You can apply for your trial version here.
You'll receive a link to download the SDK.

I would also like to take this opportunity to thank our customers.
Your valuable feedback allows us to build an even better product!
Keep sending your feedback out our way!

XPS Variable Data example with the NiXPS SDK

2008-09-12T12:31:00.005+02:00

The XPS file format lends itself very good for so-called variable data applications.
Roughly defined, variable data applications use the process of taking a template document, and generating different copies of this template, each containing some variable content. This could be text, but also graphics like images.
Typically the variable content comes from a database.
If these generated documents are also printed out, then people tend to talk about variable data printing(VDP).

Some real world examples of variable data processing:

Invoices. The base invoice layout stays the same, but the content changes depending on who and what.
Personalized direct marketing pieces. You know, these 'Hi Mike, you have won $10.000!', and variants ;-)
Bills. For instance mobile phone bills, or credit card bills.
Ads. Some real estate ads for instance have a similar layout, only the picture and the description of the property changes.
All sorts of custom paperwork like insurance policies or contracts, where most of the content is always the same, just some particular info that needs to change for each copy.
Etc...

It's all about combining graphical rich documents with data pulled from a database.

Now XPS is a format that really shines here, more on that below.
I will first demonstrate how to implement this using our NiXPS SDK.

Generating an XPS template is very easy. Either you can export your template document directly from your application (Office 2007 allows this), or otherwise you can print to an XPS file with the free XPS document writer that Microsoft ships with Vista (separate free download for XP).
Make sure you put some placeholders in the content where you want the variable data to go.

In our example we use a fax cover sheet in Word, where the sender, recipient, subject, etc... are all replaced with placeholders called TAG_TO, TAG_FROM, etc...
Saving this to XPS is a snap with the XPS export plug-in in Word 2007.

Now, we will use our NiXPS library from .NET to do the variable data processing.
Data can be stored in various ways, and I'm sure that pulling them into a .NET environment will not be that difficult. In this example I use a fixed set of data, as I want to demonstrate NiXPS variable data features, not database access functionality.

To try this out you need to download our NiXPS SDK v2.5.2, you can apply for a trial version here.
You will receive a link via e-mail which gives you access to our SDK.

So, what we need is a few lines of C# code to do the variable data processing:


// This routine replaces a given string in a document.
// It detects if a font is subset, and replaces the font.
static void doReplaceText(NOHandler pDoc, string pSearch, string pReplace, string pFontSubstitute)
{
    NOVectorHandler lMissingFonts = NOVector_new(pDoc);
    NODocument_searchAndReplaceText(ref pDoc, System.Text.Encoding.UTF8.GetBytes(pSearch), System.Text.Encoding.UTF8.GetBytes(pReplace), lMissingFonts, 1);

    if (NOVector_size(ref lMissingFonts) > 0)
    {   // in this case, the font needs replacing, we replace this with Arial by default
 NOHandler lFont = NOFont_new(ref pDoc, NOVector_getPartIDAtIndex(ref lMissingFonts, 0));
 NOFont_replaceWithFile(ref lFont, System.Text.Encoding.UTF8.GetBytes(pFontSubstitute));
    }

    NODocument_searchAndReplaceText(ref pDoc, System.Text.Encoding.UTF8.GetBytes(pSearch), System.Text.Encoding.UTF8.GetBytes(pReplace), lMissingFonts, 0);
    NOVector_delete(ref lMissingFonts);
}

// main test program
static void TestSearchAndReplace()
{
    string lFile = "..\\..\\examples\\testfiles\\template.xps";
    string lFileOut = "..\\..\\examples\\output\\template_replaced.xps";
    string lFontFile = "..\\..\\examples\\testfiles\\Arial.ttf";

    NOHandler lFileHandler = NOPackage_readPackageFromFile(System.Text.Encoding.UTF8.GetBytes(lFile));
    NOHandler lDoc = NOPackage_getDocument(ref lFileHandler, 0);

    doReplaceText(lDoc, "TAG_TO",           "Mr. Recipient", lFontFile);
    doReplaceText(lDoc, "TAG_FROM",         "Mr. Sender", lFontFile);
    doReplaceText(lDoc, "TAG_COMPANY",      "Acme Inc.", lFontFile);
    doReplaceText(lDoc, "TAG_DATE",         "09/30/2008", lFontFile);  
    doReplaceText(lDoc, "TAG_FAX",          "(06) 555-1234", lFontFile);
    doReplaceText(lDoc, "TAG_PAGES",        "1", lFontFile); 
    doReplaceText(lDoc, "TAG_PHONE",        "(06) 555-1235", lFontFile);
    doReplaceText(lDoc, "TAG_SENDER_REF",   "REF/234-67", lFontFile);  
    doReplaceText(lDoc, "TAG_SUBJECT",      "Variable Data Fax Example", lFontFile);
    doReplaceText(lDoc, "TAG_REF",          "REF/44-66-77", lFontFile);

    NOPackage_writePackageToFile(ref lFileHandler, System.Text.Encoding.UTF8.GetBytes(lFileOut));
    NOPackage_destroyPackage(ref lFileHandler);
}

Everything starts in TestSearchAndReplace().
We load up the template.xps file, get a handle to the first document, and start calling doReplaceText() to replace our TAGs with actual data.

The doReplaceText() function attempts a search and replace, but the first call is a so called 'dry run', this is used to see if the fonts that are used in the XPS are subset, and if this subset can be used for the new string.
Typically XPS files contain embedded fonts, and this is problematic if you want to replace a given text string with something else, chances are that this new sting uses characters fron the font that are not available.
The strategy that we use here is that we detect this, and in that case fallback to Arial.

The end result is a copy of the template, with the placeholders replaced.

The reason I say that XPS really shines here, is for a few reasons:

It is very easy (and free) to generate XPS templates. And with the fact that XPS generation software is default available by default in Vista, all sorts of exciting applications become easier than before.
The inherent quality of XPS being 'self contained' make it a very good container as a template. And not 'a specific type of XPS', all XPS.
The XPS format is XML based, and current XPS generators take full advantage of this. In combination with a powerful library like our NiXPS SDK, this becomes a very efficient way of generating a large amount of print ready documents, very quickly.
With XPS viewing capabilities becoming more widespread (also default Vista), it starts to become feasible to distribute the generated XPS copies directly to users, providing them with a personilized electronic copy they can print themselves.
Our SDK only modifies the bare minimum (only the text constructs and the font in the example), most of the file stays literally the same. This means a lot less overhead processing (we do not parse the XPS to an object model, to then write it out again, potentially completely changed). This way we can guarantee that the quality of hte output matches the input. Also, this allows you to combine this workflow with other XPS processing, as our SDK doesn't touch (nor rewrites) XPS contructs it doesn't need to touch.

Spindrift on XPS and NiXPS

2008-09-05T10:32:00.007+02:00

Spindrift is a newsletter published by Digital Dots, an independent, and respected, graphic arts research group.
In their latest issue they publish an extensive article on XPS, written by Laurel Brunner.

The article is noteworthy for the fact that it acknowledges the current viewpoint in the graphic arts that XPS is regarded as a complete waste of time and space, but Spindrift arguments against it.
My personal experiences with meeting graphical arts people all around the world are somewhat similar.
Of course this is a feeling that is based on subjective arguments (Microsoft is no good, Adobe is king), rather than on objective arguments.
Not that subjective arguments are not important; perception and emotions around products (and standards) are indeed very important, but I'm inclined to think that at the end of the day it are the objective arguments that make the most sense, and will be used as a basis by customers taking business decisions.

In the article quite a number of objective arguments are presented in favor of XPS, and why dismissing it is foolish.
Most of the arguments are along the lines of the top 9 benefits I posted earlier.
But a few new ones. Like the fact that being XML based, XPS has some inherent advantages over PDF as a platform for applications like variable data output. Even against Adobe's recent catch-up with yet another PDF flavor called PDF/VT.
NiXPS is also featured in the article as one of the new generation XPS developers.
And the focus is put on our NiXPS Edit application, which provides one of the missing links in an XPS work flow: corrective editing.

Spindrift believes, and I quote:

... everyone who cares about the future of print media production landscape believes XPS could open up the market for corporate print like never before.

Amen to that.

NiXPS SDK v2.5.2 released

2008-09-03T14:05:00.003+02:00

Today we are releasing our NiXPS SDK v2.5.2.

We've added some new stuff in here, mainly PDF output optimizations.
Also, we introduced a new API call which allows you to easily convert an image file to XPS.
This is presented in more detail in Kristof's previous blog post. For the rest: more bug fixes.

Read the changelog here.

And apply for your trial version here.
You'll receive a link to download the SDK.

Give it a spin, and let us know!

Convert JPG to XPS

2008-09-01T12:24:00.008+02:00

A lot of people ask for the ability that our NiXPS SDK can generate XPS files direct from all kinds of different file formats.

We are working on a general solution for all printable document formats.
But if the file you want to create an XPS from happens to be an image file, then this is quite easy to do with our SDK.

This is possible via our object model ever since our v2.0 SDK.
But to make it easier, as of NiXPS SDK v2.5.2, we are providing an extra convience function to do this.

In the following .NET example is shown you how to use our library to generate an XPS file from a JPEG file, with only a few lines of code:


static void TestGenerateXPSFromJPEG() 
{ 
 string lFile1 = "../../examples/testfiles/siena.jpg"; 
 string lOutputFile = "../../examples/output/siena.xps"; 
 NOHandler lPackage = NOPackage_createFromImage(System.Text.Encoding.UTF8.GetBytes(lFile1)); 
 NOPackage_writePackageToFile(ref lPackage, System.Text.Encoding.UTF8.GetBytes(lOutputFile));
 NOPackage_destroyPackage(ref lPackage); 
}

(note: an 'NOPackage' is NiXPS SDK speak for an XPS file).

It all boils down to: NOPackage_createFromImage.
This call also works for easy conversion of PNG, HD Photo and TIFF files to XPS.

If you are using our library from C++ you can also make use of the same convenience function: NOPackage::createFromImage.

As an alternative you can access the XPS object model and program directly on top of the object level API of our library. Your code to achieve the same result would look like this:


void createXPSFromJPEG()
{
    NOPackage *lPackage = NOPackage::createPackage(true);
    NODocument lSourceDoc1=lPackage->getDocument(0);
    NOPage lPage = lSourceDoc1.createPage();
    NOImage lImage = lPage.addImage("../testfiles/siena.jpg");
    NOXFixedPage lFixedPage = lPage.getFixedPage();
    UInt32 lWidth = lImage.getWidthInPixels();
    double lXFactor = lImage.getXResolution() / 96.;
    UInt32 lHeight = lImage.getHeightInPixels();
    double lYFactor = lImage.getYResolution() / 96.;
               
    lFixedPage.intialize(lWidth*lXFactor,lHeight*lYFactor);

    NOXCanvas lCanvas = lFixedPage.createCanvas(0);
               
    UTF8String lFilename = lImage.getFileName();
               
    char lRectangle[100];
    sprintf(lRectangle,"M 0,0 L %f,0 %f,%f 0,%f z",
                       lWidth*lXFactor,lWidth*lXFactor,
                       lHeight*lYFactor,lHeight*lYFactor);

    NOXPath lXPath = lCanvas.createPath(0);
    lXPath.setData(NOString(lRectangle));
               
    NOXCP_Brush lBrush = lXPath.createPathFill(0);
    NOXImageBrush lImageBrush = lBrush.createImageBrush(0);
               
    sprintf(lRectangle,"0,0,%f,%f",lWidth/lXFactor,lHeight/lYFactor);
    lImageBrush.setViewbox(NOXViewBox(NOXStringBase(NOString(lRectangle))));
    sprintf(lRectangle,"0,0,%f,%f",lWidth*lXFactor,lHeight*lYFactor);
    lImageBrush.setViewport(NOXViewBox(NOString(lRectangle)));
 lImageBrush.setTileMode(NiXPSObjects::None);
    lImageBrush.setViewboxUnits(NiXPSObjects::Absolute);
    lImageBrush.setViewportUnits(NiXPSObjects::Absolute);
               
    NCommon::UTF8String lBaseString(lImage.getPartName());
    lBaseString = "/" + lBaseString;
    lImageBrush.setImageSource(NOString(lBaseString.c_str()));

    lPackage->writePackageToFile(pOut);
    NOPackage::destroyPackage(lPackage);
}

A bit more 'chatty', but it shows the flexibility of the object model.
You could use this also as a start to add more things on top (like text, more images, etc...).

If you want a trial version of our library: get it here.
You can also browse through the documentation of our library.

We appreciate any feedback and gladly help you out with all your questions.

Benefit #9: XPS leverages your investment in Windows

2008-08-06T08:00:00.001+02:00

Chances are that you already invested in Windows PCs for your business. Most probably PCs that are running Windows XP, as these are currently the most deployed business desktop (however, Vista deployments are gaining – July 2008).

By adopting XPS as your electronic document format of choice, you leverage your investment in Windows PCs. As these PCs are either already capable of generating and viewing XPS, or can be upgraded for free with the same functionality, you can enjoy the benefits of a very capable, secure electronic document, and this without purchasing extra software licenses.

XPS makes perfect economic sense.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

Benefit #8: XPS saves you money

2008-08-05T08:00:00.001+02:00

Now it gets interesting. Creating XPS files is free, provided you run Windows Vista or Windows XP. The same applies to viewing: a free viewer is built into Windows Vista.
For the other windows versions you can download this for free from Microsoft’s website.

As result, you don’t have to purchase software licenses for software to generate your electronic documents, this in contrast to other solutions.

Do the math.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

Benefit #7: XPS is a natural extension of .NET and WPF

2008-08-04T08:00:00.002+02:00

.NET and Windows Presentation Foundation are powerful and exciting technologies that are used more and more as tools to develop enterprise applications.

If your applications are based on .NET or WPF, then generating XPS documents from them is a snap. It is provided by default, at no extra cost.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

Benefit #6: XPS is efficient

2008-08-03T08:00:00.001+02:00

One of the many qualities of XPS is its focus on printing. A lot of documents end up on paper, and XPS really shines here.

XPS is the cornerstone of Microsoft’s new printing architecture for Windows Vista. It raises the bar on color fidelity, image quality and typography on printing Windows.

Printer vendors are developing native XPS drivers to let their hardware take advantage of this, and this will allow an end to end XPS workflow which will not involve any costly conversions anymore.

What you see (XPS document on screen) ends up on paper fast and correct.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

Benefit #5: XPS is easy

2008-08-02T08:00:00.001+02:00

XPS generation is available for free as it is bundled with Vista. It is available for free from Microsoft for Windows XP, and there is also a free plug-in for Office 2007. As a result, chances are that you can already create and view XPS documents, but you just don’t realize it yet.

Moreover companywide deployment, and updating, is very easy, as it is a core Windows technology. This saves time and effort for your IT team.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

Benefit #4: XPS is safe

2008-08-01T08:00:00.001+02:00

Electronic documents are no software applications, the same way paper documents do not contain moving parts, or an engine for that matter.

The primary goal of an electronic document is to be a container for human readable content, presented in a particular layout. XPS is very good at that.

Technically it is possible to add all kinds of programmable, hence executable, features to an electronic document. But the result would be a format that is potentially hazardous as these executable features can be exploited by malicious people. Recent computing history teaches us that it is not a matter of ‘if’, but more a matter of ‘when’ these kinds of features will be exploited for malice.

XPS does not contain any programmable features; as a result it is guaranteed to be safe. This is a big plus for your company, and also for the people you are sending your documents to.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

Benefit #3: XPS is a reliable format for the future

2008-07-31T08:00:00.001+02:00

XPS is developed by Microsoft, but released as an open specification and in the process of being standardized at ECMA.

The format is based on a mixture of tried and tested, open en freely available technologies as XML, ZIP, JPEG …

Information stored in an XPS file can be easily retrieved. And as the document format is described in a clear, open and freely available specification, it is a reliable format to store information in for now, but also to store for the future.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

Benefit #2: XPS is truly ‘what you see is what you get’

2008-07-30T08:00:00.002+02:00

If you send a paper document to someone, you expect him to receive something that has the same content, but also the exact same layout, images, etc… This matters, and it should not be different when sending electronic documents.

Sending native documents around is problematic, as these documents typically contain references to fonts and images that are stored on your computer, but not on your recipient's computer. It is even possible that the software at the recipient’s end, provided he even has the required software, reformats the document to another printer than the one you happen to be using. As a result: a bad experience.

Even PDF, which improved this situation somewhat, is not immune to this problem. PDF does not require fonts to be stored in the document itself for instance. As a result it is not uncommon your nicely designed PDF ends up horribly broken at the customers end.

XPS is engineered from the start to ‘contain everything’. An XPS document MUST contain everything required to correctly render the document faithfully. So no bad experiences, your recipient sees your document exactly as you intended, and without any technical hassle. XPS is truly WYSIWYG.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

More XPS info

2008-07-29T08:39:00.002+02:00

Adrian Ford published a nice article on his blog about XPS, and more specifically what the philosophy behind the format is, and how this impacts the featureset and future direction of the format.
It's a great read, and I totally agree with the focus of the format on being a true representation of paper, even if this means sacrificing more advanced technological features. It's a good sign Microsoft feels the same way about it.

Benefit #1: XPS is ideal for sharing and publishing

2008-07-29T08:00:00.001+02:00

What makes up a good electronic document format?

We at NiXPS feel that a good electronic document format should be easy and cheap to create, reliable and hassle free and easy and cheap to view.

XPS gives you that; as XPS is built into Windows, it can be generated as easy as it is to print a document. XPS viewers are also built into Windows Vista and are freely available for other platforms, so people can view them. And XPS is a graphically rich format that represents exactly the document as you made it in your authoring application like Word.

As a result you can safely send around XPS documents for document review, but also use XPS as a format to publish documents on the web. The documents will keep the exact layout and formatting you have made them in, and your recipient will enjoy a hassle free experience in using your documents.

(This article is part of the 'Top 9 Benefits of using XPS for your business'-series)

Top 9 Benefits of using XPS for your business

2008-07-28T17:54:00.003+02:00

There is a lot of misunderstanding and lack of knowledge about the XML Paper Specification (XPS) electronic document format.

In my view there are quite a number of tangible benefits to the format, and I'm going to present some of them here more in detail. I've compiled a list of 9, covering opportunities that can be realized on a business, operational and budget level. I'm sure there are more, but 9 is a good start ;-)

I'll start off tomorrow with 'Benefit #1: XPS is ideal for sharing and publishing'.

Enjoy reading them, and feel free to share your thoughts/opinions in the comments.