Even ConTeXt, which seems to be more consistent in defining the
environments, avoids defining a \startchapter \stopchapter.
Best,
Hooman
LaTeX doesn't really distinguish between commands and environments, so
the code in the subject is in fact valid LaTeX:
\documentclass{article}
\begin{document}
\begin{section}{section heading}
contents of the section
\end{section}
\end{document}
The main difference between this and the "usual" way is that
environments form groups, so assignments would be restored at the end of
the environment. Thus the global values have to be placed on the save
stack, which takes away a certain amount of memory. Furthermore, LaTeX
generally seems to avoid large and deeply nested environments as a
design principle.
--
Change “LookInSig” to “tcalveu” to answer by mail.
+
people write stuff like
\newcommand{\mysection}{\secion{abc}def}
and therefore it is not adequate to search syntactically in the code (if
it is not annotated or avoids issues introduced by the previous command..
This may or may not be solved by integrating the transformation into
some interpreting application as LaTeX compiler
However, why do you bother?
Don't forget that environments are also TeX groups, which can be
important. (I'd point out that this type of thing is bound to come up
as the LaTeX3 project move forward.)
--
Joseph Wright
> On Sep 5, 8:21�pm, Philipp Stephani <LookIn...@arcor.de> wrote:
>> Hooman schrieb:
>>
>> > This might be a silly question, but I was wondering when LaTeX was
>> > originally written, why the sectioning commands are not defined as
>> > usual environments. Thinking in the line of XHTML, it would have been
>> > easier to parse LaTeX markup to other markup languages, had it been
>> > written in a more consistent way. Is there a technical reason on doing
>> > this, or it was just saving on the amount of typing one has to do.
>>
>> LaTeX doesn't really distinguish between commands and environments, so
>> the code in the subject is in fact valid LaTeX:
>>
>> \documentclass{article}
>>
>> \begin{document}
>>
>> \begin{section}{section heading}
>> � �contents of the section
>> \end{section}
>>
>> \end{document}
>>
>> The main difference between this and the "usual" way is that
>> environments form groups, so assignments would be restored at the end of
>> the environment. Thus the global values have to be placed on the save
>> stack, which takes away a certain amount of memory. Furthermore, LaTeX
>> generally seems to avoid large and deeply nested environments as a
>> design principle.
>
> Don't forget that environments are also TeX groups, which can be
> important. (I'd point out that this type of thing is bound to come up
> as the LaTeX3 project move forward.)
Not to mention that they form groups.
--
David Kastrup
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
It gets more important everyday to have the ability to generate more
than one form of output. Generation of HTML is not straightforward
from LaTeX or TeX source and even after generating the HTML, the
output is not nearly as beautiful as PDF output. These questions got
me thinking about the problems that impede TeX from generating
different types of output natively, and with relative ease.
Are there provisions in LaTeX3 regarding generation of XML, HTML, or
other formats?
On Sep 5, 6:05 pm, David Kastrup <d...@gnu.org> wrote:
>
> There isn't anything that bothers per se. The question was just out of
> curiosity. The problem that gets me thinking recently is the ability
> of LaTeX to generate outputs suitable for different mediums. TeX and
> friends are designed to be paper friendly; the output is beautiful
> printed document even if the user does not know much about TeX and its
> internal structure (I am one of them).
>
> It gets more important everyday to have the ability to generate more
> than one form of output. Generation of HTML is not straightforward
> from LaTeX or TeX source and even after generating the HTML, the
> output is not nearly as beautiful as PDF output. These questions got
> me thinking about the problems that impede TeX from generating
> different types of output natively, and with relative ease.
The big problem with HTML is that it is not really designed for the
sorts of documents that LaTeX is meant to produce. The print medium and
the 'screen' medium are really very different. TeX is a typesetting
engine and LaTeX is the typographical design layer added on top of TeX.
Typesetting *implies* a concrete printed result. HTML is meant to be a
far 'looser' markup system, that allows for widely varying output
screens -- it is *designed* to ajdust the output for *any* screen size,
resolution, color space, etc. and to work with a limited set of fonts
(often ones chosen by the *viewer* and NOT the author or typographical
designer. The author / typographical designer is not in a real position
to impose any sort of concrete design for a webpage (HTML). Instead,
what a web designer does (if he/she is doing things properly) is
creating a rather fluid design/markup that will adapt itself to the web
browser's / client system setup (in terms of the screen size,
resolution, color space, font selection, etc. available).
With reguard to using \begin{section}...\end{section}, the question
becomes, what happens to text between section groups? The implication
is that this text is not part of a section, which does not really make
sense. 'sections' are not really a markup entity. section *headings*
are. So what really would make sense would be:
\begin{sectionheading}This is a section heading \end{sectionheading}
(Think of 'sectionheading' as really being like a flavor of the HTML H tags:
<H2>This is a section heading</H2>
And
\section{heading}
really maps to somerthing on the order of:
<H2>heading</H2>
In the LaTeX world, creating an environment for a short chunk of text is
not usually done.
>
> Are there provisions in LaTeX3 regarding generation of XML, HTML, or
> other formats?
>
>
>
>
> On Sep 5, 6:05=A0pm, David Kastrup <d...@gnu.org> wrote:
> > Joseph Wright <joseph.wri...@morningstar2.co.uk> writes:
> > > On Sep 5, 8:21=A0pm, Philipp Stephani <LookIn...@arcor.de> wrote:
> > >> Hooman schrieb:
> >
> > >> > This might be a silly question, but I was wondering when LaTeX was
> > >> > originally written, why the sectioning commands are not defined as
> > >> > usual environments. Thinking in the line of XHTML, it would have bee=
> n
> > >> > easier to parse LaTeX markup to other markup languages, had it been
> > >> > written in a more consistent way. Is there a technical reason on doi=
> ng
> > >> > this, or it was just saving on the amount of typing one has to do.
> >
> > >> LaTeX doesn't really distinguish between commands and environments, so
> > >> the code in the subject is in fact valid LaTeX:
> >
> > >> \documentclass{article}
> >
> > >> \begin{document}
> >
> > >> \begin{section}{section heading}
> > >> =A0 =A0contents of the section
> > >> \end{section}
> >
> > >> \end{document}
> >
> > >> The main difference between this and the "usual" way is that
> > >> environments form groups, so assignments would be restored at the end =
> of
> > >> the environment. Thus the global values have to be placed on the save
> > >> stack, which takes away a certain amount of memory. Furthermore, LaTeX
> > >> generally seems to avoid large and deeply nested environments as a
> > >> design principle.
> >
> > > Don't forget that environments are also TeX groups, which can be
> > > important. (I'd point out that this type of thing is bound to come up
> > > as the LaTeX3 project move forward.)
> >
> > Not to mention that they form groups.
> >
> > --
> > David Kastrup
> > UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
hel...@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
In ConTeXt, the new structure code in MKIV defines \startchapter ...
\stopchapter etc. The main reason is to be able to specify title,
bookmark text, toc text, heading marks etc easily. Not everything
works right now, as some of the backend mechanisms are also being
changed. For example, you can do
\starttext
\startsection[title={Section title},
list={Title in TOC},
bookmark={title in bookmark}, % does not work yet
reference={sec:test},
]
Contents of the section
\stopsection
\stoptext
\startsection ... \stopsection does not introduce a group.
Aditya
> \begin{section}{section heading}
> contents of the section
> \end{section}
I've played around with some code (as yet unreleased) to allow you to
write something like this:
\begin{relsec}{section heading}
...
\begin{relsec}{subsection heading}
...
\end{relsec}
...
\begin{relsec}{subsection heading}
...
\begin{relsec}{subsubsection heading}
...
\end{relsec}
...
\end{relsec}
...
\end{relsec}
My impression before writing the thing was that it would make editing
text much easier, because subsections can be rearranged to sections and
so on without any changes to the markup. In practise it became a little
more tedious to write in the first place, but I didn't spend long
experimenting.
(Other factors, such as nice editor support for the current \section,
\subsection way of doing things, eventually convinced me it wasn't
worth the effort at the time to invent new markup for the document I
was writing.)
Will
these issues come up from time to time, and no-one ever decides to go
forward (scan google groups for previous incarnations of the
discussion -- it may be as far back as the very beginnings of c.t.t,
but it's definitely there somewhere). fwiw, i too wrote a thing like
your relsec and gave it up after trying it in a few contexts.
--
Robin Fairbairns, Cambridge