Some LaTeX users in Aachen thought about a general-use markup
language this spring. I wrote some code and a rough project
description, however, we could need some help.
If you are interested, visit the provisional project page at
http://latex-bronger.sourceforge.net/gummi/
Tschö,
Torsten.
Crosspost & Followup-To: comp.lang.python
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bro...@jabber.org
(See http://ime.webhop.org for ICQ, MSN, etc.)
http://docutils.sourceforge.net/
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Aahz writes:
> In article <87odgyy...@wilson.homeunix.com>,
> Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>> Some LaTeX users in Aachen thought about a general-use markup
>> language this spring. I wrote some code and a rough project
>> description, however, we could need some help.
>
> http://docutils.sourceforge.net/
The provisional project page already points to
http://docutils.sourceforge.net/rst.html which is sufficient I
think.
Tschö,
Torsten.
My point is that docutils already exists; given the combined competition
from LaTeX and docutils and OpenOffice, you should probably explain what
differentiates your project and why people should support your project
instead of (or in addition to) others.
Aahz writes:
> Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>> Aahz writes:
>>
>>> Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>>>
>>>> Some LaTeX users in Aachen thought about a general-use markup
>>>> language this spring. I wrote some code and a rough project
>>>> description, however, we could need some help.
>>>
>>> [...]
>
> My point is that docutils already exists; given the combined
> competition from LaTeX and docutils and OpenOffice, you should
> probably explain what differentiates your project and why people
> should support your project instead of (or in addition to) others.
reStructuredText, AsciiDoc, and some others focus on source code
documentation, or on software documentation. In contrast to that,
our markup should be suitable for PhD theses, papers and the like.
Thus, it has weaker means for code snippets, RFC citation etc, but
rich syntax for bibliographic entries, index entries, math, and
floating figures. Additionally, input methods simplify using
characters like δ, ⇒, or ”.
The differences to LaTeX are explained comprehensively on the
webpage, and actually LaTeX is the real competitor rather than
reStructuredText. OOo isn't a plain text format, and has no strong
semantic markup.
TeX/LateX have been around forever and are well established standards,
as awful as they are. Why do we want ANOTHER markup language? We
need fewer, not more.
I briefly looked over the specification, and it looks like you're
targeting a LaTeX backend. Are you planning on outputting to LaTeX and
using that to generate e.g. PDF versions of documents, or do you plan
to have a real PDF/Postscript backend?
--
Evan Klitzke <ev...@yelp.com>
Paul Rubin writes:
Well, because they are awful. ;-) I don't see that there is a
bunch of already existing projects, in fact, I don't see anyone
challenging LaTeX at all. However, competition is a good thing, and
I think there are enough aspects about LaTeX that can be done better
so that this project is worth being done.
Evan Klitzke writes:
> On 8/23/07, Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>> Some LaTeX users in Aachen thought about a general-use markup
>> language this spring. I wrote some code and a rough project
>> description, however, we could need some help.
>>
>> If you are interested, visit the provisional project page at
>> http://latex-bronger.sourceforge.net/gummi/
>
> I briefly looked over the specification, and it looks like you're
> targeting a LaTeX backend. Are you planning on outputting to LaTeX
> and using that to generate e.g. PDF versions of documents, or do
> you plan to have a real PDF/Postscript backend?
Yes, I plan to use LaTeX as a mere backend slave for getting PDFs.
I will *try* to keep the LaTeX readable but mostly for debugging
purposes. I don't think that a native PDF backend is helpful on the
short run because LaTeX just works well for this (I don't like
LaTeX's usability but I do like TeX's typesetting abilities).
There is another way to get PDFs which I certainly want to give a
try sometime, namely XSL:FO.
However, I don't know how feasible direct PDF output is. I'm
somewhat scared by line breaking algorithms, hyphenation and all
this, though.
Tschö,
Torsten.
What about ODF ? (http://www.odfalliance.org/)
Isn't it a good competitor ?
Olive
> Paul Rubin writes
>
>> TeX/LateX have been around forever and are well established
>> standards, as awful as they are. Why do we want ANOTHER markup
>> language?
>>
> Well, because they are awful. ;-) I don't see that there is a
> bunch of already existing projects, in fact, I don't see anyone
> challenging LaTeX at all. However, competition is a good thing, and
> I think there are enough aspects about LaTeX that can be done better
> so that this project is worth being done.
>
Well there is ConTeXt <URL:http://wiki.contextgarden.net/>. I've never
actually used it, but from reading the docs I deem it a very attractive
alternative to LaTeX.
/W
olive writes:
> [...]
I'd be a nice further backend but I doubt that people want to enter
XML.
Why not if the schema is designed toward data entry.
You could then use XSLT to convert to ODF for publishing.
What you need is good structured text editor which hides as much as
possible the underlying XML (or other) format.
Olive.
Wildemar Wildenburger writes:
> [...]
>
>> Well, because they are awful. ;-) I don't see that there is a
>> bunch of already existing projects, in fact, I don't see anyone
>> challenging LaTeX at all. However, competition is a good thing,
>> and I think there are enough aspects about LaTeX that can be done
>> better so that this project is worth being done.
>
> Well there is ConTeXt <URL:http://wiki.contextgarden.net/>. I've
> never actually used it, but from reading the docs I deem it a very
> attractive alternative to LaTeX.
That's right, I failed to mention ConTeXt, which really is a
competitor to LaTeX. I even took one good idea from context, namely
the availability of syntax elements in different human languages.
However, ConTeXt documents are as much cluttered as LaTeX. ConTeXt
is a huge system with the aim of fine control on the PDF layout.
Therefore, it is even harder to convert it to HTML than it is for
LaTeX. Besides, I never managed to comprehend its documentation.
It has its good aspects, too, but these are the reasons why I don't
think that it would be a good starting point for improving the
situation with plain text document markup languages.
/W
We are talking about two different things: data entry and document
publishing.
for me ODF is good for document publishing only.
I agree that Plain Text Markup is usually better than XML even with a
good XML editor and a simple schema.
But few people are used to Plain Text Markup (excepted in some
scientific area maybe) and it is error prone.
This is why some user-friendly PTM or XML based editors are needed.
Good user-friendly editor will help in spreading standard.
OpenOffice is a good example for ODF but this has never happened to
XML or any other markup language.
Olive
Enh. reST is intended to be a general-purpose system. It's certainly
extensible, and I've added code for index entries myself. There has
been some recent activity on improving bibliographic support, and I
believe some people are working on integrating MathML.
>Additionally, input methods simplify using characters like δ, ⇒, or
>”.
"Everyone" says to just use a Unicode editor. Long-term, I think that's
what's going to happen -- you're starting your project too late for this
to make much sense.
>The differences to LaTeX are explained comprehensively on the
>webpage, and actually LaTeX is the real competitor rather than
>reStructuredText. OOo isn't a plain text format, and has no strong
>semantic markup.
Then you're really caught between a rock and a hard place. LaTeX is
extremely well-entrenched; at the same time reST is gaining features.
You would probably make much better progress on your goals by simply
working on the reST project -- I doubt you can improve on reST as a
markup language, and the more you try to cram in, the more you're going
to look like LaTeX, anyway.
OTOH, this is Open Source, and nobody's going to stop you. ;-) I just
think you're also not going to get much traction.
> Paul Rubin writes:
>
> > TeX/LateX have been around forever and are well established
> > standards, as awful as they are. Why do we want ANOTHER markup
> > language?
>
> Well, because they are awful. ;-) I don't see that there is a
> bunch of already existing projects, in fact, I don't see anyone
> challenging LaTeX at all. However, competition is a good thing, and
> I think there are enough aspects about LaTeX that can be done better
> so that this project is worth being done.
There are alternatives to LaTeX if you are prepared to look for them.
One of these is Lout:
Another option is to use TeX, but with Python as an alternative "macro
language":
David
>>> [snip]
>
> But few people are used to Plain Text Markup (excepted in some
> scientific area maybe) and it is error prone.
>
It looks very much like Gummi's authors and target audience actually are
part of the few people you are talking about: i.e. console-happy folks
that are perfectly fine with how the math system goes in LaTeX, say, but
are annoyed by the clutter besides that. I can't imagine they would
want to go anywhere near an equation editor, for example.
Looks like a worthwhile project to me :-)
David Boddie writes:
> On Fri Aug 24 11:04:33 CEST 2007, Torsten Bronger wrote:
>
>> Paul Rubin writes:
>>
>>> TeX/LateX have been around forever and are well established
>>> standards, as awful as they are. Why do we want ANOTHER markup
>>> language?
>>
>> Well, because they are awful. ;-) I don't see that there is a
>> bunch of already existing projects, in fact, I don't see anyone
>> challenging LaTeX at all. However, competition is a good thing,
>> and I think there are enough aspects about LaTeX that can be done
>> better so that this project is worth being done.
>
> There are alternatives to LaTeX if you are prepared to look for
> them. One of these is Lout:
>
> http://lout.sourceforge.net/
I know Lout but its syntax is not simple enough to me. Besides, it
does not enforce semantic markup.
> Some LaTeX users in Aachen thought about a general-use markup
> language this spring. I wrote some code and a rough project
> description, however, we could need some help.
>
> If you are interested, visit the provisional project page at
> http://latex-bronger.sourceforge.net/gummi/
Sounds a good idea - LaTeX has so many historical hangovers. How many people
on earth can actually write a LaTeX style file?
I'm not sure about writing LaTeX output, however, due to the crude nasty
ways it handles fonts and so on. How are you going to get enough controls
for users over what they always complain about: fonts, page breaking, and
positioning of figures? Maybe it's an okay first step however.
Jeremy
--
Jeremy Sanders
http://www.jeremysanders.net/
Aahz writes:
> Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>> [...]
>>
>> reStructuredText, AsciiDoc, and some others focus on source code
>> documentation, or on software documentation. In contrast to
>> that, our markup should be suitable for PhD theses, papers and
>> the like. Thus, it has weaker means for code snippets, RFC
>> citation etc, but rich syntax for bibliographic entries, index
>> entries, math, and floating figures.
>
> Enh. reST is intended to be a general-purpose system. It's
> certainly extensible, and I've added code for index entries
> myself.
I like reST very much, and it is used for all documentation in the
"Gummi" source files. I could probably use it as a starting point
for the features that I want but the same is true for AsciiDoc or
MediaWiki. I doubt, however, that the resulting syntax is what I
want (see below).
> There has been some recent activity on improving bibliographic
> support, and I believe some people are working on integrating
> MathML.
But I hope only for the backend side?
>> Additionally, input methods simplify using characters like δ,
>> ⇒, or †.
>
> "Everyone" says to just use a Unicode editor. Long-term, I think
> that's what's going to happen -- you're starting your project too
> late for this to make much sense.
Well, your newsreader failed to specify UTF-8, and my newsreader
failed to do a proper auto-detect. So, Unicode has not arrived yet.
;-)
Seriously: Most people can't enter those characters. In LaTeX, you
can use many Unicode characters directy for years, however, only few
documents make use of this. To most people, it's probably simpler
to write \alpha than to find and use the Unicode-insertion tool of
their editor.
> [...]
>
> Then you're really caught between a rock and a hard place. LaTeX
> is extremely well-entrenched;
But only in a small group (compared to Word for example).
The main motivation of our group was to see that many people stay
away from LaTeX because it is too complicated. The basic assertion
of our project is that this complexity is not necessary while still
maintaining important features of LaTeX (plain text file format,
semantic markup). It is a tradeoff, though: You give up a lot of
flexibility. However, I think that this particular type of
flexibility (namely, local layout tweaking) is of minor
importance.
Probably one important thing that didn't get through yet is that we
try to get people to semantic markup who don't come from engineering
or science. These are heavily under-represented in the LaTeX
community. "Gummi" (or however we'll call it) is not supposed to be
another Geek language. On the contrary, our goal is that even a
typical linguistics student loves to write their seminar paper with
"Gummi".
Reading only forums and newsgroups, one may think that this is
impossible but in real life, I've seen more people using LaTeX
exactly once and never again than people who keep using it. If I
look at typical modern LaTeX preambles, I know what went wrong, so I
see a lot of potential.
However, then a very defensively constructed syntax is crucial, and
everything must just work -- without having to use a tool chain or
declaring things before you can use them.
Howdy!
We Americans do the same. ;-)
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
This is funny. I developed a pretty good competence in LaTeX to write my
thesis (which thanks to LaTeX, looked beautiful) and never once used
LaTeX again.
The biggest hurdle to these markup languages is collaborative documents
and that LaTeX and the like are impossible for collaborators to learn.
Yes, impossible, in the 0%-chance-of-ever-happening meaning. So you get
stuck with Word. This is the reality once you are passed writing term
papers.
James
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
Torsten,
I have another question about your markup language. Are there any
plans on adding provisions for layout and positioning? The difficulty
of learning advanced layout has been one of my major frustrations with
LaTeX (I'm referring to LaTeX's weird box system, I'm not sure exactly
what the proper terminology for it is).
--
Evan Klitzke <ev...@yelp.com>
Evan Klitzke writes:
> On 8/23/07, Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>> Some LaTeX users in Aachen thought about a general-use markup
>> language this spring. I wrote some code and a rough project
>> description, however, we could need some help.
>
> I have another question about your markup language. Are there any
> plans on adding provisions for layout and positioning? The
> difficulty of learning advanced layout has been one of my major
> frustrations with LaTeX (I'm referring to LaTeX's weird box
> system, I'm not sure exactly what the proper terminology for it
> is).
I don't know exactly what you mean but the answer is probably no.
For example, I want the author to state the title, keywords, etc of
his document, however, he should not state that he wants the title
printed centred and 4cm from the top of the page.
The latter is defined in the "theme" which will be given as a set of
ordinary LaTeX commands (for the LaTeX backend).
Tschö,
Torsten.
> I don't know exactly what you mean but the answer is probably no.
> For example, I want the author to state the title, keywords, etc of
> his document, however, he should not state that he wants the title
> printed centred and 4cm from the top of the page.
>
> The latter is defined in the "theme" which will be given as a set of
> ordinary LaTeX commands (for the LaTeX backend).
Isn't the problem that making such a theme will be very hard?
One of the annoying things about LaTeX is lack of control over positioning
(e.g. floats, page breaks...). The one thing most LaTeX users moan about is
trying to get their document to fit into an n page limit (e.g. for a
proposal). Maybe the theme could have some options to control spacing,
however, like some sort of CSS.
I think the one thing that would improve LaTeX is orthogonality in its
commands (e.g. why no 8pt option for the document, why the crazy \small,
\LARGE, etc commands?), and fixing the font system to be based around
modern fonts. Finally making bibtex part of the core and making it easy to
use would be great.
Jeremy Sanders writes:
> Torsten Bronger wrote:
>
>> I don't know exactly what you mean but the answer is probably no.
>> For example, I want the author to state the title, keywords, etc
>> of his document, however, he should not state that he wants the
>> title printed centred and 4cm from the top of the page.
>>
>> The latter is defined in the "theme" which will be given as a set
>> of ordinary LaTeX commands (for the LaTeX backend).
>
> Isn't the problem that making such a theme will be very hard?
Well, it will be a lot of work because there are so many elements
but there is no high complexity. There will be a standard LaTeX
backend, and further backends can be built of top of that so that
for some of them, only very little extra code is necessary.
> One of the annoying things about LaTeX is lack of control over
> positioning (e.g. floats, page breaks...). The one thing most
> LaTeX users moan about is trying to get their document to fit into
> an n page limit (e.g. for a proposal).
Well, trying to meet a page limit is a more exotic requirement in my
opinion. Anyway, apart from the theme and some parameters that you
can pass to it, there will be a LaTeX cfg file which, if present in
the document directory, will be inserted directly before
"\begin{document}". This is a quick and simple way for LaTeX
wizards to configure the LaTeX process. In this file, you can set a
smaller lineskip and a tighter font, for example.
> Maybe the theme could have some options to control spacing,
> however, like some sort of CSS.
At least *I* won't include a CSS parser, escpecially not for the
document source file. My aim is to keep the list of parameters for
the backend a one-liner for most documents. Themes may recognize
arbitrary many parameters but the standard themes will know only a
few (paper size, margins, font/fontsize, columns, one/twoside, and a
few more).
Of course, a third-party theme may use CSS for LaTeX, possibly the
very same CSS file which is used for the accompanying HTML backend.
> I think the one thing that would improve LaTeX is orthogonality in
> its commands (e.g. why no 8pt option for the document, why the
> crazy \small, \LARGE, etc commands?),
(There is the extsizes package.) I understand "orthogonality" as
the independence of features, and by and large this is true for
LaTeX. \small is not for *global* font changes after all. You may
miss completeness, well, Gummi will surely offer even less, which I
think is one of its chances. I certainly miss homogeneity in LaTeX
(for example, 10-12pt is in the standard classes, 8-20pt is in
extsizes), and in this respect, Gummi will offer much more.
> and fixing the font system to be based around modern
> fonts. Finally making bibtex part of the core and making it easy
> to use would be great.
This is another opportunity: You can hide the toolchain (well, this
is done by LaTeX editors, too) and implementation uglinesses from
the author. By the way, Gummi will use the new biblatex package for
the bibliography. It's really a relief to abandon the notorious
BibTeX style language for good.
Some people asked me whether it wouldn't be better to improve LaTeX
instead, however, this would make possible only a small fraction of
these goals. BibTeX is a good example: Its syntax is utter crap,
and even with biblatex you have to learn how to use the outdated
7bit (sometimes 8bit) format of bib files. The whole LaTeX system
is immutably optimised for English letters. Aleph will ease this
somewhat sometime. In Gummi, the only thing left of all this is
that "en" is the default document language.
I'd always assumed (I never spent much time) that Germans were
another culture that had the habit of greeting groups on entrance.
Australians, English, and most of North America just don't have
that habit.
Steve.
"Wildemar Wildenburger" <wild...@freakmail.de> wrote in message
news:mailman.240.11879504...@python.org...
There, I did it. Now I got my country invaded. But maybe that's a good
thing ... at least we will get democracy and finally find happiness.
/W
(OK, sorry. I couldn't resist. Don't take it personally. Take it
nationally. ;) )
Unfortunately Americans are also well known for their inability to
detect irony, so your pointed remarks about democracy and happiness will
probably go mostly unnoticed.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------
> TeX/LateX have been around forever and are well established standards,
> as awful as they are. Why do we want ANOTHER markup language? We
> need fewer, not more.
Because time marches on, and the deficiencies of the old way of doing things
become more obvious, not less. For all the wonderful layout capabilities of
TEX, I've never seen a decent font done with METAFONT--not a single one.
They all looked like rubbish compared to what was available with those
early PostScript-based Apple LaserWriters.
By the way, did you know there was life before TEX? Back in that era, the
main open-source markup system in use was ... troff. Still not quite dead
today, it lives on in the definition of Unix/Linux man pages.
> By the way, did you know there was life before TEX? Back in that era, the
> main open-source markup system in use was ... troff. Still not quite dead
> today, it lives on in the definition of Unix/Linux man pages.
I would hardly call troff "open source", at least not "back in that era".
When I first started using roff and nroff, you had to sign all sorts of
non-disclosure paperwork to get a copy of Unix. It wasn't until much later
that things like the BSD and GNU projects started coming out with open
source versions.
Of course, the whole roff family is based on the old runoff program (which
in turn was probably based on something else).
Anybody remember Scribe?
Not directly....
http://groups.google.com/group/comp.os.cpm.amethyst/msg/d12201a697384a6a
> Anybody remember Scribe?
(raising hand)
OT, but I still have a bunch of Scribe source documents from college.
Of course, as I attended CMU where it originated I suppose that's not
unusual. Definitely pre-WYSIWYG, but one of the first to separate
presentation markup from structure (very much in line with later stuff
like SGML from IBM although I don't recall the precise timing relation
of the two), including the use of styles.
I personally liked it a lot (I think the markup syntax is easier on
the eyes than the *ML family). If I remember correctly, for a while
there, it was reasonably common to see Scribe-like markup in
newsgroups (e.g,. "@begin(flame)" and @end("flame") or "@b[emphasis]")
before SGML/XML/HTML became much more common ("<flame> ... </flame>").
-- David