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.
The
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?
>
> Same for other characters.
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
> 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.
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
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
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,
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
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.
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
> default setting for the --color argument.
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
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 arguing
>>> that in this mode,
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. As has been
said before, interlinear annotation, emoji and other features of Unicode which
are now
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
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,
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
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 the
> fact that
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", "grep" and so on, line editing
> > experience of your
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
> alphanumerics
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
> 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
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. What systems are we
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
> 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
> 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: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.
>
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
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.
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 their macOS Terminal /
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
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,
32 matches
Mail list logo
