From: Ondrej Certik (firstname.lastname@example.org)
Date: Sun Jun 29 2008 - 17:59:24 CDT
On Sat, Jun 28, 2008 at 2:19 PM, Kirill Smelkov
> On Fri, Jun 27, 2008 at 09:30:58AM +0200, Ondrej Certik wrote:
>> first thanks Xun, Phillips, Johannes, Kent and Asmus for your
>> feedback. My comments are below.
>> On Thu, Jun 26, 2008 at 9:53 PM, Asmus Freytag <email@example.com> wrote:
>> > On 6/26/2008 11:15 AM, Kent Karlsson wrote:
>> > The plain text ones have their uses for quick and dirty footnote symbols and
>> > for indicating squared units in otherwise non-mathematical texts as well as
>> > similar *simple* usages. Such fallbacks are best limited to single digits of
>> > the 8859-1 subset to avoid the surprises you ran into.
>> > In addition, as you had noted earlier, the full repertoire of super and
>> > subscript characters are the proper choice for phonetic notations (e.g.
>> > digits used as tone marks). Such notations require preservation of specific
>> > semantics across formatting languages. They require much more extensive
>> > Unicode support as well as special fonts, and they wouldn't survive
>> > transcoding anyway, meaning the issues you encountered with your examples
>> > aren't as relevant in that field of application.
>> > A./
>> > PS: in the late 90's a request had been forwarded from people maintaining a
>> > chemical database to add a small number of additional Greek subscripts. The
>> > rationale was that they type of database was not able to handle any markup.
>> > The request never went anywhere, for lack of specific input from the
>> > submitters beyond an initial discussion, and it is unknown how they solved
>> > their problem. The database was intended for regulatory purposes, so one
>> > assumes that some solution was found, but there has been no information.
>> For general mathematical formulas, one needs to use TeX or a similar
>> system (mathml for example, but the current rendering engines for
>> mathml, like in browsers, do not look as good as TeX). Of course we
>> support this in sympy, but what I am asking for is to improve the
>> experience in the terminal, because you cannot use tex or mathml in
>> the terminal (those require a full graphical fronted, like a browser,
>> or a windows application)
>> To give you the idea what I mean, look at these examples:
>> (especially the screenshots of the terminals at the end). See also
>> this thread for the background why we want that:
>> The observation is, that one can take advantage of unicode and print a
>> surprisingly lot of formulas in a plain text (terminal) mode. E.g.:
>> but as I said, some characters are missing. As I understand, unicode
>> still has a lot of free space to add more characters, right? Is there
>> some technical problem with it? If not, let's discuss the
>> philosophical issues: you can do all superscripts, except "q". I
>> understand those could be from historical reasons, but anyway, let's
>> just add "q" somewhere and be done with it. Then let's add all missing
>> latin letters to subscripts, there are already 8 of them, so let's add
>> the rest too. And then the same for greek super and subscripts.
>> Some of you objected (if I understand) that one should not use sub or
>> superscripts, because those are meant only for backward compatibility,
>> one should use a markup. Well, as Kent has remarked, it is useful in
>> many cases. That's why all the numbers were added. Well, the latin
>> (and greek) letters would be *very* useful to math, because you can
>> represent tensors easily with it. If there were not latin/greek
>> sub/superscripts in unicode, I would understand that. But in the
>> present case, where clearly the support is already there, only half
>> finished, it seems to me that the best way to go forward is to finish
>> the support for all latin/greek sub/superscripts.
> I can only second this!
> The support for latin super and subscripts is already half-there, so it
> would be *very* convenient to have it 100% done.
> Markup is good, but a lot of research environment still work in plain
> terminal (e.g. like XTerm), so having unicode building blocks is quite
I should note that some people actually prefer the terminal to
anything else. For example me. :) So it's not some temporary solution
to overcome the time until all applications can show TeX like markup.
> Look, support for e.g. next is already there in unicode:
> v(t) = ⎮ k(τ - t)*s(τ) dτ, где
> Ψ₀(z) = C*ℯ
> So maybe let's do it 100% and consistent?
Exactly, that's what I think too.
>> What do you think? If you are not against and agree with me that it
>> should be done, I'd like to do the work --- I'd appreciate any
>> pointers about what should I do.
>> If you don't agree, I'd like to discuss it. :)
> I could too try to help.
> Thanks beforehand.
Thanks Kirill for the offer of helping here as well. Anyway, there
doesn't seem to be any major objections (if there are, let's discuss
it), so I think we need to follow the rules here:
Especially read the "Interim Solutions". After readingt it, I think
what we should do is that we'll start with adding the characters in
the Private Use Area and make sure that our application SymPy (e.g.
Python) can show them just fine in the terminal. After we have this,
we'll have the exact idea what stuff needs to be fixed/patched and we
can propose adding them officially into some non Private Use Area of
This archive was generated by hypermail 2.1.5 : Sun Jun 29 2008 - 18:03:39 CDT