Re: [unicode] Re: Unicode editing

2001-04-06 Thread Roozbeh Pournader
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

[unicode] Re: Unicode editing

2001-03-28 Thread Marco Cimarosti
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

[unicode] Re: Unicode editing

2001-03-28 Thread Jonathan Coxhead
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

[unicode] Re: Unicode editing

2001-03-28 Thread Marco Cimarosti
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

[unicode] Re: Unicode editing

2001-03-22 Thread Roozbeh Pournader
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

[unicode] Re: Unicode editing

2001-03-22 Thread Marco Cimarosti
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

[unicode] Re: Unicode editing

2001-03-21 Thread Marco Cimarosti
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

[unicode] Re: Unicode editing

2001-03-21 Thread J M Sykes
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:

[unicode] Re: Unicode editing (RE: Unicode complaints)

2001-03-21 Thread Marco Cimarosti
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

[unicode] Re: Unicode editing

2001-03-21 Thread Edward Cherlin
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

[unicode] Re: Unicode editing (RE: Unicode complaints)

2001-03-20 Thread Roozbeh Pournader
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

[unicode] Re: Unicode editing (RE: Unicode complaints)

2001-03-20 Thread Roozbeh Pournader
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