Re: [admin] Re: [Clump] Re: Rebel With A Cause
Christophe Rhodes <csr21@cam.ac.uk> writes:
* ability to store multiple revisions of articles, and retrieve any of the versions (for bonus points, also a diff); revision tracking;
It occurs to me that CVS will do this so perhaps we could store the articles in CVS but not let authors have direct write privileges.
* ability to retrieve articles in multiple formats (TeX/Docbook source, html, postscript) if the source that the author submits permits easy conversion;
Can cl-typesetting output to any of these formats in addition to PDF? Erik.
On Mon, Nov 03, 2003 at 08:16:11AM -0500, Erik Enge wrote:
Christophe Rhodes <csr21@cam.ac.uk> writes:
* ability to retrieve articles in multiple formats (TeX/Docbook source, html, postscript) if the source that the author submits permits easy conversion;
Can cl-typesetting output to any of these formats in addition to PDF?
That's IMHO the wrong way around - the question should be which of these formats you can use as *input* to cl-typesetting [1]. The concept of typesetting doesn't really make sense for HTML output [2]. Converting the cl-typesetting PDF output to PostScript is trivial, but PDF is probably more useful anyway. -Klaus [1] in a future version - the current one is an (impressive) proof of concept using Lisp as the input language. You'd need to write a conversion layer to accept other input formats. [2] unless you create the document as a huge table with pixel-sized cells that you render into :-)
Klaus Weidner writes:
On Mon, Nov 03, 2003 at 08:16:11AM -0500, Erik Enge wrote:
Christophe Rhodes <csr21@cam.ac.uk> writes:
* ability to retrieve articles in multiple formats (TeX/Docbook source, html, postscript) if the source that the author submits permits easy conversion;
Can cl-typesetting output to any of these formats in addition to PDF?
That's IMHO the wrong way around - the question should be which of these formats you can use as *input* to cl-typesetting [1]. The concept of typesetting doesn't really make sense for HTML output [2].
I think the basic idea for cl-typesetting is to have three layers: input formats ==> typesetting engine ==> ouput formats sexp cl-typsetting cl-pdf tex-like postscript ... HTML ... So if something is written in a cl-typesetting input format, it should be possible to get it in any of the output formats. Obviously it's currently pre-alpha, but certainly what's in the list above is planned.
[2] unless you create the document as a huge table with pixel-sized cells that you render into :-)
I disagree. You can't actually do too much micro-setting, but if you target HTML-with-css, you can at least do typesetting in the large. -- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
On Mon, Nov 03, 2003 at 11:24:49AM -0800, Thomas F. Burdick wrote:
I think the basic idea for cl-typesetting is to have three layers:
input formats ==> typesetting engine ==> ouput formats sexp cl-typsetting cl-pdf tex-like postscript ... HTML ...
So if something is written in a cl-typesetting input format, it should be possible to get it in any of the output formats. Obviously it's currently pre-alpha, but certainly what's in the list above is planned.
I think I see what you mean - it would be useful to have an engine that could for example create an HTML document containing an automatically generated table of contents, index, cross-references and so on, and to use CSS to provide an approximation of the intended print layout. I'm currently doing something similar for documents that I'm maintaining; I'm editing them in Perl's POD format (which is pleasant to edit due to containing only a minimal amout of markup, i.e. making something italic takes 3 characters I<foo>, compared to HTML's 7 characters <i>foo</i> and LaTeX's 9 characters \textit{foo}). Since the pod2html converter doesn't do a good job with section numbering and the table of contents, I'm using pod2latex as an intermediate step and then latex2html to get the output I want. This is duplicated code since both LaTeX and latex2html need to parse the TeX macros to generate the information they need. In a Lisp solution it would be much easier to abstract out the intermediate interface here. The layer to do that doesn't exist in cl-typesetting yet, and I'd see it as a fairly separate thing that should be abstracted out instead of being commingled as it is in LaTeX: input formats ==> logical markup ==> typesetting ==> output formats sexp table of contents pdf: pdf tex-like index pagination docbook section numbers page# xrefs html image/table numbers graphical output POD footnotes html: HTML ... ... split into files internal hyperlinks style sheet text output plain text ... It's a matter of terminology where you draw the border between these stages. I'd love to take a crack at the "logical markup" phase if I can find some time in my schedule (or a clone)... -Klaus
participants (3)
-
Erik Enge -
Klaus Weidner -
Thomas F. Burdick