A successor to TeX/Latex?
plen...@yahoo.com
I shall speak the heresy unto ye. I find TeX code (the programming
part)
almost unreadable, in part because I did not RTFM, but I never did
because as useful as TeX/Latex are, I believe there is something
inherently problematic in the design of TeX.
But I must ask, has anyone here ever thought that same, that
perhaps TeX is not well designed and perhaps there is need
for developing an alternative to TeX wherein the programming
part is more easy to digest?
For instance, one could take a hint from PHP, which has textual
sections and code sections completely separated rather than
intermingled as in TeX.
Back in the old days I wrote a simple alternative to TeX that
I coded directly in PostScript. It worked although of course all
bare words were code, and text was in (parentheses). I did not
keep that software, but now I wish I had. I want something where
I can sink my coding mind into the software part and have a
chance at creating document types that suit my needs.
I wish for a TeX where the code part is very much like C.
I don't want to rely on others who know more about TeX's
seemingly impenetrable innards, because as always when
their code fails or is too limited, I have only perilous options
like RTFM.
Thanks.
Bob Tennent
> I shall speak the heresy unto ye. I find TeX code (the programming
> part)
> almost unreadable, in part because I did not RTFM, but I never did
> because as useful as TeX/Latex are, I believe there is something
> inherently problematic in the design of TeX.
>
> But I must ask, has anyone here ever thought that same, that
> perhaps TeX is not well designed and perhaps there is need
> for developing an alternative to TeX wherein the programming
> part is more easy to digest?
You seem to talking about TeX macros rather TeX the program. Please
clarify (and then you'll get ripped to shreds for your blasphemy :+)
Bob T.
plen...@yahoo.com
> You seem to talking about TeX macros rather TeX the program.
Yes, that is correct.
All right let's start with an idea. Suppose I want to create a page
in which text occupies four areas of the page, each is rectangular.
The text must flow from one to the next, and then each
subsequent page will have the same four boxes. How to code that
using TeX macros? I have definite ideas about margins, of course,
and page width/height. I have concluded that trying this with
Latex would be futile, because their ideas will never be adapted
to this idea.
Nicola Talbot
Its actually fairly easy to do this using the flowfram package.
Regards
Nicola Talbot
Scott Pakin
> But I must ask, has anyone here ever thought that same, that
> perhaps TeX is not well designed and perhaps there is need
> for developing an alternative to TeX wherein the programming
> part is more easy to digest?
Yes, people have thought of producing a more programmable TeX but it's a
big task. You might want to check out LuaTeX (http://www.luatex.org/),
which uses Lua for the programming part. Some other projects in this space
include PerlTeX (http://www.ctan.org/tex-archive/macros/latex/contrib/perltex/)
and PyTeX (http://www.pytex.org/), which attempt to integrate respectively
Perl and Python with (La)TeX. Finally, AMRITA (http://www.amrita-ebook.org/)
provides a platform for multiple languages (including LaTeX and a variety
of scripting languages) to interoperate.
-- Scott
Rolf Niepraschk
...
>
> Yes, people have thought of producing a more programmable TeX but it's a
> big task. You might want to check out LuaTeX (http://www.luatex.org/),
> which uses Lua for the programming part. Some other projects in this space
> include PerlTeX
> (http://www.ctan.org/tex-archive/macros/latex/contrib/perltex/)
> and PyTeX (http://www.pytex.org/), which attempt to integrate respectively
> Perl and Python with (La)TeX. Finally, AMRITA
> (http://www.amrita-ebook.org/)
> provides a platform for multiple languages (including LaTeX and a variety
> of scripting languages) to interoperate.
>
In addition: "ExTeX"
==> http://www.extex.org/
...Rolf
Aaron Hsu
> But I must ask, has anyone here ever thought that same, that
> perhaps TeX is not well designed and perhaps there is need
> for developing an alternative to TeX wherein the programming
> part is more easy to digest?
There is Lout, which attempts to do this.
--
Aaron Hsu <aaro...@sacrificumdeo.net>
"No one could make a greater mistake than he who did nothing because he
could do only a little." - Edmund Burke
Peter
Have you had a look at ANT (Ant is Not Tex) at http://ant.berlios.de/?
Among its features it claims
* a saner macro language (no catcodes)
* a builtin high-level scripting language
--Peter
David Kastrup
I don't think that it plays in the same ballpark as LuaTeX since, as
far as I can see, you can't program functionality in a document or
style file with it: you need to compile and link programmatic
extensions separately and they play at an entirely different level.
It may be quite nicer than extending TeX in Pascal, but basically that
seems to be the level where the programmability enters. Writing style
files with a Java part appears to have more fundamental seams to the
TeX level than the approach taken with LuaTeX (which is still being
refined).
--
David Kastrup
Michele Dondi
wrote:
>big task. You might want to check out LuaTeX (http://www.luatex.org/),
>which uses Lua for the programming part. Some other projects in this space
Just wondering: is the work on LuaTeX strictly linked with Lua itself
or are hooks provided so that at least part of what's been done could
be reusable with other embeddable (in the sense of "explicitly
designed with embeddability as a precise goal") languages, like io
(<http://www.iolanguage.com>).
>include PerlTeX (http://www.ctan.org/tex-archive/macros/latex/contrib/perltex/)
>and PyTeX (http://www.pytex.org/), which attempt to integrate respectively
>Perl and Python with (La)TeX. Finally, AMRITA (http://www.amrita-ebook.org/)
It should be stressed for the benefit of the OP that the kind of
integration with PerlTeX and (I believe) PyTeX is at a much higher
level, being more comparable, albeit with a necessarily poor analogy,
with the C preprocessor, while that of LuaTeX is much tighter...
Michele
--
>It's because the universe was programmed in C++.
No, no, it was programmed in Forth. See Genesis 1:12:
"And the earth brought Forth ..."
- Robert Israel in sci.math, thread "Why numbers?"
plen...@yahoo.com
> > Yes, people have thought of producing a more programmable TeX but it's a
> > big task. You might want to check out LuaTeX (http://www.luatex.org/),
> > which uses Lua for the programming part. Some other projects in this space
> > include PerlTeX
> > (http://www.ctan.org/tex-archive/macros/latex/contrib/perltex/)
> > and PyTeX (http://www.pytex.org/), which attempt to integrate respectively
> > Perl and Python with (La)TeX. Finally, AMRITA
> > (http://www.amrita-ebook.org/)
Wow, thanks.
M. Tylee Atkinson
people have written to do cool stuff is a very good reason to stay with
this (excellent) platform. It's the same reason why Perl is so
well-used (CPAN in it's case, is the central repository of code to do
pretty much anything).
At the markup level, I think that TeX/LaTeX is pretty good by today's
standards (certainly well ahead of its time) but does lack some semantic
consistency (some things are opened and then closed (e.g. lists),
whereas others are not (e.g. sections). Maybe other TeX macro packages,
such as ConTeXt are more consistent/modern in that area.
Another completely different alternative is DocBook. It is very good
for technical documentation and I've used it successfully for that on
many occasions. However, it's no good (currently) at Maths because
you'd have to write in MathML -- which is both different than the status
quo (LaTeX) and more verbose -- and it doesn't have an equivalent of
CTAN for people to share cool XSL routines and so on.
People don't like change (even though we are generally quite good at
adapting to it) so that's one major reason why we've stuck with
TeX/LaTeX. TeX is fantastic and so is LaTeX, so there is little
pressing us to move on to newer standards. Yes, by today's standards it
might seem a little rough around the edges in places, but it really is
very flexible and powerful and until something truly compelling comes
along to challenge it, I'm sure many will stay happily with it.
Speaking from an accessibility perspective, where accessibility is often
seen as an excuse to force people to change, LaTeX has actually
surprised me quite a bit lately. Using TeX4ht, I've been able to make
very accessible versions of my papers. It did take a bit of work
getting used to the system, but now I can produce really great online
and printed versions, and the online ones are great for more than just
vision-impaired and blind readers. (I've even written a system to
convert LaTeX documents to Braille, based on btrans, and it seems to
work quite well in simple cases, too.)
In fact I came to LaTeX simply because everyone else in my office was
using it. I preferred the consistent semantic markup of DocBook XML at
the time, but now I use LaTeX because it produces excellent results and
can even be coaxed to make accessible ones too. I've got used to its
foibles and no longer see them as heinous crimes against consistency,
too :-).
</my_two_pence>
--
M. Tylee Atkinson <M.T.At...@lboro.ac.uk>
j...@amrita-ebook.org
> On Tue, 07 Aug 2007 16:09:26 -0600, Scott Pakin <scott+...@pakin.org>
>
> Just wondering: is the work on LuaTeX strictly linked with Lua itself
> or are hooks provided so that at least part of what's been done could
> be reusable with other embeddable (in the sense of "explicitly
> designed with embeddability as a precise goal") languages, like io
> (<http://www.iolanguage.com>).
>
the following message to one of the LuaTeX developers, April 2006:
Dear Taco,
I understand from the LuaTeX FAQ that third-party feedback is
currently
not encouraged. However, I have one observation that I hope you
might consider. Specifically, I would have thought it possible,
and desirable, to introduce a lightweight intermediate layer to broker
communications between TeX and Lua.
The situation would be analagous to converting between graphics
formats.
Rather than writing N^2 conversion programs (a2b, a2c, b2a, b2c,
c2a, c2b etc.) it is possible to get away with the 2N conversion
programs
(a2xyz, b2xyz, c2xyz, xyz2a, xyz2b, xyz2c etc.). The motivation being
that when a new format comes along one need only construct xyz2new
and new2xyz to be able to convert to any one of the other formats.
So instead of having tex2lua and lua2tex communications one would have
{tex,lua}2broker and broker2{tex,lua}. That way it would be be
straightforward for a third-party to add their own favourite scripting
language, as most of the machinations live with the broker and do not
change with the choice of embedded language (at least not for
languages
implemented in C, which covers perl python, ruby etc.).
I realise, from arguments of portablity, that you might not want to
have a
situation where there are 57 varieties of embedded interpreter. But
the
broker-design would provide a springboard for whatever language
developments
might occur down the road without needing to be rewritten. As for the
cost of the overhead, it would not be great and with the advent of
multicore processors I'm not sure it is something to worry about.
Afterall, much of TeX's programming clunkiness stems from decisions
that were too focussed on the machine's of the day; a mistake
that crops up time and time again.
In any event. I look forward to trying out LuaTeX when it is
made publicly available.
All the best with your project,
James Quirk
Joachim Schrod
> At the markup level, I think that TeX/LaTeX is pretty good by today's
> standards (certainly well ahead of its time) but does lack some semantic
> consistency (some things are opened and then closed (e.g. lists),
> whereas others are not (e.g. sections).
You know that for most markup this is pure convention?
You can write
\begin{section}{Section Name}
... stuff ...
\end{section}
> Another completely different alternative is DocBook. It is very good
> for technical documentation and I've used it successfully for that on
> many occasions. However, it's no good (currently) at Maths because
> you'd have to write in MathML -- which is both different than the status
> quo (LaTeX) and more verbose -- and it doesn't have an equivalent of
> CTAN for people to share cool XSL routines and so on.
Can you tell about DocBook backends that produce typeset output in
the same quality as proper LaTeX documents (i.e., not the ones that
take the default page layout and default section headers of LaTeX#s
standard classes, but maybe memoir or koma-script; in addition I
expect utilization of booktabs and other sensible layout improvements).
Up to now, I wasn't able to locate one. While I use DocBook for
some technical manuals, the layout design and typesetting quality
is not something to be proud of. I wrote some XSLT hacks myself,
but there not robust and reliable; therefore I would like to reuse
work that has been done by more experienced folks.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jsc...@acm.org
Roedermark, Germany
Brian Blackmore
> Yes, that is correct.
Sounds like an mpage solution to me, since the page layout is so
astonishingly simple. ;)
Your final comment has nevertheless struck the correct chord, namely
plan on doing that type of stuff in TeX because it's a rather simple
output hack. That's plain TeX here ---
I guess I'm not entirely convinced that this 'problem' is an issue with
the macro language, though, because I'm not completely sure how one
would expect to do it in a functional programming language and have it
look any bit better than the comparable output hack. If you're talking
about the ability to create linked parboxes at any point on the page,
the simple fact is that TeX doesn't natively have a notion of the first,
whence you have to code it, and the second is a completely different
layout mechanism than the TeX typesetting engine uses.
As to the first, I could conceive of creating a set of linked parbox
macros, but it becomes a question of the ultimate shape of each one. I
don't think the situation would improve with a functional interface
because you'd still have the same amount of work to do. Even the notion
of a native array isn't going to help much because there's no
linktoparbox(x,y,...) capability; you'd have to write that too.
The usefulness (in general) of such a thing is somewhat unclear, as is
the notion of how proper the typeset output would be.
As to placing stuff at any point on the page, well there are plenty of
examples on this newsgroup of people asking that question. It is,
simply put, a somewhat different paradigm, but nevertheless ultimately
easy to achieve (with some constraints).
In conclusion, I'll say that you should just use plain TeX, because
there are many easy examples of macro coding out there that would make
it all rather a bit more clear. There's yet anything that I haven't
been able to make it do, including color, unicode, etc., that I've
needed it to do. Does it require thinking? Yes, indeed it does. Then
again, I would argue that most programming should require thinking, and
if the thought is absent, so will the resulting code be crap.
--
Brian Blackmore
blb8 at po dot cwru dot edu
M. Tylee Atkinson
> You know that for most markup this is pure convention?
> You can write
>
> \begin{section}{Section Name}
>
> ... stuff ...
>
> \end{section}
Cool!
> Up to now, I wasn't able to locate one. While I use DocBook for some
> technical manuals, the layout design and typesetting quality is not
> something to be proud of. I wrote some XSLT hacks myself, but there not
> robust and reliable; therefore I would like to reuse work that has been
> done by more experienced folks.
I did actually forget to mention DB2LaTeX [1], which does allow you to
use LaTeX for the typesetting of DocBook files. I think that the
quality of the DocBook->XML-FO->PDF chain is now a lot better than it
was when I wrote my dissertation on converting LaTeX to Braille (in
DocBook, hehe), but if you prefer the way TeX/LaTeX presents things,
there is always this alternative.
best regards,
[1] http://db2latex.sourceforge.net/
Ulrich M. Schwarz
> Joachim Schrod wrote:
>> You know that for most markup this is pure convention? You can write
>>
>> \begin{section}{Section Name}
>>
>> ... stuff ...
>>
>> \end{section}
>
> Cool!
Beware, however, that stars don't work the way you might think:
\documentclass{article}
\begin{document}
\begin{section}{Section one}
Bla.
\end{section}
\begin{section*}{Section without a number?}
Blabla
\end{section*}
\begin{section}*{Section without a number!}
\end{section}
\section*{Section without a number!}
\end{document}
HTH
Ulrich
Javier Bezos
"Ulrich M. Schwarz" <broth...@gmx.net> escribió en el mensaje
news:c3c.46ba1...@absatzen.de...
>>> \begin{section}{Section Name}
>>>
>>> ... stuff ...
>>>
>>> \end{section}
...
> Beware, however, that stars don't work the way you might think:
> \documentclass{article}
...
> \begin{section*}{Section without a number?}
> Blabla
> \end{section*}
But fixed easily:
\makeatletter
\@namedef{section*}{\section*}
\makeatother
Javier
-----------------------------
http://www.texytipografia.com
Joachim Schrod
> Joachim Schrod wrote:
>
>> technical manuals, the layout design and typesetting quality is not
>> something to be proud of. I wrote some XSLT hacks myself, but there
>> not robust and reliable; therefore I would like to reuse work that has
>> been done by more experienced folks.
>
> I did actually forget to mention DB2LaTeX [1], which does allow you to
> use LaTeX for the typesetting of DocBook files. I think that the
> quality of the DocBook->XML-FO->PDF chain is now a lot better than it
> was when I wrote my dissertation on converting LaTeX to Braille (in
> DocBook, hehe), but if you prefer the way TeX/LaTeX presents things,
> there is always this alternative.
DocBook->XML-FO->PDF does not handle bibliographies, indexes, and
does not typeset figures properly. Footnotes sucks. The grid
approach of XML-FO is good enough to produce forms (I use it for
that), but not for real typeset books. IMNSHO, this tool chain is
not of any use for decent quality requirements.
I know DB2LaTeX and use it for simple documents; but for more
complex ones my XSLT custom styles have reached a size that I could
start to transform the whole document myself with my own scripts.
And, frankly, XSLT styles are a horrid mess to maintain, sometimes
even harder than LaTeX macro code. (I wouldn't have thought that
one could desing a style sheet language where this is the case.)
Why they are selled as an improvement is beyond my intellectual
reach. (OK; maybe I'm biased here, with my LaTeX and STIL work. ;-)
Javier Bezos
> But fixed easily:
>
> \makeatletter
> \@namedef{section*}{\section*}
> \makeatother
In fact, it's even easier:
\newenvironment{section*}{\section*}{}
Javier
-----------------------------
http://www.texytipografia.com
Luis Rivera
> Have you had a look at ANT (Ant is Not Tex) athttp://ant.berlios.de/?
> Among its features it claims
>
> * a saner macro language (no catcodes)
> * a builtin high-level scripting language
>
Speaking as an end-user, without a CS degree...
I tried AnT once, and my conclusion was that even though it is way
easier to compile, install and run (compared to the mess of web/tangle/
pas|c), it has a slight bias towards the way LaTeX does stuff (not
only its syntax, but some the limitations of the current version of
the system; for instance, you can't typeset italic boldface smallcaps
text easy, since the current implementation of the NFSS is hard-coded
in the processor). I never got to write macros, partly because I
didn't need to (good point), partly because I had to learn yet another
programming language (bad point).
Some things I think are OK with the way TeX was designed is that you
can redefine the input syntax without touching the underlying
typesetting engine (one advantage of having \catcode's), so TeX's
engine can be adapted to a number of different markup languages; plus,
the <escape><csname> syntax of the current macro language makes it
easy to discern what is what while writing macros. I have experienced
writing macros as a pain, but I believe that this is due to some
limitation in the current set of built-in control sequences rather
than a fault in the macro language as such.
Anyway, IMHO LuaTeX seems like the right way to go: preserving the
current macro language, for backwards compatibility, and extending the
system with a small, imperative, embedded scripting language. (That's
why I use gel rather than perl for my text transformation tasks: I
find the merge of gema and lua more intuitive and easier to handle
than even the simplest perl.)
My penny thoughts.
Luis.
Michele Dondi
wrote:
>system with a small, imperative, embedded scripting language. (That's
>why I use gel rather than perl for my text transformation tasks: I
>find the merge of gema and lua more intuitive and easier to handle
>than even the simplest perl.)
Although I'm a Perl junkie, thanks for letting me know. It seems
interesting. Somebody should tell @Larry to look into it to see if
there's any interesting feature to steal for Perl 6. (But I'm sure
sombody will be in this business already.)
David Kastrup
> On Fri, 10 Aug 2007 21:11:21 -0000, Luis Rivera <jlr...@gmail.com>
> wrote:
>
>>system with a small, imperative, embedded scripting language. (That's
>>why I use gel rather than perl for my text transformation tasks: I
>>find the merge of gema and lua more intuitive and easier to handle
>>than even the simplest perl.)
>
> Although I'm a Perl junkie, thanks for letting me know. It seems
> interesting. Somebody should tell @Larry to look into it to see if
> there's any interesting feature to steal for Perl 6. (But I'm sure
> sombody will be in this business already.)
Lua is a minimalistic design, so the inspiration would be rather what
uninteresting features could be thrown away for Perl 6.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
Michele Dondi
>> Although I'm a Perl junkie, thanks for letting me know. It seems
>> interesting. Somebody should tell @Larry to look into it to see if
>> there's any interesting feature to steal for Perl 6. (But I'm sure
>> sombody will be in this business already.)
>
>Lua is a minimalistic design, so the inspiration would be rather what
>uninteresting features could be thrown away for Perl 6.
Fair enough. Though even a minimalistic language could exhibit a nice
way to solve a problem that may manifest itself in a far from being
minimalistic one. And if that's a good idea, it could be lifted. Well,
in line of principle: I agree that probabilities will be low.
David Kastrup
> On Sat, 11 Aug 2007 12:23:16 +0200, David Kastrup <d...@gnu.org> wrote:
>
>>> Although I'm a Perl junkie, thanks for letting me know. It seems
>>> interesting. Somebody should tell @Larry to look into it to see if
>>> there's any interesting feature to steal for Perl 6. (But I'm sure
>>> sombody will be in this business already.)
>>
>>Lua is a minimalistic design, so the inspiration would be rather what
>>uninteresting features could be thrown away for Perl 6.
>
> Fair enough. Though even a minimalistic language could exhibit a nice
> way to solve a problem that may manifest itself in a far from being
> minimalistic one. And if that's a good idea, it could be lifted. Well,
> in line of principle: I agree that probabilities will be low.
Lua has an efficient and straightforward closure and coroutine model.
Juhapekka Tolvanen
Joachim Schrod <jsc...@acm.org> writes:
> Can you tell about DocBook backends that produce typeset output in the
> same quality as proper LaTeX documents (i.e., not the ones that take
> the default page layout and default section headers of LaTeX#s
> standard classes, but maybe memoir or koma-script;
That is why I like to use ReStructured Text. I can modify settings of
LaTeX-output as much as I ever want and in addition I can write very
simple and human-readable markup.
Here is my typical docutils.conf
---- Clip Here -----
# This file is public domain. There is no warranty.
[general]
datestamp: %Y-%m-%d %H:%M:%S %Z
footnote_backlinks: true
generator: true
input_encoding: UTF-8
input_encoding_error_handler: strict
output_encoding: UTF-8
output_encoding_error_handler: strict
[writers]
[doc_utils_xml writer]
doctype_declaration: true
indents: true
xml_declaration: true
[html4css1 writer]
attribution: parens
cloak_email_addresses: true
[s5_html writer]
attribution: parens
cloak_email_addresses: true
current_slide: true
[latex2e writer]
attribution: parens
use_latex_toc: true
use_latex_footnotes: true
compound-enumerators: true
section-prefix-for-enumerators: true
documentclass=scrartcl
#documentoptions=12pt,a4paper,oneside,BCOR15mm,DIV16,landscape
#documentoptions=12pt,a4paper,oneside,BCOR15mm,DIV16,landscape
#documentoptions=12pt,a4paper,oneside,BCOR0mm,DIV17,landscape
documentoptions=12pt,a4paper,oneside,BCOR10mm,DIV18
#documentoptions=10pt,a4paper,oneside,BCOR15mm,DIV17
#documentclass=article
#documentoptions=12pt,a4paper,oneside
---- Clip Here -----
As you can see, there was KOMA-Script class called "scrartcl".
And here is RST.tex
---- Clip Here -----
% My LaTeX-settings to be used with python-docutils and reStructuredText
% Author:
% Juhapekka Tolvanen
% http://iki.fi/juhtolv
% juhtolv (at) iki (dot) fi
% This file is public domain. There is no warranty.
% This makes stfloats or fix2col obsolete. This loads fixltx2e.
%% "When the new output routine for LaTeX3 is done, this package will
%% be obsolete. The sooner the better..."
\RequirePackage{dblfloatfix}
% This makes type1cm and type1ec obsolete:
\RequirePackage{fix-cm}
% To ease checking pdf(la)tex with if-statements
\RequirePackage{ifpdf}
%\setcounter{secnumdepth}{3}
\setcounter{secnumdepth}{7}
%%%%%%%%%%%%%%%%%%%%%
% Packages
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Fonts
%
% Most special chars, also copyleft
\usepackage{textcomp}
% Palatino:
% Very good, if you are going to read from paper.
% Use this even if you do not write math.
% A packet called "palatino" is deprecated. See: CTAN: l2tabu
%\usepackage{mathpazo}
% Use Palatino-fonts of fpl-neu -package:
% <http://home.vrweb.de/~was/x/FPL/>:
%\renewcommand{\rmdefault}{fp9x}
% Just like above, but use old style digits:
%\renewcommand{\rmdefault}{fp9j}
% Concrete fonts:
% Slab serif, hence works quite well on screen.
%\usepackage{beton}
% There are no bold Concrete fonts, but it is generally accepted that the
% Computer Modern Sans Serif demibold condensed fonts are an adequate
% substitute. If you are using concmath or ccfonts and you want to
% follow this suggestion, then use the package with boldsans class
% option (in spite of the fact that the concmath documentation calls it
% sansbold class option).
%\renewcommand{\bfdefault}{sbc}
% Bitstream Charter:
% Better for reading from screen
%\usepackage{charter}
% Bitstream Vera -fonts:
% Even better for reading from screen.
% If you use this, you'd better comment away those
% Sans Serif- and Monospace -settings below, because
% Bitstream Vera has good sans serif- and monospace-fonts, too.:
\usepackage{bera}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Sans Serif -font
% This should be taken from CM-Super- and hfbright-fonts:
%\renewcommand{\sfdefault}{cmbr}
% Use this, if CM Super-fonts are broken:
%\renewcommand{\sfdefault}{lmss}
% Helvetica
%\renewcommand{\sfdefault}{phv}
% Also this trick is from l2tabu
%\usepackage[scaled=.95]{helvet}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Monospace-font:
% This should be taken from CM-Super-fonts:
%\renewcommand{\ttdefault}{cmtt}
% Use this, if CM Super-fonts are broken:
%\renewcommand{\ttdefault}{lmtt}
% Quite good monospace-font:
%\renewcommand{\ttdefault}{txtt}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% cmap: "Make the PDF files generated by pdflatex "searchable and copyable"
% in Adobe (Acrobat) Reader and other compliant PDF viewers."
% (Must be before fontenc-package)
\ifpdf % Some people may have buggy cmap.
\usepackage{cmap}
\fi
\usepackage[T1]{fontenc}
\ifpdf
\usepackage[protrusion=true,expansion=true,verbose=true,final=true]{microtype}
\else
\usepackage[verbose=true,DVIoutput=true,draft=false,final=true]{microtype}
\fi
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage{setspace}
%\singlespacing
\onehalfspacing
%\spacing{1.7} % This causes bugs like this: (\end occurred inside a group at level 1)
%\doublespacing
---- Clip Here -----
If I have RST-file called "README.txt", then compiling it goes like
this, when using some Bourne Shell -esque shell::
---- Clip Here -----
export DOCSBASENAME="README"
rst2latex --language=en --report=5 --toc-entry-backlinks \
--section-numbering --strip-comments --stylesheet=RST \
--graphicx-option=pdftex --font-encoding=T1 --use-verbatim-when-possible \
${DOCSBASENAME}.txt ${DOCSBASENAME}.tex
pdflatex -src-specials -file-line-error-style ${DOCSBASENAME}.tex
while grep 'Rerun to get' ${DOCSBASENAME}.log > /dev/null
do
pdflatex -src-specials -file-line-error-style ${DOCSBASENAME}.tex
done
pdflatex -src-specials -file-line-error-style ${DOCSBASENAME}.tex
---- Clip Here -----
And then comes the best part: Syntax of ReStructured Text is very easy,
much easier than syntax of (X)HTML, XML, TeX, LaTeX or ConTeXt:
---- Clip Here -----
##############
Document title
##############
**************************
Subtitle of whole document
**************************
Level 1 Subtitle
################
Some text in first paragraph. More text. And even more text. Yet more
text. And once again more text.
Start of second paragraph.
More text. And more.
``juhtolv (at) iki (dot) fi``
Level 2 subtitle
****************
Level 3 subtitle
================
Level 4 subtitle
++++++++++++++++
Level 5 subtitle
----------------
Level 6 subtitle
................
.. =================================================================
.. This is not just a text file! This is also reStructuredText -file!
.. You can convert this file to many formats with python-docutils
.. http://docutils.sourceforge.net/
.. http://docutils.sourceforge.net/rst.html
.. Help for text editors:
.. For Emacs:
.. Local Variables: ***
.. mode: rst ***
.. coding: utf-8 ***
.. fill-column: 77 ***
.. End: ***
.. For Vim:
.. vim: set ft=rst fenc=utf-8 fdm=marker :
---- Clip Here -----
--
Juhapekka "naula" Tolvanen * http colon slash slash iki dot fi slash juhtolv
"S teki. S teki. S teki. S wo kakusei. S teki. S teki. S teki. S wo umekome.
S teki. S teki. S teki. M wo setsudan. S teki. S teki. Puratonikku wo
hajimemashou." Dir en grey
hasan.k...@gmail.com
It's simply disgusting; therefore I prefer *reStructuredText* (rST) which is converted via Sphinx to LaTex/PDF. To ease the process I even wrote a browser based editor NoTex (available at https://notex.ch) which sufficiently isolates me from LaTex, without forgoing it's brilliant output.