Jasper Reports: multi line text field - java

I'm generating a pdf report with Jasper Reports 3.1.2. I have a multi line text field that contains several lines: this field is split over 2 consecutive pages.
The problem is that on AiX and Linux systems the last line in the first page is always missing (on Windows systems everything is fine). I've tried modifying margins, sizes and fonts but nothing happens: the last line of the first page is always missing
Any idea?
Thanks in advance

What font are you using? Problems like this are usually† caused by fonts not being available. Use font extensions to ensure that you know what font is being used, and then it should render well everywhere.
Also make sure to set this in jasperreports.properties:
net.sf.jasperreports.awt.ignore.missing.font=false
That's great for testing since it catches missing fonts immediately.
†By "usually" I mean "so often that it's indistinguishable from always". But of course it's theoretically possible that there is some other source in this case.

Related

Troubles with local letters PentahoPDFReporting

I am using Pentaho Report Designer 3.8.3 and I have small, aesthetic problem with fonts.
I have implemented, or better say, I am aimplementing OpenSans font into my pentaho.
Its cirrent state is, that i have installed this font into Linux(which is my pentaho runing on) and also into java. But i still have 2 problems with fonts:
1.) I see OpenSans font in html only when i open it on PC where it actually is installed. Whenever i open report with openSans font on machine where it is not installed, it change it for something else, Arial for example.
(I have added OpenSans to: '/usr/lib/jvm/' and also into: '/usr/share/fonts')
2.) After publishing report to PDF, I see only '?' instead of accentuated characters. But in html, I see no '?', each letter is as it should be.
(I have added
org.pentaho.reporting.engine.classic.core.modules.output.pageable.pdf.Encoding=ISO 639-1 #my language code, Slovak
into '/home/pentaho/pentaho/biserver-ce/tomcat/webapps/pentaho/WEB-INF/classes/classic-engine.properties' file)
Does anyone have an idea wht else should I try to make it work properly?
I'm not sure what you can do with html export other than doing the usual approach of setting the font-family so it has something to fall back to.
However in PDF look carefully at the pdf export options, you'll see there's a "embed fonts" option. Enable that and your pdf will work anywhere!

Apache POI doesn't quite give enough space when autosizing

I am building an Excel file with Apache POI. After I add all of the content I autosize the columns using sheet.autoSizeColumn(i).
Sometimes it doesn't quite give enough space. I have tried Verdana and Calibri-Regular (had to switch to Calibri-Regular from Calibri because the autosize was going completely crazy all of a sudden on our Windows 7 boxes but worked fine on our Linux boxes, which is a mystery to me). Is there something I can do to fix this? Or is there a way to add a little padding after autosizing?
Edit:
On my Windows dev box I tried setting the font to Verdana with font.setFontName("Verdana"). All of the content definitely changes to Verdana and the sizing on the columns is perfect. On the Linux production box I used the bit of Java code that Gagravarr referenced in the below comments to print out a list of the fonts that Java sees. I tried Monospaced but the spacing was identical to the above screenshot. I then tried Dingbats and the content was still readable (which it shouldn't have been) while the spacing was really off (see screenshot below).
Also openjdk and Oracle JDK do not use the same font engine (SUN∕Oracle kept its legacy engine for fear any change would break badly coded apps). It's quite possible openjdk will work better on linux for font stuff, since it reuses the same font libraries as the rest of the system, instead of reinventing a square wheel.
Fonts are a legal nightmare; Linux fonts licensing is usually liberal enough you can copy, modify and deploy them anywhere but the reverse is not true (Microsoft was very careful to create vendor lock-in for anyone foolish enough to build apps depending on Windows fonts)
I am not sure whether this will resolve your problem or not, but if you have asked about "is there a way to add a little padding after autosizing?".... yes you can do it by following way.
testSheet.autoSizeColumn(ColIndex);
testSheet.setColumnWidth(ColIndex ,testSheet.getColumnWidth(ColIndex)+PaddingWidth);

Difference between reports generated in two different servers

I stumbled in a weird problem in which the same report generated in one server is different from the one generated on another server.
The package deployed (WAR file) is the same, I checked event the MD5 of it. The same data is being used to generate the report, so no difference from the application itself.
I took a look into the Java version and the one that is generating the report as expected is using Oracle JVM 1.7 and the one generating the weird formated report is using OpenJDK.
I suppose this should be the problem right? In this case what else could I check to maybe find the problem?
Things I already have checked are:
war file deployed to both servers;
fonts installed on both servers are the same;
version of both servers (right one is being run on a apache-tomcat-7.0.28 and the weird one apache-tomcat-7.0.29);
properties and version of libraries;
ADD
Within the report I have a few fields that are justified, and these are stretched and line break is positioned in a quite strange position.
For example the blue area should present 2 lines, but it presents 3, the second is the word with a big letter spacing and a 3rd one with just one word that should be on the second line. And the green area is presenting 2 lines which is fine but the last line it is justifying the word to the entire line increasing the space between the letters.
I recheck all the configuration and components and here is the result:
upgrading locally tomcat to 7.0.29 didn't solved the problem;
fonts configured are exactly the same;
font visually resulted in both PDF files are the same;
no log output from JR that could indicate something is missing / wrong;
war file (deployment package) is the same (lib are the same);
server configuration are the same;
What was missing is to change the JVM, and indeed changing JVM from OpenJDK 1.6.0-b09 to Oracle JVM 1.7.0_25-b15 solved the problem.

JTable won't display Unicode correctly when the application is executed from the command line or a jar file. It works fine in eclipse, though

I'm writing an application that reads a text file containing a list of vocabulary words in both English and Chinese. These are then displayed in a JTable. When I run or debug the app in Eclipse, everything displays fine. I can see and read the characters and the English. However, when I execute the app from the command line or from an executable jar, it's all wrong. The characters show up as either squares or as gibberish.
I also have a text box that when I type Chinese into it, it displays correctly.
My first thought was that it was a font problem. I was using a font installed on my system. Since I can't guarantee that the person using this app will have that font, I moved it to a resource folder and load the font from a file. The font appears as though it's been loaded so I'm convinced it's not a font issue.
I found another question that suggested using -Dfile.encoding=utf-8. I've tried this and it did not work.
Would the brilliant folks at Stack Overflow have any advice on how to make this work?
I'm writing this on a non-chinese version of Windows.
Well then you won't ever be able to get a Java program to produce Chinese command-line output.
Java, like almost all languages, uses the C standard library which has byte-based IO. The Windows command prompt interprets byte-based IO using the locale-specific default code page. That's never a UTF, so Unicode characters outside of the current locale's default code page just won't work.
(In theory you should be able to get it to work by changing your console fonts and using chcp 65001 (UTF-8) together with -Dfile.encoding=UTF-8, but in practice it doesn't work reliably due to bugs in the C runtime. Unicode on the command prompt is a long-standing sore point.)

English characters don't show up when entering text with Indic input method in Swing

I'm working on an application that accepts text in English and performs transliteration with a custom 3rd party API into an Indic language (one of several that are supported). The application is targeted at Windows XP/7 and Ubuntu.
We use a custom input method that loads the required Indic font, and uses it render text. Also, the user can correct the transliterated text by typing in English and pressing space (similar to how Google Transliterate works).
The problem is that with certain Indic fonts, typing in English shows up empty box characters (even though the actual characters typed are detected and transliterated accordingly).
I have used the ttf-indic-fonts-0.5.0 font pack that comes with Ubuntu, and was able to substitute some of them. For the others, if I copy the corresponding font from Windows (I'm developing this on Windows 7) then all problems are solved.
However, we cannot redistribute Windows fonts with our application and want an open alternative.
Other than trying to find a substitute font, is there anything else that we're doing wrong, or need to check, to make sure that English characters can be typed in a JTextField when an Indic font is being used?
As an example - from the Ubuntu package mentioned above, the lohit_pa.ttf font for Punjabi has this problem. If I copy the default Windows font for Punjabi (raavi.ttf) then it works fine.
I found a solution to the problem. I installed the fonts on Windows (open the font, click install) and browsed the contents using Character Map. These fonts only have glyphs for the language in question, not English.
I used FontForge to merge the 2 fonts. (Fontforge's author doesn't provide binaries anymore - but if you have access to Ubuntu you can install it from the repository. No such luck if you only have Windows).
After this, I'm able to type in English again.

Categories

Resources