ICEfaces
  1. ICEfaces
  2. ICE-10987

ace:dataExporter - add support for the encoding attribute

    Details

      Description

      By default the encoding attribute of the ace:dataExporter sets the encoding to UTF-8. If this attribute is changed to use 'ANSI' for example, it will still encoding the content with UTF-8.

        Activity

        Hide
        Arran Mccullough added a comment -

        Uploaded test case that shows this issue.

        Steps:

        • Load welcomeICEfaces.jsf
        • Export the content of the table and save the file some where.
        • Open the csv file with an editor, Notepad++ for example. Looking at the encoding it is set to UTF-8 not ANSI
        Show
        Arran Mccullough added a comment - Uploaded test case that shows this issue. Steps: Load welcomeICEfaces.jsf Export the content of the table and save the file some where. Open the csv file with an editor, Notepad++ for example. Looking at the encoding it is set to UTF-8 not ANSI
        Hide
        Arturo Zambrano added a comment -

        r48575: added support for the encoding attribute in ace:dataExporter for the CSV and XML formats.

        Testing notes, documentation and other notes to follow.

        Show
        Arturo Zambrano added a comment - r48575: added support for the encoding attribute in ace:dataExporter for the CSV and XML formats. Testing notes, documentation and other notes to follow.
        Hide
        Arturo Zambrano added a comment -

        r48583: added 'pdfFont' attribute to specify a custom font for the exported PDF file and added TLD documentation regarding encoding

        Show
        Arturo Zambrano added a comment - r48583: added 'pdfFont' attribute to specify a custom font for the exported PDF file and added TLD documentation regarding encoding
        Hide
        Arturo Zambrano added a comment - - edited

        Testing notes:

        • Please read the new TLD documentation for the 'encoding' and 'pdfFont' attributes.
        • Test the CSV, XML, and PDF formats separately (The XLS format is not affected by these changes).
        • The test app needs to be modified and tested as explained below. Simply checking the Encoding menu in Notepad++ is not a reliable way to determine the encoding, since Notepad++ simply gives its best guess as to the encoding in use. There's nothing in plain text files to inform the readers/viewers what encoding is being used.
        • Modify the test app by including some Unicode characters either in the XHTML file or hardcoded in the Java bean. The characters in the Java bean must be escaped, using the Java format (i.e. \u0000) in order for them to be displayed and exported correctly. The only Unicode character in the attached test app is not escaped, so it won't be displayed correctly, unless it's escaped. In the XHTML file, Unicode characters must be escaped in the XML format (i.e. &#x0000; ), unless the encoding is explicitly declared in the xml prolog (e.g. <?xml version='1.0' encoding='UTF-8' ?> ), in which case Unicode characters can be typed directly.
        • For example, you can use these escaped characters in Java '\u0407 \u03fe \u0401' and these escaped characters in XHTML '&#x0407; &#x03FE; &#x0401;'.
        • You can test the plain text formats (CSV and XML) by specifying the UTF-8 encoding (or simply not including the 'encoding' attribute, since UTF-8 is the default encoding) and verifying that Unicode characters can be viewed correctly in a text editor. Then, you can change the encoding to 'US-ASCII' or 'Windows-1252' and see that Unicode characters are replaced by question marks. The 'ANSI' value is not an official encoding type.
        • You can test the PDF format by specifying the absolute path to a font file in the host system, using the 'pdfFont' attribute. I recommend using the most common TrueType fonts like Arial, Helvetica, Times New Roman, etc., since the font itself has to support the desired encoding in order to be used, and popular fonts usually support Unicode (Courier and other terminal/console fonts might not support Unicode completely or at all). Once the PDF document is exported, verify that Unicode characters are displayed correctly (if 'UTF-8' was the specified encoding) and that specified font was actually used in the document.
        • More information will be added to the wiki page.
        Show
        Arturo Zambrano added a comment - - edited Testing notes: Please read the new TLD documentation for the 'encoding' and 'pdfFont' attributes. Test the CSV, XML, and PDF formats separately (The XLS format is not affected by these changes). The test app needs to be modified and tested as explained below. Simply checking the Encoding menu in Notepad++ is not a reliable way to determine the encoding, since Notepad++ simply gives its best guess as to the encoding in use. There's nothing in plain text files to inform the readers/viewers what encoding is being used. Modify the test app by including some Unicode characters either in the XHTML file or hardcoded in the Java bean. The characters in the Java bean must be escaped, using the Java format (i.e. \u0000) in order for them to be displayed and exported correctly. The only Unicode character in the attached test app is not escaped, so it won't be displayed correctly, unless it's escaped. In the XHTML file, Unicode characters must be escaped in the XML format (i.e. &#x0000; ), unless the encoding is explicitly declared in the xml prolog (e.g. <?xml version='1.0' encoding='UTF-8' ?> ), in which case Unicode characters can be typed directly. For example, you can use these escaped characters in Java '\u0407 \u03fe \u0401' and these escaped characters in XHTML '&#x0407; &#x03FE; &#x0401;'. You can test the plain text formats (CSV and XML) by specifying the UTF-8 encoding (or simply not including the 'encoding' attribute, since UTF-8 is the default encoding) and verifying that Unicode characters can be viewed correctly in a text editor. Then, you can change the encoding to 'US-ASCII' or 'Windows-1252' and see that Unicode characters are replaced by question marks. The 'ANSI' value is not an official encoding type. You can test the PDF format by specifying the absolute path to a font file in the host system, using the 'pdfFont' attribute. I recommend using the most common TrueType fonts like Arial, Helvetica, Times New Roman, etc., since the font itself has to support the desired encoding in order to be used, and popular fonts usually support Unicode (Courier and other terminal/console fonts might not support Unicode completely or at all). Once the PDF document is exported, verify that Unicode characters are displayed correctly (if 'UTF-8' was the specified encoding) and that specified font was actually used in the document. More information will be added to the wiki page.
        Hide
        Arturo Zambrano added a comment -

        r48585: committed improvements to the 3.3 EE maintenance branch

        Show
        Arturo Zambrano added a comment - r48585: committed improvements to the 3.3 EE maintenance branch
        Hide
        Carmen Cristurean added a comment - - edited

        ICEfaces4 trunk r48585: verified on Firefox41, IE11, Chrome49, MS Edge, no issues found.
        Added QA dataExporter 'enconding' and 'pdfFont' test: http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataExporter
        Test page: /dataExporterEncoding.jsf

        Show
        Carmen Cristurean added a comment - - edited ICEfaces4 trunk r48585: verified on Firefox41, IE11, Chrome49, MS Edge, no issues found. Added QA dataExporter 'enconding' and 'pdfFont' test: http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataExporter Test page: /dataExporterEncoding.jsf

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Arran McCullough
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: