About exporting

About exporting

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

Hi

After some years of using orgmode, and exporting using its defaults, I 
would like to take a quality leap and find a way of exporting for life. 
My options: LaTeX, ODT, HTML.

LaTeX: I can see some masters here that make professional books, and I 
have some friends that publish scientific papers using LaTeX. But, it 
looks like a like a rabbit hole to me, since even the masters seem to 
have to modify the tex file directly (is this correct?), not being 
sufficient orgmode to culminate the work by itself. And to learn LaTeX 
seems a lifelong activity (almost like "learning" orgmode). BTW, when I 
export to LaTeX although it gets the job done, it sends a lot of error 
messages.

ODT: I take this one as a lower level solution than LaTeX, but it looks 
easier to tame, and it even allows to use templates,  for example to 
make reports in the workplace. Do you think it is worth focusing on ODT 
exporting? Could it be a definitive solution to publish papers and books 
directly from orgmode? ODT exporting sends some error message to me, but 
at least I understand it.

HTML: I have seen some themes 
<https://olmon.gitlab.io/org-themes/latexcss/latexcss.html> designed to 
export in LaTeX format using HTML. Here we would have the "definitive 
tool": The power of LaTeX in the versatility that could give the use of 
different themes for different purposes. But, do you think it could get, 
some day, the quality of a direct LaTeX export? No errors by my side 
when exporting to HTML.

How do you think I should spend some hundreds (or thousands) of hours to 
achieve maestry exporting my documents?

Best regards.


[-- Attachment #2: Type: text/html, Size: 2019 bytes --]

Re: About exporting

[William Denton]

On 29 March 2021, Ypo wrote:

> How do you think I should spend some hundreds (or thousands) of hours to 
> achieve maestry exporting my documents?

I think the key question is:  Do you want to preserve them as web pages or 
page-based documents?  If the web, then it's HTML; if documents, I'd use LaTeX. 
OpenDocument is a fine format, and if you have a lot of fairly simple documents, 
you could certainly use it, but it's not the best way to get articles and books 
print-ready yourself.  And if you want to make beautiful documents with great 
typography, LaTeX is the best choice, and of course integrates very well with 
Org.  (I've never tweaked the LaTeX output from Org by hand, but some projects I 
do fully in LaTeX because it's just easiest to have total control and edit with 
AucTeX).

To get better at it, I'd recommend reading the manual for the Memoir class [1] 
(the first few chapters that talk about page design, at least, then refer to the 
rest as needed) and Robert Bringhurst's THE ELEMENTS OF TYPOGRAPHIC STYLE [2] 
(which will give you ideas you can implement and right away your documents will 
look great).



Bill

[1] https://www.ctan.org/pkg/memoir
[2] https://en.wikipedia.org/wiki/The_Elements_of_Typographic_Style
--
William Denton :: Toronto, Canada   ---   Listening to Art: https://listeningtoart.org/
https://www.miskatonic.org/         ---   GHG.EARTH: https://ghg.earth/
Caveat lector.                      ---   STAPLR: https://staplr.org/

Re: About exporting

[autofrettage]

Hi Ypo and the rest of you all,

> After some years of using orgmode, and exporting using its defaults, I would like to take a quality leap and find a way of exporting for life. My options: LaTeX, ODT, HTML.
/.../
> How do you think I should spend some hundreds (or thousands) of hours to achieve maestry exporting my documents?

I have some odd thoughts about this.

About 30 years ago I worked for a start-up company. As a young engineer, freshly hooked on LaTeX, I tried to convince my colleagues we should produce the users' manuals for our product with LaTeX. Since persuasive speech is not one of my strengths, they opted for Word 5.

For various reasons I stayed for only a few years. Recently I visited them, and heard that the users' manuals had been ported hither and thither between various wysiwyg DTP programs. They are now back in Word, and my former colleagues didn't even remember the documents had started their journey there!

If they only had listened to me in the beginning!

The moral seems to be that whatever time and effort you plow into learning LaTeX, will not be wasted. Chances are that LaTeX will be there in thirty years' time, working roughly the same as now.


Roughly. At a fine grain level, LaTeX -- not to speak about Org Mode -- is a moving target. How on earth can you hope for attaining mastery at exporting documents? Many individuals are continuously refining these tools, so the mere mortals among us will always fight a losing battle keeping up.


Late adoption is a great trick for making life a bit easier. Postpone teaching yourself the latest tricks, until other friendly internet citizens have had time to write streamlined explanations ;-)


Last but not least, think like Bruce Lee:

“You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.”*

So, teach yourself whatever you need now (where "now" includes a foreseeable future).

Cheers
Rasmus

* LaTeX = ninjutsu, ODT = boxing, HTML = kick in the groin?

Re: About exporting

[Juan Manuel Macías]

Hi,

Ypo <ypuntot@gmail.com> writes:

> LaTeX: I can see some masters here that make professional books, and I
> have some friends that publish scientific papers using LaTeX. But, it
> looks like a like a rabbit hole to me, since even the masters seem to
> have to modify the tex file directly (is this correct?), not being
> sufficient orgmode to culminate the work by itself. And to learn LaTeX
> seems a lifelong activity (almost like "learning" orgmode). BTW, when
> I export to LaTeX although it gets the job done, it sends a lot of
> error messages.

I can tell you some points about my experience with the export to LaTeX,
since that's what I work the most with.

The advantages of using Org instead of "pure" LaTeX (as I already
discussed in another thread) are, IMHO, (a) being able to work on a much
lighter and human readable source (consider, for example, what a list
looks like in Org and what it looks like in LaTeX); and (b) be able to
export to various formats consistently from a single source. Therefore,
it would not be necessary to edit the *.tex document, as we would lose
the latter advantage.

Of course, if you want to use Org to create "refined" documents or books
with LaTeX, you're going to have to learn LaTeX. But "learning LaTeX" is
a imprecise term, since LaTeX has a minimal kernel concept expanded by a
(infinity of) macro packages. Even you can write your own packages, if
you know how to do it. That is, learning latex involves: a) learning
LaTeX syntax (which is not especially arduous) and b) learn the packages
you are going to use (and, therefore, *study its documentation*). The
documentation for each package is on CTAN (https://www.ctan.org/); you
also have, of course, lots of online documentation about LaTeX and TeX
in general. A very good place is https://tex.stackexchange.com/

My personal story has been to use LaTeX for years, until I decided to do
it from Org, but still using LaTeX ...

It also depends on the type of book/document you want to make. When
deals with very large books I usually create the preamble in a Org
document separately, and then I tangle the code in a tex file. And I
also use Org Publish to separate the parts of the book into small
documents (very useful).

Another great thing about Org, on the other hand, is that it has many
resources for control the export process. For example, in a book I'm
working on I noticed that the font has a kerning (separation
between characters) too close between the sign "(" and the italic "f",
producing a rather ugly effect. Simply, with a simple function in Elisp
I was able to readjust that space in the export process (see:
https://orgmode.org/manual/Advanced-Export-Configuration.html#Advanced-Export-Configuration)

All of this that I have discussed, of course, may sound too abstract.
But I can comment in more detail on more specific issues, if you have
any questions :-)

Best regards,

Juan Manuel 

Re: About exporting

[Samuel Wales]

is org ootb mma?  for those of us who woul dlike to spend, like, zero
time exporting, and then, like, less than a half hour fixing htat one
thing that is irritating about hte output, with no errors?  i can
dream.

On 3/29/21, autofrettage <autofrettage@protonmail.ch> wrote:
> Hi Ypo and the rest of you all,
>
>> After some years of using orgmode, and exporting using its defaults, I
>> would like to take a quality leap and find a way of exporting for life. My
>> options: LaTeX, ODT, HTML.
> /.../
>> How do you think I should spend some hundreds (or thousands) of hours to
>> achieve maestry exporting my documents?
>
> I have some odd thoughts about this.
>
> About 30 years ago I worked for a start-up company. As a young engineer,
> freshly hooked on LaTeX, I tried to convince my colleagues we should produce
> the users' manuals for our product with LaTeX. Since persuasive speech is
> not one of my strengths, they opted for Word 5.
>
> For various reasons I stayed for only a few years. Recently I visited them,
> and heard that the users' manuals had been ported hither and thither between
> various wysiwyg DTP programs. They are now back in Word, and my former
> colleagues didn't even remember the documents had started their journey
> there!
>
> If they only had listened to me in the beginning!
>
> The moral seems to be that whatever time and effort you plow into learning
> LaTeX, will not be wasted. Chances are that LaTeX will be there in thirty
> years' time, working roughly the same as now.
>
>
> Roughly. At a fine grain level, LaTeX -- not to speak about Org Mode -- is a
> moving target. How on earth can you hope for attaining mastery at exporting
> documents? Many individuals are continuously refining these tools, so the
> mere mortals among us will always fight a losing battle keeping up.
>
>
> Late adoption is a great trick for making life a bit easier. Postpone
> teaching yourself the latest tricks, until other friendly internet citizens
> have had time to write streamlined explanations ;-)
>
>
> Last but not least, think like Bruce Lee:
>
> “You must be shapeless, formless, like water. When you pour water in a cup,
> it becomes the cup. When you pour water in a bottle, it becomes the bottle.
> When you pour water in a teapot, it becomes the teapot. Water can drip and
> it can crash. Become like water my friend.”*
>
> So, teach yourself whatever you need now (where "now" includes a foreseeable
> future).
>
> Cheers
> Rasmus
>
> * LaTeX = ninjutsu, ODT = boxing, HTML = kick in the groin?
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: About exporting

[Tim Cross]

Ypo <ypuntot@gmail.com> writes:

> Hi
>
> After some years of using orgmode, and exporting using its defaults, I would like to take a quality leap and find a way of exporting for life. My options:
> LaTeX, ODT, HTML.
>

Forget your goal. Technology and user expectations moves too fast and you will never find a
solution 'for life' in the sense you mean. More important is to learn
how to adapt and change. 

> LaTeX: I can see some masters here that make professional books, and I have some friends that publish scientific papers using LaTeX. But, it looks like a
> like a rabbit hole to me, since even the masters seem to have to modify the tex file directly (is this correct?), not being sufficient orgmode to culminate
> the work by itself. And to learn LaTeX seems a lifelong activity (almost like "learning" orgmode). BTW, when I export to LaTeX although it gets the job
> done, it sends a lot of error messages.
>

I've been using Latex since 1990 and it hasn't changed much. The two
biggest mistakes I see people make all the time with Latex are -

1. Trying to heavily customize document format using Latex and Tex
macros and low level Latex/Tex commands instead of using available
packages to modify the output in a consistent manner.

2. Breaking the 'word' habit of believing your a typsetting expert and
need to tweak margins, line spacing, headers, list indentation, etc etc.
Your not a typsetting expert (at least most of us are not) and your far
better off trusting those who write the packages.

Reality is, very few of us have the expertise to know what a well
formatted and typeset document actually looks like. It is actually a
complex skill with lots of subtleties and pitfalls. Problem is, we have
been swamped by poor document formatting due to programs like MS Word
and grown to accept the poor practices it exhibits.

Latex itself is actually very easy with only a few commands. It only
gets complex when you try to work at a very low level and even that
complexity is mainly because it looks unusual with what is considered
these days to be a weird syntax. In 30 years of use, I've hardly done
any Latex or Tex, rarely used Latex macros and have never had to write
more than a line or two of Latex or Tex code. With very few exceptions,
whenever I wanted something, it has almost certainly been done by
someone else and all I really need to do is add a package and configure
it. 

The trick with Latex is to go with the flow, not against it. When you do
find areas of the default document style you don't like, look for
packages to adjust the formatting rather than try to tweak it yourself.
For example, nearly everyone will want to adjust the page margins. don't
try to do this by using low level Latex commands to adjust line length,
paragraph width, line spacing etc. Instead, use a package like the
geometry package. If you want additional options for tables or modify
how tables look, try some of the many available table formatting
packages. If you simply don't like the default document style, then look
into the various other document style packages that are available. 

What you end up with is one or two sets of 'default' packages which
generate the documents formatted how you want. It may take some initial
research to find these, but once you have them, you will very rarely
need to do any tweaking.

Once you know which packages you want and have your 'sets', then you can
modify your org configuration to use those packages. for example, I have
latex 'classes' defined in my org config for work, technical documents,
letters, beamer presentations, general documentation and default. I
select which one I want by adding the #+LATEX_CLASS: option at the top
of the document. The 'work' group is a highly custom document which
includes logo and colour which make my documents conform to the document
style policy where I work, technical documents use the HiTech package,
general documents use the koma-script document format and default uses
the default Latex format. I rarely have to modify the *.tex files
generated in exports - like maybe once or twice in a year and I produce
quite a lot of documents. The hardest one to get working was the work
class, but that was because the policy was rather complex regarding
colours, logo size and position, margin, line spacing, font, hyperlink
colour/font etc. Once I got it working though, it has not required
modification until the policy is modified.

With respect to errors from Latex when crating your documents. A lot of
those are probably better classified as warnings rather than errors.
Latex will tell you when you have things like long words it cannot
hyphenate well and when it cannot determine when/where to break a line
to avoid an 'overfilled' element. Often these can be ignored. However,
sometimes, you may need to give Latex a 'hint' or helping hand by
slightly modifying your content (for example, a table with a column
which is too wide may need you to manually add line breaks or an
included image may need some size hints etc.  

> ODT: I take this one as a lower level solution than LaTeX, but it looks easier to tame, and it even allows to use templates,  for example to make reports in
> the workplace. Do you think it is worth focusing on ODT exporting? Could it be a definitive solution to publish papers and books directly from orgmode?
> ODT exporting sends some error message to me, but at least I understand it.
>

I've never liked the ODT output. I find the documents I produce using
ODT to be 'uglier' than those with Latex. However, if I need to produce
the document in a format which allows others to edit it, ODT can be
useful. 

> HTML: I have seen some themes designed to export in LaTeX format using HTML. Here we would have the "definitive tool": The power of LaTeX in the
> versatility that could give the use of different themes for different purposes. But, do you think it could get, some day, the quality of a direct LaTeX export?
> No errors by my side when exporting to HTML.
>

No, because they serve different purposes. Latex is superior in every
way when it comes to producing a PDF or a printed document. HTML is
superior when you want to display the content in a browser. HTML is
terrible when you want to print the output. 

I think it is a mistake to try and just focus on one export format. The
great benefit of org mode is that you can export in multiple formats
with minimal or no changes to the source. If you need to export in a
format which will allow others to edit the document, ODT is great, if
you need to export to publish on the web, HTML, if you need a PDF Latex,
if you need a presentation, either beamer or something like reveal. They
all have a role to play.

A better use of time is getting to know org and how it can be configured
so that you can setup your export environments with defaults which suit
your requirements. When I see people modifying *.tex files generated by
org, it is often because they have not worked out how to add the
additional packages or set the configuration for those packages in org. 



-- 
Tim Cross

Re: About exporting

[Thomas S. Dye]

Aloha Ypo,

"Exporting for life" is a vague target, so it is difficult to give 
precise recommendations.

It is usually the case that export to LaTeX doesn't require 
subsequent modification of the tex file.  In most cases for my 
work, I am exporting to a LaTeX document style/class provided by 
someone else.  This is fairly typical of the LaTeX world, where 
academic journals and university degree programs design their own 
in-house styles and then ask authors to use them.  The idea behind 
LaTeX is that LaTeX defines the meaningful units of a document 
(headers, paragraphs, quotes, etc.) so that a single LaTeX 
document can be exported to multiple targets, each of which styles 
the document units in its own way.  Because Org mode targets 
LaTeX, and not a particular style, this means that Org mode 
inherits LaTeX's style agnosticism.

Of course, there are exceptions to this general rule, where a 
LaTeX class/style defines document units that extend the LaTeX 
spec.  It can be tricky to get Org mode to export to one of these 
non-standard styles.

If you intend to create documents with bibliographies, then IMHO 
LaTeX export is the best choice.  BibTeX defines a plain text 
bibliographic database that is very widely used and capable of 
meeting the most exact bibliographic requirements.  John Kitchin 
has written org-ref to manage BibTeX databases from Org mode, and 
Joost Kremers has ebib, which integrates nicely with Org mode and 
accomplishes many of the same tasks covered by org-ref.  A native 
Org mode bibliographic solution has been discussed for many years 
and there is an org-cite branch that is a nearly complete work in 
progress.  This will be designed to use Citation Style Language, 
rather than BibTeX, which means (at least currently IIUC) that 
there will be somewhat less fine control over bibliographic 
format, although there are thousands of CSL style definitions, 
which presumably cover all the most likely targets.  In my 
experience, CSL approximates most bibliographic styles, rather 
than producing them exactly, so YMMV.

Even without the need for bibliographies, LaTeX might be your best 
choice.  In my field, most of the journals *require* an MS Word 
document, a practice that gives me no end of heartburn.  I've 
found that export to LaTeX followed by conversion with the Haskell 
program pandoc gives the best results.  Pandoc is pretty nifty, 
with conversion among quite a few different formats.  LaTeX 
provides a rich input, which pandoc handles really well.

hth,
Tom


Ypo writes:

> Hi
>
> After some years of using orgmode, and exporting using its 
> defaults, I would
> like to take a quality leap and find a way of exporting for 
> life. My options:
> LaTeX, ODT, HTML.
>
> LaTeX: I can see some masters here that make professional books, 
> and I have some
> friends that publish scientific papers using LaTeX. But, it 
> looks like a like a
> rabbit hole to me, since even the masters seem to have to modify 
> the tex file
> directly (is this correct?), not being sufficient orgmode to 
> culminate the work
> by itself. And to learn LaTeX seems a lifelong activity (almost 
> like "learning"
> orgmode). BTW, when I export to LaTeX although it gets the job 
> done, it sends a
> lot of error messages.
>
> ODT: I take this one as a lower level solution than LaTeX, but 
> it looks easier
> to tame, and it even allows to use templates,  for example to 
> make reports in
> the workplace. Do you think it is worth focusing on ODT 
> exporting? Could it be a
> definitive solution to publish papers and books directly from 
> orgmode? ODT
> exporting sends some error message to me, but at least I 
> understand it.
>
> HTML: I have seen some themes
> <https://olmon.gitlab.io/org-themes/latexcss/latexcss.html> 
> designed to export
> in LaTeX format using HTML. Here we would have the "definitive 
> tool": The power
> of LaTeX in the versatility that could give the use of different 
> themes for
> different purposes. But, do you think it could get, some day, 
> the quality of a
> direct LaTeX export? No errors by my side when exporting to 
> HTML.
>
> How do you think I should spend some hundreds (or thousands) of 
> hours to achieve
> maestry exporting my documents?
>
> Best regards.


--
Thomas S. Dye
https://tsdye.online/tsdye

Re: About exporting

[Greg Minshall]

i tend to be situational.  some things i export to html, some to pdf,
some to both.  it just depends on the need of whatever small project i'm
working on.

Re: About exporting

[Eric S Fraga]

On Tuesday, 30 Mar 2021 at 09:06, Tim Cross wrote:
> The trick with Latex is to go with the flow, not against it. 

+1

This is the first thing I tell my students.  LaTeX knows much much more
about how to make documents look good than any of us ever will.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: About exporting

[Colin Baxter]

>>>>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:

    > On Tuesday, 30 Mar 2021 at 09:06, Tim Cross wrote:
    >> The trick with Latex is to go with the flow, not against it.

    > +1

    > This is the first thing I tell my students.  LaTeX knows much much
    > more about how to make documents look good than any of us ever
    > will.

Very true. Unfortunately, you also have to "go with the flow" with the
publishers who insist on receiving a docx file. Thankfully there's
pandoc, but it's an annoying waste of time having to convert from LaTeX
to some dreadful docx.

Best wishes,

Colin.

Re: About exporting

[Detlef Steuer]

Am Tue, 30 Mar 2021 09:01:33 +0100
schrieb Colin Baxter <m43cap@yandex.com>:

> Very true. Unfortunately, you also have to "go with the flow" with the
> publishers who insist on receiving a docx file. Thankfully there's
> pandoc, but it's an annoying waste of time having to convert from
> LaTeX to some dreadful docx.

Yeah.

Btw. I had do deliver rtf recently. Is there any documented way to generate
rtf from org? A quick search did not turn up an ox-rtf or similar. Does any
of you have experience with generating rtf?

Detlef

Re: About exporting

[Eric S Fraga]

On Tuesday, 30 Mar 2021 at 09:01, Colin Baxter wrote:
> Very true. Unfortunately, you also have to "go with the flow" with the
> publishers who insist on receiving a docx file. 

I'm lucky in that the vast majority of the journals I deal with accept
(and prefer) LaTeX.

> Thankfully there's pandoc, but it's an annoying waste of time having
> to convert from LaTeX to some dreadful docx.

Yes.  I have had to do this a few times.  Pandoc is very useful although
even org's ODT export has often been good enough with some followup
editing in LibreOffice.  But I hate having to do anything in a word
processor...

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: About exporting

[Eric S Fraga]

On Tuesday, 30 Mar 2021 at 10:13, Detlef Steuer wrote:
> Btw. I had do deliver rtf recently. Is there any documented way to generate
> rtf from org? 

Two routes that I know of:
1. org -> LaTeX -> rtf using latex2rtf
2. org -> odt -> rtf by saving as that format in LibreOffice.
Pandoc may have similar, of course.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: About exporting

[Juan Manuel Macías]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Tuesday, 30 Mar 2021 at 09:06, Tim Cross wrote:
>> The trick with Latex is to go with the flow, not against it. 
>
> +1
>
> This is the first thing I tell my students.  LaTeX knows much much more
> about how to make documents look good than any of us ever will.

If you don't know anything about typography, perhaps it is preferable to
let LaTeX do its work. With the standard classes (or non-standard ones,
like Koma) and a few packages the result it will always be better than
in a Word-style word processor. For example, TeX justifies paragraphs in
a very more intelligent way, understanding the paragraph as a whole, and
not line by line, as word processors do. In fact, the Plass-Knuth
algorithm (see:
http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf) from TeX was
implemented by Adobe for its layout software InDesign. pdfTeX
implemented, in addition, micro-typographic features (protrusion and
expansion), based on the theories of the great German typographer
Hermann Zapf (author of typefaces such as Palatino and Optima and friend
of Donald Knuth). Those properties were picked up by LuaTeX, which in
turn picked up the legacy of a TeX experimental variant (that I
used quite a bit in the early 2000), Omega, later Aleph.

So, yes, you can get very high-quality documents using LaTeX. And there
is also ConTeXt, another TeX format with a radically different
conception compared to LaTeX, more monolithic and, in certain aspects,
more avant-garde. But that does not mean that LaTeX, used as is, produce
a typographically finished result. LaTeX is the means, not the end. Of
course, through packages we can adjust many things at a high level. An
obvious example is the geometry package, but to establish good page
dimensions you have to know what you are doing... But other things can
only be adjusted by hand, visually, unless someday some AI comes to do
that job ;-)

A very typical example: the \raggedbottom option is almost never
acceptable in a book. The \flushbottom option requires that the height
of the composition box is a multiple of the line spacing. TeX also does
very good work with the vertical stretch gaps (glues), but we also want
to modify them depending on the chosen font, the main text body, etc.
And a penalty of widow and orphan lines will also be desirable. There
are many ways to do it (including packages), but the simplest is to add
a couple of TeX primitives to the preamble, with these values:

\widowpenalty=10000
\clubpenalty=10000

But if we have penalized widows or orphans we will get pages that have
one line less, *unacceptable* in a book. That we will have to fix
manually, probably adding a line to the paragraph (\looseness=1), but it
will depend on the context. If we use LuaTeX we can apply things like
the ones discussed in this thread:
https://tex.stackexchange.com/questions/372062/paragraph-callback-to-help-with-widows-orphans-hand-tuning

There are, in short, many things in a 'standard' LaTeX document that
require fine adjustment. Packages like lua-typo or impnattypo are
helpful in this regard. But some typography skills are required. Of
course, this knowledge is accessible to everyone. There are so many
bibliography, but I would highly recommend the writings of Stanley
Morison, author of the Times Roman and a great theorist of the modern
typography. Of course, as for TeX, the TeX Book is always an almost
obligatory (and exciting) read :-)

Best regards,

Juan Manuel 

Re: About exporting

[Joost Kremers]

On Tue, Mar 30 2021, Eric S Fraga wrote:
> On Tuesday, 30 Mar 2021 at 10:13, Detlef Steuer wrote:
>> Btw. I had do deliver rtf recently. Is there any documented way to generate
>> rtf from org? 
>
> Two routes that I know of:
> 1. org -> LaTeX -> rtf using latex2rtf
> 2. org -> odt -> rtf by saving as that format in LibreOffice.
> Pandoc may have similar, of course.

Yes, Pandoc can write rtf files. Since it can also read Org files, you may be
able to use it to go from Org to rtf directly.

-- 
Joost Kremers
Life has its moments

Re: About exporting

[Martin Steffen]

Hi, here's my angle (which works for myself) how I use org-exporting in
connection with doing documents (I use in the meantime also org to
export as input for jekyll to produce HTML, but that's a different use,
the heavy lifting there is done in jekyll).


I am a LaTeX user since quite some time (also a bit TeX and texinfo)
ever since students. For LaTeX, I consider myself close to carrying a
black belt, maybe brown :-), for TeX and texi it's more dabbling (actually
for texinfo, I in the meantime use org and export to texinfo)

My (academic) environment and my field encourages use of LaTeX, that or
at least tolerates it; there are colleagues not to mention the
administration, who never would consider touching something
"unprofessional" like LaTeX, not mention org....


Evern since I picked up org, I use org also to produce LaTeX. Often
diferent versions of Latex-src from the same org file. Sometimes LaTeX +
HTML side by side, sometimes ODT.

For ODT, it's often that someone forces me to ``it must be doc-file''
(or docx), because for some document and "doc-file" is synonymous.


The more the use-case for the document is proper typesetting /and
nothing else/, so the focus is on one single typeset output, the more I
simply work in LaTeX only. I have the feelinga it's faster, and the
fancy stuff (macros, enviorinments, styles, classes), I rely on LaTeX's
facilities anyway, even if I use org as pre-stage.

If I have a multi-purpose use-case, I often use org, or actually, it's a
mixure. Still the fancy stuff (typesetting specification, macros,
environments....) is done in latex. By multi-purpose, I for instance
mean I do for some courses. The slides are in LaTeX, which means, beamer
mode,and org supports that reasonably. A different version of the
"slides" contains more text (sentences, expanations, etc). So I export a
different version (different export tags).

Still some portions of the overall document are native LaTeX. those are
typically included (not ``inlined''), often formulas and math
definitions, one reason being that editing LaTeX is faster in that case
than editing that in org.

And a third version could be HTML for webpages etc.  Of course one can
have conditional text in LaTeX as well, but org is quite good in that as
well. One can export latex to html, but generating it from org is
better.


There is one case where I do _NOT_ use org for such documents (though I
use org basically most things I do), and that is

     collaborative editing,

working together on a document (maybe shared by git), at least with a
document of some amount of complexity and typesetting requirement.

Even if I know that some colleagues use org (very few only, though), I
have the distinct feeling it gives too much headaches. Org would work
fine, being text, so revisioning is easy.

However, it's TOO flexible. I do quite complex documents with org
(exporting to latex), but I am not sure how sure to make it reliably
work when working together with one or more persons, and how much
``debugging'' and headache it would take.  I for instance like to test
out new packages, have the newest org. For LaTeX, that seems mostly
unproblematic, for org, not sure.

And then comes the personal habits: One great thing is that org is
flexible and one can make use of useful ``workflows'' or conventions
that profitable for oneself, and one gets used to it, one can adapt, and
then I have extra packages and adaptations. I can handle that (because I
adapt that myself), but it may conflict with other people's fiddlings.

Of course, in latex you can fiddle endlessly as well; even if one has
agreed on common macros and class files and conventios, one can easily
mess it up (typically for novices, who start changing layout or
typesetting, injecting manual spacing etc). But in LaTeX it seems more
under control, the purpose is to provide uniform typesetting of text
documents, it allows you to imposes "discipline" on the format (if you
are willing to stick to the agreed style files etc) Org, on the other
hand, is not about "uniform, classy output", it's not about
"discipline", it offers freedom and encourages playing around with, and
people who like to work with org _like_ to play around with it and to
stuff with it that others did not though of.

That's why I have not dared to write challenging (latex) documents with
org collaboratively (complex documents alone, yes, simple documents
jointly, but not all....)
[
Martin














>>>>> "Ypo" == Ypo  <ypuntot@gmail.com> writes:

    Ypo> Hi

    Ypo> After some years of using orgmode, and exporting using its
    Ypo> defaults, I would like to take a quality leap and find a way of
    Ypo> exporting for life. My options: LaTeX, ODT, HTML.

    Ypo> LaTeX: I can see some masters here that make professional
    Ypo> books, and I have some friends that publish scientific papers
    Ypo> using LaTeX. But, it looks like a like a rabbit hole to me,
    Ypo> since even the masters seem to have to modify the tex file
    Ypo> directly (is this correct?), not being sufficient orgmode to
    Ypo> culminate the work by itself. And to learn LaTeX seems a
    Ypo> lifelong activity (almost like "learning" orgmode). BTW, when I
    Ypo> export to LaTeX although it gets the job done, it sends a lot
    Ypo> of error messages.

    Ypo> ODT: I take this one as a lower level solution than LaTeX, but
    Ypo> it looks easier to tame, and it even allows to use templates,
    Ypo> for example to make reports in the workplace. Do you think it
    Ypo> is worth focusing on ODT exporting? Could it be a definitive
    Ypo> solution to publish papers and books directly from orgmode? ODT
    Ypo> exporting sends some error message to me, but at least I
    Ypo> understand it.

    Ypo> HTML: I have seen some themes designed to export in LaTeX
    Ypo> format using HTML. Here we would have the "definitive tool":
    Ypo> The power of LaTeX in the versatility that could give the use
    Ypo> of different themes for different purposes. But, do you think
    Ypo> it could get, some day, the quality of a direct LaTeX export?
    Ypo> No errors by my side when exporting to HTML.

    Ypo> How do you think I should spend some hundreds (or thousands) of
    Ypo> hours to achieve maestry exporting my documents?

    Ypo> Best regards.

Re: About exporting

[autofrettage]

Hi,

Just a remark about what Martin Steffen wrote:

> There is one case where I do NOT use org for such documents (though I
> use org basically most things I do), and that is
>
> collaborative editing,
>
> /.../ one can easily
> mess it up (typically for novices, who start changing layout or
> typesetting, injecting manual spacing etc).
> /.../
> That's why I have not dared to write challenging (latex) documents with
> org collaboratively (complex documents alone, yes, simple documents
> jointly, but not all....)

Not even the most streamlined DTP-wysiwyg-program is safe from this.
Far from. I even doubt typewritten documents can be written colla-
boratively, without someone messing things up.

There should be something like pilot licences for using certain
computer tools, not to speak about programming, but let's not sink
into squabbles about that...

cheers
Rasmus

Re: About exporting

[Martin Steffen]

>>>>> "autofrettage" == autofrettage  <autofrettage@protonmail.ch> writes:

    autofrettage> Hi,


    autofrettage> Not even the most streamlined DTP-wysiwyg-program is

I agree. I did not want to imply that. 
    autofrettage> safe from this.  Far from. I even doubt typewritten
    autofrettage> documents can be written colla- boratively, without
    autofrettage> someone messing things up.

Also that is common (I wrote many publications collaboratively with
latex. One can mess up at every level (from the line where a revision
merge conflict occurs, to latex incompatibilities (though that's not a
big problem resp. one can get that under control) up to notational,
linguistic or ``semantic'' incompatibilities (section 4 contradicts
content-wise what has been written is section 3). None of that can (or
should) be prevented by any form of tool. it depends on communicating
with each other, using one's brain, and a few other qualities.


As far as LaTeX vs. org is concerned (for producing readable documents
in varying degree of requirements as far as the complexity of document
is concerned and the typesetting quality), in my experience it's as
follows: of course everything that can be done by latex can be done with
org (trivially). As far as collaboration is concerned, if you get more
experienced with latex (and learn from mistakes and get better making
use of it), you will somehow rely on provided classed and other things
offered (and making good use of macros etc), and not messing it up,
knowing better than latex how it should looks like. That may including
writing class files yourself or style files (and sharing them with your
collaborators), but with experience you get more "disciplined" (if you
are willing to follow that discipline).


Though one can do the same in org (to disipline oneself to avoid messing
up collaboratively working on a shared document), I simply think it's
harder.

Both latex and org gives you freedom whatever you do (and you can use it
to mess it up; and as you send, also in a restrictive DTP or a harsh
straightjacket of producing "text" by filling out many small web-forms,
each free-form text at most 200 characters, like in a web-questionnaire,
you still can mess it up).

I enjoy the freedom that editing latex (and the support given by emacs)
for the same reason I enjoy the freedom of org (and the support given
many org-packages).


The difference is, in latex I don't want to explore the freedom I have
(like messing up things that styles prepared from me, or write
{\Large\textbf{Chapter 1: \hspace{4mm} Introduction}} instead of using
the command \chapter{Introduction}. And this experience of NOT using
parts of the freedom is shared with between experienced latex users
(especially those that collaborate in a good way with latex together on
shared documents) In org, getting experienced with org for me leads me
doing more and more creative things.  I have one or two colleagues, they
do completely different things than me or do it completely differntly,
and that's fine. But it's not a basis for using org for collaboratively
writing books. Of course it's doable, but requires more
(self-)discipline. I have also seen people I collaborate with that do in
LaTeX things like {\Large\textbf{Chapter 1: \hspace{4mm} Introduction}},
though this are either beginners (if they stick to this for them
established use of how to write LaTeX, makes a text-based collaboration
not useful for me.... On can still talk things through etc but not write
a common text :-))

In my experience, ith latex, it's possible to write text together for
well-intended people. Publishing houses tell you ``these are the classes
and style files (among perhaps others) that you _have_ to use, and also
do the following...''  (same possible for wisiwyg-editors, I assume),
and if you don't mess that up (like overwriting the defaults) you have a
chance to get a uniformely looking output (and on a halfway portable
platform, like a CTAN compatible latex installation). I cannot imagine
that publishers would prescibe ``this is the org-settings and features
you as author must to use to publish with us''.

Org (for the discussed usecase of exporting documents) is just a way to
produce LaTeX, latex takes care of portability and can assist with
uniformity and quality of type setting, but org intends (many) other
(useful) things.

Martin










    autofrettage> There should be something like pilot licences for
    autofrettage> using certain computer tools, not to speak about
    autofrettage> programming, but let's not sink into squabbles about
    autofrettage> that...

    autofrettage> cheers Rasmus

Re: About exporting

[autofrettage]

Martin Steffen wrote:

> I cannot imagine
> that publishers would prescibe ``this is the org-settings and features
> you as author must to use to publish with us''.

If anyone, then the IEEE. In the late 80s, their instructions to authors included a mindboggling number of allowable DTP-program (and other) file formats, and an equally mindboggling number of physical storage alternatives.

...but I acknowledge that was over 30 years ago.

Cheers
Rasmus

Re: About exporting

[Juan Manuel Macías]

Martin Steffen <msteffen@ifi.uio.no> writes:

> In my experience, ith latex, it's possible to write text together for
> well-intended people. Publishing houses tell you ``these are the classes
> and style files (among perhaps others) that you _have_ to use, and also
> do the following...''  (same possible for wisiwyg-editors, I assume),
> and if you don't mess that up (like overwriting the defaults) you have a
> chance to get a uniformely looking output (and on a halfway portable
> platform, like a CTAN compatible latex installation). I cannot imagine
> that publishers would prescibe ``this is the org-settings and features
> you as author must to use to publish with us''.

Unfortunately today the old 'division of powers' that always worked has
been broken in many scenarios: the author writes, the typesetter
composes the book and the publisher publishes it, and neither of them
interferes in the other's work, although all three live together in the
same body. The WYSIWYG word processors have had a lot to do with
distracting the author in untimely typographical concerns by imposing an
unnatural way of writing, where the format is confused with the content
and its structure. And DTP software, on the other hand, which is
intended for magazines and graphic design, have imposed a rather
negligent way of producing books.

Knuth created TeX in the '70s for his own books, because he was
disgusted with the result he was getting from an increasingly poor
publishing industry, in the transition from mechanical printing and
photocomposition to computerized editorial production. But somehow he
also reinvented the printing press of the digital age, since TeX is
first and foremost an emulator of the art and technique of ancient
linotypists, monotypists, typesetters and so on. Lamport wrote LaTeX for
his own documents, as a high-level language for TeX, since TeX only
works on the physical plane, and plainTeX was quite spartan. But time
has shown that LaTeX (and later ConTeXt) is the perfect semantic layer
of TeX. Tex and LaTeX are essentially *typographic* tools, with true
professional demands, but which authors can use on "autopilot" (a very
small part of LaTeX).

However, *I would not recommend anyone to use LaTeX for writing*. A
light markup language is more comfortable and efficient for me. Some
people prefer Markdown, but IMHO, Org Mode represents the most natural
way (aside from paper) to write. It helps me organize my ideas. And when
I write I don't worry about typographical problems at all, although I
work as a professional typesetter. Of course, with LaTeX and its
autopilot (standard classes, basic packages, no direct formatting, no
custom code, etc., etc.) you can do the same. But Org represents one
more step in confort and productivity.

Best regards,

Juan Manuel 

Re: About exporting

[Tim Cross]

Martin Steffen <msteffen@ifi.uio.no> writes:

>
> There is one case where I do _NOT_ use org for such documents (though I
> use org basically most things I do), and that is
>
>      collaborative editing,
>
> working together on a document (maybe shared by git), at least with a
> document of some amount of complexity and typesetting requirement.
>

Yes, this is still the big unresolved challenge. The sad truth is people
think editing using word and 'track changes' is a good way to do
collaborative documents. I found it was actually pretty bad once you had
more than 2 people working on the document. It really only worked well
if the collaborators worked in serial i.e. one after the other and you
had a single file which just had track changes on it.

My 'solution', which wasn't great, but which I still preferred to
fighting word and track changes, was to send out the document exported
as ascii from org, to each collaborator and told them 'just edit it,
don't worry about formatting, I'll fix that'.

I would then use diff on the returned ascii files to combine them back
into a single ascii file, convert that back to ork and then export the
final form in whatever format was required. This had a couple of
advantages and disadvantages -

Advantages were I had control over the final document. Was actually
useful to release PDFs stamped with 'draft' until agreement was reached
and then issue a single final document. It is amazing how much confusion
can exist in large organisations because multiple versions of some
document are floating around and people lose track of which was the
final version.

Other advantage was I simply didn't have to deal with word. Even doing
all the diff combining (using Emacs of course!) and re-formatting was
faster for me with org than fighting with word and trying to get a good
looking final word document which contains heaps of conflicting styles
etc. (dig into the metadata for a Word document which has been shred and
edited by multiple people and you will know what I mean!).

Disadvantages included some people just not being able to deal with
editing a plain ascii document - just too use to word processing and
found the whole process frustrating. Also, in some situations, people
hated giving up control of the document.

The other somewhat ironic disadvantage was that the organisation was use
to ugly and badly formatted word documents which had a heap of
organisation format 'policy' which you had to comply with (type of font,
font size, margins, line spacing etc. I had to 'uglify' the latex output
in order to make the documents look like other documents produced in the
organisation. This took a bit of effort, but at least once it was done,
I could re-use the setup.

Funny thing was, whenever I produced a document which was just produced 
with un-uglified Latex, I would typically get comments about what a nicely formatted
document it was. Nobody ever said that with documents which complied
with the organisation's 'policy'!

-- 
Tim Cross

Re: About exporting

[Eric S Fraga]

On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
> However, *I would not recommend anyone to use LaTeX for writing*. A
> light markup language is more comfortable and efficient for me. 

Totally agree!  Although, over the years, I have written many papers in
LaTeX directly, in the past decade I have increasingly relied on org as
the writing tool.  It imposes much less friction on the creative process
and, as you say, it enables better management of the writing task.  And,
as it gives direct access to LaTeX when necessary, you lose nothing by
writing in org.

And *tables*!  Enough said. :-)

But, as always, YMMV.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: About exporting

[Martin Steffen]

>>>>> "Eric" == Eric S Fraga <e.fraga@ucl.ac.uk> writes:

    Eric> On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
    >> However, *I would not recommend anyone to use LaTeX for
    >> writing*. A light markup language is more comfortable and
    >> efficient for me.

    Eric> Totally agree!  Although, over the years, I have written many
    Eric> papers in LaTeX directly, in the past decade I have
    Eric> increasingly relied on org as the writing tool.  It imposes
    Eric> much less friction on the creative process and, as you say, it
    Eric> enables better management of the writing task.  And, as it
    Eric> gives direct access to LaTeX when necessary, you lose nothing
    Eric> by writing in org.

I would not go so far as not recommend latex (over org) for _anyone_ at
all. I for my part will stick with latex for a certain documents; for
others, org is better (has to do with the mentioned creative process,
and other advantages).


However, I write papers heavy in  math-notation (in the more theoretical
corners of conmputer science). There is a lot of math discplay (and I
like to rely heavily on macros etc).

For me, part of the preference of latex is the ratio between math and
similar things over ``text''. a blog-like text (not heavy on math), or a
note, or a wiki-like document etc, all that's great with org.

For math-typesetting, that's less of a ``creative flow of ideas
thing''. Of course, as having been mentioned, I can always escape to
latex inline or for displays etc. And I can also import my
macro-definitions etc (and I do that).

But actually, when typing, I think I am faster in latex. There are a
couple of features, I like (and my muscle-memory of my fingers rely in
them) in latex-modes of emacs.

Tab completion for environments and macros, remembering the last
environments I used, support of bibtex (like also completion or showing
the reference). Indentention of environments plus highlighting. And last
not least; if I ``compile'' the document (firing off latex, bibtex, or
index or whatever), the compilation runs in the background. As far as I
do that in org (exporting to pdf), it blocks emacs. Not that it's a
huge  delay even, at least for smaller documents, I hate that an editor
or some tool is slower than me, it gets on my nerves if the computer
slows me down. And there is a final thing which (for me) seem to work
better in latex-mode compared to org. That's jumping to the ``next
error'' with some key stroke. That's important,  LaTeX's own error
output it quite poor, but jumping to error locations is vital.


I would not be surprised if some of that is somehow supported by org as
well (for TeX), only I have not figured it out, or perhaps I was too
lazy to figure it out how. Too lazy because LateX mode works for me fine
even for challenging and long documents (where for simpler ones or where
the focus is not on typesetting org works).

Martin






    Eric> And *tables*!  Enough said. :-)

    Eric> But, as always, YMMV.

    Eric> -- : Eric S Fraga via Emacs 28.0.50, Org
    Eric> release_9.4.4-254-g37749c

Re: About exporting

[Juan Manuel Macías]

Martin Steffen <msteffen@ifi.uio.no> writes:

> [...] And last not least; if I ``compile'' the document (firing off latex,
> bibtex, or index or whatever), the compilation runs in the background.
> As far as I do that in org (exporting to pdf), it blocks emacs. Not
> that it's a huge delay even, at least for smaller documents, I hate
> that an editor or some tool is slower than me, it gets on my nerves if
> the computer slows me down.

There is the async-export (C-a) option in org-export-dispatcher.

Anyway, I usually use the latexmk script a lot, even with Org
(combined with Org Publish: I export sub-documents to *tex from Org and
compile later with latexmk the master document. latexmk with the -pvc
options is wonderful.

I agree that AUCTeX is excellent; maybe (IMHO) the best LaTeX editor out
there.

Best regards,

Juan Manuel 

Re: About exporting

[Eric S Fraga]

On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
> And there is a final thing which (for me) seem to work better in
> latex-mode compared to org. That's jumping to the ``next error'' with
> some key stroke. That's important, LaTeX's own error output it quite
> poor, but jumping to error locations is vital.

Yes, this is an issue I have as well.  And the fact that the error
messages are for the LaTeX lines, not the org lines, so you end up
sometimes having to look at the LaTeX code and then go back to the org
file.  This definitely adds friction!

> I would not be surprised if some of that is somehow supported by org as
> well (for TeX), only I have not figured it out, or perhaps I was too
> lazy to figure it out how. 

No, I don't think there's anything (at the moment) to help with this.  I
would love to be proven wrong, mind you!  Org always has more
capabilities than I know...

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: About exporting

[Tim Cross]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
>> And there is a final thing which (for me) seem to work better in
>> latex-mode compared to org. That's jumping to the ``next error'' with
>> some key stroke. That's important, LaTeX's own error output it quite
>> poor, but jumping to error locations is vital.
>
> Yes, this is an issue I have as well.  And the fact that the error
> messages are for the LaTeX lines, not the org lines, so you end up
> sometimes having to look at the LaTeX code and then go back to the org
> file.  This definitely adds friction!
>
>> I would not be surprised if some of that is somehow supported by org as
>> well (for TeX), only I have not figured it out, or perhaps I was too
>> lazy to figure it out how. 
>
> No, I don't think there's anything (at the moment) to help with this.  I
> would love to be proven wrong, mind you!  Org always has more
> capabilities than I know...

the only small bit of help I've found is org-lint, which has helped me
find issues in the past. Doesn't help track down errors from *.tex ->
pdf etc, but often an error in the org file causes the errors in the
*.tex export.

Having said that, I find the most common cause of errors in the *.tex
export is due to in-line Latex in my org file. I rarely run into errors
due to export of 'normal' org content.

When I do run into problems, I just open the *.tex file in Auctex mode
and track it down that way. Usually, it isn't too hard to work out where
that relates back to the source org file. Being able to do that
semi-automatically would be nice, but I think something that would be
very difficult to implement. You would need something to parse the tex
error output, extract text which could be then searched for in the org
file. As mentioned, the problem is tex errors don't always contain that
information, so you would probably also have to parse the tex file and
then try to map that back to the corresponding part of the org file
(which assumes of course that it is the org data which has caused the
issue and not something relating to latex package or package
configuration).

-- 
Tim Cross

Re: About exporting

[Eric S Fraga]

On Thursday,  1 Apr 2021 at 18:00, Tim Cross wrote:
> the only small bit of help I've found is org-lint, which has helped me

org-lint is very helpful indeed.

> Having said that, I find the most common cause of errors in the *.tex
> export is due to in-line Latex in my org file. I rarely run into errors
> due to export of 'normal' org content.

yes, true for me as well.  the root cause of most of my errors are tikz
pictures... one missing semicolon or a $ in the wrong place...  The
problem is that I often have these in beamer presentations and the
errors are always at the end of the frame, not in the tikz picture.

But this is now starting to be almost OT so enough. :-)

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: About exporting

[Timothy]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
>> And there is a final thing which (for me) seem to work better in
>> latex-mode compared to org. That's jumping to the ``next error'' with
>> some key stroke. That's important, LaTeX's own error output it quite
>> poor, but jumping to error locations is vital.
>
> Yes, this is an issue I have as well.  And the fact that the error
> messages are for the LaTeX lines, not the org lines, so you end up
> sometimes having to look at the LaTeX code and then go back to the org
> file.  This definitely adds friction!

This may sound facetious, but my current approach is just to not write
LaTeX in Org files, and have only robust LaTeX I've already worked out
the kinks for loaded.  I think in part this works for me because of a
particular system I have in place (that IMHO works *wonderfully* with
Org) which I plan on submitting patches to upstream (to Org) in the
not-to-distant future.

--
Timothy

Re: About exporting

[Eric S Fraga]

On Thursday,  1 Apr 2021 at 16:50, Timothy wrote:
> I think in part this works for me because of a particular system I
> have in place (that IMHO works *wonderfully* with Org) which I plan on
> submitting patches to upstream (to Org) in the not-to-distant future.

Interesting.  Look forward to seeing this!

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: About exporting

[Timothy]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Thursday,  1 Apr 2021 at 16:50, Timothy wrote:
>> I think in part this works for me because of a particular system I
>> have in place (that IMHO works *wonderfully* with Org) which I plan on
>> submitting patches to upstream (to Org) in the not-to-distant future.
>
> Interesting.  Look forward to seeing this!

If you want to get an "sneak peek" you may be interested in taking a
quick look at:
https://tecosaur.github.io/emacs-config/config.html#content-feature-preamble

In essence this system is the combination of LaTeX snippet / generated
content with feature detection.

For example, this is what I have for working with Julia code:
#+begin_src emacs-lisp
(add-to-list 'org-latex-conditional-features '((and org-export-has-code-p "^[ \t]*#\\+begin_src julia\\|^[ \t]*#\\+BEGIN_SRC julia\\|src_julia") . julia-code) t)
(add-to-list 'org-latex-feature-implementations '(julia-code :snippet org-latex-julia-mono-fontspec :order 0) t)

(add-to-list 'org-latex-feature-implementations '(.microtype-lualatex :eager t :when (microtype julia-code) :prevents microtype :order 0.1 :snippet "\\usepackage[activate={true,nocompatibility},final,tracking=true,factor=2000]{microtype}\n"))
(add-to-list 'org-latex-feature-implementations '(.custom-font-no-mono :eager t :prevents custom-font :order 0 :snippet (org-latex-fontset :serif :sans)) t)
#+end_src

It's been evolving for a several weeks now, and I feel like it should
soon settle down enough that I will be happy preparing a patch based on
it.

--
Timothy

Re: About exporting

[Juan Manuel Macías]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
>> And there is a final thing which (for me) seem to work better in
>> latex-mode compared to org. That's jumping to the ``next error'' with
>> some key stroke. That's important, LaTeX's own error output it quite
>> poor, but jumping to error locations is vital.
>
> Yes, this is an issue I have as well.  And the fact that the error
> messages are for the LaTeX lines, not the org lines, so you end up
> sometimes having to look at the LaTeX code and then go back to the org
> file.  This definitely adds friction!

These days I'm working on a book (a dictionary) of over 1000 pages. The
preamble contains 1813 lines of code (+/-), and is written separately in
a Org document, through literary programming. Contains: a) A lot of
(La)TeX code written (or perpetrated) by me, b) some Lua functions to
control certain parts of the process, c) all the configuration for Xindy
(the indexes) in Common Lisp (inside a filecontents* environment).
Everything, of course, ordered by sections. With this cocktail it seems
that something can go wrong at some point :-) However I find it very
easy to debug having things well separated. And I can always tangle
different versions of the preamble...

As I have already mentioned, I use Org Publish intensively. Some parts
of my Org Publish setup for this project are:

[...]
:base-directory "~/Git/DHTC/libro/org/"
:base-extension "org"
; *.tex files and output
:publishing-directory "~/Git/DHTC/libro/tex/"
:publishing-function org-latex-publish-to-latex
:body-only t
:exclude "DHTC-master\\.org\\|bibli-dhtc\\.org"

Each part of the book is an *org document that I export to *tex using
Org-Publish (:body-only t). And each document only includes at the
beginning:

#+SETUPFILE: diccionario.setup
#+INCLUDE: "elisp"

(that is, a setup file and a file that I have named `elisp' where I include
functions and filters).

And then I have a master document, as simple as possible, where the
preamble and the subdocuments are added through '\input{...}'. I have
defined this macro:

#+MACRO: input (eval (if (org-export-derived-backend-p org-export-current-backend 'latex) (concat "@@latex:\\input{@@" $1 ".tex" "@@latex:}@@") $1))

And, with a simple Elisp function, I compile the final document (or
parts of it) using latexmk (with `start-process-shell-command'). I add
an argument so that a dedicated buffer is generated with the output of
latexmk. As latexmk runs in interactive mode, every time I do a change
in a subdocument and call Org-Publish again, latexmk rebuilds everything
automatically. The latexmk output is very neat and warns of possible
errors. Also I always have an alternative branch in the repository to do
tests when I put 'experimental' code.

By all this I mean that using LaTeX from Org (but without stopping using
LaTeX) gives me a pretty productive and organized workflow. I recommend
try it out for large books.

Best regards,

Juan Manuel 

Re: About exporting

[Eric S Fraga]

Looks interesting indeed.  You're using many more LaTeX features than I
ever do and I can see how your configuration would be useful in those
cases.  More examples will help in understanding when it will be useful.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c