Page 1 of 1

Viewer does not show eol properly for EBCDIC viewer

Posted: 14 May 2010, 18:01
by pganelin
Hello,
Salamander Viewer has one very annoying bug while displaying EBCDIC (i.e CP1252) encoded files.
The EOL character for EBCDIC encoding in 0x40. Character 0x40 is incorrectly converted to 0x3F and subsequently displayed as a question mark. As a result all lines are displayed as a single line.


Example file is attached. Viewer encoding is "IBM EBCDIC International CP1252"

Re: Viewer does not show eol properly for EBCDIC viewer

Posted: 17 May 2010, 10:45
by mdruiter
EBCDIC (i.e CP1252)
EBCDIC is not CP1252 :? I think you mean you view an EBCDIC file with conversion to CP1252.
The EOL character for EBCDIC encoding in 0x40
The new line character in EBCDIC, and in your file, is 0x15.
I see it's translated to ? indeed, as is the line feed character (0x25).
See for instance: convert\centeuro\ebcd1252.tab
You can probably fix this yourself by changing the .tab files. Altap might want to fix this for everyone else.

Re: Viewer does not show eol properly for EBCDIC viewer

Posted: 17 May 2010, 12:10
by mdruiter
To fix this thing alone, use the attached file (remove .txt). But the same should be done for conversion to ASCII for instance, and probably other EBCDIC characters should change...

Re: Viewer does not show eol properly for EBCDIC viewer

Posted: 17 May 2010, 16:40
by pganelin
Thank you for the prompt response.
It fixed the problem.
Pavel

Re: Viewer does not show eol properly for EBCDIC viewer

Posted: 06 Apr 2012, 23:48
by mdruiter
Altap people, shouldn't you fix this?

Re: Viewer does not show eol properly for EBCDIC viewer

Posted: 07 Apr 2012, 15:59
by Petr Solin
What is your source for EBCDIC encoded files?

When I see EBCDIC encoding in unicode tables, I don't see any meaning for character 0x15, linefeed is character 0x25, see in all three attached encoding tables.

Re: Viewer does not show eol properly for EBCDIC viewer

Posted: 10 Apr 2012, 17:00
by SvA
0x15 is NEL = Newline and is used in text files for line separation, there is also 0x0d CR and 0x25 LF, which you currently map in conversion to their ASCII equivalents but this leaves the line separator problem beside. Since the conversion is unidirectional, there is nothing to stop you from converting NEL to one of these also.

Here's my suggestion: convert 0x15 to 0x0a or 0x0d to get unix/mac line endings in the converted text or leave it at 0x15 and add 0x15 to the line separator choices in the viewer's configuration.

Re: Viewer does not show eol properly for EBCDIC viewer

Posted: 12 Apr 2012, 08:39
by Petr Solin
OK, it seems to me that the best solution on Windows is to convert 0x15 "new line" to "line feed" (0x0a in CP125x). New EBCDIC tables are attached and will be available in next Preview Build. Thanks for reporting this!

Re: Viewer does not show eol

Posted: 13 May 2012, 20:26
by alm10965
I have approximately a similar problem.

If I want to view an Example file content:

Code: Select all

this is line1
this is line2
this is line3
this is line4
this is line5
this is line6
this is line7
the file content is transposed like this:

Code: Select all

t
h
i
s
 
i
s
 
l
i
n
e
1
t
h
i
s
 
i
s
 
l
i
n
e
2


t
h
i
s
 
i
s
 
l
i
n
e
3

t
h
i
s
 i
s
 
l
i
n
e
4


t
h
i
s 
i
s
 
l
i
n
e
5

t
h
i
s
 
i

s
 
l
i
n
e
6

t
h
i
s
 
i
s
 
l
i
n
e
7
I've tried out ebcd1252.tab.txt and the new version in convert.zip for ebcdasci.tab and ebcd1250.tab
D:\Salamand\254\convert\westeuro
D:\Salamand\254\convert\centeuro

But the result is to see the file content in one horizontal line like the test file SALAMANDER.TXT <http://forum.altap.cz/download/file.php?id=1016>

Anyway, it's not so easy to describe my problem and I'm not total sure, if I have posted at the right place at this forum. But I will appreciate, to get a solution.

Sincerely, alm
gplus.to/alm10965
PS: backup/newer version via http://pastebin.com/Fdchcnyy

Re: Viewer does not show eol properly for EBCDIC viewer

Posted: 03 Jun 2012, 20:57
by Petr Solin
It seems like UTF16 file (unicode), null characters are taken also as line-ends. Please upload some test file as attachment to this topic. Unicode is not supported yet, we plan it after release of version 3.0.