On 2/13/2019 5:19 PM, Mark E. Shoulson
via Unicode wrote:
And
again, all this is before we even consider other issues; I can't
shake the feeling that there security nightmares lurking inside
this idea.
Default ignorables are bad juju.
A./
On 2/12/19 12:05 PM, Kent Karlsson via Unicode wrote:
Den 2019-02-12 03:20, skrev "Mark E. Shoulson via Unicode"
:
On 2/11/19 5:46 PM, Kent Karlsson via Unicode wrote:
Continuing too look deep into the crystal ball, doing some more
hand swirls...
...
...
The scheme quoted (far) below (from
Philippe Verdy replied to my post, including quoting me.
WJGO >> Thinking about this further, for this application copies of the
glyphs could be redesigned so as to be square and could be emoji-style
and the meanings of the characters specifying which colour component is
to be set could be
James Kass wrote:
Nobody disagreed and I think it’s a splendid suggestion. If anyone is
discussing drafting a proposal to accomplish this, please include me
in the “cc”.
I too would like to receive copies of any discussions please.
In relation to the proposal, I opine that the facility
Oh, the crystal ball is pure solid state, no moving or hot parts.
A magic 8-ball on the other hand can easily get jammed...
(Now, enough of that...)
/K
Den 2019-02-12 02:57, skrev "James Kass via Unicode" :
>
> On 2019-02-11 6:42 PM, Kent Karlsson wrote:
>
>> Using a VS to get italics, or
Den 2019-02-12 03:20, skrev "Mark E. Shoulson via Unicode"
:
> On 2/11/19 5:46 PM, Kent Karlsson via Unicode wrote:
>> Continuing too look deep into the crystal ball, doing some more
>> hand swirls...
>>
>> ...
>>
>> ...
>>
>> The scheme quoted (far) below (from wjgo_10009), or anything like
On 2019-01-24 Andrew West wrote,
> The ESC and UTC do an appallingly bad job at regulating emoji, and I
> would like to see the Emoji Subcommittee disbanded, and decisions on
> new emoji taken away from the UTC, and handed over to a consortium or
> committee of vendors who would be given a
Philippe Verdy wrote,
>>> case mappings,
>>
>> Adjust them as needed.
>
> Not so easy: case mappings cannot be fixed. They are stabilized in
Unicode.
> You would need special casing rules under a specific "locale" for maths.
In BabelPad, I can select a string of text and convert it to math
On 2/11/19 5:46 PM, Kent Karlsson via Unicode wrote:
Continuing too look deep into the crystal ball, doing some more
hand swirls...
...
...
The scheme quoted (far) below (from wjgo_10009), or anything like it,
will NEVER be part of Unicode!
Not in Unicode, but I have to say I'm intrigued by
On 2019-02-11 6:42 PM, Kent Karlsson wrote:
> Using a VS to get italics, or anything like that approach, will
> NEVER be a part of Unicode!
Maybe the crystal ball is jammed. This can happen, especially on the
older models which use vacuum tubes.
Wanting a second opinion, I asked the magic
Den 2019-02-11 10:55, skrev "wjgo_10...@btinternet.com via Unicode"
:
> Doug Ewell wrote:
>
>> , just as next to nobody is using the proposed VS14 mechanism
>
> Well, of course not because use of VS14 in a plain text document to
> record a request for an italic glyph version is not at the
Doug Ewell wrote:
…, just as next to nobody is using the proposed VS14 mechanism …
Well, of course not because use of VS14 in a plain text document to
record a request for an italic glyph version is not at the present time
an official part of Unicode. The next scheduled Unicode Technical
Le dim. 10 févr. 2019 à 02:33, wjgo_10...@btinternet.com via Unicode <
unicode@unicode.org> a écrit :
> Previously I wrote:
>
> > A stateful method, though which might be useful for plain text streams
> > in some applications, would be to encode as characters some of the
> > glyphs for indicating
Le dim. 10 févr. 2019 à 16:42, James Kass via Unicode
a écrit :
>
> Philippe Verdy wrote,
>
> >> ...[one font file having both italic and roman]...
> > The only case where it happens in real fonts is for the mapping of
> > Mathematical Symbols which have a distinct encoding for some
> >
Den 2019-02-10 16:31, skrev "James Kass via Unicode" :
>
> Philippe Verdy wrote,
>
>>> ...[one font file having both italic and roman]...
For OpenType fonts, there is a "design axis" called "ital". Value 0 on that
axis would be roman (upright, normally), and value 1 on that axis would be
Egmont Koblinger wrote:
> There are a lot of problems with these escape sequences, and if you go
> for a potentially new standard, you might not want to carry these
> problems.
As others have pointed out, I am suggesting the use of some profile of ISO 6429
within plain text to implement these
Philippe Verdy wrote,
>> ...[one font file having both italic and roman]...
> The only case where it happens in real fonts is for the mapping of
> Mathematical Symbols which have a distinct encoding for some
> variants ...
William Overington made a proof-of-concept font using the VS14
Le dim. 10 févr. 2019 à 05:34, James Kass via Unicode
a écrit :
>
> Martin J. Dürst wrote,
>
> >> Isn't that already the case if one uses variation sequences to choose
> >> between Chinese and Japanese glyphs?
> >
> > Well, not necessarily. There's nothing prohibiting a font that includes
>
On Sat, Feb 9, 2019 at 6:23 AM Richard Wordingham via Unicode <
unicode@unicode.org> wrote:
> On Sat, 9 Feb 2019 04:52:30 -0800
> David Starner via Unicode wrote:
>
> > Note that this is actually the only thing that stands out to me in
> > Unicode not supporting older character sets; in PETSCII
Martin J. Dürst wrote,
>> Isn't that already the case if one uses variation sequences to choose
>> between Chinese and Japanese glyphs?
>
> Well, not necessarily. There's nothing prohibiting a font that includes
> both Chinese and Japanese glyph variants.
Just as there’s nothing prohibiting a
On 2019/02/09 19:58, Richard Wordingham via Unicode wrote:
> On Fri, 8 Feb 2019 18:08:34 -0800
> Asmus Freytag via Unicode wrote:
>> Under the implicit assumptions bandied about here, the VS approach
>> thus reveals itself as a true rich-text solution (font switching)
>> albeit realized with
Egmont Koblinger wrote:
Should this scheme be extended for colors, too? What to do with the
legacy 8/16 as well as the 256-color extensions wrt. the color
palette? Should Unicode go into the business of defining a fixed set
of colors, or allow to alter the palette colors using the OSC 4 and
Previously I wrote:
A stateful method, though which might be useful for plain text streams
in some applications, would be to encode as characters some of the
glyphs for indicating colours and the digit characters to go with them
from page 5 and from page 3 of the following publication.
On Sat, 9 Feb 2019 04:52:30 -0800
David Starner via Unicode wrote:
> Note that this is actually the only thing that stands out to me in
> Unicode not supporting older character sets; in PETSCII (Commodore
> 64), the high-bit character characters were the reverse (in this
> sense) of the low-bit
On Sat, Feb 9, 2019 at 4:58 AM David Starner via Unicode <
unicode@unicode.org> wrote:
>
> On Sat, Feb 9, 2019 at 3:59 AM Kent Karlsson via Unicode <
> unicode@unicode.org> wrote:
>
>>
>> Den 2019-02-08 21:53, skrev "Doug Ewell via Unicode" > >:
>> > • Reverse on: ESC [7m
>> > • Reverse off: ESC
On Sat, Feb 9, 2019 at 3:59 AM Kent Karlsson via Unicode <
unicode@unicode.org> wrote:
>
> Den 2019-02-08 21:53, skrev "Doug Ewell via Unicode" >:
> > • Reverse on: ESC [7m
> > • Reverse off: ESC [27m
>
> "Reverse" = "switch background and foreground colours".
>
> This is an (odd) colour thing.
Den 2019-02-08 21:53, skrev "Doug Ewell via Unicode" :
> I'd like to propose encoding italics and similar display attributes in
> plain text using the following stateful mechanism:
Note that these do NOT nest (no stack...), just state changes for the
relevant PART of the "graphic" (i.e. style)
Den 2019-02-08 22:29, skrev "Egmont Koblinger via Unicode"
:
> (Mind you, I don't find it a good idea to add italic and whatnot
> formatting support to Unicode at all... but let's put aside that now.)
I don't think Doug mean to "add it to the Unicode standard", just to
have a summary of "handy
On Fri, 8 Feb 2019 18:08:34 -0800
Asmus Freytag via Unicode wrote:
> On 2/8/2019 5:42 PM, James Kass via Unicode wrote:
> You are still making the assumption that selecting a different glyph
> for the base character would automatically lead to the selection of a
> different glyph for the
Asmus Freytag wrote,
> You are still making the assumption that selecting a different glyph for
> the base character would automatically lead to the selection of a
different
> glyph for the combining mark that follows. That's an iffy assumption
> because "italics" can be realized by choosing
On 2/8/2019 5:42 PM, James Kass via
Unicode wrote:
William,
Rather than having the user insert the VS14 after every character,
the editor might allow the user to select a span of text for
italicization. Then it would be up to
William,
Rather than having the user insert the VS14 after every character, the
editor might allow the user to select a span of text for italicization.
Then it would be up to the editor/app to insert the VS14s where appropriate.
For Andrew’s example of “fête”, the user would either type
On Fri, 8 Feb 2019 14:26:28 -0800
Asmus Freytag via Unicode wrote:
> On 2/8/2019 2:08 PM, Richard Wordingham via Unicode wrote:
> On Fri, 8 Feb 2019 17:16:09 + (GMT)
> "wjgo_10...@btinternet.com via Unicode" wrote:
>
> Andrew West wrote:
>
> Just reminding you that "The initial character
On 2/8/2019 2:08 PM, Richard Wordingham
via Unicode wrote:
On Fri, 8 Feb 2019 17:16:09 + (GMT)
"wjgo_10...@btinternet.com via Unicode" wrote:
Andrew West wrote:
Just reminding you that "The initial
On Fri, 8 Feb 2019 22:29:57 +0100
Egmont Koblinger via Unicode wrote:
> Some terminal emulators have made up some new SGR modes, e.g. ESC[4:3m
> for curly underline. What to do with them? Where to draw the line what
> to add to Unicode and what not to? Will Unicode possibly be a
> bottleneck of
On Fri, 8 Feb 2019 17:16:09 + (GMT)
"wjgo_10...@btinternet.com via Unicode" wrote:
> Andrew West wrote:
>> Just reminding you that "The initial character in a variation
>> sequence
>> is never a nonspacing combining mark (gc=Mn) or a canonical
>> decomposable character" (The Unicode
Hi guys,
Having been a terminal emulator developer for some years now, I have
to say – perhaps surprisingly – that I don't fancy the idea of reusing
escape sequences of the terminal world.
(Mind you, I don't find it a good idea to add italic and whatnot
formatting support to Unicode at all...
+∞
-- Rebecca Bettencourt
On Fri, Feb 8, 2019 at 12:55 PM Doug Ewell via Unicode
wrote:
> I'd like to propose encoding italics and similar display attributes in
> plain text using the following stateful mechanism:
>
> • Italics on: ESC [3m
> • Italics off: ESC [23m
> • Bold
I'd like to propose encoding italics and similar display attributes in
plain text using the following stateful mechanism:
• Italics on: ESC [3m
• Italics off: ESC [23m
• Bold on: ESC [1m
• Bold off: ESC [22m
• Underline on: ESC [4m
• Underline off: ESC [24m
•
Andrew West wrote:
Just reminding you that "The initial character in a variation sequence
is never a nonspacing combining mark (gc=Mn) or a canonical
decomposable character" (The Unicode Standard 11.0 §23.4). This means
that a variation sequence cannot be defined for any precomposed
letters
On Tue, 5 Feb 2019 16:01:41 +
Andrew West via Unicode wrote:
> You would
> have to first convert any text to be italicized to NFD, then apply
> VS14 to each non-combining character. This alone would make a VS
> solution unacceptable in my opinion.
What is so unacceptable about having to do
On Tue, 5 Feb 2019 at 15:34, wjgo_10...@btinternet.com via Unicode
wrote:
>
> italic version of a glyph in plain text, including a suggestion of to
> which characters it could apply, would test whether such a proposal
> would be accepted to go into the Document Register for the Unicode
>
James Kass wrote:
William’s suggestion of floating a proposal for handling italics with
VS14 might be an example of the old saying about “putting the cart
before the horse”.
Well, a proposal just about using VS14 to indicate a request for an
italic version of a glyph in plain text,
William Overington wrote,
> Well, a proposal just about using VS14 to indicate a request for an
> italic version of a glyph in plain text, including a suggestion of to
> which characters it could apply, would test whether such a proposal
> would be accepted to go into the Document Register for
Philippe Verdy responded to William Overington,
> the proposal would contradict the goals of variation selectors and would
> pollute ther variation sequences registry (possibly even creating
conflicts).
> And if we admit it for italics, than another VSn will be dedicated to
bold,
> and
the proposal would contradict the goals of variation selectors and would
pollute ther variation sequences registry (possibly even creating
conflicts). And if we admit it for italics, than another VSn will be
dedicated to bold, and another for monospace, and finally many would follow
for various
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.
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
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,
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
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
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 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
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 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
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
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, 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
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
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
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 instance "ISO/IEC 8613-6,
On Mon, 28 Jan 2019 at 01:55, James Kass via Unicode
wrote:
>
> This bold 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 text over the internet with no
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 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 tag characters
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
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
> enhancement is
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 had spilled over
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.
>>
>> It seems conformant, unobtrusive, requiring no
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 20, 2019 at
Den 2019-01-28 02:53, skrev "James Kass via Unicode" :
> plain-text and are uncomfortable using the math alphanumerics for this,
> although the math alphanumerics seem well qualified for the purpose.
It "works" basically only for English (note that any diacritics would be
placed suitable for
So you used
"bold
I.e, you converted from ASCII to tag characters the full HTML sequences
"" and "", including the HTML element name. I see little interest
for that approach.
Additionally this means that U+E003C is the tag identifier and its scope
does not end for the rest of the text (the HTML
On 2019-01-27 11:44 PM, Philippe Verdy wrote:
> You're not very explicit about the Tag encoding you use for these styles.
This bold new concept was not mine. When I tested it
here, I was using the tag encoding recommended by the developer.
> Of course it must not be a language tag
Apart from that control sequences for (some) styling is standardised
(since decades by now), and the "tag characters" approach is not:
For the control sequences for styling, there is no pretence of nesting,
just setting/unsetting an aspect of styling. For etc. (in tag
characters) there is at
You're not very explicit about the Tag encoding you use for these styles.
Of course it must not be a language tag so the introducer is not U+E0001,
or a cancel-all tag so it is not prefixed by U+E007F
It cannot also use letter-like, digit-like and hyphen-like tag characters
for its introduction.
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
enhancement is described in the release notes linked on this download page:
On 2019-01-26 12:18 AM, Asmus Freytag (c) responded:
On 1/25/2019 3:49 PM, Andrew Cunningham wrote:
Assuming some mechanism for italics is added to Unicode, when
converting between the new plain text and HTML there is insufficient
information to correctly convert to HTML. many elements may
On 1/25/2019 3:49 PM, Andrew Cunningham wrote:
Assuming some mechanism for italics is added to Unicode, when
converting between the new plain text and HTML there is insufficient
information to correctly convert to HTML. many elements may have
italic stying and there would be no meta
Assuming some mechanism for italics is added to Unicode, when converting
between the new plain text and HTML there is insufficient information to
correctly convert to HTML. many elements may have italic stying and there
would be no meta information in Unicode to indicate the appropriate HTML
On 1/25/2019 1:06 AM, wjgo_10...@btinternet.com wrote:
Asmus Freytag wrote;
Other schemes, like a VS per code point, also suffer from being
different in philosophy from "standard" rich text approaches. Best
would be as standard extension to all the messaging systems (e.g. a
common markdown
Asmus Freytag wrote;
Other schemes, like a VS per code point, also suffer from being
different in philosophy from "standard" rich text approaches. Best
would be as standard extension to all the messaging systems (e.g. a
common markdown language, supported by UI). A./
Yet that claim of
On Thu, Jan 24, 2019 at 11:16 PM Tex via Unicode wrote:
> Twitter was offered as an example, not the only example just one of the most
> ubiquitous. Many messaging apps and other apps would benefit from italics.
> The argument is not based on adding italics to twitter.
And again, color me
ssaging systems (e.g. a common
markdown language, supported by UI).
A./
tex
*From:*Unicode [mailto:unicode-boun...@unicode.org] *On Behalf Of
*Asmus Freytag via Unicode
*Sent:* Thursday, January 24, 2019 10:34 PM
*To:* unicode@unicode.org
*Subject:* Re: Encoding italic
On 1/24/2019 9:44 P
would be to the apps that would benefit, to add italicizing
and editing capabilities.
tex
From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Asmus Freytag
via Unicode
Sent: Thursday, January 24, 2019 10:34 PM
To: unicode@unicode.org
Subject: Re: Encoding italic
On 1/24
On 1/24/2019 9:44 PM, Garth Wallace via
Unicode wrote:
But the root problem isn't the kludge, it's the lack of
functionality in these systems: if Twitter etc. simply
implemented some styling on their own, the whole thing would be
a moot
On Wed, Jan 23, 2019 at 1:27 AM James Kass via Unicode
wrote:
>
> Nobody has really addressed Andrew West's suggestion about using the tag
> characters.
>
> It seems conformant, unobtrusive, requiring no official sanction, and
> could be supported by third-partiers in the absence of corporate
>
Den 2019-01-24 03:21, skrev "Mark E. Shoulson via Unicode"
:
> On 1/22/19 6:26 PM, Kent Karlsson via Unicode wrote:
>> Ok. One thing to note is that escape sequences (including control sequences,
>> for those who care to distinguish those) probably should be "default
>> ignorable" for display.
On Thu, Jan 24, 2019 at 10:42:59PM +, Richard Wordingham via Unicode wrote:
> On Thu, 24 Jan 2019 18:24:07 +0200
> Khaled Hosny via Unicode wrote:
>
> > On Thu, Jan 24, 2019 at 03:54:29PM +, Andrew West via Unicode
> > wrote:
> >> On Thu, 24 Jan 2019 at 15:42, James Kass
> >> wrote:
>
On Thu, 24 Jan 2019 18:24:07 +0200
Khaled Hosny via Unicode wrote:
> On Thu, Jan 24, 2019 at 03:54:29PM +, Andrew West via Unicode
> wrote:
>> On Thu, 24 Jan 2019 at 15:42, James Kass
>> wrote:
>>> Going off topic a little, I saw this tweet from Marijn van Putten
>>> today which shows
> Maybe I should have said emoji are fan-driven.
That works. Here's the previous assertion rephrased:
We should no more expect the conventional Unicode character encoding
model to apply to emoji than we should expect the old-fashioned text
ranges to become fan-driven.
And if we don't
On Thu, Jan 24, 2019 at 03:54:29PM +, Andrew West via Unicode wrote:
> On Thu, 24 Jan 2019 at 15:42, James Kass wrote:
> >
> > Here's a very polite reply from John Hudson from 2000,
> > http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML024/1042.html
> > ...and, over time, many of the
On Thu, 24 Jan 2019 at 15:42, James Kass wrote:
>
> Here's a very polite reply from John Hudson from 2000,
> http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML024/1042.html
> ...and, over time, many of the replies to William Overington's colorful
> suggestions were less than polite. But it
taking place and my document is just one of
several possibilities being considered.
William Overington
Thursday 24 January 2019
-- Original Message --
From: "Andrew West via Unicode"
To: "Mark E. Shoulson"
Cc: "Unicode Discussion"
Sent: Thursday, 2019 Jan 24
1 - 100 of 166 matches
Mail list logo
