We recently encountered a PDF file, that we were able to convert to a WPF FixedDocument instance, and view in a standard DocumentViewer
It turns out that XPS is sometimes trickier to generate than plain WPF elements.
We recently encountered a PDF file, that we were able to convert to a WPF FixedDocument instance, and view in a standard DocumentViewer:
However, when we used “Save as XPS” from the DocumentViewer window and tried to view the resulting XPS file, we got the following:
Closer inspection of the XPS file revealed that the page contained the following snippet for one of the text strings on the page:
The “Indices” attribute suggests that it holds the indices of each glyph in a font, but it commonly specifies the exact placement each glyph. The snippet above does this too. It specifies the placement of the next glyph relative to the previous one.
During the computation of the location of one character, we arrived at a position that was slightly offset to the left compared to the previous one. And so we produced the offset –1. In PDF this is not necessarily an error. In principle, this technique may be used to place several glyphs on top of each other in order to produce a single “combined character”, such as characters with diacritical marks or ligatures. In practice however, negative offsets are often avoided.
This particular case was a bit unclear. It involved some invisible text that consisted of seemingly random codes. Consequently, we chose simply to ignore the negative offset:
And now all is well again. It remains to be seen however if we encounter cases where such negative offsets are more critical. The most interesting part is of course that having a valid WPF instance does not guarantee that the resulting XPS document is alright.