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
On Sun, 10 Feb 2019 00:59:46 +0100
Egmont Koblinger via Unicode wrote:
> Is there such a monospace font obeying wcwidth (that is: double wide
> character for when a spacing mark is combined) for Devanagari?
For CV, that would correspond to a Hindi typewriter, so the odds look
good. The
On Sat, 9 Feb 2019 18:42:52 +0100
Egmont Koblinger via Unicode wrote:
> The
> problem that I don't know how to address is: What if harfbuzz tells us
> that the overall width for rendering a particular grapheme cluster is
> significantly different from its designated area (the number of
>
On Sat, 9 Feb 2019 22:29:31 +0100
Adam Borowski via Unicode wrote:
> On Sat, Feb 09, 2019 at 10:01:21PM +0200, Eli Zaretskii via Unicode
> wrote:
> > I don't know. Maybe it keeps a database of character combinations
> > that need shaping, each one with the maximum width on display the
> >
Hi,
On Sun, Feb 10, 2019 at 12:52 AM Richard Wordingham via Unicode
wrote:
> This is an example of where one needs a font designed for terminal
> emulators.
Definitely, this is another approach I forgot to mention in my mail,
rather than VTE switching to harfbuzz and figuring out all the
On Sat, 9 Feb 2019 22:31:37 +0100
Egmont Koblinger via Unicode wrote:
> Let's take the Devanagari improvement of the other day. Until now,
> there were plenty of dotted circles shown, and combining spacing marks
> that should've been placed before the letter were placed after the
> letter,
On Sat, 9 Feb 2019 13:02:55 -0800
"Asmus Freytag \(c\) via Unicode" wrote:
> To force Hindi crosswords mode you need to segment the string into
> syllables,
> each having a variable number of characters, and then assign a single
> display
> position to them. Now some syllables are wider than
On 2/9/2019 1:40 PM, Egmont Koblinger wrote:
On Sat, Feb 9, 2019 at 10:10 PM Asmus Freytag via Unicode
wrote:
I hope though that all the scripts can be supported with more or less
compromises, e.g. like it would appear in a crossword. But maybe not.
See other messages: not.
For the
On Sat, Feb 9, 2019 at 10:10 PM Asmus Freytag via Unicode
wrote:
> > I hope though that all the scripts can be supported with more or less
> > compromises, e.g. like it would appear in a crossword. But maybe not.
>
> See other messages: not.
For the crossword analogy, I can see why it's not
Hi Asmus,
On Sat, Feb 9, 2019 at 10:02 PM Asmus Freytag (c) wrote:
> are you excluding CJK because of the difficulty handling a large
> repertoire with mechanical means?
No, I excluded CJK because they're pretty well solved in terminals,
and nowhere near along the lines of how they work with
On Sat, Feb 09, 2019 at 10:01:21PM +0200, Eli Zaretskii via Unicode wrote:
> > From: Egmont Koblinger
> > Date: Sat, 9 Feb 2019 20:36:50 +0100
> > Cc: Richard Wordingham ,
> > unicode Unicode Discussion
> >
> > On Sat, Feb 9, 2019 at 8:13 PM Eli Zaretskii wrote:
> >
> > > That's the
On 2/9/2019 11:48 AM, Egmont Koblinger wrote:
Hi Asmus,
On quick reading this appears to be a strong argument why such emulators will
never be able to be used for certain scripts. Effectively, the model described
works
well with any scripts where characters are laid out (or can be laid out)
On 2/9/2019 12:07 PM, Egmont Koblinger
via Unicode wrote:
On Sat, Feb 9, 2019 at 9:01 PM Eli Zaretskii wrote:
then what you say is that some scripts
can never be supported by text terminals.
I'm not familiar at all with all the
Egmont,
On 2/9/2019 11:48 AM, Egmont Koblinger via Unicode wrote:
Are there any (non-CJK) scripts for which crossword puzzles don't exist?
There are crossword puzzles for Hindi (in the Devanagari script). Just
do an image search for "Hindi crossword puzzle".
But the conventions for these
Hi Ken,
> There are crossword puzzles for Hindi (in the Devanagari script). Just
> do an image search for "Hindi crossword puzzle".
It's easy to confirm the existence by an image search, it's hard to
confirm the non-existence ;)
> The existence proof of techniques to cut up text into syllables
On Sat, Feb 9, 2019 at 9:01 PM Eli Zaretskii wrote:
> then what you say is that some scripts
> can never be supported by text terminals.
I'm not familiar at all with all the scripts and their requirements,
but yes, basically this is what I'm saying. I'm afraid some scripts
can never be
> From: Egmont Koblinger
> Date: Sat, 9 Feb 2019 20:36:50 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> On Sat, Feb 9, 2019 at 8:13 PM Eli Zaretskii wrote:
>
> > That's the application's problem, not the terminal's. An application
> > that wants its column to line
Hi Asmus,
> On quick reading this appears to be a strong argument why such emulators will
> never be able to be used for certain scripts. Effectively, the model
> described works
> well with any scripts where characters are laid out (or can be laid out) in
> fixed
> width cells that are
On Sat, Feb 9, 2019 at 8:13 PM Eli Zaretskii wrote:
> That's the application's problem, not the terminal's. An application
> that wants its column to line up _and_ wants to support complex text
> scripts will need to move cursor to certain coordinates, not to assume
> that 7 codepoints always
> From: Egmont Koblinger
> Date: Sat, 9 Feb 2019 20:03:21 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> Let's suppose a utility outputs these two lines of text:
> abcdefg|
> complex|
>
> whereas "abcdefg" are these English letters themselves, but "complex"
> is a
On quick reading this appears to be a
strong argument why such emulators will
never be able to be used for certain
scripts. Effectively, the model described works
well with any scripts where characters
are laid out (or can be laid out) in fixed
width cells
On Sat, Feb 9, 2019 at 7:56 PM Eli Zaretskii wrote:
> I'm probably missing something, because I don't see the grave problems
> you hint at. Any width provided back by a shaper can be rounded to
> the nearest integral character cell, so your canvas can still remain
> rectangular.
Let's suppose
> From: Egmont Koblinger
> Date: Sat, 9 Feb 2019 19:25:08 +0100
> Cc: Richard Wordingham ,
> unicode Unicode Discussion
>
> > You need to use what HarfBuzz tells you _instead_ of wcswidth. It is
> > in general wrong to use wcswidth or anything similar when you use a
> > shaping engine
On Sat, Feb 9, 2019 at 7:07 PM Eli Zaretskii wrote:
> You need to use what HarfBuzz tells you _instead_ of wcswidth. It is
> in general wrong to use wcswidth or anything similar when you use a
> shaping engine and support complex script shaping.
This approach is not viable at all.
Terminal
> Date: Sat, 9 Feb 2019 18:42:52 +0100
> Cc: unicode Unicode Discussion
> From: Egmont Koblinger via Unicode
>
> What if harfbuzz tells us that the overall width for rendering a
> particular grapheme cluster is significantly different from its
> designated area (the number of character cells
Hi Richard,
On Sat, Feb 9, 2019 at 3:08 PM Richard Wordingham via Unicode
wrote:
> It would be good to be able to access a maintained statement of the
> VTE rules for allocating characters to a cell, or group of cells, as
> appropriate.
What VTE did, up to a couple of days ago:
It opens the
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, 09 Feb 2019 09:42:09 +0200
Eli Zaretskii via Unicode wrote:
> > Date: Sat, 9 Feb 2019 00:18:14 +
> > From: Richard Wordingham via Unicode
> >
> > > For character composition, you must have a shaping engine to talk
> > > to, and the shaper should tell you the width of each
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
> From: Elias Mårtenson
> Date: Sat, 9 Feb 2019 13:33:49 +0800
> Cc: Egmont Koblinger , unicode
>
> Moreover, emitting the control sequences that set the mode is in
> itself a complication, because if the terminal doesn't support them,
> the result could be corrupted display. You will need
37 matches
Mail list logo
