usually gives unexpected results, especially when tables
are used as float. In a float table, however, I would not use normal
footnotes via \footnotemark but the solution from the threeparttable package.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Well, next week I will continue commenting. I will try to stay up to
>> date with everything that is being discussed here. By the way, if
>> someone wants to collaborate on the branch, I can add them as a
>>
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> The latest added to the branch are Maxim's proposals (and code) for
>> backend control. See this thread:
>>
>> https://list.orgmode.org/?t=20240321102752
>>
>> And this other thread
Ihor Radchenko writes:
> Max Nikulin writes:
>
>> On 09/04/2024 15:52, Ihor Radchenko wrote:
>>> Aside: It looks like your public branch is not up-to-date as the time
>>>of writing this email - I do not see commits changing the syntax to
>>>@foo{...} and @@{...} yet,
>>
>> Do you have in
Ihor Radchenko writes:
> We may introduce \apostrophe entity.
>
> "two articles: 'my friends\apostrophe party' and 'the students\apostrophe
> papers'"
>
> "A Greek folk song says: \apostrophe{}να \apostrophe{}ρθώ το βράδυ'"
It's not a bad idea to use entities. I just discovered that an \rsquo
en
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> ━━━
>> #+OPTIONS: ':t
>> #+language:es
>>
>> "my friends' party and the students' papers"
>> ━━
word, as in Greek:
"να 'ρθώ το βράδυ"
(Org would confuse the apostrophe in the word 'ρθώ with second-level
opening quotes)
Perhaps a possible solution would be to allow the use of a specific,
customizable character, other than an apostrophe, for second-level
quotes. Or at l
Max Nikulin writes:
> I am afraid that :export will cause confusion with :exports for source
> code blocks. Its name differs by just "s" but possible values have
> nothing common.
I agree. At the moment two alternative names come to mind: :backends or
:export-rules
> Another issue is more gene
Max Nikulin writes:
> Would you mind against new thread as an umbrella for next bunch of
> topics? Current one becomes too large from my point of view.
Ok, I agree. I suggest that from now any new thread related to the new
object have as subject:
"inline-special-block: specific topic to discuss
Max Nikulin writes:
> An update with a couple of bugs fixed. Now it is possible to specify
> different export rules for a backend and all its derivatives:
I have implemented your code in the last commit. I think it is a great
improvement, thanks a lot.
As I mentioned in a past email, these days
(?* 'content)
> (?/ nil)
> (_ 'full
I've been testing your code and it works very well. It is certainly
finer than the current approach. I think it could be implemented, and we
are testing that.
Tomorrow I will make a new commit with your code.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Thank you for your comments.
Max Nikulin writes:
> On 15/03/2024 09:19, Juan Manuel Macías wrote:
>> The attribute supports one or more elements separated by a space. Each
>> element can be any of the following signs: "*" (export only the
>> content), "-&qu
To summarize the latest improvements and modifications to the `:export'
attribute...
The attribute supports one or more elements separated by a space. Each
element can be any of the following signs: "*" (export only the
content), "-" (do not export), "=" (export the rest normally), "=*"
(export th
Juan Manuel Macías writes:
> It was necessary with the previous implementation, which excessively
> abused regexp. Not now (I want to do a few more tests and I'll make a
> new commit with the changes). With the new implementation, now:
>
> - do not export
>
>
changes). With the new implementation, now:
- do not export
* export only the content
= rest (full)
=* rest (contents only)
backend- do not export this backend (and the backends derived from it)
backend+ (or, perhaps, just "backend") export this backend (idem)
backend* export
nt
- "==" :: rest (full)
- "=*" :: rest (only the content)
- "!backend-name+ :: export this backend (full)
- "!backend-name*" :: export this backend (only the content)
- "!backend-name- :: do not export this backend
?
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ds
@foo[:export latex rest*]{lorem ipsum dolor}
==> the opposite of the above.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
se a macro.
>> :export "latex+ html+ rest*"
>
> "rest" might be a valid backend name.
I will try to implement the "rest" option.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Max Nikulin writes:
> On 10/03/2024 09:08, Juan Manuel Macías wrote:
>> I'm thinking about adding a new global attribute, `:export', that
>> would granularly control whether or not to export the object and how to
>> export it.
>
> I have a bit differ
https://i.ibb.co/CBRnfXG/pantallazo-79248380551244229p8.png
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Juan Manuel Macías writes:
> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.
>
> Possible values: "noexport", "contents" (it would export only the
I'm thinking about adding a new global attribute, `:export', that
would granularly control whether or not to export the object and how to
export it.
Possible values: "noexport", "contents" (it would export only the content)
or the backends to which you want to export, separated by spaces. Each
bac
Juan Manuel Macías writes:
> Max Nikulin writes:
>
>> However it is still gives
>>
>> (org-export-string-as "Alpha@Beta["
>> 'html
>> '(:export-options (body-only)))
>> Debugger entered--Lisp error: (wr
he problem is the contents-begin variable. When it is nil it
produces that error. I will make a new commit to fix the bug.
Thanks for all the tests you're doing!
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Juan Manuel Macías escribió:
> Ok, I think you and Maxim are right. This is a clear bug. I hope it
> was fixed in the last commit.
Now:
(org-export-string-as "Alpha@Beta{" 'latex t))
==> Alpha@Beta\{
(org-export-string-as "Alpha@Beta{gamma}" 'la
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> Debugger entered--Lisp error: (wrong-type-argument
>>> number-or-marker-p nil)
>>
>> Maybe in that case you could add a zero width space character.
>>
>> In any case, if someone has reas
ot;Alpha_Beta":
(org-export-string-as "Alpha_beta"
'html
'(:export-options (body-only)))
Alphabeta
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Juan Manuel Macías writes:
> Ihor Radchenko escribió:
>
>> I am wondering if @@[...]{...} would be better than @_...
>> It should be slightly easier to type.
>
> Another possibility would be @:[...]{...}, which is somewhat shorter.
>
> (I don't have any speci
ort snippet).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
the point when Org mode is used as standard
> documentation format.)
I have modified the syntax in the last commit. Now:
@type[...]{...} (or @_[...]{...})
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> (org-export-string-as "Alpha&Beta{"
>> ...
>> mmm, right. And there may also be a problem with the subscripts:
>> &_{subscript}...
>>
>> Perhaps we should think about a st
quot;
mmm, right. And there may also be a problem with the subscripts:
&_{subscript}...
Perhaps we should think about a structure less prone to ambiguities. For
example:
&:type[attrs]{text} / &:_[attrs]{text}
(I think someone had suggested something like this in a past message,
but
the content (in LaTeX, HTML and odt). You can try:
&_{/lorem/}&_{*ipsum*}&_{_dolor_}
==> LaTeX: \emph{lorem}\textbf{ipsum}\uline{dolor}
==> HTML loremipsumdolor
==> ODT loremipsumdolor
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
t;b" :html-tag "b")("i" :html-tag "i"))
&b{intra}&i{word}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ey simply
want a text to be exported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).
I think an option could be added to disable global attributes or specify
which backend they should be used on. Anywa
there are the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination
porters and the output format. So, how about
something like:
- Custom Export Fragment
- Custom Export Span
- Custom Export "Whatever"
- ...
?
(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdow
teractive)
│ (add-hook 'after-save-hook #'org-latex-export-to-latex nil t))
│ (remove-hook 'after-save-hook #'org-latex-export-to-latex t)
│ (when (equal (process-status "latexmk") 'run)
│ (kill-process "latexmk"
└
And a screencast:
<https://cloud.disroot.org/s/ztFfa27kdsnNkGc>
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Max Nikulin writes:
> In Org syntax, "elements" are paragraphs and larger parts, while parts
> within paragraphs are named objects. I admit that for org-element
> everything is element.
In my initial message I used 'element' loosely. Note that
inline-special-block is included in org-element-all-o
om inline markup.
Custom span?
I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
eplace commands).
I think you're right. I have removed the need for "!" in the last
commit.
Now the syntax is:
&alias{text}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
#x27;s famous quote: \foreignlanguage{latin}{\textit{Alea iacta est}}
│
│ Caesar's famous quote:
{\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
└
== HTML:
┌
│ Caesar's famous quote: Alea iacta est
│
│ Caesar's famous quote: Alea iacta est
└
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
spite they may be exported to the same command.
>
>> In any case, I think that my implementation leaves open the possibility
>> of extending it with everything you mentioned, or anything else.
>
> The question is proper balance of built-in features, flexibility,
>
prelatex:
&_[:prelatex \foo\bar\vaz\blah{}]{text}
==> {\foo\bar\vaz\blah{}text}
I'm not opposed to your ideas, I just can't find a use case for it. In
LaTeX, I mean. In the case of HTML I find it useful, indeed, to have
more control over the tags: , , etc.
In any case, I think th
Max Nikulin writes:
> #+options: custom-object(:type la :latex_element foreignlanguage
> :latex_pre "{latin}")
mmm, I see it as not very flexible and perhaps too complicated for the user.
My idea with the concept of inline-special-block is that it is like the
inline version of its older brother
Max Nikulin writes:
> Juan Manuel your ":fr{}" and similar objects is a domain-specific
> language that is quite different from a generic element proposed by
> Samuel. Do you think it makes sense to modify your inline special
> block patch to allow creation of concise DSL?
Hi, Bastien,
Bastien Guerry writes:
> Ihor Radchenko writes:
>
>> AFAIU, Juan does not have write access to savannah.
>> Should we give it? Of course, if he is willing to use savannah. Any
>> other public repo is also fine.
>
> Juan, let me know if you need access:
> https://orgmode.org/worg/org
h", "French", "Italian", "Greek", etc.?
(If I shared something in Spanish, I could translate the article in the
body of the message).
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
use I
don't have enough knowledge of odt to work on this backend, which would
be the next step.
Thanks for the info!
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
amet.
Related: https://list.orgmode.org/87ttlyloyr@posteo.net/
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
This patch is for testing purposes only, although the implementation for
LaTeX backend is perfectly usable.
The basic syntax of the new element is:
&foo{lorem ipsum dolor}
=> LaTeX: \foo{lorem ipsum dolor}
Nested elements are possible, as well as the inclusion of other elements
such as macros,
Juan Manuel Macías writes:
> Regarding the "optional parameters", there is nothing defined, although
> I think they should be adapted to each backend. A possible use that
> occurs to me:
>
> &foo[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"
Juan Manuel Macías writes:
> Syntax:
>
> &[optional parameters]{contents}
Correction:
&type[optional parameters]{contents}
Samuel Wales writes:
> for language feature, there are various options here which range from e.g.
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
>
To expand a little more... Another problem I see in your example is
nesting. In my proposal, the blocks can be nested:
ith this type of elements
inside the paragraph.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ould produce in LaTeX:
\foo[lorem]{blah blah}{ipsum}
and in HTML:
blah blah
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From 587e77feb1c4e6881d527d1fd3a6e541efb596d4 Mon Sep 17 00:00:00 2001
From: Ju
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Ihor Radchenko writes:
>>> This is a good idea, although it would be better to make this new markup
>>> element within the framework of more general inline special block we
>>> discussed in the past
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> I'm dedicating a local branch to developing this proof of concept and
>> testing it in my workflow, so far with good results. The basic idea is
>> to provide Org with multilingual features and various metho
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> We need to finalize inline special block syntax first, and then talk
>>> about special cases like inline language markup you propose.
>>
>> As I already said, in my local branch I have both elements
age-ini-only language-ini-alt)))
(format "\\foreignlanguage{%s}{%s}" lang contents)
#+end_src
Opinions, suggestions, feedback, ideas?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ms that, as an example, open-office
> exporting understands the language.
Hi, Luca. You may be interested in taking a look at this thread, where
this problem and other related issues such as fallback fonts in LaTeX
export are discussed:
https://list.orgmode.org/?t=20230830082719
Best regards,
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>>> new header arguments.
>>
>> org-create-formula-image inserts LaTeX code:
>
> `org-create-formula-image' w
epackage[AUTO]{babel}
(see 'LaTeX header and sectioning structure' in the Org Manual)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
of :imagemagick. Or you could even think of any possible
conversion process using a hypothetical :pdf-postprocess
- A branch for orf-create-formula-image
- a third branch to export to html, with org-babel-latex-htlatex.
Having three clearly differentiated branches would make the code easier
to maintain.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
ypuntot writes:
> Is it related with AUTHOR property?
> I am starting to add these properties to every book, and chapter of
> the book, that I study. I hope this doesn't lead to a suboptimal
> workflow.
>
> Doesn't this work?
>
> :PROPERTIES:
> :AUTHOR: García-Ael, Cristina and Pérez-Gar
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> neither do I, This is why I'm asking for people to tell me what they
>>> use ;-)
>>
>> The babel ini files (why hadn't I thought of th
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> Moreover, it would be nice to unify handling .png and imagemagick
>>> branches of the code.
>>
>> I agree. In any case, I still think that the coexistence of two methods
>> to convert to image
derivate = no
.
------>8
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
-latex-known-warnings regexp in the attached patch.
I think it should work fine now...
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From 742d67f2e8d4f1896d89f7543948facd65687ffe Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
ers as the European Latin (T1-encoded) Fonts, while in their
upper half (128–255) they contain letters and symbols for African
languages that use extended Latin alphabets."
etc.
But I can't find a simpler list anywhere.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Compos
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> When I try the patch with a simple file like
>>>
>>> Hello. 你好。
>>>
>>> I do not see any warnings or errors indicated.
>>
>> How weird... And don't they at least appe
Sorry, the previous patch was incomplete. The attached patch is correct.
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Rationale for the attached patch: It seems that a common problem that
> users have with exporting to LaTeX is unicode characters that cannot be
> repre
'warning' string.
Naturally, the added Org warnings do not solve the problem, but at least
they give some clues on how to properly adjust the document.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipogra
s for
maintaining the code.
The first solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
aTeX?", in the end
a LaTeX manual is made instead of Org.
I'm glad you enjoyed the jump to LuaTeX. :-)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> I am attaching a new patch with this idea incorporated. I have also
>> changed the name from full-to-pdf to standalone.
>>
>> + (process (cdr (assq :process params)))
>> + (org-pr
Juan Manuel Macías writes:
>> Ihor Radchenko writes:
>> Would it make sense to make :pdf-process work for png previews as well?
>
> It would be ideal. The expected value for org-latex-pdf-process is a
> command or a list of commands, but org-preview-latex-default-process
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> May you please explain in more detail how these new header arguments fit
>>> into other available LaTeX code block parameters? In particular, when
>>> exporting to .png/.svg/.html or when :imagemagick
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> The attached patch adds two new header args to the LaTeX block:
>>
>> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
>> locally to the block. This can be useful for evaluati
#x27;("cd %o && context %f")
\starttext
\startsection[title={Testing ConTeXt}]
Lorem ipsum dolor.
\stopsection
\stoptext
#+end_src
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From fe1
Irfan S writes:
> FYI, there is also
> [[https://github.com/fuxialexander/org-pdftools][org-pdftools]] which
> provides similar (and additional) functionality, and is on MELPA.
> Thanks for sharing your code.
Thank you very much, I didn't know that.
Best regards,
Juan Manuel
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Many times I need to "save" an annotation point in the pdf-tools
>> annotations buffer. So I defined a new link type and the function to
>> store it. The link is stored with the structure:
>>
>
Max Nikulin writes:
> On 04/02/2024 22:21, Ihor Radchenko wrote:
>>
>> Another option is to have a new set of keywords:
>> #+LATEX_AUTHOR:
>> #+HTML_AUTHOR: ...
>>
>> For multiple authors, we may introduce something like
>>
>> #+AUTHOR: John Doe
>> #+AUTHOR+: Luke Skywalker
>
> Another idea:
>
Ihor Radchenko writes:
> Hi,
>
> What do you think about an idea to modify Org mode front page
> (https://orgmode.org/), adding the most recent blog posts and
> discussions about Org mode?
>
> We might use Org-related records from Sacha's news and/or
> https://planet.emacslife.com/ as a source, sc
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Sorry if this is off topic, but something like this:
>>
>> #+AUTHOR: Fred Astaire
>> #+AUTHOR: Ginger Rogers
>>
>> is exported to LaTeX as:
>>
>> \author{Fred Astaire Ginger Rogers}
Astaire Ginger Rogers}
Shouldn't there be some separation? In LaTeX the usual thing is:
\author{Fred Astaire \and Ginger Rogers}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
truetype and opentype fonts in XeLatex and LuaLaTeX and setting
opentype properties. fontenc is for 'pre-Unicode' LaTeX font encoding. I
would say that what Pedro proposes is limited only to the output in
pdfTeX.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de dato
Ihor Radchenko writes:
> Max Nikulin writes:
>
>> On 26/01/2024 19:53, Ihor Radchenko wrote:
>>> So, I am leaning towards reverting that commit - that will allow things
>>> like
>>>
>>> #+TITLE: This is a test title[fn::This is test]
>>
>> I hope, document metadata will be generated with strippe
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> ...
>> \title{Lorem ipsum dolor\thanks{blah blah}}
>> ...
>>
>> Org does not have support for this type of notes in the #+title or
>> #+author keywords. For LaTeX you can use a macro.
>
>
Colin Baxter writes:
> >> Perhaps it is better to avoid footnotes in titles and to add some
> >> phrase to the body instead.
>
> > That is the ideal scenario. I also believe that footnotes should
> > be avoided in section headings, if possible. Or at least, have
> > another typ
numbering (symbols, letters...). The manyfoot and bigfoot packages
allow constructions of this type, with various footnote apparatus.
Best regards,
Juan Manuel
--
Juan Manuel Macías --
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> +#+begin_example
>>> +,#+latex_class_options: [greek,spanish,oneside]
>>> +,#+language: es
>>> +,#+latex_header: \PassOptionsToPackage{
Ihor Radchenko writes:
> Upon looking closer into selective removal, it turned out to be more
> tricky than I thought. I'm afraid that using \\[0pt] only in some places
> may become a bit of headache to maintain - we may accidentally break
> certain regexp replacements in `org-latex-verse-block'.
Pedro Andres Aranda Gutierrez writes:
> +#+begin_example
> +,#+latex_class_options: [greek,spanish,oneside]
> +,#+language: es
> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> +#+end_example
I think this example
Ihor Radchenko writes:
> I see your point.
> Although I am still a bit hesitant to remove
> `org-latex-line-break-safe'.
> What would be the benefit of removing it? For now, I mostly just see
> that it will make the life harder for users in Scenario B.
It's a complicated situation, because we now
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> Paragraph\\
>>> @@latex:[foo]@@
>>
>> But since in both cases it is literal LaTeX code, the correct thing
>> would be for the user to be in charge of adding the curly braces to the
>> squa
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> \begin{itemize}
>>> \item {[}bax]
>>> \item {[}aur]
>>> \end{itemize}
>>
>> Great! Simple and effective. And more surgical than pandoc's global
>> solution. But now a quest
Max Nikulin writes:
> On 18/01/2024 20:05, Ihor Radchenko wrote:
>> With the patch, I am getting the following:[...]
>> \begin{center}
>> \begin{tabular}{lr}
>> {[}foo] & 2\\[0pt]
>> {[}bar] & 3\\[0pt]
>> \end{tabular}
>> \end{center}
>
> It means that [0pt] is not necessary any more. However user
Ihor Radchenko writes:
> This turned out to be a lot easier than I thought.
> See the attached patch.
>
>>> \command
>>> [unrelated text]
>>>
>>> If there are, we may actually want to consider pandoc's approach
>>> seriously.
>>
>> In principle, any environment that takes an optional argument in a
Ihor Radchenko writes:
> If the idea with custom command does not have obvious downsides, it
> might be a better option. In the previous thread, we only considered
> redefining \\ itself - obviously a non-starter for environments that
> re-define \\ by their own, like here.
I find several drawba
1 - 100 of 831 matches
Mail list logo