From: Ypo <ypuntot@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: First steps exporting to tex
Date: Sun, 4 Apr 2021 13:04:31 +0200 [thread overview]
Message-ID: <5d1bbedb-0332-d584-c6ef-9ca0d8351003@gmail.com> (raw)
In-Reply-To: <86im538yip.fsf@login.ifi.uio.no>
[-- Attachment #1: Type: text/plain, Size: 8063 bytes --]
>>>>>>> El 03/04/2021 a las 18:00, emacs-orgmode-request@gnu.org escribió:
> Message: 34
> Date: Sun, 04 Apr 2021 00:31:24 +1100
> To:emacs-orgmode@gnu.org
> Subject: Re: First steps exporting to tex
> Message-ID:<871rbr7ag1.fsf@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
>
> Why do you think you need any of this for your 'first steps'. Start by
> just writing your org file and exporting it to LaTeX or pdf. Then, once
> you have your first document, see what you think needs changing and come
> back and ask advice on what you need to do to make the changes you want.
> In your first document, don't use any LaTeX commands, header options or
> anything else - just write your document using standard org mode.
>
> Org already sets up a reasonable starting default. Once you know what
> the default is, then we can discuss what you may need to change. For
> many documents, you may not need to change much at all and you may not
> need any templates - for example, you will likely want to change the
> margin sizes (this is a common request) or you may want to see what some
> of the other 'standard' LaTeX document classes are like. All of this can
> be achieved with just minor configuration of org mode.
>
> The org export to LaTeX only needs to be as complicated as you need it
> to be. Org has variables which can be used to add/remove things from the
> preamble and once you have those configured, you don't have to put
> anything in the org file itself. Start simple and add as you find a need
> rather than try to start with something complex which might not be
> necessary.
>
> -- Tim Cross
Hi Tim
I have been exporting from orgmode to PDF time ago, but very basic PDFs,
playing with some basic options of orgmode. When I tried to produce a
meeting minute with a logo in the heading, I decided that I should learn
better a way of exporting, because the minute meeting was a first
challenge, but many more would come. For example, for that task I
started with this code, which I think it goes far beyond what the "LaTeX
Defaults" can offer (I must yet "play around" a lot with it):
#+BEGIN_SRC
#+options: toc:nil
#+options: num:1
#+options: d:nil
#+export_file_name: BORRAR
#+options: broken-links:mark
#+LaTeX_header_extra: \usepackage{fancyhdr}
#+begin_export LaTeX
\thispagestyle{fancy}
\lhead{\includegraphics[width=4cm]{//192.168.1.2/f/LOGO-IMAGEN
CORPORATIVA/IMAGEN CORPORATIVA 2018/DEFINITIVO ANAGRAMAS/SELLO1_grueso.png}}
\rhead{Student Name: John Doe\\
Student ID: 1234\\
Course: IDB 601 (Fall 2020)}
#+end_export
#+END_SRC
The buffer I exported my meeting notes from has much more information
which is not related with meetings nor with the logo. So I foresaw 3
things:
1. A fast cluttering of the buffers with LaTeX headings would happen,
as I will learn more about LaTeX and I will want to add more and
more packages.
2. A need for flexibility to be able to export different kinds of
documents from the same buffer, ideally achieved just by changing a
line (or few lines) in the buffer. Although, from my example, it
seems that ~#+begin_export...~ contents can't be added in that way.
3. A great potential if it were possible to use already existing, and
well curated, LaTeX templates frictionless through orgmode.
I find quite useful to analyse the default generated TeX file though.
Best regards
>>>>>>> El 03/04/2021 a las 12:15, Martin Steffen escribió:
Good morning, Martin
> For the "preamble" of a latex document, the general setup that comes
> _before_ \begin{document} and before any output is generated, I use
> native latex using instructions like
>
> #+BEGIN_SRC
> #+latex_header: \input{switches}
> #+latex_header: \input{preamble}
> #+latex_header: \input{style/style-common}
> #+latex_header: \input{macros}
> #+END_SRC
Thanks for your input. I'll keep with that.
> As far controlling input is concerned, I also rely on latex-specific
> setting (outside org, also outside emacs), things like environment
> settings like $TEXINPUT, a path-specification, where one can control
> where LaTeX finds (additional) stylefiles, outside of the standard
> ``load-path''.
>
> Thus, I often try to avoid to use hardcoded things, like
>
> >>> \input{~//export//template.tex}
>
> I would use \input{template} (".tex" is not needed) and I make sure, the
> templatex.tex file is included in the $TEXINPUTS-path. Typically, the
> current directory "./" should be included by default (and stuff from
> the latex-installation is also routinely found)
Thanks. But I can read in this post:
https://tex.stackexchange.com/questions/93712/definition-of-the-texinputs-variable
that ~$TEXINPUT~ could give some problems with LuaLaTeX, could it be? It
seems important, since LuaLaTeX is the safe recommendation of our
mailing list pal Juan Manuel Macías [maciaschain@...].
>>>>>>> El 03/04/2021 a las 12:43, Dr. Arne Babenhauserheide escribió:
A pleasure, Arne.
> Alternatively you can use #+INCLUDE: template.org
> to grab more than just the org-setup.
And there you show me a different way: ~#+INCLUDE,~ "competing" with
~\input{}~. What would be the difference?
> Have a look at \DeclareUnicodeCharacter:
> https://www.draketo.de/light/english/emacs/char-not-setup-latex
Does that mean that some symbols must be declared one by one in order to
be exported using LaTeX?
>>>>>>> El 03/04/2021 a las 14:10, Juan Manuel Macías escribió:
Hi, Juan Manuel :-)
> The correct way is \input{~/export/template.tex}
I've already tried that. But it doesn't seem to understand the HOME
directory ~~/~. At least at Windows.
> A *.sty file is what is known in LaTeX jargon as a "package", and it
> would come to be the equivalent of what is a *.el file in Emacs,
> /mutatis mutandis/. In a sty file you can put whatever you want, but a
> different syntax must be used and these files are subject to a series of
> good practices. Therefore, a sty file is more indicated to introduce
> 'heavy' code that you want reuse in other documents (defined commands
> and macros, etc.). In short, what comes to be a package ;-) At the user
> level, and unless you want to write your own package (see:
> https://www.overleaf.com/learn/latex/Writing_your_own_package), it is
> almost never necessary.
So I will keep myself far away from .sty by now.
> Great care must be taken here. One thing is a LaTeX class, which is
> something laborious and complex to write, and another thing what Org
> understands for a LaTeX class :-) Classen and the class concept are a
> essential component for LaTeX, as a class is the first thing you must
> declare in a preamble with the command \documentclass{}. There are the
> standard classes (article, book and others) and other ones, more
> specialized. A class changes globally the behavior of the document and
> all LaTeX commands as \section, \subsection and many more, and add its
> own commands.
>
> A 'LaTeX class' for Org is a light translation of the above. It is
> actually "what type of LaTeX document you want to get".
>
> You can easily define your own LaTeX 'classes' for Org documents. For
> example: I have an 'empty class', to be able to add the entire preamble,
> without Org charging me anything before the \begin{document}
> (add-to-list 'org-latex-classes
> '("empty"
> "[NO-DEFAULT-PACKAGES]
> [PACKAGES]
> [EXTRA]"
> ("\\section{%s}" . "\\section*{%s}")
> ("\\subsection{%s}" . "\\subsection*{%s}")
> ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
> ("\\paragraph{%s}" . "\\paragraph*{%s}")
> ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
>
> And I have in my ~/.emacs:
>
> (setq org-latex-default-class "empty")
> (setq org-latex-default-packages-alist nil)
> (setq org-latex-packages-alist nil)
> (setq org-latex-hyperref-template nil)
Thanks for your class. I suppose that "nulls" the orgmode LaTeX export
defaults, so you can control it completely.
Thank you all
[-- Attachment #2: Type: text/html, Size: 12095 bytes --]
next prev parent reply other threads:[~2021-04-04 11:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-03 9:31 First steps exporting to tex Ypo
2021-04-03 10:15 ` Martin Steffen
2021-04-04 11:04 ` Ypo [this message]
2021-04-04 11:36 ` Juan Manuel Macías
2021-04-05 5:05 ` Tim Cross
2021-04-03 10:43 ` Dr. Arne Babenhauserheide
2021-04-03 12:10 ` Juan Manuel Macías
2021-04-03 13:31 ` Tim Cross
2021-04-03 16:55 ` Diego Zamboni
2021-04-03 17:07 ` William Denton
2021-04-03 17:49 ` Juan Manuel Macías
2021-04-03 18:36 ` Jean Louis
2021-04-03 20:46 ` Juan Manuel Macías
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5d1bbedb-0332-d584-c6ef-9ca0d8351003@gmail.com \
--to=ypuntot@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).