Enfocus We signed a partnership with Enfocus, the goal is to develop exciting XPS related products based on: our XPS technology and Enfocus preflighting and quality management expertise.

We choose not to say too much about what we are exactly working on at this stage, I don't want to spoil the surprise. But this is an exciting development for both our companies, and the products that will be introduced as a result of this partnership will allow end-users to do fantastic stuff with XPS.

NiXPS is all about XPS technology, and the various different markets (Adam, Enfocus, ...) where we offer our technology illustrates how versatile our SDK is.
We will be at the upcoming OnDemand show in Boston, giving demo's and info about our applications and SDK on the XPS Land pavilion. Do not hesitate to come by if you're in the neighboorhood.

Read more about all this in our press release.

Update: media coverage:

• http://www.packagingessentials.com/grnews.asp?id=2008-02-25-21.43.50.000000
  
• http://www.printingtalk.com/news/xps/xps100.html
  
• http://members.whattheythink.com/news/newslink.cfm?id=30884
  
• http://www.silobreaker.com/DocumentReader.aspx?Item=5_828092422
  
• http://www.graphicnet.se/iuware.aspx?pageid=2476&ssoid=76552
  
• http://www.quickprinting.com/web/online/Industry-News-and-Trends/NiXPS-Announces-Technology-Partnerships-with-Enfocus-and-ADAM/1$5354
  

  ¶ 14:43 0 Comments

  XPS contains no scripting: Less Is More You can over engineer a format until it becomes a threat.

I think Microsoft took a sensible approach by not including any general executing/scripting features in XPS whatsoever. Of course, they had(have?) their share of trouble with supporting general scripting in their Office document formats.

Document formats shouldn't contain general purpose scripting or other general code executing features. People receiving electronic documents do not expect documents to behave like applications, so they won't treat them with the same prudence as applications.  ¶ 10:01 0 Comments

  Terminal Services Easy Print is based on XPS Microsoft's Terminal Services software allows client server computing like in the good old X Server days: you have your super duper heavy server (or server farm) running everything for every user, and you have your clients connecting to this server, and merely functioning as input (keyboard & mouse) / output (screen) terminals.

It's a system that makes sense in a big environment, where a lot of control is needed over the desktops - yeah, big companies spring to mind ;-)

I've played with this already a few times, and it actually works quite nice. Even to the point that you sometimes hardly notice the fact that you're working on a thin client.

Now, what has this to do with XPS?

Take a look here: the next version of Terminal Services (Windows Server 2008) is using XPS as the format to support remote to the client printing.
This is called printing redirection, it means that you are working ok on the server and all that, but you do want your print jobs to appear on the desktop printer next to you. Either the admin of the server has setup your printer on the server (meaning: network printer, driver installed, etc...). If not, you can use printing redirection: the server routes the print job to your local machine to print.

This means the server needs to generate a file and send it over to your client to be able to print. And as the server has no driver for your printer, an intermediate spool file format was chosen: XPS.

It make sense to use XPS: it contains all the resources required to be able to print, and is fully device independent, allowing high fidelity printing between the server and the client.

It's a nice demonstration of the capabilities of XPS, and illustrates the multitude of scenario's where we are going to see this format pop up in the future.  ¶ 12:40 0 Comments

  XPS from Word 2007: image downsampling I had a discussion last week regarding image resolution in XPS output from Office 2007.
Claim was that it was not possible to create XPS output from Office 2007 with high resolution images.
This is a problem - as you need high resolution images if you want to have a decent print output on a high quality print machine (f.i. on a digital printer).

This lead me to investigate this issue a bit further.

Let's first take a look at Word 2007. As a test I make a Word document and placed 3 images with different resolutions in it: 600dpi, 220 dpi and 179dpi respectively:



If you export this file to an XPS file (using the free Office XPS add-in), and enable all high quality settings:



And you check the corresponding XPS file using NiXPS Edit:



You see all the images are reduced to 96dpi resolution, this is not what we want if we want to send this document to a printer.

There is way to improve this -

Open the word document again, and select a particular image, and note the option compress pictures you have on the top left:



This controls the sub sampling of the images when exporting XPS. If you set this to the highest quality setting, and redo the export, you get a file with images with the following resolutions:



Every image with a resolution below 220dpi is not sub sampled, all images with a higher resolutions are sub sampled to 220dpi.

So for Word 2007 it seems it is not possible to make an XPS file which keeps the resolution of high-res images intact. However, given the the correct configuration, it is possible to limit the down sampling to 220dpi.

This resolution is reasonable, giving the environments and user scenario's Word 2007 is used for, however I would have preferred more control on how Word 2007 handles high-res images on XPS output.

I ran another test using Publisher 2007; here no sub sampling occurs, the images keep their exact same resolution. Please note that there are a few options in Publisher 2007 to allow sub sampling.  ¶ 12:30 1 Comments