Mati Allouche wrote:
> [...] All this combines to produce a
> long posting. If this subject is not one of your favorites,
> you should quit before getting bored :-)
And this of course also applies to the follow up.
> In order to ease the reading, I have inserted my answers to
> Marco within
>
On 05/10/2001 02:11:55 PM Edward Cherlin wrote:
>Regardless of current usage, "keyboard language" is a dreadful term,
I concur.
I find the following terminology generally works and, at least for me,
avoids confusion:
- "input method": Any system for data entry, including simple keyboards,
inp
]
# [mailto:[EMAIL PROTECTED]]On Behalf Of Edward Cherlin
# Sent: Thursday, May 10, 2001 10:12 PM
# To: [EMAIL PROTECTED]
# Subject: Keyboard terminology (was RE: Unicode editing)
#
#
# At 4:23 PM +0200 5/10/01, Marco Cimarosti wrote:
# >Mati Allouche wrote:
# [snip]
#
# > > [...]
# > >
At 4:23 PM +0200 5/10/01, Marco Cimarosti wrote:
>Mati Allouche wrote:
[snip]
> > [...]
> > First of all, I would prompt Mati to find a different term
>> than "Keyboard Language", e.g. "Keyboard Layout" or
>> "Keyboard Locale". [...]
>>
>> I have no doubt that my terminology can be improved
Mati Allouche wrote:
> [...] All this combines to produce a
> long posting. If this subject is not one of your favorites,
> you should quit before getting bored :-)
And this of course also applies to the follow up.
> In order to ease the reading, I have inserted my answers to
> Marco within
>
Jonathan Rosenne wrote:
> > ** Remove "Keyboard Language"? [...]
> Our keyboards are bi-lingual, they come with two keyboard
> languages, Hebrew and English, same as 8859-8. [...]
> [...] we hit Alt-Shift to switch keyboard language.
I see: if "keyboard language" is a standard term in the operat
> -Original Message-
> From: Marco Cimarosti [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 26, 2001 7:55 PM
>
> > Matitiahu Allouche (Mati) has prepared a document "Guidelines
> > of a Logical User Interface for Editing Bidirectional Text".
> > It is being discussed at the SII.
> >
>
> Matitiahu Allouche (Mati) has prepared a document "Guidelines
> of a Logical User Interface for Editing Bidirectional Text".
> It is being discussed at the SII.
>
> With his kind permission, I have placed it at
> http://www.qsm.co.il/Hebrew/logicUI22.htm
Thanks for the link! Matitiahu's docum
Matitiahu Allouche (Mati) has prepared a document "Guidelines of a Logical User
Interface for Editing Bidirectional Text". It is being discussed at the SII.
With his kind permission, I have placed it at
http://www.qsm.co.il/Hebrew/logicUI22.htm
Comments are welcome.
Jony
I must correct a couple of blunders in my previous mail. Sorry about this.
But a plain "sorry" is so inappropriate these days, so please allow me to
say: "regret", "wan xi", "yihan", "very sorry", "baoqian", "qian yi",
"apologies", "we apologize", "daoqian".
This rich apology vocabulary is taken
Bob Hallissy wrote:
> >4) Text selections, cursor movements and mouse hit-testing
> are done in a
> strictly visual way, so they are more or less as easy as in non-bidi
> editing.
>
> My question is about strictly visual selection: I take this
> to mean that when I select a region of text, the
I haven't followed this discussion all along, so sorry if this has been
addressed, or if I'm misunderstanding you.
>4) Text selections, cursor movements and mouse hit-testing are done in a
strictly visual way, so they are more or less as easy as in non-bidi
editing.
My question is about strictl
(A note: I am starting too wonder whether this discussion is appropriate on
this mailing list. Or whether we should prepend an "off topic" prefix...)
Roozbeh Pournader [mailto:[EMAIL PROTECTED]] wrote:
> On Wed, 28 Mar 2001, Marco Cimarosti wrote:
> > Storing the level with each character is enou
Ok, just found time to continue the thread...
On Wed, 28 Mar 2001, Marco Cimarosti wrote:
> It depends. Enough for what?
>
> Storing the level with each character is enough for generating *one* valid
> Unicode logical order. This logical string should have the same logical
> order as the origi
Jonathan Coxhead wrote:
>Consider
>
> RLE a b c PDF RLE d e f PDF
>
> in an LTR region (where a, b, ... are neutral). This displays as
>
> cbafed
No, I think it displays as:
fedcba
(Read on...)
> i e, 2 RTL runs in LTR order. If you encode that as
>
> a b c d
On 28 Mar 01, at 12:02, Marco Cimarosti wrote:
> > > struct MyWysiwygGlyph
> > > {
> > > wchar_t GlyphCode;
> > > int EmbeddingLevel;
> > > };
> > > I think that Roozbeh had something quite similar in mind.
> >
> > Yes. I was not sure that if that's enoug
Roozbeh Pournader wrote:
> On Wed, 21 Mar 2001, Marco Cimarosti wrote:
> > struct MyWysiwygGlyph
> > {
> > wchar_t GlyphCode;
> > int EmbeddingLevel;
> > };
> > I think that Roozbeh had something quite similar in mind.
>
> Yes. I was not sure that i
On Wed, 21 Mar 2001, Marco Cimarosti wrote:
> Visual: she said i need water and expired
> Levels: 0
> Logic:she said i need water and expired
>
> I don't see how such an embedding could be useful, so I would iron
> level "2" to the surrounding
On Wed, 21 Mar 2001, Marco Cimarosti wrote:
> struct MyWysiwygGlyph
> {
> wchar_t GlyphCode;
> int EmbeddingLevel;
> };
>
> I think that Roozbeh had something quite similar in mind.
Yes. I was not sure that if that's enough, but after
I was wondering whether storing the bidirectional embedding level together
with *each* character would have resulted in an excessive increase in the
size of the edit buffer. 'Cause, as someone recently noted, "size DOES
matter".
But, checking in the bidirectional algorithm
(http://www.unicode.or
Edward Cherlin wrote:
> >But, in this case, each *single* character in the block must be
> >independently flagged with the property, so that it retains
> it also if it is
> >copied&pasted somewhere else: the actual start and end codes
> will only be
> >generated when rebuilding the Unicode stri
ource is
the Oxford Dictionary of Quotations, second ed. 1953. I hope it's not
significant that it doesn't appear in the 1979 edition.)
- Original Message -
From: "Edward Cherlin" <[EMAIL PROTECTED]>
To: "Unicode List" <[EMAIL PROTECTED]>
Sent:
Roozbeh Pournander wrote:
> If you open a file that contains two adjacent runs at the
> same level, will you make them one run when you write the file?
That was the idea. But only in the case when it is *really* an embedding
having the same directionality as the text where it is inserted. Like
At 9:30 AM -0800 3/17/01, Marco Cimarosti wrote:
[snip]
>But, although I mentioned rich text, what I really had in mind was plain
>text. Maybe in a rich text environment, where it is normal to get a run of
>text it and tag it with some property (e.g. underlined, bold, etc.), it
>would also be pos
On Tue, 20 Mar 2001, Marco Cimarosti wrote:
> I am not sure that I catch what you mean here.
>
> My simplified view was that each visual segment of text (i.e. one or more
> adjacent characters at the same level) should have the opposite
> directionality than the two segments around it.
If yo
On Tue, 20 Mar 2001, Marco Cimarosti wrote:
> I am not sure what you mean, but it sounds very similar to what you wanted
> to avoid.
That was a preface, for the next idea that you've somehow agreed to...
> Condition (a) clearly doesn't apply to applications whose purpose *is* to
> change the
Your message
To: Unicode List
Cc: Unicode List; 'Michael Everson'
Subject: RE: Unicode editing (RE: Unicode complaints)
Sent:Tue, 20 Mar 2001 06:28:44 -0800
did not reach the following recipient(s):
[EMAIL PROTECTED] on Tue, 20 Mar 2001 13:08:01 -0800
> If it were me, I would keep two copies who update each other
> when that's needed.
I am not sure what you mean, but it sounds very similar to what you wanted
to avoid.
> Or perhaps we should only keep the active paragraph in your
> WYSIWYG format?
Makes sense. Also, all lines (or paragraphs)
On Tue, 20 Mar 2001, Marco Cimarosti wrote:
> Hmmm... I would say that my "WYSIWYG Unicode", or any other similar display
> format, is not fit for doing searching, sorting, spell checking, etc.
>
> For all these kinds of things I would convert text back to "proper Unicode"
> and go with standa
Roozbeh Pournader wrote:
> People will fail to use it. Software should show the
> ligature. Any way, I
> don't like using a Lam-Alef character in the text. I want to
> do sub-word
> searching and things like that, and it will ruin those.
Hmmm... I would say that my "WYSIWYG Unicode", or any oth
Roozbeh Pournader wrote:
> Exactly what I was talking about :)
Of course it is your idea. I just thought about it in the last week-end :)
> I'm not sure about the times two
> embeddings occur exactly adjacent to each other. I have a sense that
> merging the two may have bad effects.
I am not su
On Mon, 19 Mar 2001, Marco Cimarosti wrote:
> I never considered this. For a casual user it is so cute to see the letters
> changing shape, and it is also very instructive for one learning the script.
>
> But I see how this must be annoying for people typing in Arabic all the
> time.
The great
On Mon, 19 Mar 2001, Marco Cimarosti wrote:
> And this could happen with lam-alef, not only for users who don't have the
> ligature on their keyboard, but also for users who have it but fail to use
> it.
People will fail to use it. Software should show the ligature. Any way, I
don't like using
On Mon, 19 Mar 2001, Marco Cimarosti wrote:
> I have been thinking about this the whole week-end, and I too came to
> the conclusion that the resolved embedding levels is what really needs
> to be maintained during editing. Once you have these, you can safely
> throw away all the bidi controls
Sorry for turning this thread into a monologue, but I must correct myself
once more:
> If you select "ghi" and use the "Bidi Override" command, you
> have a LTR text with one RTL embedding. Part of the RTL text
> has an unnatural directionality (LRT characters forced to
> RTL), so the resultin
On 03/19/2001 08:00:18 AM Marco Cimarosti wrote:
>I wrote:
[snip]
>> I think you need another condition:
>>
>> 3. a word-forming Arabic (or other connective script)
>> character has just been typed.
>
>Why don't I connect my brain before starting typing!?
>
>Condition 1 is more than enough to p
I wrote:
> Peter constable wrote:
> > 1. the insertion point is not before a word-forming Arabic (or other
> > connective script) character, and
> > 2. some local (i.e. adjacent to the insertion point) change
> > to the text (insertion or deletion) has occurred since the insertion
> > was moved
Roozbeh Pournader wrote:
> ...Take
> this example: she wants to type "MEEM-SEEN-TEH-QAF-LAM". She
> presses Meem,
> she sees an isolated Meem, she presses Seen, the Meem becomes initial
> Meem, and a final Seen gets added. She presses Teh, Seen
> becomes medial,
> final Tah getting added, W
Roozbeh Pournader wrote:
> > - All sequences of characters that are perceived as single
> letters by users
> > are treated as such (e.g., laam-alif in Arabic or the ksha
> ligature in many
> > Indic scripts). Of course, the "DErenderer" maps these
> extra glyphs back to
> > the corresponding se
Roozbeh Pournader wrote:
> Now I like this. This is getting near to what I had in mind.
> Characters,
> together with their embedding levels (and possibly more).
You are right!
I have been thinking about this the whole week-end, and I too came to the
conclusion that the resolved embedding level
On Sat, 17 Mar 2001, Marco Cimarosti wrote:
> But I see no easy way to conjugate the complexity of bidi embedding and
> overriding with the simplicity of a WYSIWYG representation. Not in plain
> text, however.
I do not see an easy way either. Good bidi editing, needs more thought and
experienc
Roozbeh Pournader wrote:
> This is the most simple but working method, one that's
> implemented in good
> old bidi software that got implemented by native bidi people.
> The users
> feel easy with this, but this may not be enough for them.
> [...]
> In short, good bidi editing should address bot
On 03/16/2001 01:18:36 PM Roozbeh Pournader wrote:
>...Take
>this example: she wants to type "MEEM-SEEN-TEH-QAF-LAM". She presses Meem,
>she sees an isolated Meem, she presses Seen, the Meem becomes initial
>Meem, and a final Seen gets added. She presses Teh, Seen becomes medial,
>final Tah gett
On Fri, 16 Mar 2001, Marco Cimarosti wrote:
> - The automatic shaping of Arabic, Syriac and Mongolian not consistent with
> the manual shaping of Hebrew and Greek.
There is also something I always wanted to say about this. Automatic
shaping of Arabic has also some problems with the current imp
44 matches
Mail list logo
