On Sun, 03 Feb 2019 02:01:18 +0100
Kent Karlsson via Unicode wrote:
> Den 2019-02-02 16:12, skrev "Richard Wordingham via Unicode"
> :
> > Doesn't Jerusalem in biblical Hebrew sometime have 3 marks below the
> > lamedh? The depth then is the maximum depth, not the sum of the
> > depths.
>
Hi Richard,
On Sun, Feb 3, 2019 at 2:32 AM Richard Wordingham via Unicode
wrote:
> That first reference doesn't even use the word 'visual'.
The Unicode BiDi algorithm does speak about "visual positions for
display", "reordering for display" etc.
> All I am saying is that your proposal should
On Sat, 2 Feb 2019 23:02:10 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> On Sat, Feb 2, 2019 at 9:57 PM Richard Wordingham
> wrote:
>
> > Seriously, you need to give a definition of 'visual order' for this
> > context. Not everyone shares your chiralist view.
>
> When I
Den 2019-02-02 16:12, skrev "Richard Wordingham via Unicode"
:
> On Sat, 02 Feb 2019 14:01:46 +0100
> Kent Karlsson via Unicode wrote:
>
>> Well, I guess you may need to put some (practical) limit to the number
>> of non-spacing marks (like max two above + max one below; overstrikes
>> are an
Hi Richard,
> Benjamin Riefenstahl wrote:
>> the severe limitations of that environment.
Richard Wordingham writes:
> Eli will probably tell me I'm behind the times, but there are a few
> places where a Gnome-terminal is better than an Emacs GUI window. One
> is colour highlighting of text
Hi Richard,
> My main interest in this, though, is in improving the general run of
> Indic terminal cell editors. If we can get Gnome-terminal working for
> Kharoshthi, things should improve for LTR Indic. Even working on the
> false assumption that Indic scripts are like Devanagari would be an
Hi Richard,
On Sat, Feb 2, 2019 at 9:57 PM Richard Wordingham
wrote:
> Seriously, you need to give a definition of 'visual order' for this
> context. Not everyone shares your chiralist view.
When I look at the Unicode BiDi algorithm, or go to an online demo at
On Sat, 2 Feb 2019 12:54:16 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> > > Are they okay to be present in visual order (the terminal's
> > > explicit mode, what we're discussing now) too?
> >
> > Where do you define the order for explicit mode?
>
> In explicit mode, the
Richard Wordingham wrote:
> Unicode may not deprecate the tag characters, but the characters of
> Plane 14 are widely deplored, despised or abhorred. That is why I
> think of it as the deprecated plane.
Think of it as the deplored plane, then, or the despised plane or the abhorred
plane or the
Philippe Verdy wrote:
> Actually not all U+E0020 through U+E007E are "un-deprecated" for this
> use.
Characters in Unicode are not "deprecated" for some purposes and not for
others. "Deprecated" is a clearly defined property in Unicode. The only
reference that matters here is in PropList.txt:
Hi Egmont, hi all,
This is a interesting discussion here. If only because I would have
thought that there is only minimal interest by the actual target
audience in supporting these scripts in a terminal, given the severe
limitations of that environment. The most important limitation seems to
On Sat, 2 Feb 2019 13:18:03 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> On Sat, Feb 2, 2019 at 12:43 PM Richard Wordingham via Unicode
> wrote:
>
> > I'm not conversant with the details of terminal controls and I
> > haven't used fields. However, where I spoke of lines above,
On Sat, 02 Feb 2019 14:01:46 +0100
Kent Karlsson via Unicode wrote:
> Den 2019-02-02 12:17, skrev "Egmont Koblinger" :
> > Most terminal emulators handle non-spacing combining marks, it's a
> > piece of cake. (Spacing marks are more problematic.)
> Well, I guess you may need to put some
Actually not all U+E0020 through U+E007E are "un-deprecated" for this use.
For now emoji flags only use:
- U+E0041 through U+E005A (mapping to ASCII letters A through Z used in
2-letter ISO3166-1 codes). These are usable in pairs, without requiring any
modifier (and only for ISO3166-1 registered
Den 2019-02-02 12:17, skrev "Egmont Koblinger" :
> the font. It's taken from EastAsianWidth (or other means, which we're
> working on: https://gitlab.freedesktop.org/terminal-wg/specifications/issues/9
Yes, that too:
FE0F ? VARIATION SELECTOR-16 = emoji variation selector
But the issue you
Hi Richard,
On Sat, Feb 2, 2019 at 12:43 PM Richard Wordingham via Unicode
wrote:
> I'm not conversant with the details of terminal controls and I haven't
> used fields. However, where I spoke of lines above, I believe you can
> simply translate it to fields. I don't know how one best handles
Hi Richard,
> Not all terminal emulators can deal with non-spacing combining
> characters.
Both Hebrew and Arabic seem to use non-spacing combining characters,
presumably other Arabic-like scripts too.
I forgot to state explicitly in my docs, but let's just say that
handling non-spacing
Hi Richard,
> > Are they okay to be present in visual order (the terminal's explicit
> > mode, what we're discussing now) too?
>
> Where do you define the order for explicit mode?
In explicit mode, the application (Emacs, Vim, whatever) reorders the
characters, and passes visual order (left to
On Fri, 1 Feb 2019 15:15:53 +0100
Egmont Koblinger via Unicode wrote:
> Hi Richard,
>
> On Fri, Feb 1, 2019 at 12:19 AM Richard Wordingham via Unicode
> wrote:
>
> > Cropped why? If the problem is the truncation of lines, one can
> > simple store the next character.
>
> Yup, trancation of
Hi Kent,
On Sat, Feb 2, 2019 at 12:41 AM Kent Karlsson via Unicode
wrote:
> [...] neither of which
> should directly consult the font [...]
> But terminals
> (read terminal emulators) can deal with mixed single width and double
> width characters (which is, IIUC, the motivation for the datafile
20 matches
Mail list logo
