Font display issue in Win7 x 64, JRE 1.4.2.19

[DW_Microsys]

I posted this issue in Oct 2011. After one and half years, this issue still exist with the iTRiLOGI6.45 Build 05.

OS: Windows 7 x64
iTRiLOGI 6.45 Build 05.

With JRE 1.4.12.19 (recommend by iTRi), comments display like this:
http://www.freeimagehosting.net/qu1qn

With JRE 1.5.0.14 or higher, comments display like this:
http://www.freeimagehosting.net/qhjtw

Problem is with JRE other than 1.4.12.19, I always has problem transfer proglem to PLC.

Hope this time your tech team can take it seriously and find a solution.

[garysdickinson]

I suspect that the issue with different versions of Java is with font substitution. Perhaps the older vs. newer versions of Java are picking different fonts for the same job.

There is a file in the directory that the TL6.jar file is installed that provides a hint to Java as to what font you want to use to display comments.  This file is named "en_language.txt".  In my installation it can be found at "c:/program Files (x86)j/TRiLOGI/TL6".

You will need to open this file for editing and look for the following line:

commentFontName???Lucida Console

You might want to change this line to something like:

commentFontName???monospaced

You may run into a problem saving the file.  This is an issue with Windows not wanting you to easily mess up stuff in critical parts of the file system.  I suggest that you "save as" the file to somewhere else, like the desktop and then rename the original file and then copy the newly edited file back into the directory that TL6.jar was installed.

Gary D.

[support]

Are you referring to the small windows size where the button is partially covered?

You can actually drag the lower right corner of the comment windows and widen it so that all buttons are displayed correctly.

The window size is saved when you quit i-TRiLOGI. So the next time you start the program your comment editor window will assume the new size.

[DW_Microsys]

Gary, I already tried that in 2011 and it didn't work, for sure it doesn't work now.

[DW_Microsys]

Hi Mr. Support,
No, it not regarding the windows size, I know how to change the size of the window.

Please open the two screenshoots (original post) side by side, and compare the word "Sample" and "text", pay attention to letter "e". With JRE 1.4.2.19, the letter "e" is more like a letter "o". When you have a lot of comments in the program, this kind of display masses up the whole content.

Let me know if you get my concern.

[support]

It appears that you are using very high resolution display (1920 x 1080) and probably with the small O/S default font? The display differences you experienced is the rendering routine in the JRE version and is outside of the i-TRiLOGI control.

Did you try to increment the font size by changing the number assigned to "fontIncrement" in the en_language.txt file (it is important to add a single TAB after the name before the assigned number - i.e. only a single tab character allowed between fontIncrement and 1):

fontIncrement   1

I used a JRE 1.4.2_19 to start the i-TRiLOGI with two different fontIncrement and you can  see the differences in the attached pictures:

[DW_Microsys]

I knew the "fontincrement" works in Windows XP, but I'm talking about Windows 7x64bit. Did your team ever do any test in windows 7x64? The "fondincrement" doesn't work at all, at least in my laptop (Lenovo W520, windows 7x64, JRE 1.4.2.19). However, if I switch to JRE 1.5.14 or higher, it works.

Also, there's nothing to do with the screen resolution. I just tested with a 1024x768 LCD from junk room, it displays exactly the same thing. Refer to the attached picture, I just collect some words to show how difficult to read.
Refer to the attached picture, the settings are:
"fontincrement  3", windows 7x64, JRE 1.4.2.19, 1024x768 LCD screen.

Please, ask your team to find a Windows 7x64, test it out, and let me know what to do.

BTW, Windows XP was not available since 2010 Oct, and will be end of support in 2014. It would be better for yor team to develop something in Windows 7.

[support]

Your problem seems unique to your computer.

We ran the i-TRiLOGI 6.45build 05 on JRE 1.4.2_19 on a PC Windows 7 Professional 64-bit and have no problem changing the font size. In fact even with the default fontIncrement=1 the display is quite readable. Please see attached picture below:

[support]

As you can see from the screen shot below, the i-TRiLOGI program was invoked using JRE 1.4.2_19.

Sometime the issue vary from one platform to another. For example in all our computers here (Windows XP, Windows Vista, Windows Server 2008, Windows server 2008 R2, Windows 7 32-bit, Window 7x64, Windows 8 x 64), we are able to run i-TRiLOGI on JRE 1.4.2, JRE 1.6.0 and JRE 7 without problems and we can transfer program to the PLC using any of the JRE. But other users experience different issues and so far we find JRE 1.4.2 seems to solve all JRE related problems, which is why we still recommend it as the most trouble free JRE.

As for why we are still using XP - Windows XP is still the engineers' best friend since it runs most engineering related software without issue. (It is probably also the reason Windows 7 professional 64-bit still provide a virtual PC that runs Windows XP).  Unlike the folks who supply our Windows O/S - our priority is to ensure that whatever new software update we release the users using their PCs for engineering work must be able to run them. Hence the XP test is important. However, every new version of Windows or even Java bring new problems and we can only try to tackle them one at a time.

[cdenk]

Just a suggestion. Not having this problem with Trilogi and Windows 8 Pro, but could it be the video card and driver. I have had issues with Firefox on the same machine with various ATI cards when running XP PRO and the Ubuntu 11.*. Very different Fonts and line spacings. Ubuntu OK, Windows 8 needs improvement.

Thanks for the tip on the "TAB" between the label and the number

I am having issue with another software package (Intellicad) on Windows 8 not being able to run VBA. Apparently between 7 and 8 Microsoft deleted a bunch of VBA  support files from the install. When doing an upgrade the remnant files are left behind, no problem, but on a fresh install the files are missing. When run under a VM doesn't seem to be a problem. Just another one of those gotchas, these things popup in the wildest ways.  

[DW_Microsys]

Good, looks like we are making progress.

I duplicate the command line in my computer, and get error message regarding "Zh_language.txt", this can explains that why the fontincrement in "language.txt" doesn't work.

But, how could the system looking for "Zh_Lauguage.txt" instead of "Lauguage.txt"?

My Win7 is English version, and has Chinese enabled, and has set "default none-unicode" Chinese (Simplified, PRC).

My previous laptop XP 32bit has the same setting, but never had problem.

[DW_Microsys]

Ok. I rename the existing "En_language.txt"  to "zh_language.txt", and it works.

Looks like it is a bug in TL64.jar. In Windows7, if the default none-Unicode program language is set to Chinese, TL64.jar will try to load zh_language.txt instead of en_language.txt, even though the English version of TRiLOGI is installed.

It should be a easy fix from your side.

[support]

Is your region and settings set to Chinese? It is a bit strange if it isn't (must be one of those goofy thing from Windows). Also your font face looks like one of those font when Windows display English text on Chinese Application, which explains why they don't look too good.

There are two ways you can do it:

1) Copy your en_language.txt to zh_language.txt and let i-TRiLOGI load the zh_language.txt file.

2) Amend the TL64.bat file and add the following to the command string:

-Duser.language=en

E.g.

IF EXIST "C:\Program Files (x86)\Java\j2re1.4.2_19\bin\java.exe" "C:\Program Files (x86)\Java\j2re1.4.2_19\bin\java.exe" -jar -Duser.language=en TL64.jar

[support]

It is not the bug in TL64.jar. The software query the O/s for the default language and look for the corresponding language file.

[DW_Microsys]

Ok. Even it is not a bug in TL64, still you may be able to do something, because it only happens when using JRE 1.4.2.19. With other JRE, it works just fine. Or, at least you pop up some window to let user know the file is missing.