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:
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:
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.
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:
Amen to that. ¶ 10:32 0 Comments
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. ¶ 10:32 0 Comments
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! ¶ 14:05 0 Comments
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! ¶ 14:05 0 Comments
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:
(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:
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. ¶ 12:24 0 Comments
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. ¶ 12:24 0 Comments
