TUS 6.0 p 288 (p 320 of PDF) shows (around the middle of the page near
the beginning of a line) a candrabindu which appears to be spacing and
is placed to the above *and right* of a vowel sign AA.
IIUC the candrabindu is a non-spacing mark and should always be placed
*above* the base.
Is it
Am 07.10.2011 20:36, schrieb Gerrit:
Currently, if you buy a Non-Japanese Android phone, you only get the
standard Android font, which has Chinese mainland style
Hanzi/Kanji/Hanja. This is nice for all those people who are using
Chinese, but not that nice for those people who are using Japane
> From: Philippe Verdy
> Date: Tue, 11 Oct 2011 17:44:12 +0200
> Cc: Martin J. Dürst ,
> libo@gmail.com, unicode@unicode.org
>
> Then your implementation is completely couterintutive: imagine what
> will happen if you press enter in a RTL context a line that is
> continued below, but a
On Tue, 11 Oct 2011, Peter Constable wrote:
>> It works flawlessly in Firefox (which is the only browser
>> to support it - Internet Explorer, Chrome and Safari don’t
>> support it. I don’t know for Opera).
>
> I've scanned this thread and can't figure out what "it" is.
..
is displayed in t
> From: Philippe Verdy
> Date: Tue, 11 Oct 2011 17:03:51 +0200
> Cc: Kent Karlsson , Eli Zaretskii ,
> libo@gmail.com,
> unicode@unicode.org
>
> So you'll need to first compute the directionality of all characters
> in a paragraph (where paragraph are broken by strong line breaks
> en
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Gerrit
> It works flawlessly in Firefox (which is the only browser to support it
> - Internet Explorer, Chrome and Safari don’t support it. I don’t know for
> Opera).
I've scanned this thread and can't figure out
On Tue, 11 Oct 2011, I wrote:
> It bothers me that different programs display [...] differently.
"Including HTML in messages" as described in
http://www.hypermail-project.org/hypermail.html#6
didn't quite work.
Therefore I attach a tiny HTML file so that you can test
with different browsers.Tit
On Fri, 7 Oct 2011, Murray Sargent wrote:
> The ASCII solidus is used in various nonmathematical contexts
> (dates, alternatives)
It bothers me that different programs display
١٩٩٩/١٢/٣١
differently.
2011/10/11 Eli Zaretskii :
>> Date: Tue, 11 Oct 2011 13:39:36 +0900
>> From: "Martin J. Dürst"
>> CC: libo@gmail.com, unicode@unicode.org
>>
>> > Sorry, I don't follow you. There's no such "line-folding" in the
>> > Emacs implementation of the UBA. A line that doesn't fit the window
>> > wid
2011/10/11 "Martin J. Dürst" :
> Hello Kent,
>
> I was also very much thinking that mirrored glyph should be of the same
> width, but there might be subtle issues when you consider kerning. As a very
> basic example, think about kerning of the pair K), and then think about K(.
Mirroring may also m
> Date: Tue, 11 Oct 2011 12:39:57 +0200
> From: Kent Karlsson
> CC: ,
>
>
> Well, I think there is a silent (but reasonable, I would say) assumption
> that mirroring does not change the width of a glyph... I would think that if
> a font does not fulfill that, then you have a font problem (
> Date: Tue, 11 Oct 2011 18:54:10 +0900
> From: "Martin J. Dürst"
> CC: libo@gmail.com, unicode@unicode.org
>
> There is absolutely no problem to treat the algorithm in UAX#9 as a set
> of requirements, and come up with a totally different implementation
> that produces the same results. I
Hello Kent,
I was also very much thinking that mirrored glyph should be of the same
width, but there might be subtle issues when you consider kerning. As a
very basic example, think about kerning of the pair K), and then think
about K(.
Regards, Martin.
On 2011/10/11 19:39, Kent Karlsson
Den 2011-10-11 09:43, skrev "Eli Zaretskii" :
> Let me give you just one example: if the character should be mirrored,
> you cannot decide whether it fits the display line until _after_ you
> know what its mirrored glyph looks like. But mirroring is only
> resolved at a very late stage of reorde
Hello Eli,
There is absolutely no problem to treat the algorithm in UAX#9 as a set
of requirements, and come up with a totally different implementation
that produces the same results. I think actually UAX#9 says so somewhere.
But what is, strictly speaking, not allowed is to change the
requi
On 11 Oct 2011, at 00:35, Philippe Verdy wrote:
> 2011/10/7 Hans Aberg :
>> On 7 Oct 2011, at 22:22, Murray Sargent wrote:
>>
>>> In the linear format of UTN #28, 1/2/3/4 builds up as ((1/2)/3)/4 as in
>>> computer languages like C.
>>
>> OK. I looked through the paper again, and could not fin
> Date: Tue, 11 Oct 2011 10:53:39 +0900
> From: "Martin J. Dürst"
> CC: li bo , unicode@unicode.org
>
> I might add here that 'break a line' in the Bidi algorithm is done
> before actual reordering (which is done line-by-line), but after
> calculating all the levels.
Please be aware that this
> Date: Tue, 11 Oct 2011 10:29:51 +0900
> From: "Martin J. Dürst"
> CC: li bo , unicode@unicode.org
>
> >> From section 3:
> >
> >Paragraphs are divided by the Paragraph Separator or appropriate
> >Newline Function (for guidelines on the handling of CR, LF, and CRLF,
> >see Section 4.
> From: Philippe Verdy
> Date: Tue, 11 Oct 2011 01:00:19 +0200
> Cc: li bo , unicode@unicode.org
>
> 2011/10/10 Eli Zaretskii :
> >> what's the meaning of 'appropriate Newline Functions' and 'higher-level
> >> protocol paragraph determination'?
> >
> > Newline Function (NLF) is described in Sect
> Date: Tue, 11 Oct 2011 13:39:36 +0900
> From: "Martin J. Dürst"
> CC: libo@gmail.com, unicode@unicode.org
>
> > Sorry, I don't follow you. There's no such "line-folding" in the
> > Emacs implementation of the UBA. A line that doesn't fit the window
> > width is reordered as a whole. Conc
20 matches
Mail list logo
