LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Chris Rowley <[log in to unmask]>
Sat, 12 Dec 1998 18:05:25 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain (93 lines)
Roozbeh Pournader wrote:
> What about considering every core LaTeX feature and rethink about
> moving them to tools or taking them from there? E.g., many agree
> that picture should go there (since it's used less and less), and
> array should come from there.

Moving things to/from the kernel needs work by people who understand all
the possible consequences.  Thus, whilst these are probably good ideas,
they probably will not get implemented very quickly.

Has anyone tried the autoload version of the kernel?

Sebastian Rahtz wrote:
> i'm slightly bemused to hear that mathematicians now require special
> _hypertext_ as well as everything else. but I'd point out that a
> link embedded in a PDF document should be able to be expressed in
> XPointer syntax perfectly well, which helps a little. I'd agree that
> internally the PDF model is simplistic - but then who *has*
> implemented anything better in mainstream software?

As a model of what is it simplistic?  Some of it is the opposite of
simplistic, being over-speciliased and baroque.

And what are the `internals of a model' in this context?

But perhaps he just mean its model of links and other hyper-stuff?

... and:
> it's more important to implement the infrastructure to make LaTeX
> documents convertible into potential browser formats or other
> formats that exists or may come along in the future by providing a
> consistent and well-defined interface.

And even more important to implement the infrastructure to make
something like pdfLaTeX (eg context;-) able to easily, portably and
transparently convert logical browser formats into well-formatted and
well-typeset documents (for both screen and paper) described in some
sufficientlly rich, device-independent language.

... and also:
> by which we see why LaTeX is unpopular in production workflows. that
> translates to "10% failure"

10% failure would be heaven in our production typesetting environment
(and we do not see any efficiency gain from sending the stuff
across the world to be keyboarded ... but this probably

But we still have enough people around who recall the problems we used
to have with 30% failure in a galley/paste-up hard-copy external
typeseting system: even 40% failure with electronic typesetting/editing
is, for them, absolute zen already!

An important and big difference between 10% failure from a flexible,
programmable system and an (expensive, probably) black box is that
with the former one can often fix the failure for ever more.

and moreover!:
> my (admittedly naive) view is that presentation MathML is like plain
> TeX maths, ie it provides building blocks for putting practically any
> math on the page.

It would be even better if in some respects it was even nearer to TeX;
but it has some features (eg the dreadfully-named <ROW>) that are
needed for presentation maths mark-up but are missing from TeX.

> real users put a layer on top (macros), to let them
> write commands which have semantic meaning for them.

Could we please see some examples of MathML, or is it XML, macros that
might appear in a document?

> if you accept this, then the XML/MathML world is no different. make up
> a new language, using XML syntax, to say whatever you want
>   <foo n="3">x<bar>y</bar></foo>
> (forget the verbose syntax for now), and then provide the XSL
> transformation script which maps that to presentational MathML.

I have been reliably informed that XSL does not allow specifications
that are expressive enough to do this job (basically since it knows
nothing about maths, in the sense that it has no concept of arithmetic).

I am sure that all these little niggles can be fixed, given sufficent
committee-person-hours, but that still leaves a vital question unanswered:
as Marcel Oliver wrote --
> Would this not create similar portability/conversion/parsing problems
> that we have with TeX now if this were sufficiently powerful?