Reporting Services: PDF Renderer FAQ

Fonts

Have you first looked at our 'Designing for PDF Output' documentation?

Reporting Services 2000: https://technet.microsoft.com/en-us/library/aa178934(SQL.80).aspx

Reporting Services 2005: https://technet.microsoft.com/en-us/library/ms159713.aspx

Reporting Services 2008: https://technet.microsoft.com/en-us/library/ms159713(SQL.100).aspx

What is the difference between a character and a glyph?

A glyph is a specific graphical rendering - like A, A, or A of a given character - A.

Why do I see ?'s appearing in my textboxes instead of some/all characters?

This may occur when the font you have selected for the textbox does not contain the glyphs for the character you are trying to use. When rendering reports to PDF, it is necessary for us to obtain font metric information (character widths, bounding boxes, etc) from the font for the glyphs used in the report. If our calls into the Win32 GDI library tell us a glyph does not exist in the specified font, a ? will be used instead.

An example of this happening is when a report tries to display Chinese characters in a textbox defined to use the Arial font, which does not contain these glyphs. If you switch font of the textbox to Arial Unicode MS (or another font that contains these glyphs), the ?'s will disappear and the report will render correctly assuming the specified font is available on both the client viewing the PDF and the Report Server generating the PDF.

Why do I see black boxes in my textbox instead of some/all characters?

This issue is similar to the above issue but generally occurs when the textbox font is installed on the Report Server but not on the client. It can also occur if the installed font files are different on the client than on the server with the client not containing all the glyphs used in the report. The black boxes occur when the server is able to retrieve glyph and font metric information which it writes into the PDF file but the client is unable to find those glyphs.

Why do I see ?'s or black boxes in my PDF but not when I use IE?

Some application (IE, for instance) will do glyph substitution. What this means is that the application will detect that you do not have all the information needed to display a text string and will automatically attempt to find another font on the machine that is similar enough to substitute in place of the original font.

Why doesn't Reporting Services do glyph/font substitution?

We have talked about various glyph/font substitution strategies but knowing the correct decisions to make on the server supposes we have knowledge of the client machine that will be viewing the PDF. Ideally, we would embed the necessary parts of the font directly into the PDF (when the font specifically allows for this) so that the reports will look the same across client machines regardless of what fonts those clients have installed locally.

When will Reporting Services do font embedding?

This feature is definitely high on my priority list for the PDF renderer, but it's not a quick task to get right. We really wanted to get this into Reporting Services 2005 but weren't able to. And sadly, it is not currently in the latest CTP of Reporting Services 2008, either.

That said, there is a lame work-around that exists today. For reports that are delivered to a file share or from within a custom application, it is possible to post-process the PDF and embed fonts with custom code. From what I've heard/read, the pdf toolkit does not support font embedding but PDFTron does.

I've installed the font on my client/server but I still see ?'s or black boxes. Why?

For the client machine, closing all instances of the PDF viewer then reopening them should fix the issue.

For the server, restarting the services should allow the PDF renderer to pick up the new font information.

Unfortunately, I have also seen times where I needed a full machine reboot to get the client/server to recognize the newly installed font.

File Size

Why are the PDFs exported from the Win/WebForms control so large?

Compression of the PDF document is not supported in Visual Studio 2005 WinForms or WebForms controls running in local mode.  When these controls run in server mode, this limitation is not present and the server will compress the PDF files.

The controls that will ship with Visual Studio 2008 will not have this limitation, however they will not be able to compress as well as PDF files generated on the server.  These controls will make use of the .NET System.IO.Compression classes which are not as efficient as the native compression libraries the server uses.

I'm not using the controls in local mode and my PDFs are still big.  Why?

If your PDF contains charts or PNG images, those images may be translated into bitmaps before being added to the PDF file.  Although this bitmap data will be recompressed, it will not be as space efficient as the original image.  To avoid this translation, use JPEG images or PNG files of color type 3 (PNG color type information can be found at https://en.wikipedia.org/wiki/PNG).

Prior to Reporting Services 2005 SP1, PNG images of additional color types were allowed.  Unfortunately, in order to fix a bug causing some PNGs to appear corrupted when rendered to PDF we needed to add the color type restriction.  Even more unfortunate is the fact that charts are sent to the PDF renderer as non-color type 3 PNGs of high DPI.  This is certainly a limitation we want to remove in the future but very unlikely it will be fixed in Reporting Services 2005.