>
> As an example I think it would be useful to support the greek
> alphabet, in this case I guess mainly for variable names. Also it
> would be useful to output something like =EC in a string so that the
> program can append units or something like that. Also something like =D3
> might be a function name.
>
> In the case of html and mathml they are represented by ampersand
> followed by the name followed by a semicolon.
>
<snip>
> What I'm suggesting is something like this, but using escape
> characters that are transparent to command line and list, then html
> and mathml would translate to this form, other output forms would
> translate to their own format. Output forms which only support ascii
> could just use the name like: 'alpha' which seems a reasonable
> fallback.
>
> I hope the unicode characters display in this message otherwise it
> won't make much sense. It displayed all right when I typed it into
> Google Groups.
My mailer conveted this to "quoted printable", but no problem,
I know how HTML character entities work. Let me explain why
I am not entusiastic about escapes. Namely, if you want
something quick and dirty you can do this now like below:
(3) -> )set output mathml on
(3) -> ("α"::Symbol)::Polynomial(Integer)
(3) α
<math xmlns="http://www.w3.org/1998/Math/MathML"; mathsize="big" display="block">
<mi>α</mi>
</math>
Type: Polynomial(Integer)
(4) -> )set output tex on
(4) -> )set output mathml off
(4) -> ("\alpha"::Symbol)::Polynomial(Integer)
(4) \alpha
$$
\alpha
\leqno(4)
$$
Type: Polynomial(Integer)
In other words you can use strings denoting HTML entities or TeX
characters as variable names and they will get to external format,
so they will render as apropriate symbol. Arguably this works
only because our output formaters are lousy -- careful formatter
would escape all special characters so that in MathML output
form 'α' we would get '&alpha;' which would render the
same as textual version (so not a Greek letter). However, this
illustrates problems with escaping: reliably getting correct
results is painful. Escapes are unavoidable for input form
limited media and may be also neccessary in output, but
using escaping during processing should be best avoided,
and if really needed escaping should be encapsulated so that
it is transparent. Also, this example illustrates that sometimes
beeing lousy (literally trasmitting special sequences) is
useful.
Few more remarks:
1) It seems that you really ask for "complete" support for Unicode
(or at least mathematical subset of Unicode). Namely, for
something better than hack above we really need a worked out
design. For processing Unicode is done and really I see
no reason to design something different. Of course there
remain issue of input and output (where escapes may be
neccessary), but is is not clear how much is really needed.
For use in source code relatively crude techniques (like
having a function which conerts Unicode code point (integer)
to correspinding character) should be enough. For interactive
use your suggestion goes into direction of turning FriCAS
into a word processor. Since there exist several fine
text editors and two of them (emacs and now Texmacs) have
interfaces to FriCAS and AFAIK allow rich variety of Unicode
input/output the logical thing to do is to use editor to get
charaters from/to user and just transmit UTF-8 to/from FriCAS.
2) The reason I started to look at output routines (beyond
Texmacs format which was direct cause) is that we accumulated
a lot ad hoc stuff and confusion in output routines so that
getting something done is getting hard. So I would like
to decrease ad-hockery (and not increase it). Of course
some ad-hoc solutions are useful, but they are really like
taking high-interest loan -- they cost a lot of effort
in future. And like loan they make sense if there is
emergency or prospect for big payoff.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
