Re: How could a typesetting system be today?

["Charles P. Schaum" <verbo.solo@sbcglobal.net>]

>  > There is your unified system. XML rulez - for better or for
>  > worse. It's really no fun to write XML by hand.
> 
> But, as you said, TeX and Lilypond have a similar syntax. I belive
> they could share some kind of common language.
> 

What you are thinking about is probably a "master document" scheme that
would locally contextualize and process content. You would likely need
some kind of "magic number" system for this to work.

That would probably rule out older hardware because loading and
unloading entire backends (or trying to run them all) is expensive on
processing and memory.

Also you have the potential for fork hell or dependency hell. IIRC there
are MusicTeX, MusixTeX, Lillypond, etc. and some takes this and others
that. There's an Omega package for typesetting pages from the Biblia
Hebraica Stuttgartensia, Makor, and then there are fonts that do most of
that themselves. You have EDMAC and Ledmac, but ConTeXt could probably
handle the lemmatization even more intuitively. (I ought to try that.)
So, which way is right, since coexistence may be a problem. One wants
plain, the other LaTeX. And you can't necessarily intermix the two. I'm
no XML guru, but that's the likely solution.

Since everything has a history, then you have to build a community where
picking and choosing this over that can be a problem; see, for example,
http://blogs.sun.com/jimgris/entry/building_opensolaris_communities

Then we get to GUI or not.

It's probably the case that XML would be the likely candidate. In that
case, Scribus or OOo would be a good place to look. But then you have
all the complex dev issues with OOo. It can take a day to compile on
anything that is more than two or three years old.

In the end, a typesetting metalanguage would require a community to use
it, deep wallets to fund it, or both. And you would have to ask people,
some of whom still miss their old Lisp machines, Multics, and so on, to
make a switch when they know that publishers already have their niche
development tools in place.

And DEK himself wanted to encourage not simply the finding of or
agreement on the right answer to the question (why some hate the
TeXbook) but the heuristics for finding "right" questions and their
answers (why some love the TeXbook).

But whose "right" wins in the design of the metalanguage? Because that
would collide with good old Appendix D, Dirty Tricks, and everyone's
dirty trick complicates interactions of plugins.

It's like the old days when you saved memory on a machine by putting
what looks to be some data in an odd-size piece of memory, when it's
really a set of instructions at an (unusual) odd address instead of an
even. So how do you disambiguate that? You can't just use an assembler;
you have to disassemble the hand-coded 'data' with a debugger to see the
real instructions.

OK, resources are cheaper now, but this means either making dirty tricks
illegal for any historic instruction set like brand X assembler or TeX,
or coming up with a huge parser that can sail the seas of corner cases.

The former threatens backward compatibility, thus meeting resistance in
the TeX/LaTeX community and probably others. OpenDoc does have
government support, so that's an edge. But then there's Microsoft that
herds its users into the pastures of non-standards-compliance.
Additionally, huge parsers are expensive to implement in several ways.

And wasn't SGML supposed to be a generalized markup language? I do like
the idea, but I think that balancing details over against abstractions
(the Suenden that LaTeXers commit at times come to mind) is always going
to be a sort of np-complete issue.

Charles

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________