IzPack
  1. IzPack
  2. IZPACK-528

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

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0.1, 4.3.0
    • Fix Version/s: 4.3.4, 5.0
    • Component/s: Panels
    • Labels:
      None
    • Number of attachments :
      2

      Description

      The value of the encoding attribute of <res> element is ignored in install.xml.

      For instance, when the file of the EUC-JP encoding is specified with Windows, the display of LicencePanel is garbled.

      <resources>
      <res id="LicencePanel.licence" src="legal/License.txt" encoding="EUC-JP"/>
      </resources>

      1. CompilerConfig_4.3.4v2.java
        121 kB
        Timothy Fridey
      2. CompilerConfig_5.0.0beta5v2.java
        114 kB
        Timothy Fridey

        Activity

        Hide
        Tuomo Soinio added a comment -

        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.

        Show
        Tuomo Soinio added a comment - 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.
        Hide
        Tuomo Soinio added a comment - - edited

        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.

        Show
        Tuomo Soinio added a comment - - edited 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.
        Hide
        Tuomo Soinio added a comment -

        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.

        Show
        Tuomo Soinio added a comment - 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.
        Hide
        Julien Ponge added a comment -

        Would you be able to provide a patch?

        Thanks a lot!

        Show
        Julien Ponge added a comment - Would you be able to provide a patch? Thanks a lot!
        Hide
        Timothy Fridey added a comment - - edited

        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.

        Show
        Timothy Fridey added a comment - - edited 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.
        Hide
        Timothy Fridey added a comment -

        No parse attribute fix version2

        Show
        Timothy Fridey added a comment - No parse attribute fix version2
        Hide
        Julien Ponge added a comment -

        It's in, thanks Timothy.

        Show
        Julien Ponge added a comment - It's in, thanks Timothy.
        Hide
        Julien HENRY added a comment -

        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.

        Show
        Julien HENRY added a comment - 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.

          People

          • Assignee:
            Julien Ponge
            Reporter:
            Tuomo Soinio
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: