Accenture chooses the NiXPS SDK I do not have the habit of announcing every deal we make here at NiXPS, but last week we have received a purchase order from global consulting giant Accenture. They are doing a project for one of their customers, and after careful evaluation, chose us.

Accenture is one of the biggest customers NiXPS has to date, and we are very pleased that they adopts the NiXPS technology for their XPS processing requirement.

It shows that XPS is becoming a reality for those who are needing and building electronic document solutions.
For NiXPS it is encouraging that we see that we are at the forefront of technolgy for editing, manipulating and converting XPS documents.  ¶ 11:54 0 Comments

  PDF: Flashy, but insecure again


A brand new security exploit in PDF allows an attacker to plant malware on the computer of unsuspecting people receiving PDF documents, read the overview here.

Javascript is not the attack vector this time, it's the embedded Flash runtime mandated by the PDF 1.8 spec that presents itself useful to exploiters.

Oh dear.  ¶ 14:08 0 Comments

  OpenXPS approved by ECMA ECMA send out a press release where they announce that OpenXPS has been formally approved as a standard: ECMA-388.

It's good to have this vendor neutral standardization of the XPS specification.

Of course, now we have the interesting situation wher all the software that is installed in the field adheres to the original (Microsoft's) XPS specification. Windows Vista en Windows 7 will not generate OpenXPS, but Microsoft's XPS for the time being (read more about Microsoft's stance here).
It is reasonable to assume that OpenXPS will become the defacto standard for XPS over time, but a lot of this depends on the appearance of devices and software that are supporting OpenXPS.

NiXPS has been following the development of OpenXPS closely, and we are working on supporting it in our future products!  ¶ 13:28 0 Comments

  Reducing PDF size with NiXPS SDK v2.6.3 Our latest SDK release has a few options which potentially reduce the size of a converted PDF.

It's all about fonts. In some cases it is allowed in a PDF file not to embed fonts. This is the case for the so called 'Base 14' fonts, a list of 14 fonts that need not to be embedded. A PDF viewing or processing device is required to have this font available as part of its implementation.

For very small, text centric, PDF files, the biggest contributor to file size is the embedded font.

Of course, not embedding the font is potentially problematic, as this defeats the foundation that the document should be portable, and a such contain everything to be able to properly reproduce the document.

Nonetheless, in some cases it is a tradeoff some people like to take, and in v2.6.3 we have a few options which help out.

The first option is the "Base14FontEmbedding" option. If you set its value to "DoNotEmbed", the PDF converter will not embed the font when it is one of the base 14 set.

The second option, "Base14SimilarFonts", goes even a bit further, as it will replace fonts that are similar to the base 14 set, by a base 14 font, and subsequently not embed it.

Setting these options on documents that contain a lot of text in Helvetica, Times or Arial will yield significantly smaller PDF files.

To summarize, use it like this:

 NOPackage lPackage = NOPackage.readPackageFromFile("in.xps");
 
 NOOptions lOptions = new NOOptions();
 lOptions.setOption("Base14FontEmbedding","DoNotEmbed");
 lOptions.setOption("Base14SimilarFonts","DoNotEmbed"); // only if you want to replace similar fonts by a base 14
 
 NOProgressReporter lReporter = new NOProgressReporter();
 lPackage.exportToPDFWithOptions("out.pdf", lReporter, lOptions);
 
 NOPackage.destroyPackage(ref lPackage);

  ¶ 14:38 0 Comments