NiXPS
Friday, September 12, 2008
  XPS Variable Data example with the NiXPS SDK

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:


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:
 
Friday, September 05, 2008
  Spindrift on XPS and NiXPS
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.
 
Wednesday, September 03, 2008
  NiXPS SDK v2.5.2 released
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!
 
Monday, September 01, 2008
  Convert JPG to XPS
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.
 

Archives
September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / May 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / April 2008 / May 2008 / June 2008 / July 2008 / August 2008 / September 2008 / October 2008 / November 2008 / December 2008 / January 2009 / February 2009 / March 2009 / April 2009 / May 2009 / June 2009 / July 2009 / August 2009 / September 2009 / October 2009 / November 2009 / December 2009 / January 2010 / February 2010 / March 2010 / April 2010 / May 2010 / June 2010 / July 2010 / September 2010 / October 2010 / November 2010 / January 2011 /

NiXPS home
XPS info from the creators
    follow me on Twitter
    Add to Technorati Favorites

    Subscribe to
    Posts [Atom]