Re: Civil suit; ftp shutdown; mailing list shutdown

[Martin J. Dürst]

Unicode peolpe:

To follow this subject, I recommend to look through
http://mm.icann.org/pipermail/tz/ or subscribe to that mailing list at 
https://mm.icann.org/mailman/listinfo/tz.
In addition, please see 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03374.html.


Regards,Martin.

On 2011/10/07 14:14, "Martin J. Dürst" wrote:

[By accident, I sent this only to Ken first; he recommended I send it to
both Unicode and Unicore.]

I have sent a mail to a relevant IETF list (apps-disc...@ietf.org); the
IETF was looking into taking this over, with
http://tools.ietf.org/html/draft-lear-iana-timezone-database-04, but
apparently, Unicode got alerted first.

In terms of practical matters, two points seem important to me:

First, to ask the judge for a temporary permission (there's a better
legal term, but IANAL) to keep the database up until the law suit is
settled (because the database is probably down now due to a temporary
order from the judge to that effect) because of its high practical
importance.

Second, what seems to be in dispute is data about old history. While
this is important for some applications, in most applications, present
and new data is much more important, so one way to avoid problems would
be to publish only new data at some new place until the case is settled.
That would mean that applications would have to be checked for whether
they need the old data or not. Or to only publish diffs (which would be
about new, present-day data not from the source under litigation).

Regards, Martin.

On 2011/10/07 4:45, Ken Lunde wrote:

Arle and others,

The URL for the following blog post was tweeted a few minutes ago:

http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html

-- Ken

On Oct 6, 2011, at 9:45 AM, Arle Lommel wrote:


Is there any public information about the lawsuit? I was stunned to
see the forwarded mail and want to understand the implications of
this lawsuit, but I can't find any news about it other than Arthur’s
rather telegraphic note. I understand that he may not be able to
comment given pending litigation, but if we had any information at
all about what the suit is, it might help clarify if there is any
need for concern.

-Arle


It would be nice, but I don't think the Consortium can do that
without first understanding if it gets exposed to its own lawsuit.

Eric.

Re: Civil suit; ftp shutdown; mailing list shutdown

[Bill Poser]

There's a discussion of the lawsuit on
Slashdot:http://yro.slashdot.org/story/11/10/06/1743226/civil-suit-filed-involving-the-time-zone-database

On Thu, Oct 6, 2011 at 10:14 PM, "Martin J. Dürst"
wrote:

> [By accident, I sent this only to Ken first; he recommended I send it to
> both Unicode and Unicore.]
>
> I have sent a mail to a relevant IETF list (apps-disc...@ietf.org); the
> IETF was looking into taking this over, with http://tools.ietf.org/html/**
> draft-lear-iana-timezone-**database-04,
> but apparently, Unicode got alerted first.
>
> In terms of practical matters, two points seem important to me:
>
> First, to ask the judge for a temporary permission (there's a better legal
> term, but IANAL) to keep the database up until the law suit is settled
> (because the database is probably down now due to a temporary order from the
> judge to that effect) because of its high practical importance.
>
> Second, what seems to be in dispute is data about old history. While this
> is important for some applications, in most applications, present and new
> data is much more important, so one way to avoid problems would be to
> publish only new data at some new place until the case is settled. That
> would mean that applications would have to be checked for whether they need
> the old data or not. Or to only publish diffs (which would be about new,
> present-day data not from the source under litigation).
>
> Regards,   Martin.
>
> On 2011/10/07 4:45, Ken Lunde wrote:
>
>> Arle and others,
>>
>> The URL for the following blog post was tweeted a few minutes ago:
>>
>>   http://blog.joda.org/2011/10/**today-time-zone-database-was-**
>> closed.html
>>
>> -- Ken
>>
>> On Oct 6, 2011, at 9:45 AM, Arle Lommel wrote:
>>
>>  Is there any public information about the lawsuit? I was stunned to see
>>> the forwarded mail and want to understand the implications of this lawsuit,
>>> but I can't find any news about it other than Arthur’s rather telegraphic
>>> note. I understand that he may not be able to comment given pending
>>> litigation, but if we had any information at all about what the suit is, it
>>> might help clarify if there is any need for concern.
>>>
>>> -Arle
>>>
>>>  It would be nice, but I don't think the Consortium can do that without
 first understanding if it gets exposed to its own lawsuit.

 Eric.

>>>
>>>
>>>
>>
>>
>>
>>
>

Solidus variations

[Hans Aberg]

There are several solidus (slash) variations. What is the intent of those, in 
as much there been expressed, in a mathematical context?

For example, is U+2044 intended for rational numbers, and U+2215 a long 
variation of U+002F, which can be used to disambiguate a/b/c/d as in a/b∕c/d = 
(a/b)/(c/d)? And is U+FF0F intended for non-math use?

Hans


/ U+002F SOLIDUS
⁄ U+2044 FRACTION SLASH
∕ U+2215 DIVISION SLASH
／ U+FF0F FULLWIDTH SOLIDUS

RE: Solidus variations

[Murray Sargent]

One set of examples of the use of these solidus variations occurs in the 
mathematics linear format described in Unicode Technical Note #28 
(http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf). The ASCII 
solidus (U+002F) described in Section 2.1 is used to represent normal stacked 
fractions. So a/b automatically builds up to a "over" b separated by a 
horizontal fraction bar. The fraction slash (U+2044) is used to input skewed 
fractions as described later in Section 2.1 along with the division slash 
(U+2215), which is used to enter large linear fractions. In this approach, the 
full-width solidus (U+FF0F) is treated as an alias for the ASCII solidus to 
expedite equation entry with East-Asian IMEs. 

U+2215 is a mathematical operator, but the other three appear outside "math 
zones" in ordinary text. U+FF0F is used in contexts where other full-width 
Latin letters are present, e.g., in vertical East-Asian layouts. The fraction 
slash is used to display arbitrary skewed fractions such as ½ when they aren't 
encoded in Unicode. This is a mathematical context, albeit a simple one.

The ASCII solidus is used in various nonmathematical contexts (dates, 
alternatives) and reminds one of the ASCII hyphen-minus (U+002D) which also has 
multiple uses. Unicode has other "slashes" such as the U+27CB RISING DIAGONAL. 
I have a UTC action item to update Unicode Technical Report #25 with some 
discussion about U+27CB, so I'll generalize Section 2.15 "Fraction Slash" of 
that report to compare the usages of the various solidi.

Murray

-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf 
Of Hans Aberg
Sent: Friday, October 07, 2011 7:08 AM
To: Unicode Mailing List
Subject: Solidus variations

There are several solidus (slash) variations. What is the intent of those, in 
as much there been expressed, in a mathematical context?

For example, is U+2044 intended for rational numbers, and U+2215 a long 
variation of U+002F, which can be used to disambiguate a/b/c/d as in a/b∕c/d = 
(a/b)/(c/d)? And is U+FF0F intended for non-math use?

Hans


/ U+002F SOLIDUS
⁄ U+2044 FRACTION SLASH
∕ U+2215 DIVISION SLASH
／ U+FF0F FULLWIDTH SOLIDUS

Re: Solidus variations

[Jukka K. Korpela]

7.10.2011 17:07, Hans Aberg wrote:


There are several solidus (slash) variations.

> What is the intent of those, in as much there been expressed,

in a mathematical context?


Unicode mostly encodes characters that are in use or have been encoded 
in other standards. While not semantically agnostic, it is much less 
oriented towards semantic clarifications and distinctions than many 
people might hope for (and this includes me, some of the time at least).



For example, is U+2044 intended for rational numbers,


Yes, and the idea behind it is that programs may format such a number in 
a manner typographically suitable for fractions, so that the adjacent 
numbers (digit sequences) are affected. This means that e.g. 1⁄2 may 
create a rendering similar to some of the glyphs for the character ½. 
You probably won’t see this happening in your favorite email program, 
text editor, web browser, or even word processor—it’s just the 
underlying idea and a possibility, not a requirement (or commonly 
implemented).


On the practical side, it may happen that even by virtue of the 
different shape of U+2044 (vs. U+002F)—it’s typically in a 45° angle, 
though the implementation could be more complicated, even implementing 
it as horizonal—, fractions may look somewhat better. But there’s the 
risk that U+2044 is not present in the font that will be used (or cannot 
be transmitted when using many legacy non-Unicode encodings).



and U+2215 a long variation of U+002F,


I wouldn’t call it long. Visually, it might be expected to differ from 
U+002F by looking specifically like a division operator (as it _is_ a 
division operator), as opposite to the semantically ambiguous U+002F. If 
it’s longer, I think it’s longer as a consequence of extending from the 
baseline to a specific height in a different slope than U+002F.



which can be used to disambiguate a/b/c/d as in a/b∕c/d = (a/b)/(c/d)?


I don’t quite see what you mean, but if I understand the idea correctly, 
it’s not the kind of thing you’re supposed to do. U+2215 is semantically 
less ambiguous than U+002F, but the latter too can be used as a division 
operator. The choice between U+002F and U+2215 does not affect operator 
precedence.


In fact, the relatively new standard on mathematical notations, ISO 
8-2, which identifies the operators by their Unicode numbers, 
explicitly says that the symbol “/” used for division is SOLIDUS U+002F. 
Maybe they just didn’t think of other possibilities, but in any case 
this indicates that U+2215 cannot be expected to the normal, or even 
normative, symbol for division.



And is U+FF0F intended for non-math use?


As the name FULLWIDTH SOLIDUS says, it’s meant for use instead of 
SOLIDUS in East Asian writing systems. It’s just a wide variant of 
U+002F. So it may have math and non-math use, just as SOLIDUS may.


--
Yucca, http://www.cs.tut.fi/~jkorpela/

Re: Solidus variations

[Hans Aberg]

On 7 Oct 2011, at 18:58, Murray Sargent wrote:

> One set of examples of the use of these solidus variations occurs in the 
> mathematics linear format described in Unicode Technical Note #28 
> (http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf). The ASCII 
> solidus (U+002F) described in Section 2.1 is used to represent normal stacked 
> fractions. So a/b automatically builds up to a "over" b separated by a 
> horizontal fraction bar. The fraction slash (U+2044) is used to input skewed 
> fractions as described later in Section 2.1 along with the division slash 
> (U+2215), which is used to enter large linear fractions. In this approach, 
> the full-width solidus (U+FF0F) is treated as an alias for the ASCII solidus 
> to expedite equation entry with East-Asian IMEs. 

I recall looked at it before. It does not seem telling to treat expressions 
like a/b/c/d and 1/2/3/4. The standard way these days in computer languages (or 
the ones I know), is to parse as division operator, binding to the left. It 
makes it unusable as a fraction symbol or to display ratios, which would parse 
as (1/2)/(3/4).

I was playing around with this in a small parser, which is how the question 
came up. SO I think the ASCII "/" must be used as a division operator.

> U+2215 is a mathematical operator, but the other three appear outside "math 
> zones" in ordinary text. U+FF0F is used in contexts where other full-width 
> Latin letters are present, e.g., in vertical East-Asian layouts. The fraction 
> slash is used to display arbitrary skewed fractions such as ½ when they 
> aren't encoded in Unicode. This is a mathematical context, albeit a simple 
> one.

Then one can use ⁄ U+2044 FRACTION SLASH as a fraction slash. Theres are 
different rendering, like in TeX $1\over 2$, or ${}^1⁄_2$, the latter which 
looks nice in XeTeX using XITS. Then ∕ U+2215 DIVISION SLASH can be used as a 
large division sign, as you also suggest in your paper.

> The ASCII solidus is used in various nonmathematical contexts (dates, 
> alternatives) and reminds one of the ASCII hyphen-minus (U+002D) which also 
> has multiple uses. Unicode has other "slashes" such as the U+27CB RISING 
> DIAGONAL. I have a UTC action item to update Unicode Technical Report #25 
> with some discussion about U+27CB, so I'll generalize Section 2.15 "Fraction 
> Slash" of that report to compare the usages of the various solidi.

The context I have in mind is a computer that largely sticks to the ASCII 
tradition, but otherwise uses new Unicode additions to make input more 
math-like.

Hans

Re: Solidus variations

[Hans Aberg]

On 7 Oct 2011, at 19:39, Jukka K. Korpela wrote:

>> There are several solidus (slash) variations.
> > What is the intent of those, in as much there been expressed,
>> in a mathematical context?
> 
> Unicode mostly encodes characters that are in use or have been encoded in 
> other standards. While not semantically agnostic, it is much less oriented 
> towards semantic clarifications and distinctions than many people might hope 
> for (and this includes me, some of the time at least).

I am aware of that, but by tracing the origin, one can get hints of usage.

>> For example, is U+2044 intended for rational numbers,
> 
> Yes, and the idea behind it is that programs may format such a number in a 
> manner typographically suitable for fractions, so that the adjacent numbers 
> (digit sequences) are affected. This means that e.g. 1⁄2 may create a 
> rendering similar to some of the glyphs for the character ½. You probably 
> won’t see this happening in your favorite email program, text editor, web 
> browser, or even word processor—it’s just the underlying idea and a 
> possibility, not a requirement (or commonly implemented).
> 
> On the practical side, it may happen that even by virtue of the different 
> shape of U+2044 (vs. U+002F)—it’s typically in a 45° angle, though the 
> implementation could be more complicated, even implementing it as horizonal—, 
> fractions may look somewhat better. But there’s the risk that U+2044 is not 
> present in the font that will be used (or cannot be transmitted when using 
> many legacy non-Unicode encodings).

I am playing around with a small parser on top GMP, so input semantics is the 
main issue for me. Then I realized that if I let the lexer parse rational 
numbers, then 1/2/3/4 will parse as (1/2)/(3/4), and not as ((1/2)/3)/4 as 
expected in ASCII computer programs.

But using ⁄ U+2044 FRACTION SLASH as in 1⁄2/3⁄4 = (1/2)/(3/4) becomes 
unambiguous with 1/2/3/4 = ((1/2)/3)/4.

>> and U+2215 a long variation of U+002F,
> 
> I wouldn’t call it long. Visually, it might be expected to differ from U+002F 
> by looking specifically like a division operator (as it _is_ a division 
> operator), as opposite to the semantically ambiguous U+002F. If it’s longer, 
> I think it’s longer as a consequence of extending from the baseline to a 
> specific height in a different slope than U+002F.

If it is not longer, then it unusable as a divisio operator with lower 
precedence that the ASCII "/".

>> which can be used to disambiguate a/b/c/d as in a/b∕c/d = (a/b)/(c/d)?
> 
> I don’t quite see what you mean, but if I understand the idea correctly, it’s 
> not the kind of thing you’re supposed to do. U+2215 is semantically less 
> ambiguous than U+002F, but the latter too can be used as a division operator. 
> The choice between U+002F and U+2215 does not affect operator precedence.
> 
> In fact, the relatively new standard on mathematical notations, ISO 8-2, 
> which identifies the operators by their Unicode numbers, explicitly says that 
> the symbol “/” used for division is SOLIDUS U+002F. Maybe they just didn’t 
> think of other possibilities, but in any case this indicates that U+2215 
> cannot be expected to the normal, or even normative, symbol for division.
> 
>> And is U+FF0F intended for non-math use?
> 
> As the name FULLWIDTH SOLIDUS says, it’s meant for use instead of SOLIDUS in 
> East Asian writing systems. It’s just a wide variant of U+002F. So it may 
> have math and non-math use, just as SOLIDUS may.

One can use the characters how one pleases, but it would not be consistent with 
its past history. Which is what I suspected and wanted to know. Thanks.

Hans

Japanese font on Non-Japanese Android phones

[Gerrit]

Hello,

I know this is probably the wrong mailing list to ask, but I guess that 
I still have the highest chance to reach somebody who has something to 
do with this problem.


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 Japanese. Of 
course, you can read it (except for 直), but it is really not that 
pretty. Well, this is the usual Han unification problem, but on other 
devices (PCs for example), it is not that much of a problem because you 
can usually select the font, or a Japanese font is displayed by default.


Well, in Android you cannot do it, and if you don’t have the luck to 
have a Japanese phone, you will not be able to use the Japanese font 
(DroidSansJapanese.ttf). You can only install it by rooting the phone, 
which few people want to do. But if you do it, actually that font is 
quite nice.


So if somebody from Google reads this, is there maybe some way that the 
DroidSansJapanese.ttf will be included in the standard Android system, 
/and/ that it can be selected easily in the menu? (Something in the 
language screen, where you can select “preferred East Asian script: 
Chinese (China), Japanese, Chinese (Taiwan), Korean” – well, I don’t 
know if there are Korean or Taiwanese fonts available, but if yes, they 
would be nice as well). I guess if the font were be included in Android 
right from the start, the device manufacturers would not bother to 
delete it. Also, it would be necessary that you can select the font also 
if you don’t have Japanese language (which is not available on most 
western phones either way) - e.g. French system language with Japanese 
font.


Additionally, if the standard Android web browser could then use the 
html “lang” tag to select the appropriate font, it would be even nicer. 
So even if you have Chinese as the selected font, if you then surf on a 
Japanese page, the Japanese font will be displayed automatically; and 
the other way round with Chinese (if a Japanese font is selected by 
default). Firefox can do that on PCs (in contrast to Chrome), so it 
would be really nice if Android could do it as well.


I know that this is only a minor problem which 99.99% of the users will 
bother with (Japanese users also don’t bother, so it is only for all 
those western guys who are speaking Japanese instead of Chinese), but 
for the rest of them it is quite some problem, I think. I heard so many 
complaints of people I know who are absolutely not satisfied with the 
Chinese font. Also, this may not be that much of a problem on 
smartphones, but at least on Android tablets I want to have a nice font.


I hope somebody who has something to do with this problem will read this 
:) For all the other ones, sorry that I misused this mailing list.


Thanks!
Gerrit

Re: Solidus variations

[Asmus Freytag]

On 10/7/2011 11:27 AM, Hans Aberg wrote:

The context I have in mind is a computer that largely sticks to the ASCII 
tradition, but otherwise uses new Unicode additions to make input more 
math-like.

Hans,

that's essentially the same goal as behind the design of the 
"Mathematics Linear Format" described in Unicode Technical Note #28 
(http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf).


You could do worse than making this your starting point. Murray has 
spent years, probably decades working out the details of this format and 
there are working implementations that use it.


A./

Re: Solidus variations

[Hans Aberg]

On 7 Oct 2011, at 21:16, Asmus Freytag wrote:

> On 10/7/2011 11:27 AM, Hans Aberg wrote:
>> The context I have in mind is a computer that largely sticks to the ASCII 
>> tradition, but otherwise uses new Unicode additions to make input more 
>> math-like.

> that's essentially the same goal as behind the design of the "Mathematics 
> Linear Format" described in Unicode Technical Note #28 
> (http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf).

Yes, the goal is the same, but there are many ways to do a computer language. I 
am really interested in what kind of type theory to choose, commensurate with 
practice for basic types.

> You could do worse than making this your starting point. Murray has spent 
> years, probably decades working out the details of this format and there are 
> working implementations that use it.

Well, see how you resolve the conundrum of 1/2/3/4, which in computer languages 
typically parses as ((1/2)/3)/4. Changing the meaning of ASCII "/" as division 
would cause a lot of confusion.

Now, add a lexer that parses rational numbers, along with division "/". Then 
1/2/3/4 parses as (1/2)/(3/4), as the lexer finds the tokens "1/2", "/", and 
"3/4". So keeping "/" as division spoils tokenized rational numbers.

One can fix this by using ⁄ U+2044 FRACTION SLASH for rational numbers, like in 
1⁄2/3⁄4. Or by using a long slash as a division with lower precedence, say ∕ 
U+2215 DIVISION SLASH; the meaning of 1/2∕3/4 then becomes clear.

Hans

RE: Solidus variations

[Murray Sargent]

In the linear format of UTN #28, 1/2/3/4 builds up as ((1/2)/3)/4 as in 
computer languages like C. The notation actually started with C semantics and 
then added a larger set of operators, and finally adopted the full Unicode set 
of mathematical operators. You can try it out in Microsoft Office applications. 
Different groupings can be obtained by using parentheses, which may be 
discarded after build up as explained in UTN #28. As Asmus points out, I 
started working on this notation back in the late 1970's and the latest version 
is built into a number of popular products. So it's pretty thoroughly tested.

Murray

Re: Solidus variations

[Asmus Freytag]

Murray's work comes from the desire to represent mathematical equations 
faithfully, based nearly entirely on the semantics of the operators and 
having those operators be represented as Unicode characters.


One solution that he uses is the use of "redundant" parens. Parens can 
be supplied to group operands, so that you get the correct precedence, 
but, where they are not necessary to the human reader, they will be 
dropped in the formatted equation.


As input format, the linear format, therefore looks more like current 
source code, in that one does type parens.


When fractions are built up, you don't need the parens, so they are 
dropped in layout. If you take the same fraction and display it inline 
(with a slash) some or all of the parens would be needed for the human 
reader as well, so those are displayed.


How would you parse 5.5 if input as a fraction? 51/2? You do need some 
form of grouping to recognize that the 5 and the 1 are not part of the 
same numerator.


A./

Re: Solidus variations

[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 find a description of that.

> The notation actually started with C semantics and then added a larger set of 
> operators, and finally adopted the full Unicode set of mathematical operators.

In view of the problems of C semantics, as C++ shows, I am actually reviewing 
it.

> You can try it out in Microsoft Office applications.

I do not have access to that.

> Different groupings can be obtained by using parentheses, which may be 
> discarded after build up as explained in UTN #28. As Asmus points out, I 
> started working on this notation back in the late 1970's and the latest 
> version is built into a number of popular products. So it's pretty thoroughly 
> tested.

I am worrying also about the underlying mathematical semantics, where one can 
have different models. One is having the set if integers ℤ different from the 
set of rational ℚ numbers (as in C/C++), or viewing it as embedded (as in 
Scheme). In math, one shifts between the two according to context. The ideal 
would be to avoid implicit type conversions, but that would not work if one 
would want to be able to be able to enter numbers in common form.

Hans

Re: Solidus variations

[Hans Aberg]

On 7 Oct 2011, at 22:29, Asmus Freytag wrote:

> Murray's work comes from the desire to represent mathematical equations 
> faithfully, based nearly entirely on the semantics of the operators and 
> having those operators be represented as Unicode characters.
> 
> One solution that he uses is the use of "redundant" parens. Parens can be 
> supplied to group operands, so that you get the correct precedence, but, 
> where they are not necessary to the human reader, they will be dropped in the 
> formatted equation.
> 
> As input format, the linear format, therefore looks more like current source 
> code, in that one does type parens.
> 
> When fractions are built up, you don't need the parens, so they are dropped 
> in layout. If you take the same fraction and display it inline (with a slash) 
> some or all of the parens would be needed for the human reader as well, so 
> those are displayed.
> 
> How would you parse 5.5 if input as a fraction? 51/2? You do need some form 
> of grouping to recognize that the 5 and the 1 are not part of the same 
> numerator.

Apart from that I treat as 5.5 as an inexact number, distinct from the exact 
rational numbers, I use right now "5 1/2", requiring there to be exactly one 
space, where the "/" can also be a ⁄ U+2044 FRACTION SLASH.

Expressions like "f x" parse as function application "f(x)", which is popular 
now in functional languages such as Haskell. So in principle, "5 1/2" might 
parse as "5(1/2)", the constant function 5 applied to 1/2.

Hans