Corruption in wPDFViewPlus02.dll with SQL 2005 generated PDF

1. offizieller Beitrag

    We are getting corruption in certain fields when viewing a PDF file in wPDF that is generated by SQL Server 2005. wPDF can save the file correctly from within the viewer. The PDF is ok when viewed in Adobe or Foxit, either before loading into wPDF or after wPDF has saved it.

    We are using:
    wPDFViewPlus02.dll version 2.53.2.1
    wPDFView01.dll version 1.46.0.0
    wPDF.dll version 2.6.2046.26857
    wRTF2PDF02.dll version 3.2.0.11

    We have tried the latest version of wPDF; 2.58 and although the problem appears differently (the address lines look correctly formatted i.e. line feeds are in the correct places) the corruption still appears.

    We think it is related to line feed/carriage returns as the problem does not appear if they are not in the source report.

    We can confirm the problem did not happen with wPDF when viewing files generated by SQL 2000 Report Server.

    The problem does not appear when using the SQL 2005 Report Viewer control but we would rather use the wPDF libraries as they have extra functionality.

    Examples of the problem are here:
    http://www.fleettechnique.co.uk/downloads/PDF-issue/

    • Offizieller Beitrag

    Please try to copy the text in Acrobat

    "Tel: 08 ...."

    and paste it.

    You will get this

    "......................"

    Ite means that the original PDF file does not contain a valid Character to
    unicode conversion table.

    That is required for propper display in WPViewPDF.

    I assume there is a setting in the PDF generator to embed the font completely.

    It seems that Microsoft have changed the rendering in an update shipped with Service Pack 3. This topic describes the problem:


    An additional font now shows up in the Files | Properties dialog called “Encoding: Identity-H”?

    This means that some text content in the PDF Document is now written out using Glyph IDs instead of ASCII characters. That is part of a change we had to make in order to correctly support complex script characters (http://support.microsoft.com/kb/944358). These are used in languages such as Gujarati or Hindi. This fix is part of the GDI+ GDR (http://support.microsoft.com/kb/954607), which is part of SSRS 2005 CU9.

    For text content written out using Glyph IDs copy/paste is not supported for documents generated by our current PDF renderer. In order to support this our PDF renderer would need to write out a map that maps Glyph IDs back to Unicode chars. It is something that is on the list for a future release of SQL Reporting Services.

    Would it be possible for you to deploy and render one of your reports on SSRS 2008? In the latest release we added full RichText support, which in this case might give you a more granular separation in terms of what text content is written out using ASCII characters versus Glyph IDs.


    Unfortunately we cannot use SQL Server 2008 because the security layer is not compaible with our system. Will you be willing to modify your PDF lib to accomodate the Glyph changes?