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:

• 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.
  

  ¶ 12:31