Re: Information Request

Re: Information Request

[Matthew Heaney]

In article <01bc8190$f18db140$82b45ec3@newart.artel.it>, "Valerio
Bellizzomi" <net@artel.it> wrote:

>Do anyone can send me a catalog or similar document concerning ADA
>distributors in Italy ?
>I'm very interested to buy an ADA programming environment, but I know
>nothing about the ADA market because I'm new to it.
>I've already studied the ADA Reference Manual in the last two years, but
>now I want to begin programming because I'va a big project to start.

Visit the Ada home page, at

<http://www.adahome.com>

There'll be a list of vendors there.

BTW: Ada is not an acronym, and therefore is never capitalized (otherwise,
over here on this side of the Atlantic, we're liable to think you mean the
American Dental Association).  The language was named in honor of a woman,
Lady Ada Lovelace, the daughter of Lord Byron and the assistent to Charles
Babbage.  She gets the prize for being the worlds first programmer, before
there were even computers!

Good luck with Ada!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Information Request.

[Austin Obyrne]

I’m Sure Somebody Knows This. 
 
Question : 

Unicode is a splendid solution to a huge problem but how does it work in practice.

Let’s say Alice lives in the Bronx in Manhattan and knows no CJK (Chinese, Japanese, Korean) languages.  Her employers are big manufacturers and employ Alice to send communications to those countries.  Not knowing any CJK she must have the message prepared as a set of codepoints of whatever language she is to use.  Is there an on-site or resident interpreter made available in cases like this.

I would be very grateful to anybody who can shed light on how it is done in such cases especially from anybody with hands-on experience.

The interest to readers in this group might be in knowing how to program for this situation – it must almost certainly affect programmers who have to implement schemes that accommodate this.

Adacrypt.

Re: Information Request.

[Shark8]

On Friday, September 27, 2013 3:45:27 AM UTC-6, Austin Obyrne wrote:
> I’m Sure Somebody Knows This. 
> 
> Question: 
> 
> Unicode is a splendid solution to a huge problem but how does it work in practice.

Is it? The problem of "combining characters" seems to me to defeat that if there is any way to display the same character with different combining-sequences/codepoints. (e.g. "overstriking" w/ combining characters |S and S| to yield $ [just an example from my 105-key keyboard].) This is to say that there should be only one combination of combining-character to yield a glyph.

Another problem is casing. (e.g. how do you handle 'ß'? Does "ss" ever become 'ß'? Does 'ß' ever become 'S'?)

While there has been a lot of work on the Unicode standard, I'm not sure that (a) the majority of Unicode *users* understand the vision that the Unicode standard embodies, and (b) the Unicode standard has as clear an insight into matters as, say, the ARG has into Ada. (After all, Unicode is aiming to be a universal character-encoding scheme, and that requires an insight into *all* languages and their writing-systems, while the ARG is focused only on a single artificial/constructed language.)

> I would be very grateful to anybody who can shed light on how it is done in such cases especially from anybody with hands-on experience.

Well, you could try starting here:
http://www.joelonsoftware.com/articles/Unicode.html

Re: Information Request.

[Austin Obyrne]

On Friday, September 27, 2013 4:53:46 PM UTC+1, Shark8 wrote:
> On Friday, September 27, 2013 3:45:27 AM UTC-6, Austin Obyrne wrote: > I’m Sure Somebody Knows This. > > Question: > > Unicode is a splendid solution to a huge problem but how does it work in practice. Is it? The problem of "combining characters" seems to me to defeat that if there is any way to display the same character with different combining-sequences/codepoints. (e.g. "overstriking" w/ combining characters |S and S| to yield $ [just an example from my 105-key keyboard].) This is to say that there should be only one combination of combining-character to yield a glyph. Another problem is casing. (e.g. how do you handle 'ß'? Does "ss" ever become 'ß'? Does 'ß' ever become 'S'?) While there has been a lot of work on the Unicode standard, I'm not sure that (a) the majority of Unicode *users* understand the vision that the Unicode standard embodies, and (b) the Unicode standard has as clear an insight into matters as, say, the ARG has into Ada. (After all, Unicode is aiming to be a universal character-encoding scheme, and that requires an insight into *all* languages and their writing-systems, while the ARG is focused only on a single artificial/constructed language.) > I would be very grateful to anybody who can shed light on how it is done in such cases especially from anybody with hands-on experience. Well, you could try starting here: http://www.joelonsoftware.com/articles/Unicode.html

Thanks for that but the link  was far too technical and was aimed at programmers while I am talking about the much simpler person who is a non-specialist keyboard operator.

My question is how is the interface with CJK provided – there must be somebody some where who converts the CJK into Unicode hexadecimal code points for understanding by the keyboard person other wise she cannot handle it.

Many thanks - Austin

Re: Information Request.

[Shark8]

> My question is how is the interface with CJK provided – there must be somebody some where who converts the CJK into Unicode hexadecimal code points for understanding by the keyboard person other wise she cannot handle it.


Usually via an IME (Input Method Editor [IIRC]), or a keyboard for the language [or setting your keyboard to that language, Windows allows that (though the labeling on the board won't match)] -- If you're using Windows 7, there should be a "Regions and Languages" item in the Control Panel: open it
- then go to the "Keyboards and Languages" tab,
- click the "Change Keyboard" button, 
another box titled "Text services and Input Languages" [containing three tabs] should appear:
- Click on the "General" tab, if not already there,
- Click on Add to add an new keyboard (or language)

And that's that.

(Unless I misunderstand your question altogether.)

Re: Information Request.

[Austin Obyrne]

On Friday, September 27, 2013 7:33:14 PM UTC+1, Shark8 wrote:
> > My question is how is the interface with CJK provided – there must be somebody some where who converts the CJK into Unicode hexadecimal code points for understanding by the keyboard person other wise she cannot handle it. Usually via an IME (Input Method Editor [IIRC]), or a keyboard for the language [or setting your keyboard to that language, Windows allows that (though the labeling on the board won't match)] -- If you're using Windows 7, there should be a "Regions and Languages" item in the Control Panel: open it - then go to the "Keyboards and Languages" tab, - click the "Change Keyboard" button, another box titled "Text services and Input Languages" [containing three tabs] should appear: - Click on the "General" tab, if not already there, - Click on Add to add an new keyboard (or language) And that's that. (Unless I misunderstand your question altogether.)

Lets say her name is Alice - the keyboard operator.

Alice now has  a CJK keyboard on screen (I think) that she uses to mouse-click in message characters in CJK (I don't envy her task).

I can see this working now but it seems a pretty inefficient way of doing it - it must be very, very slow.

In my crypto scheme I'm planning on every message being prepared as a sring of hex.  I'm arguing that this is now a string of plaintext that can be encrypted by any ASCII based encryption program (albeit hexadecimal digits I plan to treat them as alphanumeric characters in ASCII)- it will decrypyt exactly right I can assure everybody.

Alternatively I might read in the hexadecimal integer (180B say), convert it decimal and use that as the operand in the computaton of my vector ciphertext. The benefit of doing this is that the ciphertext expansion is kept to a minimum.

Both of these methods require the natural language plaintext to be submitted as a string of hex. That of course requires an interpreter on site.

This is what has been bothering me - what does happen in practice?? 

It doesn't sound to me as if Unicode is getting much use after all that up front in recent years.

Thanks Sharky8 - Austin

Re: Information Request.

[darkestkhan]

On Friday, September 27, 2013 8:08:02 PM UTC, Austin Obyrne wrote:
> On Friday, September 27, 2013 7:33:14 PM UTC+1, Shark8 wrote:
> 
> > > My question is how is the interface with CJK provided – there must be somebody some where who converts the CJK into Unicode hexadecimal code points for understanding by the keyboard person other wise she cannot handle it. Usually via an IME (Input Method Editor [IIRC]), or a keyboard for the language [or setting your keyboard to that language, Windows allows that (though the labeling on the board won't match)] -- If you're using Windows 7, there should be a "Regions and Languages" item in the Control Panel: open it - then go to the "Keyboards and Languages" tab, - click the "Change Keyboard" button, another box titled "Text services and Input Languages" [containing three tabs] should appear: - Click on the "General" tab, if not already there, - Click on Add to add an new keyboard (or language) And that's that. (Unless I misunderstand your question altogether.)
> 
> 
> 
> Lets say her name is Alice - the keyboard operator.
> 
> 
> 
> Alice now has  a CJK keyboard on screen (I think) that she uses to mouse-click in message characters in CJK (I don't envy her task).
> 
> 
> 
> I can see this working now but it seems a pretty inefficient way of doing it - it must be very, very slow.
> 
> 
> 
> In my crypto scheme I'm planning on every message being prepared as a sring of hex.  I'm arguing that this is now a string of plaintext that can be encrypted by any ASCII based encryption program (albeit hexadecimal digits I plan to treat them as alphanumeric characters in ASCII)- it will decrypyt exactly right I can assure everybody.
> 
> 
> 
> Alternatively I might read in the hexadecimal integer (180B say), convert it decimal and use that as the operand in the computaton of my vector ciphertext. The benefit of doing this is that the ciphertext expansion is kept to a minimum.
> 
> 
> 
> Both of these methods require the natural language plaintext to be submitted as a string of hex. That of course requires an interpreter on site.
> 
> 
> 
> This is what has been bothering me - what does happen in practice?? 
> 
> 
> 
> It doesn't sound to me as if Unicode is getting much use after all that up front in recent years.
> 

Unicode is used very commonly all around the world - main reason is that it is interoperable between all (spoken) languages and systems (as long as they support Unicode)

You know what...  świat jest większy niż CJK i angielski (world is bigger than CJK and english, written in Polish) - many European languages are using additional letters, add to this cyrylic and some other alphabets and then you will see how nice Unicode is. Just for your information - before unicode we had several encoding methods for each language, making things very complex. Now it is very simple - just handling Unicode (not trivial but at least we can assume something about input). As for inputting CJK - my best advise would be to try inputting some Japanese/Chinese. You will see how it works (hint: romanization). There is no "big keyboard on the screen".

Re: Information Request.

[Shark8]

On Friday, September 27, 2013 2:08:02 PM UTC-6, Austin Obyrne wrote:
> 
> In my crypto scheme I'm planning on every message being prepared as a sring of hex.  I'm arguing that this is now a string of plaintext that can be encrypted by any ASCII based encryption program (albeit hexadecimal digits I plan to treat them as alphanumeric characters in ASCII)- it will decrypyt exactly right I can assure everybody.
> 
> Alternatively I might read in the hexadecimal integer (180B say), convert it decimal and use that as the operand in the computaton of my vector ciphertext. The benefit of doing this is that the ciphertext expansion is kept to a minimum.
> 
> Both of these methods require the natural language plaintext to be submitted as a string of hex. That of course requires an interpreter on site.

Er, it sounds to me as if you don't really know what you're talking about. In general, there are two items in play dealing with text: the encoding, and the character-set. Unicode is a character-set [kinda], encoding for Unicode can be 8-bit/variable-length, 16-bit/variable-length, 32-bit/fixed-length. In any case, the difference between the two is this: one maps some bit-sequence to a value (this is the encoding), the other maps a value to a glyph (this is the character-set).

Example:
Value $4C => '<' EBDIC
Value $4C => 'L' ASCII/Unicode
Hex $e2b4a5 => Value $2D25 (via 8-bit encoding) => GEORGIAN SMALL LETTER HOE [unicode]
Hex $00002d25 => Value $2D25 (via 32-bit encoding) => GEORGIAN SMALL LETTER HOE [unicode]

So there are [at least] two different 'mappings' in place when you're talking about text. (Three if you want to talk about typing, as there's something called keyboard scan-codes involved.)

Re: Information Request.

[Oliver Kleinke]

> Let’s say Alice lives in the Bronx in Manhattan and knows no CJK
> (Chinese, Japanese, Korean) languages.  Her employers are big
> manufacturers and employ Alice to send communications to those
> countries.  Not knowing any CJK she must have the message prepared as
> a set of codepoints of whatever language she is to use.  Is there an
> on-site or resident interpreter made available in cases like this.
> 
> I would be very grateful to anybody who can shed light on how it is
> done in such cases especially from anybody with hands-on experience.

Usually Alice would use a keyboard to enter the messages, one that has
chinese, japanese or korean glyphs on it.

Re: Information Request.

[darkestkhan]

On Friday, September 27, 2013 8:32:54 PM UTC, Oliver Kleinke wrote:
> > Let’s say Alice lives in the Bronx in Manhattan and knows no CJK
> 
> > (Chinese, Japanese, Korean) languages.  Her employers are big
> 
> > manufacturers and employ Alice to send communications to those
> 
> > countries.  Not knowing any CJK she must have the message prepared as
> 
> > a set of codepoints of whatever language she is to use.  Is there an
> 
> > on-site or resident interpreter made available in cases like this.
> 
> > 
> 
> > I would be very grateful to anybody who can shed light on how it is
> 
> > done in such cases especially from anybody with hands-on experience.
> 
> 
> 
> Usually Alice would use a keyboard to enter the messages, one that has
> 
> chinese, japanese or korean glyphs on it.

For chinese and japanese one usually uses IME to convert sounds into characters. Sounds are inputted using particular romanization method.

As for korean you can do it both ways but yeah - usually you input using korean keyboard layout (the same goes for Russian).

Re: Information Request.

[Austin Obyrne]

On Friday, September 27, 2013 10:45:27 AM UTC+1, Austin Obyrne wrote:
> I’m Sure Somebody Knows This. Question : Unicode is a splendid solution to a huge problem but how does it work in practice. Let’s say Alice lives in the Bronx in Manhattan and knows no CJK (Chinese, Japanese, Korean) languages. Her employers are big manufacturers and employ Alice to send communications to those countries. Not knowing any CJK she must have the message prepared as a set of codepoints of whatever language she is to use. Is there an on-site or resident interpreter made available in cases like this. I would be very grateful to anybody who can shed light on how it is done in such cases especially from anybody with hands-on experience. The interest to readers in this group might be in knowing how to program for this situation – it must almost certainly affect programmers who have to implement schemes that accommodate this. Adacrypt.

Many thanks all.

My question has been answered.

There isn’t any onsite interpreter as such – it falls to the programmer – also, it would not be a non specialist keyboard trained operator in such a case.

The choice of mode of operation would be subjective.

The mode that would best suit encryption (going on simultaneously in tandem with reading in) for me would be to work in Unicoded hexadecimal representation and to encrypt this simple hexadecimal string in whatever way was most convenient.  Extra considerations have to be ciphertext expansion but with the price of memory not so great these days that is acceptable even if it is very great (it is a bit large with the vector cryptography that I use).  Transmission costs would have to be considered also of course.

I think Unicode is a great invention at the end of the day. 

From my point of view I do know a lot more now than I did at the beginning of this post.

Let me say thanks to every body for their help.

Austin O’ Byrne