We have a server running SQL 2005 and Reporting services. We have a Report we use to generate purchase orders and email the resulting PDFs to our vendors. All fields in this Report use Times New Roman, either 10 or 12, point, some bold, some not. This report has not changed in months.Since Monday our vendors are reporting they are unable to copy and paste text out of some of the sections of the report. They get question marks, or boxes, not the text. This only happens on some of the fields in the report.Neither the report nor the database has changed. SQL Server was upgraded over the weekend to 9.0.3282, the CU9 update. There may have also been some security patches applied, not sure which.PDFs generated after the upgrades now have an additional font listed in the File | Properties dialog of Adobe Reader 9. It's a TrueType font. Does anyone have any ideas or knowledge about how the PDF rendering component of MS Reporting Services may have changed? Any help would be welcome.Barry Seymour

Hi Barry, For the additional font that now shows up in the Files | Properties dialog does it list Encoding: Identity-H? If that is the case then it 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. Thanks, Andre

Yes, I think you've found it. The document in question has an additional font of type Identity-H. PDFs rendered before this change do not have that font.The puzzler is that the bits of the report that are defined in the report design itself (labels, headers, etc) and SOME data fields copy/paste just fine -- others don't.The shipping address is the one the vendor needs -- and I use an expression to concatenate the various address fields for this so it looks nice. I use a series of IIF statements to contact fields with CR/LF only if the field is not empty. =iif (Trim(Fields!shipto_name.Value) <>"", Trim(Fields!shipto_name.Value) & " " & vbCrLf, "") &iif (Trim(Fields!shipto_comp.Value) <>"", Trim(Fields!shipto_comp.Value) & " " & vbCrLf, "") &iif (Trim(Fields!po_number.Value) <>"" and Trim(Fields!shipto_name.Value) ="PC Mall Warehouse", "Attn: PO " +Trim(Fields!po_number.Value) & vbCrLf, "") &iif (Trim(Fields!shipto_address.Value) <>"", Trim(Fields!shipto_address.Value) & vbCrLf, "") &iif (Trim(Fields!shipto_ref1.Value) <>"", Trim(Fields!shipto_ref1.Value) & vbCrLf, "") &iif (Trim(Fields!shipto_ref2.Value) <>"", Trim(Fields!shipto_ref2.Value) & vbCrLf, "") &iif (Trim(Fields!Shiptocsz.Value) <>"", Trim(Fields!Shiptocsz.Value) & vbCrLf, "") & iif (Trim(Fields!shipto_day_phone.Value) <> "", "Phone: " & Trim(Fields!shipto_day_phone.Value) & vbCrLf, "") &iif (Trim(Fields!shipto_fax_phone.Value) <>"", "Fax: " & Trim(Fields!shipto_fax_phone.Value) & vbCrLf, "") & iif (Trim(Fields!orderPO.Value) <>"", "End Cust. PO: " & Trim(Fields!orderPO.Value), "")Could this be a factor in the rendering of some of this data as 'Identity-H?'

Andre, I know you guys are busy, have tons of things to do, etc....but I have a difficult time understanding why you would break this functionality when the bulk of your users (yes, I am being US/European centric) do not give a wagging donkeys tail about complex script characters. People copy from pdf's all the time. This change BREAKS functionality. Are you offering a free upgrade to 2008 for the people who it affects? I'm sure the fix is as simple as swapping a dll out I hope, but the point is that the kb article mentions nothing about breaking the copy/paste functionality. Sorry for ranting, but these types of changes is what can really piss off the majority of your customers if not documented properly. Some companies do go through each and every kb article before they deploy stuff, and they still would have no idea that this "fix" would have broken the pdf copy/paste. Then they spend hours online with support, or have to post to the forums, etc.... All the while the app sits there broken. This isn't part of normal user acceptance testing to ask if they can still copy from the pdf. We have always been able to copy from pdfs, whether from Adobe, Microsoft, PDF Converter, etc........ And offtopic, but I want gridlines in Excel. Actually, what I want is a separate render option. An Excel output, and an Excel with Gridlines option. My customers can figure that out. Not borders that are rendered as cell borders in Excel. The workarounds that are given are unacceptable. This is yet another one of those issues that has existed since SSRS 2000, been complained about frequently, yet has not been addressed. SOMEONE there must know how to add that flag when they render the output to Excel. Since there has beentime to add Glyph character support, could someone start working on this? Shango

Shango, thanks for the post. You made me chuckle. ("Wagging donkey's tail" indeed!)FWIW I'm on the phone as we speak with an MS support technician and he's been very helpful. We're uninstalling the CU9 upgrade and hope to be back where we were last week. At least Andre was able to identify the exact problem pretty quickly, which has not traditionally been my experience on these forums. We should be back to proper functionality a lot more quickly than I expected.If we can find the bandwidth to install a copy of SQL08 to test this I'll post my results. I'm not CLOSING this thread yet, however... I'm hoping to have more info, so those of you who are interested, stay tuned...Barry

Uninstalling CU9 fixed the problem.

Barry, Yes, what you described (specifically, the CR/LE separator) could trigger a block of text to be now treated as complex. A potential workaround could be to have the elements of an address live in separate text boxes (to avoid the CR/LE separator). I apologize for the inconvenience that caused you and Im glad to hear that uninstalling CU9 fixed the problem. Im also looking forward to your results using SSRS 2008 if you should find time to try it out. Shango, I understand your frustration. When looking at the technical underpinnings of this issue I almost feel it would have been better to explicitly state that we do not support copy/paste for documents generated by our PDF renderer until we implement writing out the ToUnicode cmap (mapping a Glyph ID to a Unicode char). The reason is that not being able to change when we write out as ASCII characters or Glyph IDs would severely limit our ability to address issues like the complex character bug I referred to. You might argue that not officially supporting copy/paste is lame and, quite frankly, I agree. However, it is a rather tough thing to choose what do out of a big bucket of items that all are important for certain customers. That said, as the outcome of this thread (and what issues it caused for Barry) I can ensure you that this feature gets bumped up in the list of the many things that we plan to do next. Thanks, Andre

Not really an option, removing the vbCrLf -- I did it this way so one field could hold a complete address and allow for addresses that have a second address line, or not, etc. etc.I really doubt we'll get back to testing this on SQL2008 any time soon, and now we have to continually monitor this server and make sure this doesn't get reinstalled via a HotFix or something. I hope you guys can issue a fix for this soon. Barry

Some of our customer have exported their reports to pdf. When they opened the pdf file and the report footer text contains all unreadable (jumbled) characters. If they opened it again, the jumbled text will changed slightly. When they open it again and again, the footer will eventurally 'corrected itself'. They first have the problem when they have adobe reader version 7 installed. We have told them to install the version 9 but the problem is till happening.After a further investigation, this problem occurred after we applied some windows updates to our live server. one of this is :- Hotfix 3282 for SQL Server Reporting Services 2005 ENU (KB953752)We have a similar test server with the same reporting services hotfix 3282 applied.The PDF file generated after the hotfix installed can be viewed Ok in adobe reader version 9, but NOT with some other pdf file viewers. (e.g pdf complete) The text in header AND footer becomes unreadable.If we un-installed the hotfix. The PDF file generated can be viewed by adobe reader version 9 and other pdf file viewers and everything is corrected.Also if I only replaced the Microsoft.ReportingServices.ImageRendering.dll - version 9.0.3282 (which installed by the HotFix) with Microsoft.ReportingServices.ImageRendering.dll - version 9.0.3042 instead of uninstall the Hot Fix Completely.The PDF file generated can be viewed by adobe reader version 9 AND other pdf file viewers. I am not sure whether this problem is related to this but we do have the same copy and paste problem. We are going to uninstall the Hot fixfrom our live server and hope everything is OK.

Hi Andre,Has this change inthe wayfonts are handledin PDFs exported by SSRS been implemented in SQL Server 2005 Service Pack 3?Thanks,Paul

To answer Paul's question:> Has this change inthe wayfonts are handledin PDFs exported by SSRS been implemented in SQL Server 2005 Service Pack 3?Yes, the recently released SP3 includes font embedding for PDF export.Thanks,RobertRobert Bruckner; http://blogs.msdn.com/robertbruckner; This posting is provided "AS IS" with no warranties, and confers no rights.

Robert,We are experiencing a similar problem here. I had installed CU9 to SQL Reporting Services 2005, and we intermittently experienced the problem. In our case it was not the header/footer but an important section of the body of the report. I work for a hospital, and we are using this for our downtime reports, so it has to be functional.I copied an older version of the image rendering dll mentioned above, 3042, which resolved that issue. However, that brought back the black background when previewing problem.I have since installed CU10, but now the problem has reemerged, but is slightly different. Occasionally, when viewing the pdf file that has been exported from SSRS the characters in that same area of the body of the report appear as symbols. Page down, page back up, and sometimes it goes away.Is this problem still prevalent in SP3? If not, do you have a workaround?Thanks for your help.Teresa

Hello Teresa, I recommend to install SP3. However, since you have currently SP2 CU#10 installed, I think you need CU#1 for SP3 because CU#10 and CU#11 are special cases due to the parallel release of SP3. See this blog posting for more details:http://blogs.msdn.com/sqlreleaseservices/archive/2008/12/20/cumulative-update-1-for-sql-server-2005-service-pack-3.aspx HTH,RobertRobert Bruckner http://blogs.msdn.com/robertbruckner This posting is provided "AS IS" with no warranties, and confers no rights.

Hello, All. We also had the same issue as Barry. After upgrading to SQL Server 2005 Service Pack 3, we could no longer copy and paste from PDF's rendered by SSRS. Any command that would create a line break would force the entire text block to render as a glyph. This displays fine in the PDF, but creates a bunch of empty boxes when pasted into something else. As a workaround, we went ahead and installed Service Pack 3 and then rolled back the Microsoft.ReportingServices.ImageRendering.dll to version 9.0.242 It was as simple as deleting the newer version installed by SP3 and replacing it with the pre-service pack version. You can find the DLL in C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\bin Since it's a MS Assembly you don't have to worry about unregistering/registering the DLLs. Pretty simple. I hope this helps everyone who has been told to "just upgrade to SQL 2008" Good luck! Glade Mellor

Hi Guys, is anyone aware of a similar fix for Dynamics AX 2009? We're encounterring a similar issue and I'm hoping that a resolution can be found by tweaking an appropriate DLL (or by a neater solution if available). More info here: https://community.dynamics.com/product/ax/f/33/t/79073.aspx Thanks in advance, JB