ComponentOne PdfViewer™ for WinRT XAML can display PDF documents within your Windows Store applications without requiring any external application. With the 2013 v3 release of Studio for WinRT XAML, the C1PdfViewer control includes a new render mode based off the Windows PDF API that was introduced in Windows 8.1. This article discusses the new rendering mode, the tradeoffs, as well as when you should choose to use it.


Three years ago ComponentOne made waves with a commercial PDF viewer control completely written in XAML (Silverlight and WPF). The control was innovative for the company because no other control had become as popular overnight as the C1PdfViewer control. It pretty much forced competitors to eventually follow suite with their own viewers. The C1PdfViewer control has its own internal engine that parses PDF files and generates the visual elements for each page. The result is pure XAML (no DirectX or bitmap rendering). For optimal performance the control also uses UI virtualization and only renders page visuals as they come into view. The C1PdfViewer control tries its best to open and render any PDF document. It’s been a very challenging task for ComponentOne since the PDF syntax is very wide and inconsistent. There’s never just one way to define an object in PDF language. So as a result we always supported a subset of the PDF specification. The engine was designed so that documents containing unsupported content would still render, but the formatting might appear slightly off. For example, when an unsupported font is encountered, the control will try its best to find the closest supported font so the text will still render. For most, this was a sufficient trade-off to being able to natively display PDFs in WPF and Silverlight applications. Over the past three years the rendering engine has massively improved (up to and including the latest additions for AcroForm and annotation support in the 2013 v3 update). The C1PdfViewer control has also been ported to Windows Phone and the Windows Store (WinRT XAML) platforms once they sprouted. The rest of this article focuses on the WinRT version specifically.

Windows 8.1 Strategy

With the release of Windows 8.1, the WinRT XAML SDK now includes a native PDF library provided by Microsoft. This library is capable of reading any PDF file and generating each page as an image that you can display in your 8.1 Windows Store apps. Microsoft has not yet provided a complete PDF Viewer control - just the core ability to read PDF files. In essence, Microsoft has made it easier for ComponentOne. Now we only have to focus on the viewer and not the parsing engine. Our strategy with the WinRT XAML 8.1 version of C1PdfViewer is to incorporate this new API into the control so that our existing users don’t miss out on the inherent benefits. But we will also continue to push the rendering capabilities forward with our own parsing engine to deliver more features that are not possible using the Microsoft API alone, while also improving the engine. Our goal is to keep the C1PdfViewer as the original and best PDF viewing control available for Windows Store apps. We're one of the first to offer support for the PDF API, so now if you want to take advantage of Windows 8.1 you can. Combine that with our extensive PDF library that can also generate PDFs from code, ComponentOne has the most complete PDF offering overall.

Introducing the RenderMode Property

In the Studio for WinRT XAML 2013 v3 update we’ve incorporated the Windows 8.1 PDF API into C1PdfViewer by providing a single, new RenderMode property which specifies the rendering mode. You can now choose to use between “System” rendering, which uses the new API, or “Default” rendering, which uses our original rendering engine. The System rendering mode has no effect for WPF, Silverlight and Windows Phone developers. For these platforms, there is no Microsoft API available so the default rending approach is all that’s possible with C1PdfViewer.

When to use the System Render Mode

The new System render mode uses the Windows PDF API from the Windows.Data.Pdf namespace. This mode renders each page as an image. This mode is generally considered the safer route because it is more reliable for rendering unpredictable content. It’s also faster at presenting some pages to the user where there is less calculation for positioning content.

More Reliable for Images

The Default mode supports most common image types, including all binary stream formats supported by WinRT as well as deflated streams of several types (RGB, Monochrome, and several common indexed formats). However it does not support some formats such as deflated JPG streams, custom color spaces or halftones. It also does not support soft masks, TIFF data or DCTDecode/JPEG image encoding. These limitations make the System render mode a more reliable option because they are more likely to render. The image below shows an example of an incompatible image stream rendered using both render modes. RenderMode_Images So if you are creating a PDF Viewing type of app where the user can possibly open any PDF file they may have on their machine, then the System render mode is the best option.

When to use the Default Render Mode

The 'Default' mode renders the document using native XAML elements with UI virtualization. This is the original rendering mode I’ve already discussed. This “true XAML” approach enables some special features like text select and search because all text is rendered using TextBlocks.

More PDF Features

If you need interactive PDF features like bookmark navigation, text select, text search and annotations then the Default render mode is your best option. These features are not possible with the System render mode because each page is just a static image. Microsoft may enhance the native API in the future, but as of now these features are left unfinished. RenderMode_Default Both render modes support printing, horizontal orientation as well as gesture-based scaling and most of the API methods.


C1PdfViewer makes it very easy to take advantage of the new PDF API in Windows 8.1. All of the hard work in learning the new API is done for you. Our strategy to support more than one rendering mode is so that our users can take advantage of the latest technologies while continuing to use a familiar control and even share code with Windows Phone or WPF.

Cool! How do I use it?

If you’ve read this entire article and you’re still confused on how to take advantage of this new feature, all you have to do is load a PDF into C1PdfViewer and then set the RenderMode property to System. You can download the control inside Studio for WinRT XAML.