NiXPS
Thursday, February 26, 2009
XPS: Sense Of Something Coming
(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 ¶ 08:43 0 Comments
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 ¶ 08:43 0 Comments
Monday, February 23, 2009
Executable code in documents leads to trouble
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. ¶ 14:49 0 Comments
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. ¶ 14:49 0 Comments
Saturday, February 14, 2009
1234567890 is now
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! ¶ 00:31 0 Comments
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! ¶ 00:31 0 Comments
Wednesday, February 11, 2009
PR: v2.6.1 releases
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:
¶ 09:41 0 Comments
Update: News media pick-up:
¶ 09:41 0 Comments
