Using a dataset you can make a simple script on window opened event
rv = self.rootContainer.getComponent('Report Viewer')
data = self.rootContainer.ReportParameterDataset
if data:
for col in range(data.columnCount):
setattr(rv, data.getColumnsName(col), data.getValueAt(0, col))
It’s working!!
Thanks guys!!
Had the same issue, switched my font to Arial and it fixed the problem.
Similar issue occurring just recently with 8.0.13 and PDFs sent via reports. The default text “Dialog” would in some cases such as the data elements from a query would stack on each other. Once I changed the font it resolved the issue. This was/is only when sent via email they looked fine in the viewer component. What a PITA!
Dialog is a virtual font in Java and can be rendered differently on different machines depending on what physical fonts are installed.
I’m not sure how it gets translated into the PDF, but somehow I’m not surprised it’s giving you problems when viewed on another machine. Glad you figured out a work around.
Thanks for the response, interesting it worked for weeks maybe even minths till just a couple weeks ago.
I guess the question is then how do I ensure that “dialog” is not the default font in the designer? And is there a way to change all the built up reports font wholesale?
We use virtual fonts as defaults in the designer because they are guaranteed to “work” – your operating system will translate that to one of the fonts you actually have installed, but there’s no guarantee exactly which font will be used. If we used a physical font, like say Ariel, and it wasn’t installed, it would be a really bad experience for users.
Just fyi, the five logical fonts in Java are “serif”, “sansserif”, “monospaced”, “dialog” and “dialoginput”. Any other font you see is installed on your OS.
Let me do a couple of quick experiments on the mass-change of fonts issue and see if I have a solution for you on that.
Bad news and bad news. :\
I don’t see a way to mass change the fonts used, and the reporting engine does not embed the fonts into the PDF. On the one hand, that’s good, as it makes your PDFs smaller, but it does mean that if you use a font that your recipient doesn’t have then their machine will make a substitution (much like it does for Dialog), and the report may not look exactly like it does on your machine.
[edit] The PDF spec does say that Arial, Courier, Times and Helvetica are safe to use though, and are guaranteed to be in compliant PDF readers.
Very interesting … and apparently a guarantee that a logical font will work is not worth much in this case. Interesting that this is only when compiled as a PDF then emailed. I will have to check if it has this issue when saved as a PDF file on the gateway or client machine. Either way not having an option to change the default font is something Inductive should work on. Thanks for the follow up!
Re-reading this and I don’t believe the issue is the fonts installed, this occurs on any Windows machine that the report is sent to via PDF. So it resides in the conversion to PDF not in the local machine. I hope that helps to track down the root cause.
Switching font to Aerial fixed our problem too.