Richard Wordingham wrote:
> Language tagging is already available in Unicode, via the tag
> characters in the deprecated plane.
Plane 14 isn't deprecated -- that isn't a property of planes -- and the
tag characters U+E0020 through U+E007E have been un-deprecated for use
with emoji flags. Only
On Fri, 1 Feb 2019 14:47:22 +0100
Egmont Koblinger via Unicode wrote:
> Hi Ken,
>
> > [language tag]
> > That is a complete non-starter for the Unicode Standard.
>
> Thanks for your input!
>
> (I hope it was clear that I just started throwing in random ideas, a
On Fri, 1 Feb 2019 13:02:45 +0200
Khaled Hosny via Unicode wrote:
> On Thu, Jan 31, 2019 at 11:17:19PM +, Richard Wordingham via
> Unicode wrote:
> > On Thu, 31 Jan 2019 12:46:48 +0100
> > Egmont Koblinger wrote:
> >
> > No. How many cells do CJK ideograp
in Unicode that cannot be changed because of stability rules).
Le jeu. 31 janv. 2019 à 16:32, wjgo_10...@btinternet.com via Unicode <
unicode@unicode.org> a écrit :
> Is the way to try to resolve this for a proposal document to be produced
> for using Variation Selector 14 in or
Hi,
I'm trying to respond to every question, but I'm having a hard time
keeping up :-)
Thanks a lot for all the precious input about shaping!
Here's my suggestion, for version 0.2 of the recommendation:
- No longer encourage any use of presentation form characters.
- State that it's the
> From: Egmont Koblinger
> Date: Fri, 1 Feb 2019 14:35:35 +0100
> Cc: Frédéric Grosshans ,
> unicode@unicode.org
>
> > You could do that, but it will require a lot of non-trivial processing
> > from the applications. Text-mode applications don't want any complex
> > tinkering, they want
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 line for example.
I agree that one could "store the next character".
Hi Ken,
> [language tag]
> That is a complete non-starter for the Unicode Standard.
Thanks for your input!
(I hope it was clear that I just started throwing in random ideas, as
in a brainstorming session. This one is ruled out, then.)
cheers,
egmont
On Thu, Jan 31, 2019 at 4:26 PM Eli Zaretskii wrote:
> > Yes, I do argue that emacs will need to print a new escape sequence.
> > Which is much-much-much-much-much better than having to tell users to
> > go into the settings of their macOS Terminal / Konsole /
> > gnome-terminal etc. and disable
> From: Egmont Koblinger
> Date: Fri, 1 Feb 2019 14:16:03 +0100
> Cc: Adam Borowski , unicode@unicode.org
>
> There's absolutely no way we could reorder first, and then handle
> TAB's cursor movement. TAB's cursor movement happens in the lower
> layer, reordering happens in the upper one.
But
Hi,
On Thu, Jan 31, 2019 at 4:14 PM Eli Zaretskii wrote:>
> I suggest that you show the result to someone who does read Arabic.
I contacted one guy who is pretty knowledgeable in Arabic scripts, as
well as terminal emulation, I sent out an early unpublished version of
the proposal to him, but
> From: Egmont Koblinger
> Date: Fri, 1 Feb 2019 13:54:02 +0100
> Cc: Adam Borowski , unicode@unicode.org
>
> For this behavior, the only feature you need from a terminal emulator
> is to have a mode where it doesn't shuffle the characters. Currently
> every emulator I'm aware of has such a
> From: Egmont Koblinger
> Date: Fri, 1 Feb 2019 13:40:48 +0100
> Cc: unicode@unicode.org
>
> I now understand that presentation forms isn't an ideal possible
> approach, and the recommendation should be improved here.
>
> Until it happens, I'm uncertain whether using presentation form
>
Hi,
On Thu, Jan 31, 2019 at 4:10 PM Eli Zaretskii wrote:
> The reordering happens before TABs are converted to cursor motion,
> does it not?
No, not at all.
You cannot "mix" handling the input and reordering, since the input is
not available as a single step but arrives continuously in a
Hi Eli,
> So we will some day have one such terminal emulator. That's good, but
> a text-mode application that needs to support bidi cannot rely on its
> users all having access to that single terminal.
No. A text-mode application that needs to support BiDi must do the
BiDi itself and pass
Hi Eli,
> Arabic presentation forms are more like an exception than a rule, I
> hope you understand this by now. Most languages/scripts don't have
> such forms, and even for Arabic they cover only a part of what needs
> to be done to present correctly shaped text. Complex script shaping
> is
On Thu, Jan 31, 2019 at 11:17:19PM +, Richard Wordingham via Unicode wrote:
> On Thu, 31 Jan 2019 12:46:48 +0100
> Egmont Koblinger wrote:
>
> No. How many cells do CJK ideographs occupy? We've had a strong hint
> that a medial BEH should occupy one cell, while an isol
On 2019-01-31 3:18 PM, Adam Borowski via Unicode wrote:
> They're only from a spammer's point of view.
Spammers need love, too. They’re just not entitled to any.
> Date: Thu, 31 Jan 2019 23:17:19 +
> From: Richard Wordingham via Unicode
>
> Emacs needs a lot of help - I can't write a generic Tai Tham
> OpenType .flt file :-(
Which is why Emacs is migrating towards HarfBuzz.
On Thu, 31 Jan 2019 12:46:48 +0100
Egmont Koblinger wrote:
> Hi Richard,
>
> > Basic Arabic shaping, at the level of a typewriter, is
> > straightforward enough to leave to a terminal emulator, as Eli has
> > suggested.
>
> What is "basic" Arabic shaping exactly?
Just using initial, medial
On Thu, 31 Jan 2019 08:28:41 +
Martin J. Dürst via Unicode wrote:
> > Basic Arabic shaping, at the level of a typewriter, is
> > straightforward enough to leave to a terminal emulator, as Eli has
> > suggested. Lam-alif would be trickier - one cell or two?
>
> S
On 1/31/2019 12:55 AM, Tex via Unicode
wrote:
As with the many problems with walls not being effective, you choose to ignore the legitimate issues pointed out on the list with the lack of italic standardization for Chinese braille, text to voice readers, etc
Kent Karlsson wrote:
> ITU T.416/ISO/IEC 8613-6 defines general RGB & CMY(K) colour control
> sequences, which are deferred in ECMA-48/ISO 6429. (The RGB one
> is implemented in Cygwin (sorry for mentioning a product name).)
Fair enough. This thread is mostly about italics and bold and such,
Egmont Koblinger wrote:
> "Basic Arabic shaping, at the level of a typewriter, is
> straightforward enough to be implemented in the application, using
> presentation form characters, as I suggest". Could you please point
> out the problems with this statement?
As multiple people have pointed
On 1/31/2019 1:41 AM, Egmont Koblinger via Unicode wrote:
I mean, for
example we can introduce control characters that specify the language.
That is a complete non-starter for the Unicode Standard. And if the
terminal implementation introduces such as one-off hacks, they will fail
> Date: Thu, 31 Jan 2019 10:58:54 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> Yes, I do argue that emacs will need to print a new escape sequence.
> Which is much-much-much-much-much better than having to tell users to
> go into the settings of
On Thu, Jan 31, 2019 at 02:21:40PM +, James Kass via Unicode wrote:
> David Starner wrote,
> > The choice of using single-byte character sets isn't always voluntary.
> > That's why we should use ISO-2022, not Unicode. Or we can expect
> > people to fix their systems
> From: Egmont Koblinger
> Date: Thu, 31 Jan 2019 10:41:02 +0100
> Cc: Frédéric Grosshans ,
> unicode@unicode.org
>
> > Personally, I think we should simply assume that complex script
> > shaping is left to the terminal, and if the terminal cannot do that,
> > then that's a restriction of
> From: Egmont Koblinger
> Date: Thu, 31 Jan 2019 10:28:27 +0100
> Cc: Adam Borowski , unicode@unicode.org
>
> On Wed, Jan 30, 2019 at 5:10 PM Eli Zaretskii wrote:
>
> > I think the application could use TAB characters to get to the next
> > cell, then simplistic reordering would also work.
>
> From: Egmont Koblinger
> Date: Thu, 31 Jan 2019 10:21:52 +0100
> Cc: Adam Borowski , unicode@unicode.org
>
> > Does anyone know of a terminal emulator which supports isolates?
>
> GNOME Terminal's (VTE's) current work-in-progress implementation does
> remember BiDi control characters just
> From: Egmont Koblinger
> Date: Thu, 31 Jan 2019 10:11:22 +0100
> Cc: unicode@unicode.org
>
> > It doesn't do _any_ shaping. Complex script shaping is left to the
> > terminal, because it's impossible to do shaping in any reasonable way
> > [...]
>
> Partially, you are right. On the other
Is the way to try to resolve this for a proposal document to be produced
for using Variation Selector 14 in order to produce italics and for the
proposal document to be submitted to the Unicode Technical Committee?
If the proposal is allowed to go to the committee rather than being
ruled out
Le 31/01/2019 à 10:41, Egmont Koblinger a écrit :
Hi,
Personally, I think we should simply assume that complex script
shaping is left to the terminal, and if the terminal cannot do that,
then that's a restriction of working on a text terminal.
I cannot read any of the Arabic, Syriac etc.
David Starner wrote,
> The choice of using single-byte character sets isn't always voluntary.
> That's why we should use ISO-2022, not Unicode. Or we can expect
> people to fix their systems. What systems are we talking about, that
> support Unicode but compel you to use plain text? The use of
Hi Richard,
> Basic Arabic shaping, at the level of a typewriter, is straightforward
> enough to leave to a terminal emulator, as Eli has suggested.
What is "basic" Arabic shaping exactly?
I can see problems with leaving it to a terminal. It's not aware of
the neighboring character if the
On Thu, Jan 31, 2019 at 10:05 AM Richard Wordingham via Unicode
wrote:
> > How will "ls -l" possibly work? This is an example of the "table"
> > layout you were already discussing.
>
> I think the answer is that it will use the same trickery as with a
>
Hi,
> > And if you argue "so make emacs print your
> > new code to disable formatting", so do thousands of other programs that are
> > less sophisticated than emacs.
>
> Yes, I do argue that emacs will need to print a new escape sequence.
> Which is much-much-much-much-much better than having to
David Starner wrote,
> Emoji, as have been pointed out several times, were in the original
> Unicode standard and date back to the 1980s; the first DOS character
> page has similes at 0x01 and 0x02.
That's disingenuous.
Hi,
> Arabic terminals and terminal emulators existed at the time of Unicode 1.0.
I haven't found any mention of them, let alone any documentation about them.
> If you are trying to emulate those services, for example so that older
> software can run, you would need to look at how these
On Thu, Jan 31, 2019 at 12:56 AM Tex wrote:
>
> David,
>
> "italics has never been considered part of plain text and has always been
> considered outside of plain text. "
>
> Time to change the definition if that is what is holding you back.
That's not a definition; that's a fact. Again, it's
Hi,
On Wed, Jan 30, 2019 at 5:31 PM Adam Borowski wrote:
> The program (emacs in this case) can do arbitrary reordering of characters
> on the grid, it also has lots of information the terminal doesn't. For
> example, what are you going to do when there's a line longer than what fits
> on the
Hi,
> Personally, I think we should simply assume that complex script
> shaping is left to the terminal, and if the terminal cannot do that,
> then that's a restriction of working on a text terminal.
I cannot read any of the Arabic, Syriac etc. scripts, but I did lots
of experimenting with
Hi Eli,
On Wed, Jan 30, 2019 at 5:10 PM Eli Zaretskii wrote:
> I think the application could use TAB characters to get to the next
> cell, then simplistic reordering would also work.
TAB handling is extremely complicated, because in terminal emulation
TAB is not a character, TAB is a control
Hi Eli,
> Does anyone know of a terminal emulator which supports isolates?
GNOME Terminal's (VTE's) current work-in-progress implementation does
remember BiDi control characters just like it remembers combining
accents, that is, tied to the preceding letter's cell. It uses FriBidi
1.0 for the
Hi Eli,
> It doesn't do _any_ shaping. Complex script shaping is left to the
> terminal, because it's impossible to do shaping in any reasonable way
> [...]
Partially, you are right. On the other hand, as far as I know, shaping
should take into account the neighboring glyphs even if those are
On Wed, 30 Jan 2019 20:35:36 -0500
"Mark E. Shoulson via Unicode" wrote:
> On 1/30/19 8:58 AM, Egmont Koblinger via Unicode wrote:
> > There's another side to the entire BiDi story, though. Simple
> > utilities like "echo", "cat", "ls", &quo
rnatives,
like math italic characters, are problematic.
tex
-Original Message-
From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of David Starner
via Unicode
Sent: Wednesday, January 30, 2019 11:59 PM
To: Unicode Mailing List
Subject: Re: Encoding italic
On Wed, Jan
On 2019/01/31 07:02, Richard Wordingham via Unicode wrote:
> On Wed, 30 Jan 2019 15:33:38 +0100
> Frédéric Grosshans via Unicode wrote:
>
>> Le 30/01/2019 à 14:36, Egmont Koblinger via Unicode a écrit :
>>> - It doesn't do Arabic shaping. In my recommendation I'm argui
On Thursday, 31 January 2019, James Kass via Unicode
wrote:.
>
>
> As for use of other variant letter forms enabled by the math
> alphanumerics, the situation exists. It’s an interesting phenomenon which
> is sometimes worthy of comment and relates to this thread because the math
On Wed, Jan 30, 2019 at 11:37 PM James Kass via Unicode
wrote:
> As Tex Texin observed, differences of opinion as to where we draw the
> line between text and mark-up are somewhat ideological. If a compelling
> case for handling italics at the plain-text level can be made, then t
and voila.
(You don’t need a car. When I went to school we walked 6 miles to get there.
Uphill both ways. J )
tex
From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Asmus Freytag
via Unicode
Sent: Wednesday, January 30, 2019 10:20 PM
To: unicode@unicode.org
Subject: Re: Encoding
David Starner wrote,
>> ... italics, bold, strikethrough, and underline in plain-text
>
> Okay? Ed can do that too, along with nano and notepad. It's called
> HTML (TeX, Troff). If by plain-text, you mean self-interpeting,
> without external standards, then it's simply impossible.
HTML source
On 1/30/2019 7:46 PM, David Starner via
Unicode wrote:
On Sun, Jan 27, 2019 at 12:04 PM James Kass via Unicode
wrote:
A new beta of BabelPad has been released which enables input, storing,
and display of italics, bold, strikethrough, and underline
On Sun, Jan 27, 2019 at 12:04 PM James Kass via Unicode
wrote:
> A new beta of BabelPad has been released which enables input, storing,
> and display of italics, bold, strikethrough, and underline in plain-text
Okay? Ed can do that too, along with nano and notepad. It's called
HTML (TeX,
On 1/30/2019 4:38 PM, Kent Karlsson via
Unicode wrote:
I did say "multiple" and "for instance". But since you ask:
ITU T.416/ISO/IEC 8613-6 defines general RGB & CMY(K) colour control
sequences, which are deferred in ECMA-48/ISO 6429. (Th
On 1/30/19 8:58 AM, Egmont Koblinger via Unicode wrote:
There's another side to the entire BiDi story, though. Simple
utilities like "echo", "cat", "ls", "grep" and so on, line editing
experience of your shell, these kinds. It's absolutely not feasibl
plain text" italic/bold/etc
"controls" be default ignorable: one could just take the control sequences
as specified, but map the printable characters part to the corresponding
tag characters... Not that I think that that is really necessary.
Den 2019-01-30 22:24, skrev "Doug Ewell
not expect an emulator
to accept data in NFD for example.
A./
On 1/30/2019 2:02 PM, Richard
Wordingham via Unicode wrote:
On Wed, 30 Jan 2019 15:33:38 +0100
Frédéric Grosshans via Unicode wrote:
Le 30/01/2019 à 14
On Wed, 30 Jan 2019 15:33:38 +0100
Frédéric Grosshans via Unicode wrote:
> Le 30/01/2019 à 14:36, Egmont Koblinger via Unicode a écrit :
> > - It doesn't do Arabic shaping. In my recommendation I'm arguing
> > that in this mode, where shuffling the characters is the task of
>
Kent Karlsson wrote:
> Yes, great. But as I've said, we've ALREADY got a
> default-ignorable-in-display (if implemented right)
> way of doing such things.
>
> And not only do we already have one, but it is also
> standardised in multiple standards from different
> standards institutions. See for
Martin J. Dürst wrote:
> Here's a little dirty secret about these tag characters: They were
> placed in one of the astral planes explicitly to make sure they'd use
> 4 bytes per tag character, and thus quite a few bytes for any actual
> complete tags.
Aha. That explains why SCSU had to be
On Wed, Jan 30, 2019 at 05:56:00PM +0200, Eli Zaretskii via Unicode wrote:
> > - It doesn't do Arabic shaping.
>
> It doesn't do _any_ shaping. Complex script shaping is left to the
> terminal, because it's impossible to do shaping in any reasonable way
> without controlling th
> Date: Wed, 30 Jan 2019 15:49:34 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> I outline in the document problems that arise from the terminal
> emulator performing shaping on its contents in "explicit" mode, which
> is to be used by
> Date: Wed, 30 Jan 2019 15:25:32 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> > ╒═══╤══╕
> > │ filename1 │ 123 │
> > │ FILENAME2 │ 17 │
> > └───┴──┘
> >
> > I'm afraid there's no goo
> Date: Wed, 30 Jan 2019 15:07:22 +0100
> Cc: unicode@unicode.org
> From: Egmont Koblinger via Unicode
>
> Another possible approach is to leave the terminal doing BiDi, but
> embed all the text fragments in FSI...PDI blocks.
Does anyone know of a terminal emulator which supports isolates?
> From: Egmont Koblinger
> Date: Wed, 30 Jan 2019 14:36:42 +0100
> Cc: unicode@unicode.org
>
> - GNU Emacs reshuffles the characters according to the BiDi algorithm,
> expecting that the terminal emulator doesn't do any BiDi.
Yes, users are told to disable bidi reordering of the terminal, if
> A formatted table is pretty unsuitable for automated processing, and
> obviously meant for human display.
Could you please clarify how exactly that data looks like? Maybe a
tiny hexdump of an example?
Is the RTL piece of text already stored in visual order, that is,
beginning with the leftmost
On Wed, Jan 30, 2019 at 03:43:10PM +0100, Egmont Koblinger via Unicode wrote:
> On Wed, Jan 30, 2019 at 3:32 PM Adam Borowski wrote:
>
> > > > ╒═══╤══╕
> > > > │ filename1 │ 123 │
> > > > │ FILENAME2 │ 17 │
> > > > └
Hi Frédéric,
> I guess Arabic shaping is doable through presentation form characters,
> because the latter are character inherited from legacy standards using
> them in such solutions. But if you want to support other “arabic like”
> scripts (like Syriac, N’ko), or even some LTR complex scripts,
On Wed, Jan 30, 2019 at 3:32 PM Adam Borowski wrote:
> > > ╒═══╤══╕
> > > │ filename1 │ 123 │
> > > │ FILENAME2 │ 17 │
> > > └───┴──┘
> That's possible only if the program in question is running directly attached
> to the tty. That's not an option if the output is
Le 30/01/2019 à 14:36, Egmont Koblinger via Unicode a écrit :
- It doesn't do Arabic shaping. In my recommendation I'm arguing that
in this mode, where shuffling the characters is the task of the text
editor and not the terminal, so should it be for Arabic shaping using
presentation form
On Wed, Jan 30, 2019 at 03:25:32PM +0100, Egmont Koblinger via Unicode wrote:
> One more note, to hopefully clarify:
> > ╒═══╤══╕
> > │ filename1 │ 123 │
> > │ FILENAME2 │ 17 │
> > └───┴──┘
> >
> > I'm afraid there's no good way to
Hi Adam,
One more note, to hopefully clarify:
> ╒═══╤══╕
> │ filename1 │ 123 │
> │ FILENAME2 │ 17 │
> └───┴──┘
>
> I'm afraid there's no good way to do BiDi without support from individual
> programs.
In this particular example, when the output consists of RTL text in
Hi Adam,
> Even a line is way too big a piece to be safely reordered by the terminal.
> What you propose will break every full-screen program that uses line-drawing
> characters:
Certain terminal emulators already perform BiDi on their lines. They
already break every full-screen program with
Hi Eli,
> My personal experience with bringing BiDi to Emacs led me to a firm
> conclusion that BiDi support by terminal emulators cannot be relied on
> by sophisticated text editing and display applications that are
> BiDi-aware. The terminal emulator can never be smart enough to do
> what the
Hi Eli,
> > In turn, vim, emacs and friends stand there clueless, not knowing
> > how to do BiDi in terminals.
>
> This is inaccurate: [...]
I have to admit, I was somewhat sloppy in the phrasing of this
announcement. My bad, apologies.
Currently some terminal emulators shuffle the characters
een around for decades and is still
alive and well. I see absolutely no need for a "bold"
new concept here; the one below is not better in any
significant way.
/Kent Karlsson
Den 2019-01-29 23:35, skrev "Andrew West via Unicode" :
> On Mon, 28 Jan 2019 at 01:55, James Kass via
On Mon, 28 Jan 2019 at 01:55, James Kass via Unicode
wrote:
>
> This <b>bold</b> new concept was not mine. When I tested it
> here, I was using the tag encoding recommended by the developer.
Congratulations James, you've successfully interchanged tag-styled
plain t
Doug Ewell wrote,
> I can't speak for Andrew, but I strongly suspect he implemented this as
> a proof of concept, not to declare himself the Maker of Standards.
BabelPad also offers plain-text styling via math-alpha conversion,
although this feature isn’t newly added. Users interested in
On 2019-01-29 5:10 PM, Doug Ewell via Unicode wrote:
I thought we had established that someone had mentioned it on this list,
at some time during the past three weeks. Can someone look up what post
that was? I don't have time to go through scores of messages, and there
is no search facility
On Mon, 28 Jan 2019 20:55:39 -0500
"Mark E. Shoulson via Unicode" wrote:
> On 1/28/19 2:31 AM, Mark Davis ☕️ via Unicode wrote:
> >
> > But the question is how important those are in daily life. I'm not
> > sure why the double-click selection behavior is
On Mon, 28 Jan 2019 21:10:19 -0500
"Mark E. Shoulson via Unicode" wrote:
> On 1/28/19 3:58 PM, Richard Wordingham via Unicode wrote:
> > Interestingly, bringing this word breaker into line with TUS in the
> > UK may well be in breach of the Equality Act 2010.
> >
&
On Tue, 29 Jan 2019 at 10:25, Martin J. Dürst via Unicode
wrote:
>
> The overall tag proposal had the desired effect: The original proposal
> to hijack some unused bytes in UTF-8 was defeated, and the tags itself
> were not actually used and therefore could be depreciated.
And the ta
On Tue, Jan 29, 2019 at 01:50:31PM +0100, Egmont Koblinger via Unicode wrote:
> Terminal emulators are a powerful tool used by many people for various
> tasks. Most terminal emulators' bugtracker has a request to add RTL /
> BiDi support.
[...]
> Some terminal emulators decided to
> Date: Tue, 29 Jan 2019 13:50:31 +0100
> From: Egmont Koblinger via Unicode
>
> [1] https://terminal-wg.pages.freedesktop.org/bidi/
Interesting document, thanks for writing it.
My personal experience with bringing BiDi to Emacs led me to a firm
conclusion that BiDi support
Martin J. Dürst wrote:
> Here's a little dirty secret about these tag characters: They were
> placed in one of the astral planes explicitly to make sure they'd use
> 4 bytes per tag character, and thus quite a few bytes for any actual
> complete tags. See https://tools.ietf.org/html/rfc2482 for
Kent Karlsson wrote:
> We already have a well-established standard for doing this kind of
> things...
I thought we were having this discussion because none of the existing
methods, no matter how well documented, has been accepted on a
widespread basis as "the" standard.
Some people dislike
Philippe Verdy replied to James Kass:
> You're not very explicit about the Tag encoding you use for these
> styles.
Of course, it was Andrew West who implemented the styling mechanism in a
beta release of BabelPad. James was just reporting on it.
> And what is then the interest compared to
> Date: Tue, 29 Jan 2019 13:50:31 +0100
> From: Egmont Koblinger via Unicode
>
> In turn, vim, emacs and friends stand there clueless, not knowing
> how to do BiDi in terminals.
This is inaccurate: Emacs (at least the brand known as "GNU Emacs")
supports bidirectional
Hi,
Terminal emulators are a powerful tool used by many people for various
tasks. Most terminal emulators' bugtracker has a request to add RTL /
BiDi support. Unicode has supported BiDi for about 20 years now.
Still, the intersection of these two fields isn't solved. Even some
Unicode experts
On 2019/01/28 05:03, James Kass via Unicode wrote:
>
> A new beta of BabelPad has been released which enables input, storing,
> and display of italics, bold, strikethrough, and underline in plain-text
> using the tag characters method described earlier in this thread. This
&
On 2019/01/24 23:49, Andrew West via Unicode wrote:
> On Thu, 24 Jan 2019 at 13:59, James Kass via Unicode
> wrote:
> We were told time and time again when emoji were first proposed that
> they were required for encoding for interoperability with Japanese
> telecoms whose usage h
2019-1-25 13:46, Garth Wallace via Unicode wrote:
>
> On Wed, Jan 23, 2019 at 1:27 AM James Kass via Unicode <
> unicode@unicode.org> wrote:
>
>>
>> Nobody has really addressed Andrew West's suggestion about using the tag
>> characters.
>>
>
Gmail can do *Märchen* although I am not too sure about how they transmit
such formatting and not sure about how interoperatable are they.
在 2019年1月22日週二 14:43，Adam Borowski via Unicode 寫道：
> On Mon, Jan 21, 2019 at 12:29:42AM -0800, David Starner via Unicode wrote:
> > On Sun, Jan
On Mon, Jan 28, 2019 at 10:58 PM James Kass via Unicode
wrote:
>
> On 2019-01-29 1:55 AM, Mark E. Shoulson via Unicode wrote:
> > I guess "Suck it up and deal with it." And that may indeed be the
> answer.
>
> It would certainly make for shorter and simpler FAQ
On 2019-01-29 1:55 AM, Mark E. Shoulson via Unicode wrote:
I guess "Suck it up and deal with it." And that may indeed be the answer.
It would certainly make for shorter and simpler FAQ pages, anyway.
On 1/28/19 3:58 PM, Richard Wordingham via Unicode wrote:
Interestingly, bringing this word breaker into line with TUS in the UK
may well be in breach of the Equality Act 2010.
Richard.
OK, I've got to ask: how would that be? How would this impinge on
anyone's equality on the basis of &quo
On 1/28/19 2:31 AM, Mark Davis ☕️ via Unicode wrote:
But the question is how important those are in daily life. I'm not
sure why the double-click selection behavior is so much more of a
problem for Ancient Greek users than it is for the somewhat larger
community of English users. Word
On 1/27/19 4:30 PM, Philippe Verdy via Unicode wrote:
For Volapük, it looks much more like U+02BE (right half ring modifier
letter)
than like U+02BC (apostrophe "modifier" letter).
according to the PDF on
https://archive.org/details/cu31924027111453/page/n12
No, I don't think
On Mon, 28 Jan 2019 08:31:40 +0100
Mark Davis ☕️ via Unicode wrote:
> But the question is how important those are in daily life. I'm not
> sure why the double-click selection behavior is so much more of a
> problem for Ancient Greek users than it is for the somewhat larger
> communit
801 - 900 of 3185 matches
Mail list logo
