The value of the encoding attribute of <res> element is still ignored

As I cannot figure out a way to re-open IZPACK-165 I created this clone issue. Sorry if that is wrong thing to do.

Anyways, all encoding attributes of res elements are ignored still on 4.3.3 as they have been for a long time. My comment on the original bug report 165 has also been ignored, so if nothing else, could somebody comment on this? Is the bug going to be fixed in 4.4.0, or ever? Thank you.

I just noticed (looking at IzPack sources) that some conversion is done during installer building. So the issues may be partially runtime-platform-default-encoding (i.e., which language version of Windows one is using) dependent. For example I can get InfoPanel to work by having res element to specify correct ISO-8859-1 encoding for the text file, and then by specifying "java -Dfile.encoding=UTF-8 -jar installer.jar" during the installation time. Various other combinations fail, e.g., if I just have UTF-8 text file with UTF-8 res element encoding attribute, and no runtime -Dfile.encoding spec.

Ok, one more spam today. I think I figured out the problem. The following is for IzPack 4.3.3, and infopanel with the resource defined like the following:

<res id="InfoPanel.info" src="resources/readme.txt" parse="yes" encoding="ISO-8859-1"/>

What happens here, is that during the installer building (compiling) time the CompilerConfig class notices the correctly specified encoding attribute, and re-encodes the file to an UTF-8 temporary file.

The parsing (substitution) is then performed correctly. If there is no encoding (or wrong encoding) specified on the <res/>-line then the parsing probably uses platform default encoding, and likely breaks the file when it encounters, e.g., scandinavian characters.

Then on the installation run-time, the installer tries to open the re-encoded and parsed file using the platform default encoding, which is not UTF-8 for me. So that is why the absurd "-Dfile.encoding=UTF-8" makes it work.

So the bug fix would be either of the following:

• Really convert everything to UTF-8 during compiling AND forcing that character set also when actually using the resources during installation.

• Use the user-specified encoding also on the output of parsing process during compiling, and then later when using the resources during installation.

At least I think so.

Would you be able to provide a patch?

Thanks a lot!

Tuomo was half right, the files are converted to UTF-8 however the problem does not seem to be that UTF-8 is not used during installation. The problem apears to be that there is errors in the re-encoding.

1. The uri to the new encoded file is set to a variable thats never read, and therefor never added to the JAR
2. The code that sets resource files to empty (some kind of saftey feature I guess) is accutally called after the re-encoding is done, therefor even if the above code was set to the right variable it would be overwritten with the address to the blank file, hence why if you use the encoding attribute your text will be empty.

I have attaced a fix for both 5.0.0beta5 and 4.3.4RC1, sorry no GIT patch as I still can't work out how to create one with Eclipse (EGit)

Update: My mistake Tuomo was correct after all, the bug I have fixed is to do with blank text when no parse attribute is set. The two errors I described above will happen with the following entry: <res id="InfoPanel.info" src="resources/readme.txt" encoding="ISO-8859-1"/>

I will attach a new fix that also works with the parse attribute set as my first fix didn't. Whoops.

As for the acctual bug this post is about, I can't seem to repoduce the error on my machine but I would assume it would just involve using:

resourceManager.getTextResource(resNamePrifix, "UTF-8")

instead of

resourceManager.getTextResource(resNamePrifix);

When calling loadInfo() in the info panel, etc for the other panels.

No parse attribute fix version2

It's in, thanks Timothy.

Still not fixed in 5.0.0beta8.

I have a ReadMe.txt encoded in UTF-8. I have declared:
<resources>
<res id="InfoPanel.info" src="Readme.txt" encoding="UTF-8"/>
</resources>

But it is wrongly displayed on Windows where default platform encoding is not UTF-8. Looking at the code the bug seems to come from InfoPanel#loadInfo() that use the ResourceManager#getTextResource(String resource) that does not specify encoding (so default platform encoding is used...

Please reopen.