klawandronic

Hello, We finally found the issue behing the strange behaviour. Teodor, you were very right that by using a thin client you cannot influience the rendering of the report. Still we had the problem of not being able to reproduce except doing it on the client's side. Today we found out that the client's users only, could reproduce the issue. Accidentally we also found out that there's another thing they all have in common: language. In the end, the issue was with Openbravo: it translates the .jrxml files into different languages depending on the user's locale. Seems that their parser does a trim or something like that on the fields' expresions thus removing some spaces. Thanks for your help, Viorel

Hi, Till we manage to get a coloured example, here's the current thing. The expressions behind the problematic fields are: $F{CUSTOMERCONTACTNAME} != null? "Attn. " + ($F{CUSTOMERCONTACTGREETING} != null?$F{CUSTOMERCONTACTGREETING} + " ":"") + $F{CUSTOMERCONTACTNAME}: "" ($F{INVOICEPOSTAL} != null?$F{INVOICEPOSTAL} + " ":"") + $F{INVOICECITY}Regards, Viorel

Well, this is a bummer. I cannot attach the reports to this forum cause they're can not be made public. I may be able to send them to you personally but I have to ask for permission. On the other hand, there's no easy way to generate an dummy report as example, it will take us probably a few days. But what I've explained in the first post is most likelly the best example. The default paginator in iReport, the one you can find in Library: Page X of Y. The good report shows "Page 1 of 1" and the bad report shows "Page1 of1". If you take a look at the definition of these fields: "Page " + $V{PAGE_NUMBER} and " of " + $V{PAGE_NUMBER} + "" you will notice that the space between "Page " and $V{PAGE_NUMBER} and between "of " and $V{PAGE_NUMBER} are missing in the bad report. All the text fields we've defined like this(concatenating spaces in the field's expression) on the report are missing the spaces. Thanks, Viorel

You are right Teodor, we are using a browser to trigger the generation of the report. From my point of view, embedding the font into the PDF would not fix the issue cause it's not a rendering issue: The bad reports generated by the Cytrix machine are displayed the same on all machines: Cytrix, Windows, Linux. The good reports generated by Windows/Linux are displayed the same on all machines: Cytrix, Windows, Linux.Another thing to consider is the fact that the reports are stored in Openbravo so the channel used to download the PDF doesn't affect things: If I donwload on Cytrix a report generated with Windows/Linux, the report is good If I download on Windows/Linux a report generated with Cytrix, the report is badThe only influience the OS/Browser has on the generation of the PDF is the call on the servlet in charge with the generation. Or so it seems, cause it's the same report template, the same servlet, the same Java code, the same report data. The only difference we discovered so far is the client environment triggering the PDF generation process.

Hi, I managed to get my hands on some info that might help fix this issue. This post <http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=909> is saying that if the fonts used in the report template don't exist on the server machine, then rendering issues like the one we have may occur. I've also read that in certain cases the font used to render the PDFs can be loaded from the client's machine. If this is the case, then BINGO, we may have a solution ... but how can I tell the difference between the two: when does Jasper use the server's font and when does it use the client's font? Regards, Viorel

Hy guys, We have a nice problem that doesn't seem to be an earthling :-) We have the following environment: an Ubuntu 8.10 server machine which is configured with Apache 2 in front of Tomcat 6. On Tomcat we have Openbravo 2.40 which is the application we maintain for a client. Openbravo 2.40 uses Jasper Reports 2.0.5 engine. The problem is like this: if the client generates reports, then the reports are missing some spaces; if we generate the report, then the spaces are there. A good example is the default paginator in iReport: the field with expression "Page " + $V{PAGE_NUMBER} is displaying a space(Page 1) when we generate the report and none(Page1) when the clients generate it. All the fields that are constructed like this have the same behaviour. The client's environment is a huge central server running Cytrix on it and multiple consoles. We've tested it on Windows and Linux and the spaces are there. How is it possible that the same report generated by two different clients gets generated in two different ways? Good one, huh?! :-) Regards, Viorel PS: This problem is a pain in the ass cause the client makes a big deal about it.