David, Asmus,
· “without external standards, then it's simply impossible.”
· “And without external standard, not interoperable.“
As you both know there are de jure as well as de facto standards. So for years
people typed : - ) as a smiley without a de facto standard and at some
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, Troff).
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. (The RGB one
is implemented
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 feasible to
add BiDi support to these utilities.
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. (The RGB one
is implemented in Cygwin (sorry for mentioning a product name).)
(The "named" ones, though very popular
Arabic terminals and terminal emulators
existed at the time of Unicode 1.0. If you are trying to emulate
those services, for example so that older software can run, you
would need to look at how these programs expected to be fed their
data.
I see
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
> > the text editor
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 the fonts being used
> 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 Emacs and others. The terminal
> 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 good way to do BiDi without support from individual
> >
> 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 │
> > > > └───┴──┘
>
> > That's possible only if the program in
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 do BiDi without support from individual
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
26 matches
Mail list logo
