Having an issue I believe is similar to this Font rendering issue with PDF viewer - #6 by flavien
But my issue is that I am using the Arial font everywhere which I at least think is a normal font that sholud be render-able but I am having some issues.
Printing to printer, or printing to PDF, or saving the bytes from the db directly to my comptuer and opening in my local computers pdf viewer (adobe/chrome) - these all look correct.
Opening it in PDF Viewer (A script grabs the bytes from the db and uses loadPDFBytes the less than/greater than symbols come through as squares as in the linked post.
Here is the problematic version coming through from PDF Viewer -
And here is what I see when it is printed to pdf or saved directly to pdf from the db
Is there a “safest” font I could use or something else to be doing here? I am at a loss.
The Vision PDF viewer component, you mean?
The [] are the indication the font rendering system lacks a glyph to display, which means this is a bug in IcePDF, the embedded PDF library we use, since it should likely either fallback to system fonts for rendering or at least pick up Arial.
What if you run the client/designer with the system property org.icepdf.core.awtFontLoading set to true, as in:
-Dorg.icepdf.core.awtFontLoading=true?
Yes this is all vision 8.1.25.
Don’t see that in the igntion.conf. Should I add it like
wrapper.java.additional.8=-Dorg.icepdf.core.awtFontLoading=true ?
No, it'll be a client side property. You'll have to enter it in the JVM Arguments section of each configured client/designer launcher.
You might succeed, if this workaround even works, with putting
from java.lang import System
System.setProperty("org.icepdf.core.awtFontLoading", "true")
into a client startup script - as long as it runs before the PDF viewer component is actually instantiated it should still work, it looks like?
1 Like
Unfortunately neither worked - the client startup script or the jvm arguments.
Any other ideas before calling into tech support about this?
Looks like a known issue with IcePDF and special symbols based on some googling.
Tried a few other fonts like tahoma/verdana but they completely botch the whole cell, at least with Arial I still see the numbers.
Seems like this problem may exist in production now currnetly but has never been reported because when they print the PDF it does come out correctly. So this may just get ignored / glossed over. Don’t think there is anything else that can be done.
If you've got the Web Browser module already licensed you could render the PDFs there. Not as easy of a path to go PDF bytes -> rendered PDF, but it's doable.
If you don't, the web browser module is free in 8.3 
2 Likes
Ha yea I was considering the web browser but this system doesn’t have it. I don’t think this is a show stopper. When they eventually upgrade to 8.3 though I likely will take this path. Thanks!
1 Like
There is a show stopper part now of this. I have a report lookup screen where a user can look up past reports. I grab the BLOB column from the db, load it into the pdf viewer with loadPDFBytes, it looks wrong as described above with the [] bits and some other minor text issues - but when they go to print it with .print() it also prints incorrect and this is not good. It saves correctly. But we do need the ability to print it correctly.
I know I can save it to file and that looks correct and I guess maybe then do a subprocess for a command to print the file is my easist route forward unless you have any other suggestions?
The reason it prints correctly in my previous post was because it was printing form the ReportViewer component directly when the preview and accept it initially. When they go back to old records and I display/print from PDF Viewer I do have this issue still.
There's some other hail mary stuff to try to get IcePDF to load the fonts, if you explore the FontManager API:
I don't know how fruitful this will be or how much it's worth the time investment.
Is it possible to switch from Arial to something else - e.g. if you try the logical font 'Dialog' in the report itself, does it render correctly/use an appropriate fallback font at runtime? Maybe make up a test report with a bunch of different fonts and see if you can find one that works throughout the pipeline?
This might be easier 
1 Like
I just talked with the customer luckily they are ok with saving to file and opening in the default program and letting them print from there.
So I will save the PDF into something like C:\Users\Operator\Temp\Temp.pdf open that with a ProcessBuilder call to start ““ “C:\Users\Operator\Temp\Temp.pdf” and then from there its on them to print through the default program. So I am able to get around it. Phew.
Does the web browser component allow printing? Never used it. But I do think that alone might be a good enough argument for me to convince them to move to 8.3 as these reports are a huge part of their project.
1 Like
It'll take a little bit of effort to convert this lambda-heavy callback Java code to Jython, but yes, JxBrowser supports a pretty rich printing API:
2 Likes
