LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: David Carlisle <[log in to unmask]>
Date: Mon, 3 Feb 2003 09:32:48 GMT
In-Reply-To: <[log in to unmask]> (message from Frank Mittelbach on Mon, 3 Feb 2003 00:30:53 +0100)
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (54 lines)
> well, if we would like to see decent TeX support it might be good to get some
> grip on that but first it would need a clear understanding of the fields, eg
> what is the text/math notation supposed to mean? is this also TeX related?

I think the jadetex back end uses tex text/math
distinction to decide whether to stick \ensuremath around the character.

The (La)TeX parts are as you say, a bit strange in places and have some
undocumented (and possibly unknown) dependencies on external packages
(I couldn't get the cyrillic to work last time I tried). There hasn't
been any work on the latex fields since the inital jadetex work of
Sebastian. All the recent effort has been on keeping the character
descriptions up to date as the unicode 3.1 and 3.2 proposals for
mathematical characters progressed through unicode/ISO and kept
shuffling the set of characters. I mentioned the file not because I
thought that the current TeX mappings are necessarily the best but
because it's a start, and if we update that file its easy to generate
unicode/xml -> tex mappings in various formats.

> i guess with a suitable utf8 support plus a suitable translation from
> fontencoding specific commands (LICR) to math commands, (ie something like
> inpmath) we could come up with a list for unicode that would allow better
> support than what is currently in that file, since that would then work
> consistently throughout text and math selecting the right glyphs inside TeX as
> needed

Agreed, basically when I said to Roozbeh

> Ideally I think that I'd like the latex field to consistently have
> a command that could be used as latex's internal encoding independent
> command, together with some latex packages to define any additional
> commands needed, so you could switch at the latex level between
> displaying the glyph, or faking it with TeX constructs or making a
> missing-glyph marker, depending on the fonts available.

That's just another way of saying the latex field should have LICR
commands. For Latex use only it would be just as easy to define the
mappings directly in the latex package files but having them in that XML
would I think help translators from XML (especially MathML) to TeX to
come up with consistent mappings, as all the MathML entities and
character documentation is derived from there.


This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit: