Skip to Content
0

Does anyone know a way to workarround the issue with CR and USP10.DLL on Windows 10?

Jun 12, 2017 at 04:10 PM

197

avatar image
Former Member

Hi!

Does anyone know a way to fix the problem with Calibri font while exporting PDFs? The issue of the text losing ligatures? (shortlink: https://goo.gl/Wd0Pra)

Everywhere people point out at replacing the updated USP10.DLL for an older one known to work properly with CR. But so far I can't find an official release or patch to address the issue.

Now with Windows 10 the problem gets harder to fix, as CR uses the USP10.DLL from C:\windows\SysWow32 and at that location the DLL can't be replaced.

We've tried placing the lib together with the app using CR, redirecting the DLL using a .meta file, replacing everywhere when possible, removing from registry, different versions of the library, etc. None of them work on Win10

Could any of the gurus here, please give us a bit of light here?

I don't understand why the people at SAP (or the previous owners of CR) did not fix this thing on the first place

Thank you in advance

Alejandro

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

4 Answers

Best Answer
Don Williams
Jun 15, 2017 at 04:13 PM
0

Hi Alex,

First thing, in that WIKI there is a link to Download CR runtime which takes you to the page you pasted in above. Those are SP 20, the latest release. SP 21 is not out yet so no reason to change it to SP 21. If you want an older version just change the link from ...9... to 20 or what ever version you want.

I just checked, we are now shipping version 1.6, my mistake. I never confirmed this before. 1.4 has other support issue with fonts, it's not an issue with Calibri in SP 6.

So the bug was in 1.4 that I know of, see this KBA -

1547961 - The character 'i' is added after every lower case 't' when a report is exported to PDF file format

So now my question is what was the actual issue you are having?

So it's really not clear what you are having a problem with? That original link is the same issue as in the KBA above and the case was because CR was using the one located in \system32 folder and version 1.6, 1.4 was the one with the problem.

So it really doesn't make sense now why 1.4 is working for you????? SP 20 does install 1.6.

What version of Adobe Reader are you using?

I suggest you use SP 20, remove SP 9 and start from a clean PC and see if you still have the problem.

Can you send me your report with saved data so I can confirm on my PC?

Don

Share
10 |10000 characters needed characters left characters exceeded
Don Williams
Jun 12, 2017 at 08:18 PM
0

Hi Alejandro,

So it's not clear what you are asking?

CR for VS and Crystal Reports installs it into both of our folders and uses 1.4 version in this folder:

C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86

CR Designer uses the on in this folder:

C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win32_x86

Those are the locations CR and it's hard coded into CRPE32.dll, it will only use that version, so it's not clear why you are trying to replace it with some other 1.4 version, if that what you are asking?
If you are asking when you can use version 1.6 then that should be soon, maybe...

CR ONLY works with version 1.4. R&D tried to update it to version 1.6 with no change other than recompiling and the formatting was messed up to much to easily replace it so they have work through all of the updates MS did to that version first. CR's formatting engine is so dependent on that dll it's not an easy thing to do...

First priority was to get off of the MS VS C++ ATL Security dll's which SP 21 should no longer be dependent on that version. We now compile using VS 2015 compiler.

As for the usp10.dll I do know they are working on it, I don't know when they plan to release that update though. They are still working on it.

I'll see if R&D has any update for me....

Don

Show 1 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Hi Don

Thank you for your reply, I apologize, my writing wasn't clear enough to depict properly the problem.

The problem we have is the one you guessed, related with USP10.DLL and Calibri font.

We've checked the hardcoded path you mention, and we have the location :

Our app, loads the report and attempts to generate the PDF, but it's getting loaded from:

For some reason, CR runtime when invoked with our app (.NET) is not loading the DLL from where it should be hardcoded, using ProcessExplorer, we've dumped the strings of the crpe32.dll (dump enclosed) but we could not find anything valuable.

Did your guys in R&D told you any good news? :)

Regards,

Alejandro

0
Don Williams
Jun 13, 2017 at 08:39 PM
0

Hi Alejandro,

That is odd.... Which redist package did you use to deploy the CR runtime?

Are you running the app from your desktop and not through Remote or Citrix?

Try sharing the CR for VS folder and give everyone read/write permissions.

Is your app running in 32 bit mode?

Try rebooting your PC and don't start up any other program except your and see where it's loading from.

Do you have any dependencies on that dll?

Run your app before and don't load a report, if that's possible, and then look at the list. Unless you preload a report which will load the CR runtime.

Try a simple 3 liner app, load the engine, load a report and preview, does it still load from syswow64 folder?

Only thing I can think of is something else is loading the dll from syswow64 folder and the nature of Windows is not to reload it again. But it should be in it's own memory space.... mmmm

Do you have Crystal Reports Designer installed on the PC? If so try loading it first, then your app. And then export to PDF and see where CR is loading it from? You can click on Help, About.... more info button in CR Designer to see what is loaded. And I have seen both versions loaded in CRD.

No word from DEV...

[UPDATE]

I had another thought, Dan and I were discussing and one thing you may try is coping the 1.4 version into the same location as your EXE is, Windows rules for loading is always in the location of the EXE, then System then down the path statement.

And in the ProcesssMonitor logs do you see your app trying to load usp10 from the CR folder?

Don

Show 1 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Hi Don,

We have used redist package 13.0.20 (32bit) and application is running locally (32 bit mode).

Change in permissions and restart didn't help. We also tried to place dll into location of EXE but it was still ignored.

Process explorer shows that only this application is using USP10.dll (it is loaded when app starts processing reports).

As you suggested we created simple test app but the result was same (it is also using dll from syswow64).

We tried to reinstall redist package and tested it again. Process explorer shows that dll from location C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86 was used (but it is version 1.6). When we replaced it with version 1.4 it is being ignored and CR loads version from syswow64 instead.

We didn't try to install CR Designer so far.

Regard
Alejandro

0
Don Williams
Jun 14, 2017 at 10:27 PM
0

Interesting, it should not be version 1.6 in our folder. Definitely put 1.4 back into both of CR's x86 and x64 folder.

Search your PC for all copies of that dll and see where they are. Try renaming any that exist except 1.4, you'll have to start Windows in Safe Mode to be able to replace the one in syswow64 folder.

Don

Show 1 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Hi Don

We've managed to workaround it, as the version 13.0.20 shipped with USP10.DLL v 1.6, we've tried to get an older SP, we were not able to find it on SAP's site (the link points back to the Wiki article, loop..)

Fortunately we had an old version in our backups (13.0.9) and that had the correct USP10.DLL embedded, v1.4. That did the trick.

I'd propose to:

  • Take down ASAP v.13.0.20 and place v13.0.21 with the USP10.DLL v1.4, at least for now until the issue is fixed for good (to use USP v1.6 or v10); It's something ongoing for 5 years now.
  • Also please take a look on the "Access to Previous Runtime Downloads", so it points to the right repository.

Thank you for your time and support

Best regards

Alejandro

0