Some windows character encodings break on Linux

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Some DOS special characters do not print in Linux/Unix. Specifically, the 
codepage 437 box/menu characters.  These characters print fine when using 
jZebra with Windows.
http://en.wikipedia.org/wiki/Code_page_437

What is the expected output? What do you see instead?
A DOS line border instead shows as "ÃÄÄÄ" when printed.

Original issue reported on code.google.com by tres.fin...@gmail.com on 2 Dec 2010 at 8:21

[GoogleCodeExporter]

It is possible that Java is re-interpreting the charset (byte array, character 
codes, code page) before sending the data to the printer.

Windows by default should used Cp1252, although the Cp1252 wiki article doesn't 
show the special box/menu characters.
http://en.wikipedia.org/wiki/Windows-1252

On the contrary, the Cp437 wiki article does show the box characters.
http://en.wikipedia.org/wiki/Code_page_437

Forcing an environment variable to change this to Cp1252 didn't seem to help.  
kokocamp is investigating if switching to Cp437 helps.

There is also a slight chance that the browser's JavaScript is interpreting the 
character encoding differently depending on platform, and needs investigation.

-Tres

Original comment by tres.fin...@gmail.com on 2 Dec 2010 at 8:28

[GoogleCodeExporter]

Two (possibly) related bugs for reference:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5091241
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4038677

-Tres

Original comment by tres.fin...@gmail.com on 2 Dec 2010 at 8:30

[GoogleCodeExporter]

This should fix it without any code changes.  Waiting for confirmation from Eko 
Wahyudiharto that this works, then adding code snippets to sample.html for next 
version.        

       // For those trying to print special DOS characters in UNIX/Linux
       $ export JAVA_TOOL_OPTIONS=-Dfile.encoding=Cp1252;google-chrome
       // OR
       $ export JAVA_TOOLS_OPTIONS=-Dfile.encoding=Cp1252;firefox
       // You should then see
       $ Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=Cp1252

Original comment by tres.fin...@gmail.com on 22 Jan 2011 at 3:16

[GoogleCodeExporter]

Still not working... (getting closer) We're investigating further... 

Original comment by tres.fin...@gmail.com on 31 Jan 2011 at 5:10

[GoogleCodeExporter]

See my solution for this bug on thread ID:28

Original comment by erik.luk...@gmail.com on 18 Aug 2011 at 9:16

[GoogleCodeExporter]

Fixed in version 1.1.8.  Confirmed by Eko.

http://code.google.com/p/jzebra/downloads/list

Original comment by tres.fin...@gmail.com on 17 Sep 2011 at 5:21

• Changed state: Fixed

[GoogleCodeExporter]

Would like to add to this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670764

Quote from java developers:
"The CP1252 (windows-1252) converter itself behaves correctly.
 0x99 (decimal 153) ---> U+2122 (TRADEMARK SYMBOL) --> 0x99
and so on for all Cp1252 defined chars in the (decimal) 128-159 range."

"The issue here is that Win32 separates the encoding used for the console (the 
"OEM" encoding, by default) from the encoding used for all other operations 
(the "ANSI" encoding, by default). (see bug 4170549).  In this case the "OEM" 
encoding default is Cp850. This is why the output chars in the given range
result in unexpected output compared to what is expected (chars specified
in Cp1252). This bug is a duplicate of 4170549.
###@###.### 2002-05-08"

-Tres

Original comment by tres.fin...@gmail.com on 24 Apr 2013 at 1:33