[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Frontmatter / Text before first headline
From: |
Nicolas Goaziou |
Subject: |
Re: [O] Frontmatter / Text before first headline |
Date: |
Wed, 01 Feb 2012 14:43:04 +0100 |
Hello,
Jambunathan K <address@hidden> writes:
> I have trouble understanding what the real purpose of the "text before
> the first headline" is. It looks to me more like a placeholder for
> capturing the "Frontmatter" [1].
If you're talking about the first section in the parse tree, the e-ascii
back-end makes use of it: even if that part of the document, links may
have to be collected and displayed before the first headline.
Also, "Frontmatter" probably only makes sense for large
documents. I sometimes write documents that doesn't even have an
headline. Should they be considered as one big frontmatter? Where would
be the matter, then?
> I have also trouble understanding what the rightful position for it is:
>
> Should it be like:
> (a) Title, Initial Text, TOC, Chapters
> Or like
> (b) Title, TOC, Initial Text, Chapters
>
> Currently org-latex does a (b).
>
> But if I look at an organization of a typical document, I am inclined to
> think that it should be (a). It is also my contention that Table Of
> Contents is relocatable only as a means to achieve (b).
Honestly, (b) is easier to achieve than (a), since TOC can be stuffed in
preamble (that is before reading the parse tree). Also, as it's
configurable, I don't think we should bother too much here.
> I am wondering if you would be interested in formalizing frontmatter in
> Org documents. Backends will then be obligated to render the front
> matter headings as "centered text".
What about using special blocks?
--8<---------------cut here---------------start------------->8---
#+begin_abstract
This is the document abstract.
#+end_abstract
--8<---------------cut here---------------end--------------->8---
You can even use a drawer and define its export behaviour in
`org-export-format-drawer-function' (current exporter) or an equivalent.
Anyway, if it happens that tools to build complex documents are
missing[1], I agree that we should provide them, as long as they aren't
imposed to the user.
Regards,
[1] But, first, let's make sure that it's impossible, or at least very
difficult, with current ones.
--
Nicolas Goaziou