Topic: Custom Translation Tables (1 of 11), Read 65 times
Conf: Converting, Translating
From: John H
Date: Monday, May 03, 2004 07:40 PM

Hi,

I made a simple ROT-13 table to experiment with. The translate
TO works fine however the translate FROM operation does nothing
that I can see -- other than flagging the file changed.

Translate TO again restores the text.. I suppose this is by design
but it's un-intuitive.

Is it possible to create a single table file, or table pair that
will use both TO and FROM selections?

Also, the alert message box (when translating a file) that appears,
seems sort of incorrect. In testing I could simply reverse the
operation with a control-z.

--
John
VPW[64] 6.12.1
Windows 2000 (5.0.2195 Service Pack 4)

 


Topic: Re: Custom Translation Tables (2 of 11), Read 62 times
Conf: Converting, Translating
From: Ted Green
Date: Monday, May 03, 2004 08:47 PM

At 07:41 PM 5/3/2004, you wrote:

>I made a simple ROT-13 table to experiment with. The translate
>TO works fine however the translate FROM operation does nothing
>that I can see -- other than flagging the file changed.
>
>Translate TO again restores the text.. I suppose this is by design
>but it's un-intuitive.

I don't understand your problem; the translate tables work as intended. I don't think you created the tables correctly. Generally a "FROM" will reverse a "TO", but it depends upon the table.

>Is it possible to create a single table file, or table pair that
>will use both TO and FROM selections?

Tables have to be in pairs; be sure to follow the on-line help instructions for creating tables very carefully.

>Also, the alert message box (when translating a file) that appears,
>seems sort of incorrect. In testing I could simply reverse the
>operation with a control-z.

You obviously only tested a small file; the translation of a large file cannot be undone.

Ted.

 


Topic: Custom Translation Tables (3 of 11), Read 65 times, 1 File Attachment
Conf: Converting, Translating
From: John H
Date: Monday, May 03, 2004 09:05 PM

On Mon, 3 May 2004 20:47:55 -0400 GMT, Ted Green wrote:

> At 07:41 PM 5/3/2004, you wrote:

>>I made a simple ROT-13 table to experiment with. The translate
>>TO works fine however the translate FROM operation does nothing
>>that I can see -- other than flagging the file changed.
>>
>>Translate TO again restores the text.. I suppose this is by design
>>but it's un-intuitive.

> I don't understand your problem; the translate tables work as
> intended. I don't think you created the tables correctly.
> Generally a "FROM" will reverse a "TO", but it depends upon the
> table.

Basically I took the original default .TBL file and changed the TO
table to N-ZA-M and n-za-m in place of A-MN-Z and a-mn-z. The FROM
is original A-Z & a-z. Seems like the way the PDF instructed.

--
John

 
ROT13.TBL (1KB)

 


Topic: Custom Translation Tables (4 of 11), Read 64 times
Conf: Converting, Translating
From: John H
Date: Monday, May 03, 2004 10:19 PM

On Mon, 3 May 2004 20:47:55 -0400 GMT, Ted Green wrote:

>>Is it possible to create a single table file, or table pair that
>>will use both TO and FROM selections?

> Tables have to be in pairs; be sure to follow the on-line help
> instructions for creating tables very carefully.

I discovered my misunderstanding I believe. Although I read about the
position being representative to the 256 different ascii characters I
was wrongly focused on TO - FROM, thinking the FROM table was supposed
to be representative of the source characters, neglecting the fact
that the table position is the key to un-translating and not the FROM
table.

--
John

 


Topic: Re: Custom Translation Tables (5 of 11), Read 66 times
Conf: Converting, Translating
From: Ted Green
Date: Monday, May 03, 2004 11:06 PM

At 10:21 PM 5/3/2004, you wrote:
>I discovered my misunderstanding I believe. Although I read about the
>position being representative to the 256 different ascii characters I
>was wrongly focused on TO - FROM, thinking the FROM table was supposed
>to be representative of the source characters, neglecting the fact
>that the table position is the key to un-translating and not the FROM
>table.

Sounds like you have it figured out now. I am sorry for the confusion due to the brevity of the documentation. When I wrote the doco, I didn't think anyone would actually ever read it. :-)

Ted.


Ted.
-------------------------------------------------------------------------
Ted Green (ted@...) Greenview Data, Inc.
Web: www.... PO Box 1586, Ann Arbor, MI 48106
Tel: (734) 996-1300 Fax: (734) 996-1308 VEDIT - Text/Data/Binary Editor
-------------------------------------------------------------------------
Spam problems? www.SpamStopsHere.com blocks 99% of spam for businesses.

 


Topic: Custom Translation Tables (6 of 11), Read 66 times
Conf: Converting, Translating
From: Christian Ziemski
Date: Tuesday, May 04, 2004 02:41 AM

John:

On 5/3/2004 10:19:58 PM, you wrote:

>I discovered my misunderstanding I
>believe. Although I read about the
>position being representative to the 256
>different ascii characters I
>was wrongly focused on TO - FROM,
>thinking the FROM table was supposed
>to be representative of the source
>characters, neglecting the fact
>that the table position is the key to
>un-translating and not the FROM
>table.

You may want to try my macro TBL-DUMP.VDM which displays the contents of a TBL-file a bit more readable.

http://ziemski.privat.t-online.de/vedit/macros/tbl-dump.vdm


Christian

 


Topic: Custom Translation Tables (7 of 11), Read 63 times
Conf: Converting, Translating
From: Ian Binnie
Date: Tuesday, May 04, 2004 10:13 PM

On 5/4/2004 2:41:13 AM, Christian Ziemski wrote:

>You may want to try my macro
>TBL-DUMP.VDM which displays the contents
>of a TBL-file a bit more readable.
>
>http://ziemski.privat.t-online.de/vedit/
>macros/tbl-dump.vdm
>
>
>Christian

This is a neat little macro.
It still needs some mental gymnastics to create the table.
It would be nice if it was possible to display OEM and ANSI together.

 


Topic: Custom Translation Tables (8 of 11), Read 63 times
Conf: Converting, Translating
From: Pauli Lindgren
Date: Wednesday, May 05, 2004 05:35 AM

On 5/4/2004 10:13:34 PM, Ian Binnie wrote:
>
>It would be nice if it was possible to
>display OEM and ANSI together.

This might be possible with Unicode.
If you convert the table into Unicode, you could view it for example with Notepad.

However, Vedit's Unicode conversion macro currently only work with ANSI character set. (BTW, it is called ASCII to Unicode conversion, even if it works with 8-bit ANSI characters, too).

It might be good idea to expand the conversion to work with full Windows character set. And maybe with DOS (OEM) character set, and even with Mac character set, too.
Christian?

--
Pauli

 


Topic: Custom Translation Tables (9 of 11), Read 61 times
Conf: Converting, Translating
From: Christian Ziemski
Date: Wednesday, May 05, 2004 10:05 AM

Pauli:

On 5/5/2004 5:35:29 AM, you wrote:
>
>However, Vedit's Unicode conversion macro currently only work with ANSI
>character set. (BTW, it is called ASCII to Unicode conversion, even if it works
>with 8-bit ANSI characters, too).
>
>It might be good idea to expand the conversion to work with full Windows
>character set. And maybe with DOS (OEM) character set, and even with Mac
>character set, too.
>Christian?

Hmmm, I don't know much about character sets and especially UNICODE.

The UNICODE translation in VEDIT is a really simple one:
It only changes single bytes into double-bytes and vice versa.
No real character set translation!
IMHO that wouldn't be possible and wouldn't make sense via VEDIT macro.
Somewhere here in WebBoard there has been a discussion about that some time ago (IIRC).

Christian

 


Topic: Custom Translation Tables (10 of 11), Read 62 times
Conf: Converting, Translating
From: Ian Binnie
Date: Thursday, May 06, 2004 01:59 AM

On 5/5/2004 10:05:21 AM, Christian Ziemski wrote:
>Pauli:
>
>On 5/5/2004 5:35:29 AM, you wrote:
>>
>>However, Vedit's Unicode conversion macro currently only work with ANSI
>>character set. (BTW, it is called ASCII to Unicode conversion, even if it works
>>with 8-bit ANSI characters, too).
>>
>>It might be good idea to expand the conversion to work with full Windows
>>character set. And maybe with DOS (OEM) character set, and even with Mac
>>character set, too.
>>Christian?
>
>Hmmm, I don't know much about character
>sets and especially UNICODE.
>
>The UNICODE translation in VEDIT is a
>really simple one:
>It only changes single bytes into
>double-bytes and vice versa.
>No real character set translation!
>IMHO that wouldn't be possible and
>wouldn't make sense via VEDIT macro.
>Somewhere here in WebBoard there has
>been a discussion about that some time
>ago (IIRC).
>
I did some playing with unicode a little while ago.
There are conversion programs, but as stated above all work on ANSI (or whatever ISO the purists call it now). Any enhancement would need to consider Code Page & Locale.

See:-
www.unicode.org

in particular:-
http://www.unicode.org/Public/PROGRAMS/CVTUTF

This has lots of stuff, but like most standards documentation is really only comprehensibe to the people who work on it all the time.

The Windows API has some unicode translation functions, I may look at these.

Unfortunately more and more programs output in unicode. For those of us using the US English characters this is not a major problem, and the simple conversions in Vedit work.

At some time in the future Ted might have to include unicode support, but I don't envy him the task, particularly if Vedit is to remain in Assembler, and not include the Microsoft bloatware needed to handle it.

 


Topic: Custom Translation Tables (11 of 11), Read 65 times
Conf: Converting, Translating
From: Pauli Lindgren
Date: Tuesday, May 11, 2004 01:52 PM

On 5/6/2004 1:59:13 AM, Ian Binnie wrote:
>
>I did some playing with unicode a little while ago.
>There are conversion programs, but as
>stated above all work on ANSI (or
>whatever ISO the purists call it now).
>Any enhancement would need to consider
>Code Page & Locale.

I was thinking about converting between Unicode and Windows-1252 character sets. I believe that is what most Vedit users have. So there is no need to check any code pages.

Assuming code page 1252 would not work 100% right with Windows using some other code page (perhaps in Russia or Greece). However, the current method (just add byte 0x00 in front of each character) produces ALWAYS wrong results for Windows characters in range 0x80 to 0x9f.

The conversion is not that complex. You need a special conversion only for characters in range 0x80 to 0x9f. When converting from Unicode, you need a special conversion if the MSB is something else than 0x00.

Anyway, even if the macro is not changed, the menu could read "Unicode to ANSI" instead of "Unicode to ASCII".
(The term ANSI is used for ISO 8859-1 in Vedit already).



--
Pauli








ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT