* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 20:22 8% ` Juan Manuel Macías
@ 2024-01-14 12:33 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-01-14 12:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
> that is, within a paragraph. At the end of an environment like verse
> (\end{verse}) you are forced to enter vertical mode, and a new paragraph
> starts.
Is it true for any environment? Or just some?
> Therefore, I think that whether or not a verse environment ends with \\ is
> irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
> some reason that escapes me, the space after the environment is altered.
I see. Although, I am not 100% if it is something we have to deal with
in Org mode. May it be better to report this as a bug to LaTeX devs?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 18:28 5% ` Ihor Radchenko
@ 2024-01-13 20:22 8% ` Juan Manuel Macías
2024-01-14 12:33 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-13 20:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> In such scenario, we may technically violate what users ask us to do:
>>>
>>> #+begin_verse
>>> I really want newline here\\
>>> #+end_verse
>>
>> I'm not sure if users asked for that specifically.
>> ...
>> This does not:
>>
>> #+begin_verse
>> I really want newline here\\
>> #+end_verse
>
> I am not sure.
> What about
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
>
> This must not be indented.
If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
that is, within a paragraph. At the end of an environment like verse
(\end{verse}) you are forced to enter vertical mode, and a new paragraph
starts. Doing something like this, for example, adds a new paragraph
after the environment:
\documentclass{article}
\usepackage{lipsum}
\begin{document}
\begin{verse}
Lorem ipsum dolor\\
\end{verse}
\lipsum[1]
\end{document}
Even this one produces the same result:
\documentclass{article}
\usepackage{lipsum}
\begin{document}
\begin{verse}
Lorem ipsum dolor\\
\end{verse}\lipsum[1]
\end{document}
If one wants, for example, that after a verse environment there is no
vertical space or indentation, the only way to do it is by modifying, globally or
locally (with another environment) the space after the environment and
adding a \noindent to the following paragraph:
\documentclass{article}
\usepackage{lipsum}
\setlength\partopsep{-\topsep}\addtolength\partopsep{0pt}
\begin{document}
\begin{verse}
Lorem ipsum dolor\\
\end{verse}
\noindent\lipsum[1]
\end{document}
(taking into account that within the verse environment there is also a
left indentation that would also have to be modified).
Therefore, I think that whether or not a verse environment ends with \\ is
irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
some reason that escapes me, the space after the environment is altered.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 16:05 10% ` Juan Manuel Macías
@ 2024-01-13 18:28 5% ` Ihor Radchenko
2024-01-13 20:22 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-13 18:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> In such scenario, we may technically violate what users ask us to do:
>>
>> #+begin_verse
>> I really want newline here\\
>> #+end_verse
>
> I'm not sure if users asked for that specifically.
> ...
> This does not:
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
I am not sure.
What about
#+begin_verse
I really want newline here\\
#+end_verse
This must not be indented.
(Just trying to come up with valid uses of newline at the end of
LaTeX environment)
Although, the above causes Org export to fail...
\begin{verse}
This is test\\[0pt]\\[0pt]
\end{verse}
Paragraph.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-13 15:08 6% ` Ihor Radchenko
@ 2024-01-13 16:05 10% ` Juan Manuel Macías
2024-01-13 18:28 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-13 16:05 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> Can anyone think of a possible scenario where removing the '\\[0pt]' in
>> the last line would cause a problem? If not, I might send a patch in the
>> next few days. (I'm afraid that going back to abusing
>> replace-regexp-in-string. I can't think of any other more elegant
>> solution...).
>
> In such scenario, we may technically violate what users ask us to do:
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
I'm not sure if users asked for that specifically.
You want a new line when there is a new line.
This makes sense:
#+begin_verse
I really want newline here\\
blah...
#+end_verse
This does not:
#+begin_verse
I really want newline here\\
#+end_verse
For LaTeX it is the same as this:
#+begin_verse
I really want newline here
#+end_verse
But this specifically alters the expected result in LaTeX, modifying the
space after the environment:
#+begin_verse
I really want newline here\\[0pt]
#+end_verse
What is the cause? I don't know. But it happens.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
2024-01-02 23:46 11% [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
@ 2024-01-13 15:08 6% ` Ihor Radchenko
2024-01-13 16:05 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-13 15:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Can anyone think of a possible scenario where removing the '\\[0pt]' in
> the last line would cause a problem? If not, I might send a patch in the
> next few days. (I'm afraid that going back to abusing
> replace-regexp-in-string. I can't think of any other more elegant
> solution...).
In such scenario, we may technically violate what users ask us to do:
#+begin_verse
I really want newline here\\
#+end_verse
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: org-attach-git don't automatically commit changes
@ 2024-01-10 16:05 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-01-10 16:05 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> In any case, if you provide a patch, it will encourage the org
>> maintainers to join this discussion and proceed with changes.
>
> OK, this week I will try to propose a patch here, and bring it up for
> (possible) discussion. Thanks for the suggestions.
For the record, this appears to be fixed in df9b509a6.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-02 23:46 11% Juan Manuel Macías
2024-01-13 15:08 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-02 23:46 UTC (permalink / raw)
To: orgmode
Hi,
I recently discovered that if the last line of a LaTeX 'verse'
environment ends in '\\[0pt]', the space after the environment is
drastically altered. The space after a 'verse' environment (which is a
modified list environment) must be equivalent to
\partopsep+\topsep+\baselineskip. I have done the test with a document,
defining a rectangle of that height with tikz, where you can see the
difference in vertical space with and without '\\[0pt]':
https://i.imgur.com/khbboDZ.png
Naturally, this implies an issue when exporting the verse block to
LaTeX, since the presence of the '\\[0pt]' string alters the expected
result in the compiled PDF. My suggestion is that the last line of the
verse block is not exported with either the string '[0pt]' or the line
break mark '\\', since it makes no sense for that mark to be there: it
is the end of a paragraph and the very end of the environment.
Can anyone think of a possible scenario where removing the '\\[0pt]' in
the last line would cause a problem? If not, I might send a patch in the
next few days. (I'm afraid that going back to abusing
replace-regexp-in-string. I can't think of any other more elegant
solution...).
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [relevance 11%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
2023-10-26 9:14 5% ` Ihor Radchenko
@ 2024-01-02 21:43 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-02 21:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Apologies for my delay in answering all the interesting questions
you raised in this last message. November and December have been
horrible work days for me (all publishers are always in a hurry) and I
haven't been able to attend to the mailing list as I would like...
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> What about :wrap?
>>
>> I like :wrap. What's more, remembering that old thread where
>> some questions about code before/after the image were discussed,
>> what if the expected value of :wrap were a kind of template? This would
>> allow code to be placed before and/or after (not just an environment)
>> the image, always within the float environment, if it exists. Something
>> like this:
>>
>> #+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage}
>> #+CAPTION: caption
>> [[file:foo.png]]
>> ...
>> #+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{figure}{caption}
>> [[file:foo.png]]
>>
>> I don't know if it would be appropriate to explain in the Manual that
>> doing so would not be... "correct"? I don't know if there is any term in
>> programming to designate these situations which, without being bugs, are
>> functionalities not consciously sought...
>
> What about making :wrap override :float completely + obsoleting :float.
> We can allow wrap to have special values like in float:
>
> :wrap t/:wrap multicolumn/:wrap sideways
>
> With these special values, :placement will be taken into account.
+1. Great idea.
> Further, we can make templates a bit more detailed.
> Starting from similar to what you proposed in the above
>
> :wrap \begin{minipage}[b]{10pc}\small\n%{body}\n\end{minipage}
>
> to more granular control over caption, centering, comment-include,
> and image-code:
>
> %{caption} %{caption-text} %{centering} %{comment} %{comment-text}
> %{image} %{image-path}.
>
> If the :wrap text does not contain %{...} placeholder, it will be
> treated as what :float artbirary-environment does.
>
> We may even consider something like
>
> #+name: latex-template
> #+begin_src latex :export none
>
> \begin{minipage}[b]{10pc}\small
> %{body}
> \end{minipage}
> #+end_src
>
> #+attr_latex: :wrap latex-template[]
>
> As a bonus, :wrap may allow prepending/appending arbitrary code to
> headings:
>
> * Heading starting at a new page
> :PROPERTIES:
> :ATTR_LATEX: :wrap \clarpage%{default}
> :END:
I really like what you propose, both the idea and the syntax. I think
that such a versatile template system (with such a level of granularity
but with a clear syntax at the same time) would be a killer feature. It
wouldn't be bad to also extend it to the case of tables and other
backends, such as html. I also think it would solve a "classic" Org
syntax issue (in my opinion) which is the difficulty in 'nesting things'.
Well, it can be done currently (for example, the special blocks do their job
pretty well), but at the cost of increasing the verbosity of the code (I am
thinking, for example, of using the LaTeX threeparttable package through
nested special blocks...)
Best regards, and happy New Year
--
Juan Manuel Macías
^ permalink raw reply [relevance 11%]
* Re: Links & images with different attributes in the same paragraph
2023-12-16 14:44 0% ` Ihor Radchenko
@ 2023-12-19 14:39 0% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-12-19 14:39 UTC (permalink / raw)
To: emacs-orgmode
On 16/12/2023 21:44, Ihor Radchenko wrote:
> Max Nikulin writes:
>
>>> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
>>
>> Are you assuming invisible zero-width space as a way to escape literal
>> {{ or }}? I would prefer some visible characters.
>
> No, not zero-width space. Literally, {{...}}. The idea is to define
> delimiters as "[{]+" the matching number of "}". This way, we do not
> need to worry about escaping "}" inside and can get nested markup for
> free. It is more or less how Org parser works for special block:
> the opening delimiter is #+begin_whatever is matched against
> #+end_<same as opening delimiter>.
I am afraid, there is an issue if wrapped content is surrounded by
braces. An ambiguity arises for
@wrap{{{content}}}
it may be @wrap{{{ content }}}, @wrap{{ {content} }},
or @wrap{ {{content}} }. It seems, some escape character is unavoidable.
> Also, see https://list.orgmode.org/orgmode/87mtaez8do.fsf@localhost/
> with my original proposal and some discussion that followed up.
I completely forgot that you wrote about balanced parenthesis earlier.
>> Juan Manuel Macías. Re: About 'inline special blocks'
>>> Bringing that into the paragraph is
>>> unnecessarily overloading the paragraph and breaking the social contract
>>> of lightweight markup, where paragraphs should still look like
>>> paragraphs.
> I am pretty sure that I replied to that concern raised in a parallel
> thread. My idea was to allow macro replacement inside attributes:
>
> #+macro: alt #+attr_html :alt $1
> What about @wrap[<<<alt(Text)>>>]{[[/path/to/image]]}
Certainly it allows to shorten in-text arguments. Just as noweb
references, it has some disadvantages. I consider comma as macro
argument separator as a kind of a pitfall. Macro definitions, unlike
code blocks definitions for noweb references, can not be multiline
(unless defined in elisp code).
Unless something better will be proposed, I consider macro expansion
inside arguments as a viable approach. (I can not recall if it was
discussed earlier.)
^ permalink raw reply [relevance 0%]
* Re: Links & images with different attributes in the same paragraph
2023-12-16 8:06 5% ` Max Nikulin
@ 2023-12-16 14:44 0% ` Ihor Radchenko
2023-12-19 14:39 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-12-16 14:44 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin <manikulin@gmail.com> writes:
>> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
>
> Are you assuming invisible zero-width space as a way to escape literal
> {{ or }}? I would prefer some visible characters.
No, not zero-width space. Literally, {{...}}. The idea is to define
delimiters as "[{]+" the matching number of "}". This way, we do not
need to worry about escaping "}" inside and can get nested markup for
free. It is more or less how Org parser works for special block:
the opening delimiter is #+begin_whatever is matched against
#+end_<same as opening delimiter>.
Also, see https://list.orgmode.org/orgmode/87mtaez8do.fsf@localhost/
with my original proposal and some discussion that followed up.
>> What about @wrap[#+attr_html: :alt "Text"]{[[/path/to/image]]}?
>
> Leaving aside precise syntax (that perhaps should be discussed in
> another thread), it solves the issue.
>
> Do you have any idea how to address the following complain?
>
> https://list.orgmode.org/orgmode/875ykwvmz7.fsf@posteo.net
> Juan Manuel Macías. Re: About 'inline special blocks' Sun, 19 Jun 2022
> 12:47:40 +0000
>> Bringing that into the paragraph is
>> unnecessarily overloading the paragraph and breaking the social contract
>> of lightweight markup, where paragraphs should still look like
>> paragraphs.
>
> I consider it as a valid point, so I tried to take advantage of noweb
> features. I am in doubts concerning *evaluation* of expressions in
> addition to just substitutions. It allows to implement another kind of
> #+link: macro, but it gives too much power to my taste.
I am pretty sure that I replied to that concern raised in a parallel
thread. My idea was to allow macro replacement inside attributes:
#+macro: alt #+attr_html :alt $1
What about @wrap[<<<alt(Text)>>>]{[[/path/to/image]]}
Or even inline definition like
#+@macro: alt @wrap[@+attr_html :alt $1]
What about @alt[Text]{[[/path/to/image]]}
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 0%]
* Re: Links & images with different attributes in the same paragraph
@ 2023-12-16 8:06 5% ` Max Nikulin
2023-12-16 14:44 0% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-12-16 8:06 UTC (permalink / raw)
To: emacs-orgmode
On 14/12/2023 22:23, Ihor Radchenko wrote:
>
> Not necessarily. The current parser also allows balanced brackets inside
> an object.
Thanks, I forgot about it. Balancing of brackets alleviates the issue
with nested objects. I am unsure if it is still pure top-down parser,
but it does not matter.
> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
Are you assuming invisible zero-width space as a way to escape literal
{{ or }}? I would prefer some visible characters.
> As you see, my solution is conceptually similar to #+begin_quote1 idea.
It is better since balanced delimiters make adding unique suffix to
#+begin_... and #+end... unnecessary.
> What about @wrap[#+attr_html: :alt "Text"]{[[/path/to/image]]}?
Leaving aside precise syntax (that perhaps should be discussed in
another thread), it solves the issue.
Do you have any idea how to address the following complain?
https://list.orgmode.org/orgmode/875ykwvmz7.fsf@posteo.net
Juan Manuel Macías. Re: About 'inline special blocks' Sun, 19 Jun 2022
12:47:40 +0000
> Bringing that into the paragraph is
> unnecessarily overloading the paragraph and breaking the social contract
> of lightweight markup, where paragraphs should still look like
> paragraphs.
I consider it as a valid point, so I tried to take advantage of noweb
features. I am in doubts concerning *evaluation* of expressions in
addition to just substitutions. It allows to implement another kind of
#+link: macro, but it gives too much power to my taste.
^ permalink raw reply [relevance 5%]
* Re: Regression in latex export of tables?
@ 2023-11-03 2:30 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-11-03 2:30 UTC (permalink / raw)
To: emacs-orgmode
On 03/11/2023 07:58, Vikas Rawal wrote:
> Earlier version gives me this:
> \begin{center}
> \begin{tabular}{ll}
> (a,b) & open interval\\\empty
> [0,1] & closed interval\\\empty
It was changed to avoid your inconvenience:
https://list.orgmode.org/874jw2conh.fsf@posteo.net/T/#u
Juan Manuel Macías. Re: Line breaks and brackets in LaTeX export. Mon,
17 Oct 2022 18:04:34 +0000
That moment there was no hope that tabularray would support \empty out
of the box. Perhaps some stable Linux distribution still have its
version unaware of \empty.
> (defun org-export-midrule-filter-latex (row backend info)
> (replace-regexp-in-string
> "\\(<mid>\\([[:blank:]]+\\&\\)+\\)[[:blank:]]\\\\\\\\" "\\\\midrule" row))
>
> Now my \midrule becomes \midrule[0pt].
Sorry, but your have to adjust the pattern and the replacement string to
allow either optional \empty or [0pt].
I still do not see a better solution that does not require substantional
changes of the org-export framework.
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
2023-10-23 19:00 10% ` Juan Manuel Macías
@ 2023-10-26 9:14 5% ` Ihor Radchenko
2024-01-02 21:43 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-26 9:14 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> What about :wrap?
>
> I like :wrap. What's more, remembering that old thread where
> some questions about code before/after the image were discussed,
> what if the expected value of :wrap were a kind of template? This would
> allow code to be placed before and/or after (not just an environment)
> the image, always within the float environment, if it exists. Something
> like this:
>
> #+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage}
> #+CAPTION: caption
> [[file:foo.png]]
> ...
> #+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{figure}{caption}
> [[file:foo.png]]
>
> I don't know if it would be appropriate to explain in the Manual that
> doing so would not be... "correct"? I don't know if there is any term in
> programming to designate these situations which, without being bugs, are
> functionalities not consciously sought...
What about making :wrap override :float completely + obsoleting :float.
We can allow wrap to have special values like in float:
:wrap t/:wrap multicolumn/:wrap sideways
With these special values, :placement will be taken into account.
Further, we can make templates a bit more detailed.
Starting from similar to what you proposed in the above
:wrap \begin{minipage}[b]{10pc}\small\n%{body}\n\end{minipage}
to more granular control over caption, centering, comment-include,
and image-code:
%{caption} %{caption-text} %{centering} %{comment} %{comment-text}
%{image} %{image-path}.
If the :wrap text does not contain %{...} placeholder, it will be
treated as what :float artbirary-environment does.
We may even consider something like
#+name: latex-template
#+begin_src latex :export none
\begin{minipage}[b]{10pc}\small
%{body}
\end{minipage}
#+end_src
#+attr_latex: :wrap latex-template[]
As a bonus, :wrap may allow prepending/appending arbitrary code to
headings:
* Heading starting at a new page
:PROPERTIES:
:ATTR_LATEX: :wrap \clarpage%{default}
:END:
>>> ... However, :float can still be useful for
>>> certain combinations. For example, a minipage environment cannot include
>>> a caption (it produces an error of the type "LaTeX Error: \caption
>>> outside float").
>>
>> Do we know in advance which environments support \caption and which not?
>> I feel that we may handle this programmatically without creating an array
>> of almost-identical attributes.
>
> I like the idea, but unfortunately, apart from the known float
> environments, there are those that a user can define using the \newfloat
> command from the float package.
We might also consider :caption-template \captionof{figure}{%{caption-text}}
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
2023-10-23 9:27 5% ` Ihor Radchenko
@ 2023-10-23 19:00 10% ` Juan Manuel Macías
2023-10-26 9:14 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-23 19:00 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> My suggestion is to add a :environment attribute next to another
>> :environment-options attr (or something like that, to introduce any
>> arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
>> types, float or non-float.
>
> As I said above, I feel that :environment term will be overloaded then.
> What about :wrap?
I like :wrap. What's more, remembering that old thread where
some questions about code before/after the image were discussed,
what if the expected value of :wrap were a kind of template? This would
allow code to be placed before and/or after (not just an environment)
the image, always within the float environment, if it exists. Something
like this:
#+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage}
#+CAPTION: caption
[[file:foo.png]]
Thus :caption with value nil does not add any higher float environment
and would enclose (always within the template) the value of #+CAPTION as
\captionof{figure}{caption}. Of course, with a float environment
declared, :wrap can still be used. An internal environment is unlikely
(I can't think of any use case right now), but you can add arbitrary
code like \captionsetup{} or \ContinuedFloat, which should always go
inside the float environment.
The result of the previous example could also be obtained with:
#+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{figure}{caption}
[[file:foo.png]]
I don't know if it would be appropriate to explain in the Manual that
doing so would not be... "correct"? I don't know if there is any term in
programming to designate these situations which, without being bugs, are
functionalities not consciously sought...
>> ... However, :float can still be useful for
>> certain combinations. For example, a minipage environment cannot include
>> a caption (it produces an error of the type "LaTeX Error: \caption
>> outside float").
>
> Do we know in advance which environments support \caption and which not?
> I feel that we may handle this programmatically without creating an array
> of almost-identical attributes.
I like the idea, but unfortunately, apart from the known float
environments, there are those that a user can define using the \newfloat
command from the float package.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
2023-10-22 21:12 9% Are 'placement' and 'float' "obsolete terms" in inline images export Juan Manuel Macías
@ 2023-10-23 9:27 5% ` Ihor Radchenko
2023-10-23 19:00 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-23 9:27 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> So, the difference between :environment and :float is that :float also
>> encapsulates \caption in addition to the actual environment (like
>> tabularx or includegraphics) used for transcoded exported element.
>
>> I can see how :float+:placement can be imprecise and that the existing
>> :environment indeed serves a different purpose. (It might be worth
>> clarifying this distinction in the manual - it seems arbitrary from
>> the first glance).
>
>> But what would be the better name then?
>
> I think the problem is limited to images, where there is no "double"
> environment as in the case of tables (float environment that encloses an
> environment to generate the table, and :placement points to the correct
> environment).
IMHO, an equivalent of :environment for images is
\includegraphics or \includesvg.
> ... In the case of images, I am afraid that the new features
> have advanced the meaning of the old ones. Previously, :float only
> supported t/nil ("figure" by default, in case of t) along with a few
> explicit "float" environments, such as sidewaysfigure or wrapfigure.
> Since :float now can accept any string as an environment name, Pandora's
> box has been opened and the meaning of the old :float has been left
> behind: for example, we can put :float minipage, and minipage is not a
> float environment. Something similar has happened to :placement.
>
> My suggestion is to add a :environment attribute next to another
> :environment-options attr (or something like that, to introduce any
> arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
> types, float or non-float.
As I said above, I feel that :environment term will be overloaded then.
What about :wrap?
> ... However, :float can still be useful for
> certain combinations. For example, a minipage environment cannot include
> a caption (it produces an error of the type "LaTeX Error: \caption
> outside float").
Do we know in advance which environments support \caption and which not?
I feel that we may handle this programmatically without creating an array
of almost-identical attributes.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
@ 2023-10-22 21:12 9% Juan Manuel Macías
2023-10-23 9:27 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-22 21:12 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor, sorry for the late reply.
Ihor Radchenko writes:
> So, the difference between :environment and :float is that :float also
> encapsulates \caption in addition to the actual environment (like
> tabularx or includegraphics) used for transcoded exported element.
> I can see how :float+:placement can be imprecise and that the existing
> :environment indeed serves a different purpose. (It might be worth
> clarifying this distinction in the manual - it seems arbitrary from
> the first glance).
> But what would be the better name then?
I think the problem is limited to images, where there is no "double"
environment as in the case of tables (float environment that encloses an
environment to generate the table, and :placement points to the correct
environment). In the case of images, I am afraid that the new features
have advanced the meaning of the old ones. Previously, :float only
supported t/nil ("figure" by default, in case of t) along with a few
explicit "float" environments, such as sidewaysfigure or wrapfigure.
Since :float now can accept any string as an environment name, Pandora's
box has been opened and the meaning of the old :float has been left
behind: for example, we can put :float minipage, and minipage is not a
float environment. Something similar has happened to :placement.
My suggestion is to add a :environment attribute next to another
:environment-options attr (or something like that, to introduce any
arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
types, float or non-float. However, :float can still be useful for
certain combinations. For example, a minipage environment cannot include
a caption (it produces an error of the type "LaTeX Error: \caption
outside float"). Then you would have to put something like
#+ATTR_LaTeX: :float nil :environment minipage :environment-options {\linewidth}
#+CAPTION: caption
[[file:foo.png]]
==>
\begin{minipage}{\linewidth}
\includegraphics[width=.9\linewidth]{foo.png}
\captionof{figure}{caption}
\end{minipage}
Anyway, I find pros and cons of all this:
- pros: a intended feature is added, although with :float and :placement
the same thing can be achieved (sometimes), but here the effect is not
intended (in origin).
- cons: redundancy, more complexity in the code (and probably more confusion for the user?).
--
Juan Manuel Macías
^ permalink raw reply [relevance 9%]
* Re: Pandoc and nested emhases
2023-10-11 16:11 6% ` Max Nikulin
@ 2023-10-22 19:15 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-22 19:15 UTC (permalink / raw)
To: Max Nikulin; +Cc: orgmode
Sorry for the late reply. I haven't had much time these days to
keep up with the list...
Max Nikulin writes:
> It was long time ago...
>
> On 18/02/2022 07:47, Juan Manuel Macías wrote:
>> Otherwise, if you export to LaTeX with pandoc (v. 2.14.2), the result is
>> (to my surprise) correct:
>> #+begin_src sh :results latex
>> str="/lorem /ipsum/ dolor/"
>> pandoc -f org -t latex <<< $str
>> #+end_src
>> #+RESULTS:
>> #+begin_export latex
>> \emph{lorem \emph{ipsum} dolor}
>> #+end_export
>
> Nesting of the same emphasis style may be achieved with Org parser as well:
>
> (org-export-string-as
> "/lorem /ipsum// /dolor/"
> 'latex t)
> "\\emph{lorem \\emph{ipsum}} \\emph{dolor}
> "
>
> Namely closing markers should be combined. See the recent thread
> Tom Alexander to emacs-orgmode. Inconsistent text markup handling when
> double-nesting markers. Mon, 09 Oct 2023 19:02:18 -0400.
> https://list.orgmode.org/dad964f5-c764-4dd5-9829-ca38e3fbeb0d@app.fastmail.com
Interesting. So it should be understood that in Org syntax this dummy
title would be possible:
/Essays on Homer's /Odyssey//
==>
\emph{Essays on Homer's \emph{Odyssey}}
but not this other one:
/Essays on Homer's /Odyssey/. Part One/
\emph{Essays on Homer's /Odyssey}. Part One/
In any case, as Ihor commented in the thread you link, and as you also
commented in the other old thread of my discovery about Pandoc, this
behavior of Pandoc should be understood as a bug since it does not
respect the Org syntax. Although the previous example leaves me a little
perplexed.
Actually, I think nested emphases of equal category are not that
necessary. In general, putting something like \textbf{lorem
\textbf{ipsum} dolor} in LaTeX doesn't make much sense, because \textbf
is not a switch. It would only make sense with the LaTeX \emph command,
which, contrary to what some may think, is not used to put text in
italics (that's what \textit is for), but to emphasize a text according
to the context: if the context is in normal font, italics; and vice
versa. If I don't miss anything, I think there is nothing similar in
either html or odt/docx.
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: [proof of concept, tip] 'Templates with arguments' using org src blocks
2023-10-06 8:07 11% [proof of concept, tip] 'Templates with arguments' using org src blocks Juan Manuel Macías
@ 2023-10-13 16:00 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-10-13 16:00 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
On 06/10/2023 15:07, Juan Manuel Macías wrote:
> And, finally:
>
> ┌────
> │ #+header: :var table = table1
> │ #+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
> │ {{{template(tptable,table notes)}}}
> └────
Usage is quite close to "#+call:", but it does not support specifying
arguments using "#+header:"
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-org.html
I would still consider noweb (table1 is omitted):
--- 8< ---
#+property: header-args:org :exports results :results replace :noweb yes
#+NAME: tptable
#+begin_src org :exports none
,#+begin_table
,#+ATTR_LaTeX: :options [b]
,#+begin_threeparttable
$table
,#+begin_tablenotes
$notes
,#+end_tablenotes
,#+end_threeparttable
,#+end_table
#+end_src
#+header: :var table = table1
#+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
#+begin_src org
<<tptable>>
#+end_src
--- >8 ---
or "%(param)s" substitutions in python (another variant f"""{param}"""
is inconvenient for LaTeX):
--- 8< ---
#+property: header-args:python :python python3 :results org :noweb yes
:exports results
#+property: header-args:org :exports results :results replace
#+NAME: tptable
#+begin_src python :exports none
return """\
,#+begin_table
,#+ATTR_LaTeX: :options [b]
,#+begin_threeparttable
%(table)s
,#+begin_tablenotes
%(notes)s
,#+end_tablenotes
,#+end_threeparttable
,#+end_table
""" % locals()
#+end_src
#+header: :var table = table1
#+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
#+begin_src python
<<tptable>>
#+end_src
--- >8 ---
^ permalink raw reply [relevance 5%]
* Re: Pandoc and nested emhases
@ 2023-10-11 16:11 6% ` Max Nikulin
2023-10-22 19:15 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-10-11 16:11 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
It was long time ago...
On 18/02/2022 07:47, Juan Manuel Macías wrote:
> Otherwise, if you export to LaTeX with pandoc (v. 2.14.2), the result is
> (to my surprise) correct:
>
> #+begin_src sh :results latex
> str="/lorem /ipsum/ dolor/"
> pandoc -f org -t latex <<< $str
> #+end_src
>
> #+RESULTS:
> #+begin_export latex
> \emph{lorem \emph{ipsum} dolor}
> #+end_export
Nesting of the same emphasis style may be achieved with Org parser as well:
(org-export-string-as
"/lorem /ipsum// /dolor/"
'latex t)
"\\emph{lorem \\emph{ipsum}} \\emph{dolor}
"
Namely closing markers should be combined. See the recent thread
Tom Alexander to emacs-orgmode. Inconsistent text markup handling when
double-nesting markers. Mon, 09 Oct 2023 19:02:18 -0400.
https://list.orgmode.org/dad964f5-c764-4dd5-9829-ca38e3fbeb0d@app.fastmail.com
^ permalink raw reply [relevance 6%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-06 18:35 5% ` Juan Manuel Macías
@ 2023-10-06 19:49 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-10-06 19:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>>> In tables there is more consistency because :float is a float
>>> environment (table or any arbitrary value) and :environment is a table
>>> environment (tabular or any arbitrary value). Here :placement :options
>>> and :align act as what is expected of them:
>>>
>>> #+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
>>> |a|a|a|a|
>> ...
>> This is not documented and is possibly a bug.
>
> I would say that it is the expected behavior: :float is for a float
> environment and :environment is for the environment that builds the
> table (by default tabular). According to the manual:
Oops. You are indeed right. I missed that both :float and :environment
are documented for tables.
> The difference is that with images, except in cases of somewhat more
> complex constructions where there are subfigures, there is only one
> environment, "figure" by default or any other arbitrary one. There was a
> commit a while ago, I don't remember when, that allowed :float to
> support any arbitrary string as the float environment name, in images
> and tables. In images ':float t' is figure (by default) and in tables it
> is table (also by default).
So, the difference between :environment and :float is that :float also
encapsulates \caption in addition to the actual environment (like
tabularx or includegraphics) used for transcoded exported element.
I can see how :float+:placement can be imprecise and that the existing
:environment indeed serves a different purpose. (It might be worth
clarifying this distinction in the manual - it seems arbitrary from the
first glance).
But what would be the better name then?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-06 16:29 5% ` Ihor Radchenko
@ 2023-10-06 18:35 5% ` Juan Manuel Macías
2023-10-06 19:49 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-06 18:35 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> In tables there is more consistency because :float is a float
>> environment (table or any arbitrary value) and :environment is a table
>> environment (tabular or any arbitrary value). Here :placement :options
>> and :align act as what is expected of them:
>>
>> #+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
>> |a|a|a|a|
>>
>> ===>
>>
>> \begin{var}[!h]
>> \centering
>> \begin{foo}[blah]{cccc}
>> a & a & a & a\\[0pt]
>> \end{foo}
>> \end{var}
>> \end{document}
>
> This is not documented and is possibly a bug.
I would say that it is the expected behavior: :float is for a float
environment and :environment is for the environment that builds the
table (by default tabular). According to the manual:
#+begin_quote
The table environments by default are not floats in LaTeX. To make
them floating objects use =:float= with one of the following
options: =t= (for a default =table= environment), =sideways= (for a
=sidewaystable= environment), =multicolumn= [...] and
=nil=. In addition to these three values, =:float= can pass through
any arbitrary value, for example a user-defined float type with the
=float= LaTeX package
#+end_quote
and (for :environment):
#+begin_quote
Set the default LaTeX table environment for the LaTeX export
backend to use when exporting Org tables. Common LaTeX table
environments are provided by these packages: tabularx, longtable,
array, tabu, and bmatrix. For packages, such as tabularx and tabu,
or any newer replacements
#+end_quote
The difference is that with images, except in cases of somewhat more
complex constructions where there are subfigures, there is only one
environment, "figure" by default or any other arbitrary one. There was a
commit a while ago, I don't remember when, that allowed :float to
support any arbitrary string as the float environment name, in images
and tables. In images ':float t' is figure (by default) and in tables it
is table (also by default).
Update: ah, I already have the commit located, because I also remember
that I myself sent a patch to update the documentation and correct a
regression that that commit introduced (:float t produced an environment
"t" (\begin{t}...\end{t}):
https://list.orgmode.org/878ruhrvfq.fsf@posteo.net/
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-04 14:34 11% ` Juan Manuel Macías
@ 2023-10-06 16:29 5% ` Ihor Radchenko
2023-10-06 18:35 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-06 16:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> Further, we also provide :environment and :options attributes that do
>> the same thing, but without special treatment of standard
>> t/multicolumn/wrap/sideways/nil values in :float.
>
> t/multicolumn/wrap/sideways/nil... and any arbitrary value (see lines 14125
> and 14262 in org-manual.org).
My point is that actual "t", "multicolumn", "wrap", "sideways", and
"nil" LaTeX environments are not allowed.
>> So, it might be even better idea to extend :environment/:options
>> attributes to more elements - their names make more sense and the values
>> do not have a pre-defined special meanings.
>
> Currently it is not possible in inline images (if I don't miss anything) this:
>
> #+ATTR_LaTeX: :environment minipage :options {\textwidth}
> [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
Sure. But we might as well implement :environment support in addition to :float.
> Implementing :environment/:options here would result in redundancy with:
>
> #+ATTR_LaTeX: :float minipage :placement {\textwidth}
> [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
>
> which produces the same.
Sure. But didn't you motivate the change with the confusing _name_
:float? IMHO, :environment is more clear.
> In tables there is more consistency because :float is a float
> environment (table or any arbitrary value) and :environment is a table
> environment (tabular or any arbitrary value). Here :placement :options
> and :align act as what is expected of them:
>
> #+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
> |a|a|a|a|
>
> ===>
>
> \begin{var}[!h]
> \centering
> \begin{foo}[blah]{cccc}
> a & a & a & a\\[0pt]
> \end{foo}
> \end{var}
> \end{document}
This is not documented and is possibly a bug.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* [proof of concept, tip] 'Templates with arguments' using org src blocks
@ 2023-10-06 8:07 11% Juan Manuel Macías
2023-10-13 16:00 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-06 8:07 UTC (permalink / raw)
To: orgmode
Hi, this is a proof of concept of how a sort of 'templates with
arguments' can be used within Org, just with Org’s own resources at the
user level. It occurred to me that org src blocks might be handy for
this. For this test I just made a disguised format string using this
function:
┌────
│ (defun my-format-template (template vars)
│ (format
│"#+begin_src emacs-lisp :results raw :exports results :var template = %s
│ (format
│ (format \"%%s\" template)
│ %s)
│ #+end_src" template vars))
└────
and a macro:
┌────
│ #+MACRO: template (eval (my-format-template $1 $2))
└────
A simple example. We start from this template:
┌────
│ #+NAME: template1
│ #+begin_src org :exports none
│ ,*%s*
│ %s
│ #+end_src
│
│ #+header: :var hello = "Hello World"
│ #+header: :var str = "Lorem ipsum dolor"
│ {{{template(template1,hello str)}}}
└────
An example with a src block inside the template:
┌────
│ #+NAME: template2
│ #+begin_src org :exports none
│ ,#+begin_src emacs-lisp :exports results :results raw
│ (let ((name "%s"))
│ (format "/Hello, %%s/" name))
│ ,#+end_src
│ #+end_src
│
│ #+header: :var name = "World"
│ {{{template(template2,name)}}}
└────
And this example is somewhat more elaborate. We want a table in LaTeX
with the threeparttable package. Template:
┌────
│ #+NAME: tptable
│ #+begin_src org :exports none
│ ,#+begin_table
│ ,#+ATTR_LaTeX: :options [b]
│ ,#+begin_threeparttable
│ %s
│ ,#+begin_tablenotes
│ %s
│ ,#+end_tablenotes
│ ,#+end_threeparttable
│ ,#+end_table
│ #+end_src
└────
the table:
┌────
│ #+NAME: table1
│ #+begin_src org :exports none
│ ,#+ATTR_LaTeX: :center nil :booktabs t :float nil
│ ,#+caption: Lorem ipsum dolor
│ ,#+name: table1
│ |-------+--------------------------+-------|
│ | lorem | ipsum@@latex:\tnote{1}@@ | dolor |
│ | lorem | ipsum@@latex:\tnote{2}@@ | dolor |
│ |-------+--------------------------+-------|
│ #+end_src
└────
And, finally:
┌────
│ #+header: :var table = table1
│ #+header: :var notes = "\\item [1] First note\n\\item [2] Second note"
│ {{{template(tptable,table notes)}}}
└────
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-04 9:12 5% ` Ihor Radchenko
@ 2023-10-04 14:34 11% ` Juan Manuel Macías
2023-10-06 16:29 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-04 14:34 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Further, we also provide :environment and :options attributes that do
> the same thing, but without special treatment of standard
> t/multicolumn/wrap/sideways/nil values in :float.
t/multicolumn/wrap/sideways/nil... and any arbitrary value (see lines 14125
and 14262 in org-manual.org).
>>> What we might do it to introduce something like a new :wrap attribute:
>>>
>>> #+attr_latex: :wrap subfigure,{\textwidht}
>
> So, it might be even better idea to extend :environment/:options
> attributes to more elements - their names make more sense and the values
> do not have a pre-defined special meanings.
Currently it is not possible in inline images (if I don't miss anything) this:
#+ATTR_LaTeX: :environment minipage :options {\textwidth}
[[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
Implementing :environment/:options here would result in redundancy with:
#+ATTR_LaTeX: :float minipage :placement {\textwidth}
[[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
which produces the same.
In tables there is more consistency because :float is a float
environment (table or any arbitrary value) and :environment is a table
environment (tabular or any arbitrary value). Here :placement :options
and :align act as what is expected of them:
#+ATTR_LaTeX: :environment foo :float var :placement [!h] :options [blah] :align cccc
|a|a|a|a|
===>
\begin{var}[!h]
\centering
\begin{foo}[blah]{cccc}
a & a & a & a\\[0pt]
\end{foo}
\end{var}
\end{document}
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-02 14:55 9% ` Juan Manuel Macías
@ 2023-10-04 9:12 5% ` Ihor Radchenko
2023-10-04 14:34 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-04 9:12 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I am not sure about obsolete - I see not reason to obsolete the intended
>> use case. Your example is rather an abuse.
>
> Why abuse? First, it works like a charm. Second, if :float can support
> any string as an environment name, why not minipage or subfigure? As for
> :placement, the term would seem more precise to me if it were really
> "placement" (as :align in tables is actually "align"), not LaTeX code
> passed directly after the \begin{...}. That a user can put things like
> this (I do it often, and I think I'm not the only one):
>
> :placement [htbp]\SomeExtraLaTeXCode...
>
> it is a consequence of the above. It is not an "orthodox" use (I mean,
> it's not described in the manual), but it works without problems. Again,
> I don't want to seem too picky about the names, but a user who doesn't
> understand the source code might think that :placement only supports
> things like [htbp]. My idea here is: instead of implementing new
> features, recycle and take advantage of those that arise unexpectedly
> :-). Although :placement was created thinking about putting code related
> to placement figures, as it is implemented I would have called it
> :latex-code or something similar.
:float is only used for (1) tables; (2) src-blocks; (3) inline images
that are a sole element in their paragraph. But not for other Org syntax
elements - you cannot, for example, wrap a paragraph or heading into
custom environment with :float.
Further, we also provide :environment and :options attributes that do
the same thing, but without special treatment of standard
t/multicolumn/wrap/sideways/nil values in :float.
>> What we might do it to introduce something like a new :wrap attribute:
>>
>> #+attr_latex: :wrap subfigure,{\textwidht}
So, it might be even better idea to extend :environment/:options
attributes to more elements - their names make more sense and the values
do not have a pre-defined special meanings.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-02 13:10 5% ` Ihor Radchenko
@ 2023-10-02 14:55 9% ` Juan Manuel Macías
2023-10-04 9:12 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-10-02 14:55 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> ┌────
>> │ #+caption: Main caption
>> │ #+begin_figure
>> │ #+CAPTION: subcaption 1
>> │ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width \textwidth
>> │ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
>> ...
>> I think this is a case where certain elements of Org have evolved
>> (consciously or unconsciously) ahead of the names, and these names have
>> become somewhat outdated. There is not only the case of :placement. Even
>> :float seems imprecise, since can be used to create a minipage, and the
>> minipage environment is not a float environment. Would it be worth
>> making those names obsolete (with backward compatibility, of course) and
>> replacing them with slightly more precise ones? I think that new names
>> would give the user an idea of more variety of uses, like the examples I
>> have put here.
>
> I am not sure about obsolete - I see not reason to obsolete the intended
> use case. Your example is rather an abuse.
Why abuse? First, it works like a charm. Second, if :float can support
any string as an environment name, why not minipage or subfigure? As for
:placement, the term would seem more precise to me if it were really
"placement" (as :align in tables is actually "align"), not LaTeX code
passed directly after the \begin{...}. That a user can put things like
this (I do it often, and I think I'm not the only one):
:placement [htbp]\SomeExtraLaTeXCode...
it is a consequence of the above. It is not an "orthodox" use (I mean,
it's not described in the manual), but it works without problems. Again,
I don't want to seem too picky about the names, but a user who doesn't
understand the source code might think that :placement only supports
things like [htbp]. My idea here is: instead of implementing new
features, recycle and take advantage of those that arise unexpectedly
:-). Although :placement was created thinking about putting code related
to placement figures, as it is implemented I would have called it
:latex-code or something similar.
> What we might do it to introduce something like a new :wrap attribute:
>
> #+attr_latex: :wrap subfigure,{\textwidht}
That would be nice if with a single latex_attr line you could export a
single figure environment for several images, since every subfigure
environment must be inside a figure environment. And putting a single
subfigure inside a figure environment doesn't make much sense. Other
than that, the idea of :wrap is good. I find it very useful, especially
on tables.
> I think we have discussed something similar in the past, but more
> generic - allow wrapping arbitrary Org elements (headings, drawers,
> paragraphs, etc) on export.
I remember that thread. In fact, I think I created a TODO to study that,
but due to lack of time I haven't been able to take a look at it.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-01 15:08 7% Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? Juan Manuel Macías
2023-10-01 18:07 12% ` Juan Manuel Macías
@ 2023-10-02 13:10 5% ` Ihor Radchenko
2023-10-02 14:55 9% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-10-02 13:10 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> An example of more "unexpected" (but very practical) uses is this one
> with three subfigures and the subcaption package:
>
> ┌────
> │ #+caption: Main caption
> │ #+begin_figure
> │ #+CAPTION: subcaption 1
> │ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width \textwidth
> │ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
> ...
> I think this is a case where certain elements of Org have evolved
> (consciously or unconsciously) ahead of the names, and these names have
> become somewhat outdated. There is not only the case of :placement. Even
> :float seems imprecise, since can be used to create a minipage, and the
> minipage environment is not a float environment. Would it be worth
> making those names obsolete (with backward compatibility, of course) and
> replacing them with slightly more precise ones? I think that new names
> would give the user an idea of more variety of uses, like the examples I
> have put here.
I am not sure about obsolete - I see not reason to obsolete the intended
use case. Your example is rather an abuse.
What we might do it to introduce something like a new :wrap attribute:
#+attr_latex: :wrap subfigure,{\textwidht}
I think we have discussed something similar in the past, but more
generic - allow wrapping arbitrary Org elements (headings, drawers,
paragraphs, etc) on export.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-26 19:12 9% ` Juan Manuel Macías
2023-09-28 10:07 4% ` Max Nikulin
@ 2023-10-02 10:42 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2023-10-02 10:42 UTC (permalink / raw)
To: emacs-orgmode
On 27/09/2023 02:12, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> I just have checked that a dirty hack with a few lines of code for
>> `org-export-filter-final-output-functions' allows to insert arbitrary
>> text to the beginning of export result. Perhaps a more elegant solution
>> exists, but I admit it is not a straightforward way. At least it is
>> possible.
>
> And it is also possible by simply defining a new class (in Org
> terminology, not LaTeX). My usual class is an almost empty one, without
> documentclass and without packages, because I don't want org to write
> the preamble for me. But I think this is not the point.
LATEX_PRE_HEADER you proposed is a document-local setting while
`org-latex-classes' is shared by all Org documents. In that hack I used
a buffer-local variable to achieve document-specific fragment.
In the specific cases of \DocumentMetadata and .xmpdata,
LATEX_PRE_HEADER needs to be passed through `format-spec' with result of
`org-latex--format-spec' call to get notion of Org metadata. Whether it
is necessary for \PassOptionsToPackage depends on particular cases. If
such options do not vary across documents then certainly
`org-latex-classes' becomes viable.
I do not like "[NO-PACKAGES]" and similar keywords to suppress adding of
some code snippets. That is why I believe it is better to seek for
another approach to generate LaTeX preamble. I have not had a look into
Timothy's code yet, so I can say nothing concerning its flexibility in
respect to substituting metadata into code before \documentclass.
^ permalink raw reply [relevance 5%]
* Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
2023-10-01 15:08 7% Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? Juan Manuel Macías
@ 2023-10-01 18:07 12% ` Juan Manuel Macías
2023-10-02 13:10 5% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-01 18:07 UTC (permalink / raw)
To: orgmode
Juan Manuel Macías writes:
> Since the header arg :float now supports any string in inline images[...]
Sorry, I meant "the LaTeX attribute :float ..."
^ permalink raw reply [relevance 12%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-10-01 17:48 11% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-01 17:48 UTC (permalink / raw)
To: AW; +Cc: emacs-orgmode
Max Nikulin writes:
> On 28/09/2023 22:36, AW wrote:
>>
>> The idea to have a LATEX_PRE_HEADER to insert `\DocumentMetadata{}` is exactly
>> what you need right now, if you export from orgmode to current LaTeX. With
>> `\DocumentMetadata{}` you can add most of the necessary xmp data -- and I
>> write most, because I'm using it on a daily basis, but haven't checked if
>> really everything is included yet.
>
> The question is if Juan Manuel can use \DocumentMetadata instead of the
> pdfx package in his workflow.
I'm afraid that with the pdfx example that I put in the first post I
have caused a little confusion. pdfx is not part of my workflow. I only
used it once a long time ago. I've cited the code from that package here
as another example of arbitrary code that can be placed before
\documentclass. As I said, there are many more examples and possible
cases: \DocumentMetadata and \PassOptionsToPackage are two typical
cases. But, as I have already mentioned, /almost/ any LaTeX code can be
accommodated before class declaration. Even simple comments. Why not
think about a hypothetical case in which a user needs to create from Org
a *.tex file that contains comments before \documentclass? With a
LaTeX_pre_header keyword that would be possible.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-28 12:31 9% ` Juan Manuel Macías
2023-09-29 2:38 5% ` Max Nikulin
@ 2023-10-01 16:32 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2023-10-01 16:32 UTC (permalink / raw)
To: emacs-orgmode
On 28/09/2023 19:31, Juan Manuel Macías wrote:
> Starting with \documentclass, the order is important in certain cases
> and not so important in others. And, anyway, you can always use a hook
> like \AtBegin... \AtEnd..., etc.
I am judging from my past experience. Besides \usepackage{cmap} that was
necessary to be put immediately after \documentclass, there were issues
with order of \usepackage for hyperref and some other packages.
Custom commands may require some attention as well. There is an example
of reusing year in .xmpdata and document title in the pdfx docs. Such
cases may be more subtle. In the case of .xmpdata command must be
defined at the moment when the file is loaded, so it is not important
either command definition or \begin{filecontents*} placed first
(.xmpdata may be provided directly as well). In the case of
\DocumentMetadata it is not obvious if commands may defined later.
^ permalink raw reply [relevance 5%]
* Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
@ 2023-10-01 15:08 7% Juan Manuel Macías
2023-10-01 18:07 12% ` Juan Manuel Macías
2023-10-02 13:10 5% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-10-01 15:08 UTC (permalink / raw)
To: orgmode
I don't know if this nomenclature issue that I'm going to raise is
excessively formalist, but here it goes.
Since the header arg :float now supports any string in inline images
exported to latex (that is, ':float foo' is exported as the environment
\begin{foo}…\end{foo}), the header arg :placement can be used for more
than just "placement". For example, this:
┌────
│ #+ATTR_LaTeX: :float minipage :placement {\textwidth}
│ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
└────
produces in LaTeX this:
┌────
│ \begin{minipage}{\textwidth}
│ \centering
│ \includegraphics[width=.9\linewidth]{/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg}
│ \end{minipage}
└────
(in this case :placement is exported as the required minipage argument,
which is its width).
An example of more "unexpected" (but very practical) uses is this one
with three subfigures and the subcaption package:
┌────
│ #+caption: Main caption
│ #+begin_figure
│ #+CAPTION: subcaption 1
│ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width \textwidth
│ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
│ @@latex:\vspace{2ex}@@
│ #+CAPTION: subcaption 2
│ #+ATTR_LaTeX: :float subfigure :placement {.4\textwidth} :center nil :width \textwidth
│ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
│ @@latex:\hfill@@
│ #+CAPTION: subcaption3
│ #+ATTR_LaTeX: :float subfigure :placement {.4\textwidth} :center nil :width \textwidth
│ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
│ #+end_figure
└────
(In all three subfigures, :placement is exported as the subfigure
environment argument, which designates the width of each subfigure).
I think this is a case where certain elements of Org have evolved
(consciously or unconsciously) ahead of the names, and these names have
become somewhat outdated. There is not only the case of :placement. Even
:float seems imprecise, since can be used to create a minipage, and the
minipage environment is not a float environment. Would it be worth
making those names obsolete (with backward compatibility, of course) and
replacing them with slightly more precise ones? I think that new names
would give the user an idea of more variety of uses, like the examples I
have put here.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-28 12:31 9% ` Juan Manuel Macías
@ 2023-09-29 2:38 5% ` Max Nikulin
2023-10-01 16:32 5% ` Max Nikulin
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2023-09-29 2:38 UTC (permalink / raw)
To: emacs-orgmode
On 28/09/2023 19:31, Juan Manuel Macías wrote:
> I think I should insist on what I said in my previous message, with a
> copy/paste:
>
> The thing is that here it is not a question of whether something can be
> done in this way or in another better way. This is how a given package
> recommends doing it. If the user wants to use that specific package, she/he
> will have to follow these instructions.
My reading of these instructions: users have 2 options, they either
provide .xmpdata files directly or they ask LaTeX to generate it using
filecontents* and take responsibility to remove the file when they
change metadata.
I do not see any words discouraging the former way, while there are
warnings concerning pitfalls with the latter approach that still may be
convenient in some cases.
> It's more. I am thinking, for
> example, of the case in which the user has to obtain a * tex file, not a
> PDF, because she/he is collaborating with more people who do not use
> Org, but do use that code in the * tex document.
Perhaps I am wrong in my assumption that in particular case of PDF-X
compliant documents, it is unlikely that it is just a single .tex
document. If there are more files: graphics, custom packages, included
.tex file then an additional separate .xmpdata file is not an issue.
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-28 10:07 4% ` Max Nikulin
@ 2023-09-28 12:31 9% ` Juan Manuel Macías
2023-09-29 2:38 5% ` Max Nikulin
2023-10-01 16:32 5% ` Max Nikulin
1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-28 12:31 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> LaTeX code may be inserted
> - before \DocumentMetadata
> - between \DocumentMetadata and \documentclass
> - between \documentclass and preamble added by Org
> - between Org preamble and \begin{document}
The first two cases can be solved perfectly with LaTeX_pre_header,
without having to complicate your life further.
> Since ordering is important [...]
Starting with \documentclass, the order is important in certain cases
and not so important in others. And, anyway, you can always use a hook
like \AtBegin... \AtEnd..., etc.
And if users want to have complete control over the preamble (that is,
everything before \begin{document}), they can always define a new class
(in Org terminology) or write a preamble or a sty file in a separate Org
document using org-babel and literary programming. In a job I'm doing
now my preamble has 1736 lines. Writing it with org-babel is quite
comfortable. In short, I think (IMHO) Org already has enough resources
for those situations.
> I consider \begin{filecontents*}{\jobname.xmpdata} as an acceptable
> (but perhaps fragile) hack for LaTeX-first document. During export of
> Org file, this file should be written directly with values from Org
> metadata.
I think I should insist on what I said in my previous message, with a
copy/paste:
The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.
Apart from that, since any code (except \usepackage) is allowed before
\documentclass, I think that the user should have the possibility (and
the freedom) to enter in their *tex documents whatever they want in that
place, including comments, luacode, shebangs, etc.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-26 19:12 9% ` Juan Manuel Macías
@ 2023-09-28 10:07 4% ` Max Nikulin
2023-09-28 12:31 9% ` Juan Manuel Macías
2023-10-02 10:42 5% ` Max Nikulin
1 sibling, 2 replies; 200+ results
From: Max Nikulin @ 2023-09-28 10:07 UTC (permalink / raw)
To: emacs-orgmode
On 27/09/2023 02:12, Juan Manuel Macías wrote:
> Max Nikulin writes:
>> I remember recipes like "put \usepackage{cmap} immediately after
>> \documentclass" (nowadays this particular one should not be necessary).
>> So I would prefer to avoid keywords per each chunk of preamble code.
>
> I think that this would not be the case. This is not just any part of
> the preamble, but a fairly definite part. Broadly speaking, LaTeX_header
> would take care of what is after \documenclass (the axis of a LaTeX
> document); LaTeX_pre_header would do it of anything that may have come
> before. And both provide a less constricted preamble for advanced use of
> LaTeX. Frankly, I can't think of a simpler solution.
LaTeX code may be inserted
- before \DocumentMetadata
- between \DocumentMetadata and \documentclass
- between \documentclass and preamble added by Org
- between Org preamble and \begin{document}
Since ordering is important, I would prefer to assemble preamble from
predefined fragments (or replace particular ones) to putting code into
these (and probably more) slots.
>> \begin{filecontents*} from the original post is not convincing.
>
> Are you not convinced by some instructions that are included in the
> official documentation of a LaTeX package (pdfx)?
More I read about .xmpdata, more it looks similar to an ugly kludge from
my point of view. The following phrases are hardly consistent:
- "Including the metadata with the LATEX source is very convenient."
- "remember to remove the existing copy of \jobname.xmpdata file before
the next processing run".
(A side note: "overwrite" option of filecontents looks promising.)
So the goal is an XML document embedded into PDF. I admit, Org can not
provide it directly since e.g. PDF compliance level is responsibility of
a PDF engine.
However the intermediate .xmpdata file may be provided independently of
its .tex counterpart accordingly to docs. This file contains metadata
and in Org metadata are managed through keywords. Significant fraction
of metadata may be shared with HTML or MarkDown, so keywords should be
considered as primary data. Writing this file from Org (e.g. by a babel
source code block) should avoid issues with LaTeX input encodings
described in the docs. Thus generation of .xmpdata during exporting of
an .org file allows to keep metadata consistent.
Currently I do not see a way to get values of INFO argument of
org-export functions from source code blocks making access to metadata
tricky. This should be addressed somehow. I would consider specifying
metadata in a way similar to org-babel header arguments to allow more
fields than currently supported by Org. It should facilitate generation
of \DocumentMedata, .xmpdada, etc.
Ability to overwrite fragments of preamble should be supported, but only
as last resort. Specifying \DocumentMetadata or .xmpdata contents
literally should be avoided to prevent discrepancy with metadata keywords.
I consider \begin{filecontents*}{\jobname.xmpdata} as an acceptable (but
perhaps fragile) hack for LaTeX-first document. During export of Org
file, this file should be written directly with values from Org metadata.
^ permalink raw reply [relevance 4%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-26 15:39 0% ` Max Nikulin
@ 2023-09-26 19:12 9% ` Juan Manuel Macías
2023-09-28 10:07 4% ` Max Nikulin
2023-10-02 10:42 5% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-26 19:12 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Thomas S. Dye
Max Nikulin writes:
> I just have checked that a dirty hack with a few lines of code for
> `org-export-filter-final-output-functions' allows to insert arbitrary
> text to the beginning of export result. Perhaps a more elegant solution
> exists, but I admit it is not a straightforward way. At least it is
> possible.
And it is also possible by simply defining a new class (in Org
terminology, not LaTeX). My usual class is an almost empty one, without
documentclass and without packages, because I don't want org to write
the preamble for me. But I think this is not the point.
> I do not mind that generation of preamble should be more flexible, but I
> consider LATEX_PRE_HEADER as an ad hoc solution, so I am trying to find
> a better variant. That is why I asked for details concerning particular
> use cases.
IMHO, LaTeX_pre_header is obvious and transparent to the user: a version
of LaTeX_header that behaves exactly the same, except that it exports
the lines before \documentclass. It is simple and requires little code
to implement, and it is used for all cases of code before the
declaration of the class, since its syntax is consistent with
LaTeX_header. And its use does not require further explanation. You can
even play with constructions like:
#+NAME: pre
#+begin_src latex :exports none
(some stuff)
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_pre_header: <<pre>>
#+end_src
> I remember recipes like "put \usepackage{cmap} immediately after
> \documentclass" (nowadays this particular one should not be necessary).
> So I would prefer to avoid keywords per each chunk of preamble code.
I think that this would not be the case. This is not just any part of
the preamble, but a fairly definite part. Broadly speaking, LaTeX_header
would take care of what is after \documenclass (the axis of a LaTeX
document); LaTeX_pre_header would do it of anything that may have come
before. And both provide a less constricted preamble for advanced use of
LaTeX. Frankly, I can't think of a simpler solution.
> \begin{filecontents*} from the original post is not convincing.
Are you not convinced by some instructions that are included in the
official documentation of a LaTeX package (pdfx)?
https://i.imgur.com/NdLWmwc.png
The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-25 21:57 7% ` Thomas S. Dye
@ 2023-09-26 15:39 0% ` Max Nikulin
2023-09-26 19:12 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-26 15:39 UTC (permalink / raw)
To: emacs-orgmode
On 26/09/2023 04:57, Thomas S. Dye wrote:
> Aloha all,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>>
>>> If so, Org should have native support of \DocumentMetadata, not
>>> LATEX_PRE_HEADER or something similar.
>>
>> If it were the only case of code before \documentclass, I would agree.
>> But, as I have already said above, the diversity of use cases makes the
>> implementation of /ad hoc/ solutions unviable, in my opinion.
>
> FWIW, I agree with Juan Manuel here and would welcome a straightforward
> way to insert material before the header.
I just have checked that a dirty hack with a few lines of code for
`org-export-filter-final-output-functions' allows to insert arbitrary
text to the beginning of export result. Perhaps a more elegant solution
exists, but I admit it is not a straightforward way. At least it is
possible.
I do not mind that generation of preamble should be more flexible, but I
consider LATEX_PRE_HEADER as an ad hoc solution, so I am trying to find
a better variant. That is why I asked for details concerning particular
use cases.
I remember recipes like "put \usepackage{cmap} immediately after
\documentclass" (nowadays this particular one should not be necessary).
So I would prefer to avoid keywords per each chunk of preamble code.
\begin{filecontents*} from the original post is not convincing.
\DocumentMetadata perhaps should be supported out of the box.
I would consider some kind of templates that use predefined fragments
#+LATEX_REPLACE_TEMPLATE: :preamble mypreamble
#+name: mypreamble
#+begin_src latex :exports none :noweb yes
\providecommand{\pdfxopts}{x-1a}
<<ox-latex-template-preamble>>
#+end_src
with ability to use fine grain snippets instead
#+LATEX_REPLACE_TEMPLATE: :preamble detailedpreamble
#+name: detailedpreamble
#+begin_src latex :exports none :noweb yes
<<ox-latex-template-DocumentMetadata>>
\PassOptionsToPackage...
<<ox-latex-template-documentclass>>
\usepackage{cmap}
\usepackage[english,<<ox-template-language>>]{babel}
<<ox-latex-template-usepackage>>
#+end_src
I hope, something similar may be made more readable than series of
LATEX_HEADER & Co lines.
^ permalink raw reply [relevance 0%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-24 18:24 12% ` Juan Manuel Macías
@ 2023-09-26 10:37 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-26 10:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>> [...] any suggestion for improvement is very welcome [...]
>>
>> This is a bit too out of context. Improvement of what?
>
> I think it is related to the previous paragraph: "I am very interested
> in all possible improvements in babel so that it integrates as best as
> possible with automatically generated files[...]"
That's good to hear. In practical terms, if Javier gives us some contact
email, we may CC him when we think that what we discuss is related to
Babel.
>> We can also provide multiple language name variants though I don't see a
>> need to bother unless we get user requests to do such thing.
>
> I agree. I even think it would be a good point to also include the
> vernacular name of each language.
Sounds reasonable. Although, let's come back to this when we have actual
code to discuss.
> By the way, Javier has also told me that he is going to consider the
> 'onchar=ids fonts' issue related to the case of several languages that
> use the same script (already discussed here in past messages).
That would be nice, although determining language may not be trivial.
AFAIK, automatic language detection often relies upon word frequencies
(for example, see https://pypi.org/project/langdetect/) and cannot be
reliable for very short text fragments. In the case of texts combining
multiple languages arbitrarily, the problem becomes even more difficult.
In some cases (dialects), multiple languages can be valid for the same
text fragment.
That said, frequency-based approach can mostly work well, except certain
edge cases. But it requires word corpus. I am not sure how feasible it
would be to include into TeX distribution. (Maybe not very hard - it is
already quite large and a few dictionary files will not change much).
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-25 18:49 9% ` Juan Manuel Macías
@ 2023-09-25 21:57 7% ` Thomas S. Dye
2023-09-26 15:39 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Thomas S. Dye @ 2023-09-25 21:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Aloha all,
Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> If so, Org should have native support of \DocumentMetadata, not
>> LATEX_PRE_HEADER or something similar.
>
> If it were the only case of code before \documentclass, I would
> agree.
> But, as I have already said above, the diversity of use cases
> makes the
> implementation of /ad hoc/ solutions unviable, in my opinion.
FWIW, I agree with Juan Manuel here and would welcome a
straightforward way to insert material before the header.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
^ permalink raw reply [relevance 7%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-25 13:58 5% ` Max Nikulin
@ 2023-09-25 18:49 9% ` Juan Manuel Macías
2023-09-25 21:57 7% ` Thomas S. Dye
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-25 18:49 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 25/09/2023 01:42, Juan Manuel Macías wrote:
>> According to the pdfx package documentation
>> (https://www.ctan.org/pkg/pdfx), p. 6 (at the bottom of the page)/7:
>> ---
>> Warning: The \jobname.xmpdata file may be included in the main document
>> source, within a {filecontents*} environment, provided this comes before
>> the \documentclass command, as follows[...]
>> ---
>
> Does it mean that with hyperxmp you can not generate documents
> satisfying some requirements and you need namely pdfx? Is there a
> reason that .xmpdata files must be generated namely by a LaTeX engine
> and writing them by elisp code is unacceptable?
In the hyperxmp manual a comparison is made with the pdfx package and
other similar packages. Anyway, this topic deviates drastically from the
original topic of the thread. There will be users who prefer to use
hyperxmp package and users who prefer pdfx. Hyperxmp is probably more
recommended, but I don't know either one deeply, so I couldn't say. In
any case: I think the central issue is to provide support for inserting
arbitrary code before \documentclass. The pdfx example is just one valid
example (ideally Org should not put obstacles to the use of any
package). As I said, there are more cases. For example, a few packages
(I don't remember their names) are recommended to be loaded first using
\RequirePackage. And there is also the case of the \PassOptionsToPackage
command. A good practice in LaTeX documents is usually to put this
command at the very beginning of the document, to avoid messages such as
"option class for xx package error". It is placed at the very beginning
because there may be classes that already require the package involved
in the error. And one more example: a new package for LuaLaTeX was
recently uploaded to CTAN, which allows the use of shebangs in LaTeX
documents. In short, there are many heterogeneous cases, and it is the
very heterogeneity of these cases that leads to a solution similar to
LaTeX_header, IMHO. Actually, any code (except \usepackage) would be
possible before \cocumentclass.
>> For example, the newpax package, to preserve the internal links of a pdf
>> included in the document, requires putting commands like
>> \DocumentMetadata{ } before documentclass.
>
> If I understand it correctly, \DocumentMetadata is a switch to enable
> "new" LaTeX like it was for \documentclass vs. \documentstyle during
> transition to LaTeX2e from LaTeX 2.09.
https://tex.stackexchange.com/questions/686898/what-is-documentmetadata-what-key-value-pairs-does-it-take-and-when-should-i-u
(As for the transition from LaTeX2e to LaTeX 3, it seems that it is not
going to be as defined as the transition we witnessed in the leap from
LaTeX 2.09. In reality it seems that there is not going to be such a
leap but rather a "coexistence" of both worlds:
https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf)
> If so, Org should have native support of \DocumentMetadata, not
> LATEX_PRE_HEADER or something similar.
If it were the only case of code before \documentclass, I would agree.
But, as I have already said above, the diversity of use cases makes the
implementation of /ad hoc/ solutions unviable, in my opinion.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-24 18:42 12% ` Juan Manuel Macías
@ 2023-09-25 13:58 5% ` Max Nikulin
2023-09-25 18:49 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-25 13:58 UTC (permalink / raw)
To: emacs-orgmode
On 25/09/2023 01:42, Juan Manuel Macías wrote:
> According to the pdfx package documentation
> (https://www.ctan.org/pkg/pdfx), p. 6 (at the bottom of the page)/7:
> ---
> Warning: The \jobname.xmpdata file may be included in the main document
> source, within a {filecontents*} environment, provided this comes before
> the \documentclass command, as follows[...]
> ---
Does it mean that with hyperxmp you can not generate documents
satisfying some requirements and you need namely pdfx? Is there a reason
that .xmpdata files must be generated namely by a LaTeX engine and
writing them by elisp code is unacceptable?
> For example, the newpax package, to preserve the internal links of a pdf
> included in the document, requires putting commands like
> \DocumentMetadata{ } before documentclass.
If I understand it correctly, \DocumentMetadata is a switch to enable
"new" LaTeX like it was for \documentclass vs. \documentstyle during
transition to LaTeX2e from LaTeX 2.09. If so, Org should have native
support of \DocumentMetadata, not LATEX_PRE_HEADER or something similar.
I have not looked into Timothy's branch, so I am unaware if it is addressed.
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-22 16:38 5% ` Max Nikulin
@ 2023-09-24 18:42 12% ` Juan Manuel Macías
2023-09-25 13:58 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-24 18:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> On 17/09/2023 01:00, Juan Manuel Macías wrote:
>>
>> [1] A longer example to export to a pdf that has pdf-x compliance, with
>> the pdfx package:
>>
>> \providecommand{\pdfxopts}{x-1a}
>> \begin{filecontents*}{\jobname.xmpdata}
>> \Title{Some Title}
>> \Author{Author}
>> \Language{es-ES}
>> \Keywords{keywords}
>> \Publisher{publisher}
>> \end{filecontents*}
>> \documentclass{...
>
> Perhaps you have in mind other cases, but I am unsure concerning this
> one. However I have tried only setting metadata for hyperref only, so I
> may miss some important aspects.
>
> First of all, I was unaware of .xmpdata and, trying to get more info, I
> have found hyperxmp that declares to reuse data from \hypersetup without
> extra files and without the requirement to add settings before
> \documentclass.
According to the pdfx package documentation
(https://www.ctan.org/pkg/pdfx), p. 6 (at the bottom of the page)/7:
---
Warning: The \jobname.xmpdata file may be included in the main document
source, within a {filecontents*} environment, provided this comes before
the \documentclass command, as follows[...]
---
> Do you need to add commands before \documentclass because you are using
> custom classes that loads a lot of packages, so there is no chance to
> specify various options after \documentclass, but before specific
> packages are loaded?
Apart from the previous case, there are other varied cases (as I
mentioned) in which it is necessary to put code before documentclass.
For example, the newpax package, to preserve the internal links of a pdf
included in the document, requires putting commands like
\DocumentMetadata{ } before documentclass.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-21 9:00 4% ` Ihor Radchenko
@ 2023-09-24 18:24 12% ` Juan Manuel Macías
2023-09-26 10:37 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-24 18:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Timothy, Max Nikulin
Sorry for the late reply.
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> [...] I am very interested in all possible improvements in babel so that
>> it integrates as best as possible with automatically generated files.
>> Among them are the possibility of using BCP47 codes or using a language
>> (at least basically) without the need for a prior declaration. These are
>> things already done, but there are others that can still be improved.
>
> Do I understand correctly that babel, in future, may be able to
> auto-detect more languages without explicitly declaring them?
Correct. Indeed, it is possible to use the command \foreignlanguage or
its environment version (otherlanguage*) without having to
declare the language previously. I would say that \foreignlanguage is a
command that covers a high percentage of use cases in multilingual
documents, since it is intended for short fragments of text and only
loads the hyphen rules of the host language.
>> [...] any suggestion for improvement is very welcome [...]
>
> This is a bit too out of context. Improvement of what?
I think it is related to the previous paragraph: "I am very interested
in all possible improvements in babel so that it integrates as best as
possible with automatically generated files[...]"
>> Among the things I agree on is name issue. I am unifying the dice in the
>> CLDR as much as possible, and already, in fact, it is very advanced:
>>
>> https://latex3.github.io/babel/guides/locale-naming.html
>
> AFAIU, the relevant quote is
>
> They are taken from the CLDR. Wherever the CLDR doesn’t provide a name
> (eg, “Medieval Latin”), the pattern followed in practice for other names
> is applied, namely, use the ‘natural’ form in English: medievallatin.
> They should be preferably based on the description field in the IANA
> registry (eg, polytonicgreek), although some simplifications can be
> necessary, because some names are “too” descriptive. See also the
> templates for about 500 locales already available. As a secondary
> source, Glottolog is used, too. (Wikipedia articles can be taken as a
> complementary but unreliable source, and its information must be
> verified; on the other hand, internal data, like this one, is useful for
> both names and tags.)
>
> I am not very sure about "some simplifications" referring to IANA. I
> guess it is referring to language names in
> https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
> like "Puter idiom of Romansh".
>
> From Org perspective, verbosity is not a primary concern as long as we
> provide #+language: completion support. Probably, we should favor names
> that are more likely known (or can be easily found) by the language
> users. IANA and https://glottolog.org/ look like good sources we can
> link to.
>
> We can also provide multiple language name variants though I don't see a
> need to bother unless we get user requests to do such thing.
I agree. I even think it would be a good point to also include the
vernacular name of each language.
By the way, Javier has also told me that he is going to consider the
'onchar=ids fonts' issue related to the case of several languages that
use the same script (already discussed here in past messages).
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 15:12 6% ` Juan Manuel Macías
@ 2023-09-22 17:51 5% ` Zenny
0 siblings, 0 replies; 200+ results
From: Zenny @ 2023-09-22 17:51 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2690 bytes --]
On Fri, Sep 22, 2023 at 5:13 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Appended the above line, but the rendering became much worse, see
> > Ganapati and BiSht lines:
>
> Well, try this:
>
> 1. remove \newfontscript{Devanagari}{deva}
>
> 2. modify the \babelprovide for Bengali like this:
>
> \babelprovide[onchar=ids fonts,import,script=Bengali]{sanskrit-bengali}
>
> (it seems like something strange is happening between the Noto Sans
> Bengali font and LuaTeX. I don't know if it's a bug, but if I explicitly
> add the script name, it seems to render the words well. With Noto Serif
> Bengali it doesn't happen).
>
Thank you, I made the changes as you advised and changed the font to Noto
Serif variant, and it worked like wonder.
The problem is solved. Thanks a zillion.
Now it renders alright as seen in the screenshot. Have a nice weekend, Juan.
>
> Sorry, I'm afraid I don't know the language, so I'm going a bit blind
> here...
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 3522 bytes --]
[-- Attachment #2: pic-selected-230922-1950-54.png --]
[-- Type: image/png, Size: 16160 bytes --]
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-16 18:00 10% [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
2023-09-17 10:02 6% ` Ihor Radchenko
2023-09-17 17:23 6% ` Timothy
@ 2023-09-22 16:38 5% ` Max Nikulin
2023-09-24 18:42 12% ` Juan Manuel Macías
2 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-22 16:38 UTC (permalink / raw)
To: emacs-orgmode
On 17/09/2023 01:00, Juan Manuel Macías wrote:
>
> [1] A longer example to export to a pdf that has pdf-x compliance, with
> the pdfx package:
>
> \providecommand{\pdfxopts}{x-1a}
> \begin{filecontents*}{\jobname.xmpdata}
> \Title{Some Title}
> \Author{Author}
> \Language{es-ES}
> \Keywords{keywords}
> \Publisher{publisher}
> \end{filecontents*}
> \documentclass{...
Perhaps you have in mind other cases, but I am unsure concerning this
one. However I have tried only setting metadata for hyperref only, so I
may miss some important aspects.
First of all, I was unaware of .xmpdata and, trying to get more info, I
have found hyperxmp that declares to reuse data from \hypersetup without
extra files and without the requirement to add settings before
\documentclass.
Do you need to add commands before \documentclass because you are using
custom classes that loads a lot of packages, so there is no chance to
specify various options after \documentclass, but before specific
packages are loaded?
I do not think the lines above should be used directly in
LATEX_PRE_HEADER. They should be generated from #+AUTHOR:, #+TITLE:,
#+LANGUAGE: keywords. Have you considered the option to generate
.xmpdata files directly from Org instead of delegating the task to LaTeX?
Another idea is to try export filter to insert content of a source block
to the beginning of the export buffer. Unsure if it is convenient.
^ permalink raw reply [relevance 5%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 12:59 6% ` Zenny
@ 2023-09-22 15:12 6% ` Juan Manuel Macías
2023-09-22 17:51 5% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 15:12 UTC (permalink / raw)
To: Zenny; +Cc: orgmode
Zenny writes:
> Appended the above line, but the rendering became much worse, see
> Ganapati and BiSht lines:
Well, try this:
1. remove \newfontscript{Devanagari}{deva}
2. modify the \babelprovide for Bengali like this:
\babelprovide[onchar=ids fonts,import,script=Bengali]{sanskrit-bengali}
(it seems like something strange is happening between the Noto Sans
Bengali font and LuaTeX. I don't know if it's a bug, but if I explicitly
add the script name, it seems to render the words well. With Noto Serif
Bengali it doesn't happen).
Sorry, I'm afraid I don't know the language, so I'm going a bit blind
here...
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 10:02 6% ` Juan Manuel Macías
@ 2023-09-22 12:59 6% ` Zenny
2023-09-22 15:12 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-22 12:59 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1.1: Type: text/plain, Size: 553 bytes --]
On Fri, Sep 22, 2023 at 12:02 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny <garbytrash@gmail.com> writes:
>
> > It still shows the problem with
> > glyphs:
> >
> > Should look like in the attached
> > screenshots, in emacs orgmode
> > and rendered to pdf (from org to
> > docx using pandoc)
>
> Add this line to the bottom:
>
> #+LaTeX_Header:\defaultfontfeatures{Renderer=HarfBuzz}
>
Appended the above line, but the rendering became much worse, see Ganapati
and BiSht lines:
Thanks.
--
Cheers,
/z
[-- Attachment #1.2: Type: text/html, Size: 1194 bytes --]
[-- Attachment #2: pic-selected-230922-1458-27.png --]
[-- Type: image/png, Size: 16213 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 9:37 4% ` Zenny
@ 2023-09-22 10:02 6% ` Juan Manuel Macías
2023-09-22 12:59 6% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 10:02 UTC (permalink / raw)
To: Zenny; +Cc: orgmode
Zenny <garbytrash@gmail.com> writes:
> It still shows the problem with
> glyphs:
>
> Should look like in the attached
> screenshots, in emacs orgmode
> and rendered to pdf (from org to
> docx using pandoc)
Add this line to the bottom:
#+LaTeX_Header:\defaultfontfeatures{Renderer=HarfBuzz}
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 9:06 6% ` Juan Manuel Macías
@ 2023-09-22 9:37 4% ` Zenny
2023-09-22 10:02 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-22 9:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2779 bytes --]
On Fri, Sep 22, 2023 at 11:06 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Here it comes:
> >
> > | Original | Anglicized | Switch |
> > |----------+------------+------------|
> > | सत्य | Satya | Sathya |
> > | सरस्वती | Saraswati | Saraswathy |
> > | गणपति | Ganapati | Ganapathy |
> > | गोषाल | goShal | Ghoshal |
> > | गोष्ठ | GoShTha | Ghosht |
> > | मुम्बा | Mumba | Bombay |
> > | घोष | GhoSha | Ghosh |
> > | बिष्ट | BiSht | Bista |
> > | अंग | Anga | Banga |
> >
> > Gosala Mankhya (घोषाला मंख्य in Sanskrit and ঘোষালা মঙ্গ্যায় in
> Bengali)
>
> See screenshot. It's right?
>
> https://i.imgur.com/OD5nl1Q.png
>
It still shows the problem with glyphs:
Should look like in the attached screenshots, in emacs orgmode and rendered
to pdf (from org to docx using pandoc)
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 3673 bytes --]
[-- Attachment #2: pic-selected-230922-1136-17.png --]
[-- Type: image/png, Size: 37836 bytes --]
[-- Attachment #3: pic-selected-230922-1053-10.png --]
[-- Type: image/png, Size: 72162 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:58 4% ` Zenny
@ 2023-09-22 9:06 6% ` Juan Manuel Macías
2023-09-22 9:37 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 9:06 UTC (permalink / raw)
To: Zenny; +Cc: orgmode
Zenny writes:
> Here it comes:
>
> | Original | Anglicized | Switch |
> |----------+------------+------------|
> | सत्य | Satya | Sathya |
> | सरस्वती | Saraswati | Saraswathy |
> | गणपति | Ganapati | Ganapathy |
> | गोषाल | goShal | Ghoshal |
> | गोष्ठ | GoShTha | Ghosht |
> | मुम्बा | Mumba | Bombay |
> | घोष | GhoSha | Ghosh |
> | बिष्ट | BiSht | Bista |
> | अंग | Anga | Banga |
>
> Gosala Mankhya (घोषाला मंख्य in Sanskrit and ঘোষালা মঙ্গ্যায় in Bengali)
See screenshot. It's right?
https://i.imgur.com/OD5nl1Q.png
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:54 6% ` Juan Manuel Macías
@ 2023-09-22 8:58 4% ` Zenny
2023-09-22 9:06 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-22 8:58 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
On Fri, Sep 22, 2023 at 10:54 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > <some text in english>
> > <some text in devanagari>
> > <some text in bengali>
> >
> > With this both languages (scripts) were rendered) but both renderings
> > has no correct glyphs (see screenshots)
>
> Could you please copy the text of your example here, so I can compile
> it?
>
Here it comes:
| Original | Anglicized | Switch |
|----------+------------+------------|
| सत्य | Satya | Sathya |
| सरस्वती | Saraswati | Saraswathy |
| गणपति | Ganapati | Ganapathy |
| गोषाल | goShal | Ghoshal |
| गोष्ठ | GoShTha | Ghosht |
| मुम्बा | Mumba | Bombay |
| घोष | GhoSha | Ghosh |
| बिष्ट | BiSht | Bista |
| अंग | Anga | Banga |
Gosala Mankhya (घोषाला मंख्य in Sanskrit and ঘোষালা মঙ্গ্যায় in Bengali)
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 3545 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:49 4% ` Zenny
@ 2023-09-22 8:54 0% ` Zenny
2023-09-22 8:54 6% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Zenny @ 2023-09-22 8:54 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 4429 bytes --]
On Fri, Sep 22, 2023 at 10:49 AM Zenny <garbytrash@gmail.com> wrote:
> On Fri, Sep 22, 2023 at 10:41 AM Juan Manuel Macías <
> maciaschain@posteo.net> wrote:
>
>> Zenny writes:
>>
>> > Also the Bengali letters were omitted with:
>>
>> Sorry, this is the correct MWE:
>>
>> #+LaTeX_Header: \usepackage[english]{babel}
>> #+LaTeX_Header: \usepackage{fontspec}
>> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
>> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
>> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-bengali}
>> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>> #+LaTeX_Header: \babelfont[sanskrit-bengali]{rm}{Noto Sans Bengali}
>>
>> <some text in english>
>> <some text in devanagari>
>> <some text in bengali>
>>
>
> With this both languages (scripts) were rendered) but both renderings has
> no correct glyphs (see screenshots)
> Thanks!
>
Actually, the former should look like the latter, for a comparison.
> --
> Cheers,
> /z
>
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
> contents by anyone other than the intended recipient is unauthorized as it
> contains privileged and confidential information, and is subject to legal
> privilege. Please do not re/distribute it. If you are not the intended
> recipient (or responsible for delivery of the message to such person), you
> may not use, copy, distribute or deliver the email and part of its contents
> to anyone this message (or any part of its contents or take any action in
> connection to it. In such case, you should destroy this message, and notify
> the sender immediately. If you have received this email in error, please
> notify the sender or your sysadmin immediately by e-mail or telephone, and
> delete the e-mail from any computer. If you or your employer does not
> consent to internet e-mail messages of this kind, please notify the sender
> immediately. All reasonable precautions have been taken to ensure no
> viruses are present in this e-mail and attachments included. As the sender
> cannot accept responsibility for any loss or damage arising from the use of
> this e-mail or attachments it is recommended that you are responsible to
> follow your virus checking procedures prior to use. The views, opinions,
> conclusions and other informations expressed in this electronic mail are
> not given or endorsed by any company including the network providers unless
> otherwise indicated by an authorized representative independent of this
> message.
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 5845 bytes --]
[-- Attachment #2: pic-selected-230922-1052-44.png --]
[-- Type: image/png, Size: 16340 bytes --]
[-- Attachment #3: pic-selected-230922-1053-10.png --]
[-- Type: image/png, Size: 72162 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:49 4% ` Zenny
2023-09-22 8:54 0% ` Zenny
@ 2023-09-22 8:54 6% ` Juan Manuel Macías
2023-09-22 8:58 4% ` Zenny
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:54 UTC (permalink / raw)
To: Zenny; +Cc: orgmode
Zenny writes:
> <some text in english>
> <some text in devanagari>
> <some text in bengali>
>
> With this both languages (scripts) were rendered) but both renderings
> has no correct glyphs (see screenshots)
Could you please copy the text of your example here, so I can compile
it?
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:41 6% ` Juan Manuel Macías
@ 2023-09-22 8:49 4% ` Zenny
2023-09-22 8:54 0% ` Zenny
2023-09-22 8:54 6% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Zenny @ 2023-09-22 8:49 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2515 bytes --]
On Fri, Sep 22, 2023 at 10:41 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Also the Bengali letters were omitted with:
>
> Sorry, this is the correct MWE:
>
> #+LaTeX_Header: \usepackage[english]{babel}
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-bengali}
> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
> #+LaTeX_Header: \babelfont[sanskrit-bengali]{rm}{Noto Sans Bengali}
>
> <some text in english>
> <some text in devanagari>
> <some text in bengali>
>
With this both languages (scripts) were rendered) but both renderings has
no correct glyphs (see screenshots)
Thanks!
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 3212 bytes --]
[-- Attachment #2: pic-selected-230922-1049-01.png --]
[-- Type: image/png, Size: 16577 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:09 0% ` Zenny
@ 2023-09-22 8:41 6% ` Juan Manuel Macías
2023-09-22 8:49 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:41 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Also the Bengali letters were omitted with:
Sorry, this is the correct MWE:
#+LaTeX_Header: \usepackage[english]{babel}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \newfontscript{Devanagari}{deva}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-bengali}
#+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
#+LaTeX_Header: \babelfont[sanskrit-bengali]{rm}{Noto Sans Bengali}
<some text in english>
<some text in devanagari>
<some text in bengali>
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:18 6% ` Juan Manuel Macías
@ 2023-09-22 8:30 4% ` Zenny
0 siblings, 0 replies; 200+ results
From: Zenny @ 2023-09-22 8:30 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]
On Fri, Sep 22, 2023 at 10:18 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Thanks, this was extremely helpful. The pdf is produced, but the
> > Devanagari glyphs were not respected. See screenshot.
>
> Could you please create this MWE, and execute the same process?
>
> #+LaTeX_Header: \usepackage[english]{babel}
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>
> <some text in English>
>
> <some text in Devanagari>
>
Thanks!
With above MWE, the org can directly be exported to pdf, but
1. Glyphs in Devanagari are not respected as earlier
2. Bengali is completely skipped.
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 3206 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:07 4% ` Zenny
2023-09-22 8:09 0% ` Zenny
@ 2023-09-22 8:18 6% ` Juan Manuel Macías
2023-09-22 8:30 4% ` Zenny
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:18 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Thanks, this was extremely helpful. The pdf is produced, but the
> Devanagari glyphs were not respected. See screenshot.
Could you please create this MWE, and execute the same process?
#+LaTeX_Header: \usepackage[english]{babel}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \newfontscript{Devanagari}{deva}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
#+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
<some text in English>
<some text in Devanagari>
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:07 4% ` Zenny
@ 2023-09-22 8:09 0% ` Zenny
2023-09-22 8:41 6% ` Juan Manuel Macías
2023-09-22 8:18 6% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Zenny @ 2023-09-22 8:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 7223 bytes --]
On Fri, Sep 22, 2023 at 10:07 AM Zenny <garbytrash@gmail.com> wrote:
>
> On Fri, Sep 22, 2023 at 10:00 AM Juan Manuel Macías <
> maciaschain@posteo.net> wrote:
>
>> Zenny writes:
>>
>> > Exactly done as you advised, but no pdf is produced even after waiting
>> > for ~10minutes (attached screenshot)
>>
>> Let's try the following:
>>
>> 1. Export your document to a 'your-document.tex' file: C-c C-e l l
>>
>> 2. Open a terminal in your directory and run:
>>
>> latexmk -f -pdf -lualatex -interaction=nonstopmode your-document.tex
>>
>
> Thanks, this was extremely helpful. The pdf is produced, but the
> Devanagari glyphs were not respected. See screenshot.
>
>>
>> (a pdf would have to be created after compilation. If there are any
>> errors, please copy your-document.log here).
>>
>
> Also the Bengali letters were omitted with:
>
> Latexmk: Summary of warnings from last run of *latex:
>> =====Latex reported missing or unavailable character(s).
>> =====See log file for details.
>> Latexmk: ====List of undefined refs and citations:
>> Missing character: There is no ঘ (U+0998) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no ো (U+09CB) in
>> font [lmroman10-regular]:+tlig;!Missing character: There is no ষ (U+09B7)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no া
>> (U+09BE) in font [lmroman10-regular]:+tlig;!Missing character: There is no
>> ল (U+09B2) in font [lmroman10-regular]:+tlig;!Missing character: There is
>> no া (U+09BE) in font [lmroman10-regular]:+tlig;!Missing character: There
>> is no ম (U+09AE) in font [lmroman10-regular]:+tlig;!Missing character:
>> There is no ঙ (U+0999) in font [lmroman10-regular]:+tlig;!Missing
>> character: There is no (U+09CD) in font [lmroman10-regular]:+tlig;!Missing
>> character: There is no গ (U+0997) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no (U+09CD) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no য (U+09AF) in
>> font [lmroman10-regular]:+tlig;!Missing character: There is no া (U+09BE)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no য
>> (U+09AF) in font [lmroman10-regular]:+tlig;!Missing character: There is no
>> (U+09BC) in font [lmroman10-regular]:+tlig;!] [2] [3
>> Missing character: There is no ঘ (U+0998) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no ো (U+09CB) in
>> font [lmroman10-regular]:+tlig;!Missing character: There is no ষ (U+09B7)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no প
>> (U+09AA) in font [lmroman10-regular]:+tlig;!Missing character: There is no
>> ত (U+09A4) in font [lmroman10-regular]:+tlig;!Missing character: There is
>> no (U+09C1) in font [lmroman10-regular]:+tlig;!Missing character: There is
>> no আ (U+0986) in font [lmroman10-regular]:+tlig;!Missing character: There
>> is no ঘ (U+0998) in font [lmroman10-regular]:+tlig;!Missing character:
>> There is no ো (U+09CB) in font [lmroman10-regular]:+tlig;!Missing
>> character: There is no ষ (U+09B7) in font
>> [lmroman10-regular]:+tlig;!Missing character: There is no প (U+09AA) in
>> font [lmroman10-regular]:+tlig;!Missing character: There is no ত (U+09A4)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no (U+09C1)
>> in font [lmroman10-regular]:+tlig;!Missing character: There is no আ
>> (U+0986) in font [lmroman10-regular]:+tlig;!] [4] [5]
>>
>
The bengali is already installed by tlmgr:
# tlmgr install bengali
> tlmgr: package repository
> https://ftpmirror1.infania.net/mirror/CTAN/systems/texlive/tlnet
> (verified)
> tlmgr install: package already present: bengali
>
>
>
>
>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>
> --
> Cheers,
> /z
>
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
> contents by anyone other than the intended recipient is unauthorized as it
> contains privileged and confidential information, and is subject to legal
> privilege. Please do not re/distribute it. If you are not the intended
> recipient (or responsible for delivery of the message to such person), you
> may not use, copy, distribute or deliver the email and part of its contents
> to anyone this message (or any part of its contents or take any action in
> connection to it. In such case, you should destroy this message, and notify
> the sender immediately. If you have received this email in error, please
> notify the sender or your sysadmin immediately by e-mail or telephone, and
> delete the e-mail from any computer. If you or your employer does not
> consent to internet e-mail messages of this kind, please notify the sender
> immediately. All reasonable precautions have been taken to ensure no
> viruses are present in this e-mail and attachments included. As the sender
> cannot accept responsibility for any loss or damage arising from the use of
> this e-mail or attachments it is recommended that you are responsible to
> follow your virus checking procedures prior to use. The views, opinions,
> conclusions and other informations expressed in this electronic mail are
> not given or endorsed by any company including the network providers unless
> otherwise indicated by an authorized representative independent of this
> message.
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 9121 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 8:00 10% ` Juan Manuel Macías
@ 2023-09-22 8:07 4% ` Zenny
2023-09-22 8:09 0% ` Zenny
2023-09-22 8:18 6% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Zenny @ 2023-09-22 8:07 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 5090 bytes --]
On Fri, Sep 22, 2023 at 10:00 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Exactly done as you advised, but no pdf is produced even after waiting
> > for ~10minutes (attached screenshot)
>
> Let's try the following:
>
> 1. Export your document to a 'your-document.tex' file: C-c C-e l l
>
> 2. Open a terminal in your directory and run:
>
> latexmk -f -pdf -lualatex -interaction=nonstopmode your-document.tex
>
Thanks, this was extremely helpful. The pdf is produced, but the Devanagari
glyphs were not respected. See screenshot.
>
> (a pdf would have to be created after compilation. If there are any
> errors, please copy your-document.log here).
>
Also the Bengali letters were omitted with:
Latexmk: Summary of warnings from last run of *latex:
> =====Latex reported missing or unavailable character(s).
> =====See log file for details.
> Latexmk: ====List of undefined refs and citations:
> Missing character: There is no ঘ (U+0998) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no ো (U+09CB) in
> font [lmroman10-regular]:+tlig;!Missing character: There is no ষ (U+09B7)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no া
> (U+09BE) in font [lmroman10-regular]:+tlig;!Missing character: There is no
> ল (U+09B2) in font [lmroman10-regular]:+tlig;!Missing character: There is
> no া (U+09BE) in font [lmroman10-regular]:+tlig;!Missing character: There
> is no ম (U+09AE) in font [lmroman10-regular]:+tlig;!Missing character:
> There is no ঙ (U+0999) in font [lmroman10-regular]:+tlig;!Missing
> character: There is no (U+09CD) in font [lmroman10-regular]:+tlig;!Missing
> character: There is no গ (U+0997) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no (U+09CD) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no য (U+09AF) in
> font [lmroman10-regular]:+tlig;!Missing character: There is no া (U+09BE)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no য
> (U+09AF) in font [lmroman10-regular]:+tlig;!Missing character: There is no
> (U+09BC) in font [lmroman10-regular]:+tlig;!] [2] [3
> Missing character: There is no ঘ (U+0998) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no ো (U+09CB) in
> font [lmroman10-regular]:+tlig;!Missing character: There is no ষ (U+09B7)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no প
> (U+09AA) in font [lmroman10-regular]:+tlig;!Missing character: There is no
> ত (U+09A4) in font [lmroman10-regular]:+tlig;!Missing character: There is
> no (U+09C1) in font [lmroman10-regular]:+tlig;!Missing character: There is
> no আ (U+0986) in font [lmroman10-regular]:+tlig;!Missing character: There
> is no ঘ (U+0998) in font [lmroman10-regular]:+tlig;!Missing character:
> There is no ো (U+09CB) in font [lmroman10-regular]:+tlig;!Missing
> character: There is no ষ (U+09B7) in font
> [lmroman10-regular]:+tlig;!Missing character: There is no প (U+09AA) in
> font [lmroman10-regular]:+tlig;!Missing character: There is no ত (U+09A4)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no (U+09C1)
> in font [lmroman10-regular]:+tlig;!Missing character: There is no আ
> (U+0986) in font [lmroman10-regular]:+tlig;!] [4] [5]
>
> Best regards,
>
> Juan Manuel
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 6123 bytes --]
[-- Attachment #2: pic-selected-230922-1000-58.png --]
[-- Type: image/png, Size: 66542 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-22 7:04 4% ` Zenny
@ 2023-09-22 8:00 10% ` Juan Manuel Macías
2023-09-22 8:07 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-22 8:00 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Exactly done as you advised, but no pdf is produced even after waiting
> for ~10minutes (attached screenshot)
Let's try the following:
1. Export your document to a 'your-document.tex' file: C-c C-e l l
2. Open a terminal in your directory and run:
latexmk -f -pdf -lualatex -interaction=nonstopmode your-document.tex
(a pdf would have to be created after compilation. If there are any
errors, please copy your-document.log here).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 21:19 12% ` Juan Manuel Macías
@ 2023-09-22 7:04 4% ` Zenny
2023-09-22 8:00 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-22 7:04 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 3665 bytes --]
On Thu, Sep 21, 2023 at 11:19 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > I also tried with:
> >
> > (setq org-latex-pdf-process
> > (if (executable-find "latexmk")
> > '("latexmk -interaction nonstopmode -output-directory %o
> > %f")
> > "bibtex %b"
> > '("%latex -interaction nonstopmode -output-directory %o %f"
> > "%latex -interaction nonstopmode -output-directory %o %f"
> > "%latex -interaction nonstopmode -output-directory %o %f"))
>
> I think the expression is bad formed; In addition, latexmk is already
> responsible for executing bibtex or biber and other processes that
> require more than one compilation. The right thing would be:
>
> (setq org-latex-pdf-process (if (executable-find "latexmk")
> '("latexmk -f -pdf -%latex
> -interaction=nonstopmode -output-directory=%o %f")
> '("%latex -interaction nonstopmode
> -output-directory %o %f"
> "%latex -interaction nonstopmode
> -output-directory %o %f"
> "%latex -interaction nonstopmode
> -output-directory %o %f")))
>
> (or just remove the customization of that variable from your init).
>
> And then put in your document:
>
> #+LATEX_COMPILER: lualatex (or pdflatex or xelatex)
>
Exactly done as you advised, but no pdf is produced even after waiting for
~10minutes (attached screenshot)
>
> This keyword modifies the value of org-latex-compiler in the document.
> If you are going to use lualatex more often, you can put in your init:
>
> (setq org-latex-compiler "lualatex")
>
Thanks for your input.
>
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #1.2: Type: text/html, Size: 5173 bytes --]
[-- Attachment #2: pic-selected-230922-0903-25.png --]
[-- Type: image/png, Size: 10237 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 20:41 0% ` Zenny
@ 2023-09-21 21:19 12% ` Juan Manuel Macías
2023-09-22 7:04 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 21:19 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> I also tried with:
>
> (setq org-latex-pdf-process
> (if (executable-find "latexmk")
> '("latexmk -interaction nonstopmode -output-directory %o
> %f")
> "bibtex %b"
> '("%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"))
I think the expression is bad formed; In addition, latexmk is already
responsible for executing bibtex or biber and other processes that
require more than one compilation. The right thing would be:
(setq org-latex-pdf-process (if (executable-find "latexmk")
'("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
'("%latex -interaction nonstopmode -output-directory %o %f"
"%latex -interaction nonstopmode -output-directory %o %f"
"%latex -interaction nonstopmode
-output-directory %o %f")))
(or just remove the customization of that variable from your init).
And then put in your document:
#+LATEX_COMPILER: lualatex (or pdflatex or xelatex)
This keyword modifies the value of org-latex-compiler in the document.
If you are going to use lualatex more often, you can put in your init:
(setq org-latex-compiler "lualatex")
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 20:39 0% ` Zenny
@ 2023-09-21 20:41 0% ` Zenny
2023-09-21 21:19 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 20:41 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 8430 bytes --]
On Thu, Sep 21, 2023 at 10:39 PM Zenny <garbytrash@gmail.com> wrote:
>
> On Thu, Sep 21, 2023 at 10:26 PM Zenny <garbytrash@gmail.com> wrote:
>
>>
>> On Thu, Sep 21, 2023 at 9:32 PM Juan Manuel Macías <
>> maciaschain@posteo.net> wrote:
>>
>>> Zenny writes:
>>>
>>> > Here it comes:
>>> >
>>> > org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
>>> >
>>> > Its value is
>>> > ("pdflatex -interaction nonstopmode -output-directory %o %f"
>>> > "bibtex %b" "pdflatex -shell-escape -interaction nonstopmode -
>>> > output-directory %o %f" "pdflatex -shell-escape -interaction
>>> > nonstopmode -output-directory %o %f")
>>> > Original value was
>>> > ("latexmk -f -pdf -%latex -interaction=nonstopmode -
>>> > output-directory=%o %f")
>>>
>>> It seems that you have modified the original value. Besides, the
>>> docstring says:
>>>
>>> [...] %latex is the LaTeX compiler (see ‘org-latex-compiler’) [...]
>>>
>>> If you put 'pdflatex ...', it will always compile with pdflatex.
>>>
>>
> Does `#+LATEX_COMPILER: lualatex` makes no difference?
>
I also tried with:
(setq org-latex-pdf-process
> (if (executable-find "latexmk")
> '("latexmk -interaction nonstopmode -output-directory %o %f")
> "bibtex %b"
> '("%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"))
>
but it did not produce any pdf at all.
>
>
>>
>>> I would recommend that you restore the original value of
>>> org-latex-pdf-process, which uses latexmk (if it is installed, which
>>> seems to be your case), which executes '%latex' (=
>>> `org-latex-compiler'). latexmk is a perl script included in texlive that
>>> is responsible for executing all the necessary compilations (including
>>> the call to the bibliographic engine[1]).
>>>
>>
>> When I checked the `ox-latex.el` it appears using latexmk
>>
>> (defcustom org-latex-pdf-process
>>> (if (executable-find "latexmk")
>>> '("latexmk -f -pdf -%latex -interaction=nonstopmode
>>> -output-directory=%o %f")
>>> '("%latex -interaction nonstopmode -output-directory %o %f"
>>> "%latex -interaction nonstopmode -output-directory %o %f"
>>> "%latex -interaction nonstopmode -output-directory %o %f"))
>>> "Commands to process a LaTeX file to a PDF file.
>>>
>>
>> And latexmk is already installed by texlive:
>>
>> $ which latexmk
>>> /opt/texlive/2023/bin/x86_64-linux/latexmk
>>>
>>
>>
>> Or do you mean to change latexmk in init.el?
>>
>
> I do see in init.el that it has been changed to something like:
>
> (setq org-latex-pdf-process
>> '("pdflatex -interaction nonstopmode -output-directory %o %f"
>> "bibtex %b"
>> "pdflatex -shell-escape -interaction nonstopmode
>> -output-directory %o %f"
>> "pdflatex -shell-escape -interaction nonstopmode
>> -output-directory %o %f"))
>>
>
>
>> Thanks!
>>
>>>
>>> [1] In some cases some configuration is required for latexmk via a
>>> ~/latexmkrc file, but by default everything should work fine.
>>>
>>>
>>>
>>
>> --
>> Cheers,
>> /z
>>
>> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
>> contents by anyone other than the intended recipient is unauthorized as it
>> contains privileged and confidential information, and is subject to legal
>> privilege. Please do not re/distribute it. If you are not the intended
>> recipient (or responsible for delivery of the message to such person), you
>> may not use, copy, distribute or deliver the email and part of its contents
>> to anyone this message (or any part of its contents or take any action in
>> connection to it. In such case, you should destroy this message, and notify
>> the sender immediately. If you have received this email in error, please
>> notify the sender or your sysadmin immediately by e-mail or telephone, and
>> delete the e-mail from any computer. If you or your employer does not
>> consent to internet e-mail messages of this kind, please notify the sender
>> immediately. All reasonable precautions have been taken to ensure no
>> viruses are present in this e-mail and attachments included. As the sender
>> cannot accept responsibility for any loss or damage arising from the use of
>> this e-mail or attachments it is recommended that you are responsible to
>> follow your virus checking procedures prior to use. The views, opinions,
>> conclusions and other informations expressed in this electronic mail are
>> not given or endorsed by any company including the network providers unless
>> otherwise indicated by an authorized representative independent of this
>> message.
>> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>>
>>
>
> --
> Cheers,
> /z
>
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
> contents by anyone other than the intended recipient is unauthorized as it
> contains privileged and confidential information, and is subject to legal
> privilege. Please do not re/distribute it. If you are not the intended
> recipient (or responsible for delivery of the message to such person), you
> may not use, copy, distribute or deliver the email and part of its contents
> to anyone this message (or any part of its contents or take any action in
> connection to it. In such case, you should destroy this message, and notify
> the sender immediately. If you have received this email in error, please
> notify the sender or your sysadmin immediately by e-mail or telephone, and
> delete the e-mail from any computer. If you or your employer does not
> consent to internet e-mail messages of this kind, please notify the sender
> immediately. All reasonable precautions have been taken to ensure no
> viruses are present in this e-mail and attachments included. As the sender
> cannot accept responsibility for any loss or damage arising from the use of
> this e-mail or attachments it is recommended that you are responsible to
> follow your virus checking procedures prior to use. The views, opinions,
> conclusions and other informations expressed in this electronic mail are
> not given or endorsed by any company including the network providers unless
> otherwise indicated by an authorized representative independent of this
> message.
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 12464 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 20:26 4% ` Zenny
@ 2023-09-21 20:39 0% ` Zenny
2023-09-21 20:41 0% ` Zenny
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 20:39 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 6054 bytes --]
On Thu, Sep 21, 2023 at 10:26 PM Zenny <garbytrash@gmail.com> wrote:
>
> On Thu, Sep 21, 2023 at 9:32 PM Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Zenny writes:
>>
>> > Here it comes:
>> >
>> > org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
>> >
>> > Its value is
>> > ("pdflatex -interaction nonstopmode -output-directory %o %f"
>> > "bibtex %b" "pdflatex -shell-escape -interaction nonstopmode -
>> > output-directory %o %f" "pdflatex -shell-escape -interaction
>> > nonstopmode -output-directory %o %f")
>> > Original value was
>> > ("latexmk -f -pdf -%latex -interaction=nonstopmode -
>> > output-directory=%o %f")
>>
>> It seems that you have modified the original value. Besides, the
>> docstring says:
>>
>> [...] %latex is the LaTeX compiler (see ‘org-latex-compiler’) [...]
>>
>> If you put 'pdflatex ...', it will always compile with pdflatex.
>>
>
Does `#+LATEX_COMPILER: lualatex` makes no difference?
>
>> I would recommend that you restore the original value of
>> org-latex-pdf-process, which uses latexmk (if it is installed, which
>> seems to be your case), which executes '%latex' (=
>> `org-latex-compiler'). latexmk is a perl script included in texlive that
>> is responsible for executing all the necessary compilations (including
>> the call to the bibliographic engine[1]).
>>
>
> When I checked the `ox-latex.el` it appears using latexmk
>
> (defcustom org-latex-pdf-process
>> (if (executable-find "latexmk")
>> '("latexmk -f -pdf -%latex -interaction=nonstopmode
>> -output-directory=%o %f")
>> '("%latex -interaction nonstopmode -output-directory %o %f"
>> "%latex -interaction nonstopmode -output-directory %o %f"
>> "%latex -interaction nonstopmode -output-directory %o %f"))
>> "Commands to process a LaTeX file to a PDF file.
>>
>
> And latexmk is already installed by texlive:
>
> $ which latexmk
>> /opt/texlive/2023/bin/x86_64-linux/latexmk
>>
>
>
> Or do you mean to change latexmk in init.el?
>
I do see in init.el that it has been changed to something like:
(setq org-latex-pdf-process
> '("pdflatex -interaction nonstopmode -output-directory %o %f"
> "bibtex %b"
> "pdflatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"
> "pdflatex -shell-escape -interaction nonstopmode -output-directory
> %o %f"))
>
> Thanks!
>
>>
>> [1] In some cases some configuration is required for latexmk via a
>> ~/latexmkrc file, but by default everything should work fine.
>>
>>
>>
>
> --
> Cheers,
> /z
>
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
> CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
> contents by anyone other than the intended recipient is unauthorized as it
> contains privileged and confidential information, and is subject to legal
> privilege. Please do not re/distribute it. If you are not the intended
> recipient (or responsible for delivery of the message to such person), you
> may not use, copy, distribute or deliver the email and part of its contents
> to anyone this message (or any part of its contents or take any action in
> connection to it. In such case, you should destroy this message, and notify
> the sender immediately. If you have received this email in error, please
> notify the sender or your sysadmin immediately by e-mail or telephone, and
> delete the e-mail from any computer. If you or your employer does not
> consent to internet e-mail messages of this kind, please notify the sender
> immediately. All reasonable precautions have been taken to ensure no
> viruses are present in this e-mail and attachments included. As the sender
> cannot accept responsibility for any loss or damage arising from the use of
> this e-mail or attachments it is recommended that you are responsible to
> follow your virus checking procedures prior to use. The views, opinions,
> conclusions and other informations expressed in this electronic mail are
> not given or endorsed by any company including the network providers unless
> otherwise indicated by an authorized representative independent of this
> message.
> -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 8681 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 19:32 6% ` Juan Manuel Macías
@ 2023-09-21 20:26 4% ` Zenny
2023-09-21 20:39 0% ` Zenny
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 20:26 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 3731 bytes --]
On Thu, Sep 21, 2023 at 9:32 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > Here it comes:
> >
> > org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
> >
> > Its value is
> > ("pdflatex -interaction nonstopmode -output-directory %o %f"
> > "bibtex %b" "pdflatex -shell-escape -interaction nonstopmode -
> > output-directory %o %f" "pdflatex -shell-escape -interaction
> > nonstopmode -output-directory %o %f")
> > Original value was
> > ("latexmk -f -pdf -%latex -interaction=nonstopmode -
> > output-directory=%o %f")
>
> It seems that you have modified the original value. Besides, the
> docstring says:
>
> [...] %latex is the LaTeX compiler (see ‘org-latex-compiler’) [...]
>
> If you put 'pdflatex ...', it will always compile with pdflatex.
>
> I would recommend that you restore the original value of
> org-latex-pdf-process, which uses latexmk (if it is installed, which
> seems to be your case), which executes '%latex' (=
> `org-latex-compiler'). latexmk is a perl script included in texlive that
> is responsible for executing all the necessary compilations (including
> the call to the bibliographic engine[1]).
>
When I checked the `ox-latex.el` it appears using latexmk
(defcustom org-latex-pdf-process
> (if (executable-find "latexmk")
> '("latexmk -f -pdf -%latex -interaction=nonstopmode
> -output-directory=%o %f")
> '("%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"
> "%latex -interaction nonstopmode -output-directory %o %f"))
> "Commands to process a LaTeX file to a PDF file.
>
And latexmk is already installed by texlive:
$ which latexmk
> /opt/texlive/2023/bin/x86_64-linux/latexmk
>
Or do you mean to change latexmk in init.el?
Thanks!
>
> [1] In some cases some configuration is required for latexmk via a
> ~/latexmkrc file, but by default everything should work fine.
>
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 5111 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 18:44 4% ` Zenny
@ 2023-09-21 19:32 6% ` Juan Manuel Macías
2023-09-21 20:26 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 19:32 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> Here it comes:
>
> org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
>
> Its value is
> ("pdflatex -interaction nonstopmode -output-directory %o %f"
> "bibtex %b" "pdflatex -shell-escape -interaction nonstopmode -
> output-directory %o %f" "pdflatex -shell-escape -interaction
> nonstopmode -output-directory %o %f")
> Original value was
> ("latexmk -f -pdf -%latex -interaction=nonstopmode -
> output-directory=%o %f")
It seems that you have modified the original value. Besides, the
docstring says:
[...] %latex is the LaTeX compiler (see ‘org-latex-compiler’) [...]
If you put 'pdflatex ...', it will always compile with pdflatex.
I would recommend that you restore the original value of
org-latex-pdf-process, which uses latexmk (if it is installed, which
seems to be your case), which executes '%latex' (=
`org-latex-compiler'). latexmk is a perl script included in texlive that
is responsible for executing all the necessary compilations (including
the call to the bibliographic engine[1]).
[1] In some cases some configuration is required for latexmk via a
~/latexmkrc file, but by default everything should work fine.
^ permalink raw reply [relevance 6%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 18:28 13% ` Juan Manuel Macías
@ 2023-09-21 18:44 4% ` Zenny
2023-09-21 19:32 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 18:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 4891 bytes --]
On Thu, Sep 21, 2023 at 8:28 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Zenny writes:
>
> > With above code for LuaLaTeX, I have also appended:
> >
> > #+LATEX_COMPILER: lualatex
> >
> > even after specifying the LaTeX compiler to lualatex a report that
> > says, the compiler seems to use pdflatex:
> >
> > ! Fatal Package fontspec Error: The fontspec package requires
> > either XeTeX or
> > (fontspec) LuaTeX.
> > (fontspec)
> > (fontspec) You must change your typesetting
> > engine to,
> > (fontspec) e.g., "xelatex" or "lualatex"
> > instead of
> > (fontspec) "latex" or "pdflatex".
> >
> > Type <return> to continue.
> > ...
> >
> > l.45 \msg_fatal:nn {fontspec} {cannot-use-pdftex}
> >
> >
> > Entire texlive packages are installed and lualatex binary is at:
> >
> > $ which lualatex
> > /opt/texlive/2023/bin/x86_64-linux/lualatex
>
> Can you please show here the value of 'org-latex-pdf-process'?
>
> (M-x describe-variable RET org-latex-pdf-process RET)
>
Here it comes:
org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
>
> Its value is
> ("pdflatex -interaction nonstopmode -output-directory %o %f" "bibtex %b"
> "pdflatex -shell-escape -interaction nonstopmode -output-directory %o %f"
> "pdflatex -shell-escape -interaction nonstopmode -output-directory %o %f")
> Original value was
> ("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o
> %f")
>
> Commands to process a LaTeX file to a PDF file.
>
> The command output will be parsed to extract compilation errors and
> warnings according to ‘org-latex-known-warnings’.
>
> This is a list of strings, each of them will be given to the
> shell as a command. %f in the command will be replaced by the
> relative file name, %F by the absolute file name, %b by the file
> base name (i.e. without directory and extension parts), %o by the
> base directory of the file, %O by the absolute file name of the
> output file, %latex is the LaTeX compiler (see
> ‘org-latex-compiler’), and %bib is the BibTeX-like compiler (see
> ‘org-latex-bib-compiler’).
>
> The reason why this is a list is that it usually takes several
> runs of ‘pdflatex’, maybe mixed with a call to ‘bibtex’. Org
> does not have a clever mechanism to detect which of these
> commands have to be run to get to a stable result, and it also
> does not do any error checking.
>
> Consider a smart LaTeX compiler such as ‘texi2dvi’ or ‘latexmk’,
> which calls the "correct" combinations of auxiliary programs.
>
> Alternatively, this may be a Lisp function that does the
> processing, so you could use this to apply the machinery of
> AUCTeX or the Emacs LaTeX mode. This function should accept the
> file name as its single argument.
>
> You can customize this variable.
>
Thanks!
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
>
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 6618 bytes --]
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 17:53 5% ` Zenny
@ 2023-09-21 18:28 13% ` Juan Manuel Macías
2023-09-21 18:44 4% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 18:28 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Zenny writes:
> With above code for LuaLaTeX, I have also appended:
>
> #+LATEX_COMPILER: lualatex
>
> even after specifying the LaTeX compiler to lualatex a report that
> says, the compiler seems to use pdflatex:
>
> ! Fatal Package fontspec Error: The fontspec package requires
> either XeTeX or
> (fontspec) LuaTeX.
> (fontspec)
> (fontspec) You must change your typesetting
> engine to,
> (fontspec) e.g., "xelatex" or "lualatex"
> instead of
> (fontspec) "latex" or "pdflatex".
>
> Type <return> to continue.
> ...
>
> l.45 \msg_fatal:nn {fontspec} {cannot-use-pdftex}
>
>
> Entire texlive packages are installed and lualatex binary is at:
>
> $ which lualatex
> /opt/texlive/2023/bin/x86_64-linux/lualatex
Can you please show here the value of 'org-latex-pdf-process'?
(M-x describe-variable RET org-latex-pdf-process RET)
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 15:33 5% ` Juan Manuel Macías
@ 2023-09-21 17:53 5% ` Zenny
2023-09-21 18:28 13% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 17:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 4828 bytes --]
Hi Juan,
On Thu, Sep 21, 2023 at 5:33 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi, Zenny,
>
> Zenny writes:
>
> > Where does this preamble goes to? Any example?
>
> As in your example, using latex_header keywords (replacing the
> polyglossia code with the babel code):
>
> #+LaTeX_Header: \usepackage[english]{babel}
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>
> > Yet I am a bit confused because the Sanskrit/Devanagari words are used
> > not in a whole block, but in between English sentences, eg.:
>
> With Polyglossia and babel it is necessary to enter a command that
> changes the language. In the case of polyglossia, if you don't
> explicitly switch to Sanskrit the font you declared for Sanskrit is not
> used, and LaTeX still thinks the text is English. Polyglossia uses some
> commands similar to those of babel (\selectlanguage, for long texts) and
> other native ones, such as \text<lang>{text}, where <lang> is the
> secondary language. In babel you have the command
> \foreignlanguage{<lang>}{text}. For example (using polyglossia):
>
> Old expression goes like \textsanskrit{स्वस्ति सत्यं वचति}
>
> Of course, in org you would have to use some trick, like defining some
> macro (since org does not have, at the moment[1], a native language
> switching method):
>
> #+macro: sanskrit @@latex:\textsanskrit{@@$1@@latex:}@@
>
> Old expression goes like {{{sanskrit(स्वस्ति सत्यं वचति)}}}
>
> With LuaLaTeX, babel can associate a non latin language to a font
> without requiring an explicit language switch:
>
> #+LaTeX_Header: \usepackage[english]{babel}
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \newfontscript{Devanagari}{deva}
> #+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> #+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>
With above code for LuaLaTeX, I have also appended:
#+LATEX_COMPILER: lualatex
even after specifying the LaTeX compiler to lualatex a report that says,
the compiler seems to use pdflatex:
! Fatal Package fontspec Error: The fontspec package requires either XeTeX
> or
> (fontspec) LuaTeX.
> (fontspec)
> (fontspec) You must change your typesetting engine to,
> (fontspec) e.g., "xelatex" or "lualatex" instead of
> (fontspec) "latex" or "pdflatex".
>
> Type <return> to continue.
> ...
>
> l.45 \msg_fatal:nn {fontspec} {cannot-use-pdftex}
>
Entire texlive packages are installed and lualatex binary is at:
$ which lualatex
> /opt/texlive/2023/bin/x86_64-linux/lualatex
>
Thanks for your attention!
/z
> Old expression goes like स्वस्ति सत्यं वचति
>
> [1] You might be interested in this thread:
> https://list.orgmode.org/878r9t7x7y.fsf@posteo.net/
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 6485 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 13:46 5% ` Zenny
@ 2023-09-21 15:33 5% ` Juan Manuel Macías
2023-09-21 17:53 5% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 15:33 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Hi, Zenny,
Zenny writes:
> Where does this preamble goes to? Any example?
As in your example, using latex_header keywords (replacing the
polyglossia code with the babel code):
#+LaTeX_Header: \usepackage[english]{babel}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \newfontscript{Devanagari}{deva}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
#+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
> Yet I am a bit confused because the Sanskrit/Devanagari words are used
> not in a whole block, but in between English sentences, eg.:
With Polyglossia and babel it is necessary to enter a command that
changes the language. In the case of polyglossia, if you don't
explicitly switch to Sanskrit the font you declared for Sanskrit is not
used, and LaTeX still thinks the text is English. Polyglossia uses some
commands similar to those of babel (\selectlanguage, for long texts) and
other native ones, such as \text<lang>{text}, where <lang> is the
secondary language. In babel you have the command
\foreignlanguage{<lang>}{text}. For example (using polyglossia):
Old expression goes like \textsanskrit{स्वस्ति सत्यं वचति}
Of course, in org you would have to use some trick, like defining some
macro (since org does not have, at the moment[1], a native language
switching method):
#+macro: sanskrit @@latex:\textsanskrit{@@$1@@latex:}@@
Old expression goes like {{{sanskrit(स्वस्ति सत्यं वचति)}}}
With LuaLaTeX, babel can associate a non latin language to a font
without requiring an explicit language switch:
#+LaTeX_Header: \usepackage[english]{babel}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \newfontscript{Devanagari}{deva}
#+LaTeX_Header: \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
#+LaTeX_Header: \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
Old expression goes like स्वस्ति सत्यं वचति
[1] You might be interested in this thread: https://list.orgmode.org/878r9t7x7y.fsf@posteo.net/
^ permalink raw reply [relevance 5%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
2023-09-21 8:24 13% ` Juan Manuel Macías
@ 2023-09-21 13:46 5% ` Zenny
2023-09-21 15:33 5% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Zenny @ 2023-09-21 13:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 4344 bytes --]
Thanks Juan for prompt response, my replies inline below:
On Thu, Sep 21, 2023 at 10:24 AM Juan Manuel Macías <maciaschain@posteo.net>
wrote:
> Hi,
>
> I would recommend that you use babel, as it is the official package for
> language support and now has many more options than polyglossia.
Thanks for the pointer and explanation.
> You can
> try this preamble (compiles in LuaLaTeX):
>
> \documentclass{article}
> \usepackage[english]{babel}
> \usepackage{fontspec}
> \newfontscript{Devanagari}{deva}
> \babelprovide[onchar=ids fonts]{sanskrit-devanagari}
> \babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
>
Where does this preamble goes to? Any example?
>
> With \babelprovide... there is no need to add a \selectlanguage or other
> similar command. The problem with your example is that you need to put a
> command to select the language before the Devanagari text, like
> \selectlanguage{sanskrit}
>
Yet I am a bit confused because the Sanskrit/Devanagari words are used not
in a whole block, but in between English sentences, eg.:
Old expression goes like स्वस्ति सत्यं वचति (meaning 'Always tell the truth
> with positive vibes') where स्वस्ति means positive, सत्यं means truth and
> वचति means tell or speak out.
>
Any example would be appreciated for pdf export. Thanks again.
> Best regards,
>
> Juan Manuel
>
> Zenny <garbytrash@gmail.com> escribió:
>
> > Hi,
> >
> > I tried to export to pdf with the following:
> >
> > #+LATEX_HEADER: \usepackage{polyglossia}
> > #+LATEX_HEADER: \usepackage{fontspec}
> > #+LATEX_COMPILER: xelatex (also tried with lualatex)
> > #+LATEX_HEADER: \setmainlanguage{english}
> > #+LATEX_HEADER: \setotherlanguage{sanskrit}
> > #+LATEX_HEADER: \newfontfamily\devanagarifont{Noto Serif
> > Devanagari}
> >
> > स्वस्ति सत्यं वचति
> >
> > but it exports alright to odt, and even pandoc exports alright
> > directly from org file to docx file, but the Sanskrit/Devanagari fonts
> > are skipped (blank) in pdf output when exported directly from org file
> > with C-c C-e l o.
> >
> > Already tried with the solutions provided in
> >
> https://emacs.stackexchange.com/questions/27576/exporting-devanagarai-text-from-org-mode-to-latex
> ,
> > but there are no such options (variables defined) after 'M-x
> > customize-group' available.
>
> --
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
>
>
>
--
Cheers,
/z
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its
contents by anyone other than the intended recipient is unauthorized as it
contains privileged and confidential information, and is subject to legal
privilege. Please do not re/distribute it. If you are not the intended
recipient (or responsible for delivery of the message to such person), you
may not use, copy, distribute or deliver the email and part of its contents
to anyone this message (or any part of its contents or take any action in
connection to it. In such case, you should destroy this message, and notify
the sender immediately. If you have received this email in error, please
notify the sender or your sysadmin immediately by e-mail or telephone, and
delete the e-mail from any computer. If you or your employer does not
consent to internet e-mail messages of this kind, please notify the sender
immediately. All reasonable precautions have been taken to ensure no
viruses are present in this e-mail and attachments included. As the sender
cannot accept responsibility for any loss or damage arising from the use of
this e-mail or attachments it is recommended that you are responsible to
follow your virus checking procedures prior to use. The views, opinions,
conclusions and other informations expressed in this electronic mail are
not given or endorsed by any company including the network providers unless
otherwise indicated by an authorized representative independent of this
message.
-.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-.
[-- Attachment #2: Type: text/html, Size: 6318 bytes --]
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-20 14:03 5% ` Juan Manuel Macías
@ 2023-09-21 9:00 4% ` Ihor Radchenko
2023-09-24 18:24 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-21 9:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> [...] I am very interested in all possible improvements in babel so that
> it integrates as best as possible with automatically generated files.
> Among them are the possibility of using BCP47 codes or using a language
> (at least basically) without the need for a prior declaration. These are
> things already done, but there are others that can still be improved.
Do I understand correctly that babel, in future, may be able to
auto-detect more languages without explicitly declaring them?
> [...] any suggestion for improvement is very welcome [...]
This is a bit too out of context. Improvement of what?
> Among the things I agree on is name issue. I am unifying the dice in the
> CLDR as much as possible, and already, in fact, it is very advanced:
>
> https://latex3.github.io/babel/guides/locale-naming.html
AFAIU, the relevant quote is
They are taken from the CLDR. Wherever the CLDR doesn’t provide a name
(eg, “Medieval Latin”), the pattern followed in practice for other names
is applied, namely, use the ‘natural’ form in English: medievallatin.
They should be preferably based on the description field in the IANA
registry (eg, polytonicgreek), although some simplifications can be
necessary, because some names are “too” descriptive. See also the
templates for about 500 locales already available. As a secondary
source, Glottolog is used, too. (Wikipedia articles can be taken as a
complementary but unreliable source, and its information must be
verified; on the other hand, internal data, like this one, is useful for
both names and tags.)
I am not very sure about "some simplifications" referring to IANA. I
guess it is referring to language names in
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
like "Puter idiom of Romansh".
From Org perspective, verbosity is not a primary concern as long as we
provide #+language: completion support. Probably, we should favor names
that are more likely known (or can be easily found) by the language
users. IANA and https://glottolog.org/ look like good sources we can
link to.
We can also provide multiple language name variants though I don't see a
need to bother unless we get user requests to do such thing.
> The ini files contain information that is not actually used by babel,
> but that could be useful in other packages or even external
> applications. One of them is the name of the language in English and in
> the vernacular form, as they are in the Unicode CLDR. As I explain in
> the link I gave you, the purpose is that the babel name is based on the
> CLDR name with mechanical changes. Anyway, CLDR names are also included
> in the ini files, to establish correspondences more easily.
Are the "verbose" language names (name.english) changed to "simplify"
them? Or is it only done for name.babel?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 4%]
* Re: Sanskrit/Devanagari fonts not exported to org-pdf output
@ 2023-09-21 8:24 13% ` Juan Manuel Macías
2023-09-21 13:46 5% ` Zenny
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-21 8:24 UTC (permalink / raw)
To: Zenny; +Cc: emacs-orgmode
Hi,
I would recommend that you use babel, as it is the official package for
language support and now has many more options than polyglossia. You can
try this preamble (compiles in LuaLaTeX):
\documentclass{article}
\usepackage[english]{babel}
\usepackage{fontspec}
\newfontscript{Devanagari}{deva}
\babelprovide[onchar=ids fonts]{sanskrit-devanagari}
\babelfont[sanskrit-devanagari]{rm}{Noto Sans Devanagari}
With \babelprovide... there is no need to add a \selectlanguage or other
similar command. The problem with your example is that you need to put a
command to select the language before the Devanagari text, like
\selectlanguage{sanskrit}
Best regards,
Juan Manuel
Zenny <garbytrash@gmail.com> escribió:
> Hi,
>
> I tried to export to pdf with the following:
>
> #+LATEX_HEADER: \usepackage{polyglossia}
> #+LATEX_HEADER: \usepackage{fontspec}
> #+LATEX_COMPILER: xelatex (also tried with lualatex)
> #+LATEX_HEADER: \setmainlanguage{english}
> #+LATEX_HEADER: \setotherlanguage{sanskrit}
> #+LATEX_HEADER: \newfontfamily\devanagarifont{Noto Serif
> Devanagari}
>
> स्वस्ति सत्यं वचति
>
> but it exports alright to odt, and even pandoc exports alright
> directly from org file to docx file, but the Sanskrit/Devanagari fonts
> are skipped (blank) in pdf output when exported directly from org file
> with C-c C-e l o.
>
> Already tried with the solutions provided in
> https://emacs.stackexchange.com/questions/27576/exporting-devanagarai-text-from-org-mode-to-latex,
> but there are no such options (variables defined) after 'M-x
> customize-group' available.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 13%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-05 10:44 5% ` Ihor Radchenko
@ 2023-09-20 14:03 5% ` Juan Manuel Macías
2023-09-21 9:00 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-20 14:03 UTC (permalink / raw)
To: orgmode; +Cc: Ihor Radchenko, Timothy, Max Nikulin
Some new information about Babel that may be of interest to the topic of
this thread.
I have received an email from Javier Bezos (whom I know from the
Spanish-speaking TeX users' mailing list), who is the current babel
mantainer, as well as the person responsible for all the improvements
and new features of the package. Although he is not currently an
Emacs/Org user, he has been following this thread with great interest,
so I am transmitting here, with his permission, some interesting
comments from him:
#+begin_quote
[...] I am very interested in all possible improvements in babel so that
it integrates as best as possible with automatically generated files.
Among them are the possibility of using BCP47 codes or using a language
(at least basically) without the need for a prior declaration. These are
things already done, but there are others that can still be improved.
[...] any suggestion for improvement is very welcome [...]
Among the things I agree on is name issue. I am unifying the dice in the
CLDR as much as possible, and already, in fact, it is very advanced:
https://latex3.github.io/babel/guides/locale-naming.html
[...]
The ini files contain information that is not actually used by babel,
but that could be useful in other packages or even external
applications. One of them is the name of the language in English and in
the vernacular form, as they are in the Unicode CLDR. As I explain in
the link I gave you, the purpose is that the babel name is based on the
CLDR name with mechanical changes. Anyway, CLDR names are also included
in the ini files, to establish correspondences more easily.
#+end_quote
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-16 18:00 10% [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
2023-09-17 10:02 6% ` Ihor Radchenko
@ 2023-09-17 17:23 6% ` Timothy
2023-09-22 16:38 5% ` Max Nikulin
2 siblings, 0 replies; 200+ results
From: Timothy @ 2023-09-17 17:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
Hi Juan,
I’d rather not have this merged at this stage, as I think it may be redundant
once my conditional/generated export work makes its way into Org (next few
months?).
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Rationale for this patch: in certain cases, in a LaTeX document, it is
> necessary to add code before the class declaration (\documentclass…).
> For example, commands like \PassOptionsToPackage, \DocumentMetadata{ },
> etc.; or certain packages that should be loaded first using
> \RequirePackage{}; and other miscellaneous cases[1]. I think that by
> defining a new keyword `latex_pre_header’, which behaves the same as
> latex_header but concatenated before the class, these situations can be
> resolved from Org.
>
> [1] A longer example to export to a pdf that has pdf-x compliance, with
> the pdfx package:
>
> \providecommand{\pdfxopts}{x-1a}
> \begin{filecontents*}{\jobname.xmpdata}
> \Title{Some Title}
> \Author{Author}
> \Language{es-ES}
> \Keywords{keywords}
> \Publisher{publisher}
> \end{filecontents*}
> \documentclass{…
All the best,
Timothy
--
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
2023-09-16 18:00 10% [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
@ 2023-09-17 10:02 6% ` Ihor Radchenko
2023-09-17 17:23 6% ` Timothy
2023-09-22 16:38 5% ` Max Nikulin
2 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-17 10:02 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Rationale for this patch: in certain cases, in a LaTeX document, it is
> necessary to add code before the class declaration (\documentclass...).
> For example, commands like \PassOptionsToPackage, \DocumentMetadata{ },
> etc.; or certain packages that should be loaded first using
> \RequirePackage{}; and other miscellaneous cases[1]. I think that by
> defining a new keyword `latex_pre_header', which behaves the same as
> latex_header but concatenated before the class, these situations can be
> resolved from Org.
Thanks for the patch!
It looks reasonable.
> https://gnutas.juanmanuelmacias.com
> From ac6b743a4489f7bc8ab1cdae7ffd3b36e5f3c1d2 Mon Sep 17 00:00:00 2001
> From: Juan Manuel Macias <maciaschain@posteo.net>
> Date: Sat, 16 Sep 2023 19:22:39 +0200
> Subject: [PATCH] lisp/ox-latex.el (latex): Add `LATEX_PRE_HEADER' keyword
>
> * (org-latex-make-preamble): In some cases it is necessary to add code
> before the `\documentclass' line. `LATEX_PRE_HEADER' behaves the same as
> `LATEX_HEADER', except that it is concatenated before the class.
I think that you do not need to `quote' LATEX_PRE_HEADER - it is not a
lisp symbol.
Also, the new keyword should be documented in the manual.
> - (user-error "Unknown LaTeX class `%s'" class))))
> + (user-error "Unknown LaTeX class `%s'" class)))
> + (pre-header (mapconcat
> + #'org-element-normalize-string
> + (list (plist-get info :latex-pre-header) ""))))
mapconcat is redundant here.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
@ 2023-09-16 18:00 10% Juan Manuel Macías
2023-09-17 10:02 6% ` Ihor Radchenko
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-16 18:00 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
Rationale for this patch: in certain cases, in a LaTeX document, it is
necessary to add code before the class declaration (\documentclass...).
For example, commands like \PassOptionsToPackage, \DocumentMetadata{ },
etc.; or certain packages that should be loaded first using
\RequirePackage{}; and other miscellaneous cases[1]. I think that by
defining a new keyword `latex_pre_header', which behaves the same as
latex_header but concatenated before the class, these situations can be
resolved from Org.
[1] A longer example to export to a pdf that has pdf-x compliance, with
the pdfx package:
\providecommand{\pdfxopts}{x-1a}
\begin{filecontents*}{\jobname.xmpdata}
\Title{Some Title}
\Author{Author}
\Language{es-ES}
\Keywords{keywords}
\Publisher{publisher}
\end{filecontents*}
\documentclass{...
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-latex-Add-LATEX_PRE_HEADER-keyword.patch --]
[-- Type: text/x-patch, Size: 1944 bytes --]
From ac6b743a4489f7bc8ab1cdae7ffd3b36e5f3c1d2 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 16 Sep 2023 19:22:39 +0200
Subject: [PATCH] lisp/ox-latex.el (latex): Add `LATEX_PRE_HEADER' keyword
* (org-latex-make-preamble): In some cases it is necessary to add code
before the `\documentclass' line. `LATEX_PRE_HEADER' behaves the same as
`LATEX_HEADER', except that it is concatenated before the class.
---
lisp/ox-latex.el | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 14105c7cc..5e97b8b3d 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -124,6 +124,7 @@
(:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t)
(:latex-header "LATEX_HEADER" nil nil newline)
(:latex-header-extra "LATEX_HEADER_EXTRA" nil nil newline)
+ (:latex-pre-header "LATEX_PRE_HEADER" nil nil newline)
(:description "DESCRIPTION" nil nil parse)
(:keywords "KEYWORDS" nil nil parse)
(:subtitle "SUBTITLE" nil nil parse)
@@ -1984,13 +1985,18 @@ specified in `org-latex-default-packages-alist' or
(replace-regexp-in-string
"^[ \t]*\\\\documentclass\\(\\(\\[[^]]*\\]\\)?\\)"
class-options header t nil 1))))
- (user-error "Unknown LaTeX class `%s'" class))))
+ (user-error "Unknown LaTeX class `%s'" class)))
+ (pre-header (mapconcat
+ #'org-element-normalize-string
+ (list (plist-get info :latex-pre-header) ""))))
(org-latex-guess-polyglossia-language
(org-latex-guess-babel-language
(org-latex-guess-inputenc
(org-element-normalize-string
(org-splice-latex-header
- class-template
+ (if pre-header
+ (format "%s\n%s" pre-header class-template)
+ class-template)
(org-latex--remove-packages org-latex-default-packages-alist info)
(org-latex--remove-packages org-latex-packages-alist info)
snippet?
--
2.42.0
^ permalink raw reply related [relevance 10%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-12 18:12 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
@ 2023-09-15 9:54 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-15 9:54 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> [1] I think also that in this function there was an unhappy decision:
> using a syntax that is not from polyglossia but from babel leaves the
> user with little freedom of action, since polyglossia has more 'keyval'
> options, not only language variants. For example, this (real polyglossia
> code):
>
> \usepackage{polyglossia}
> \setmainlanguage{spanish}
> \setotherlanguage[numerals=arabic]{chinese}
>
> cannot be translated from (fake polyglossia code):
>
> #+language: es
> #+LaTeX_Header: \usepackage[chinese,AUTO]{polyglossia}
Since we are up to extending #+language keyword in future, may as well
allow LANG [:key val ...] values.
I expressed similar idea in https://list.orgmode.org/orgmode/87fsc05hkl.fsf@localhost/
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
@ 2023-09-12 18:12 10% ` Juan Manuel Macías
2023-09-15 9:54 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-12 18:12 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
>>> Every piece of code accessing this public constant must implement
>>> fallback from e.g. "de-ch" (or de_CH) to "de". Or to "en" for an
>>> unsupported language.
>> Not necessarily. I mostly thought about some unconventional code
>> that
>> uses the constant for some reason unexpected to us. We do not want to
>> break that.
>
> My point is that direct usage of `org-latex-language-alist' should be
> discouraged.
I understand that org-latex-language-alist is a temporary patch waiting
for something better, and is very dependent on
org-latex-guess-babel-language and
org-latex-guess-polyglossia-language[1], two functions that (IMHO)
should be made obsolete in the future. Keep in mind that the old
org-latex-babel-language-alist was more focused on the old babel ldf
files, which is a limited number of languages. Polyglossia also has a
rather limited number of supported languages. The ini files system is
more extensive and more flexible. One can even define new "virtual"
languages using \babelprovide, or write new custom ini files. With this
scenario a closed list like org-latex-language-alist doesn't make much
sense. I actually think that there would be no need for any ad hoc list
of this type for latex, and everything should be delegated to a global
language name translation system like the one Ihor is developing. I
think that would be the first stone to build native Org multilingual
support.
[1] I think also that in this function there was an unhappy decision:
using a syntax that is not from polyglossia but from babel leaves the
user with little freedom of action, since polyglossia has more 'keyval'
options, not only language variants. For example, this (real polyglossia
code):
\usepackage{polyglossia}
\setmainlanguage{spanish}
\setotherlanguage[numerals=arabic]{chinese}
cannot be translated from (fake polyglossia code):
#+language: es
#+LaTeX_Header: \usepackage[chinese,AUTO]{polyglossia}
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-10 21:15 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
@ 2023-09-11 8:32 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-11 8:32 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> For context, I plan to provide a global language-identifier alist that
>> will link human-readable language names to abbreviations like "de",
>> "de-de", etc. These abbreviations are not unique to LaTeX, but also used
>> elsewhere, so there is no guarantee that babel .ini files will always
>> use a consistent set of language abbreviations.
>
> Is the code you're working on in a public repository, to keep an eye
> on?
Not really. The story starts from the previous discussion of
translations in your French quote patch:
https://list.orgmode.org/orgmode/87pm3e6qx3.fsf@localhost/
I started writing it and realized that the current situation with all
the translations scattered all over the place (at least, ox libraries,
column view, and org-clock) is not ideal. So, I plan to factor out all
the translations into a separate file (say, org-translate). That file
will also define common interfaces to work with language codes and
translating phrases.
> As I mentioned in previous messages, that seems like a great improvement
> to me. I think it was not a happy decision at the time to use languages
> codes to declare the language of the document in Org. Language codes can
> be useful at a low level (although they can also lead to confusion), but
> I think that for a user level it is more practical to use human-readable
> names, as is done in babel or polyglossia, and in general, any user
> interface outside of LaTeX. Although babel also allows language codes as
> a value for some \babelprovide options (for example, I can define a new
> "virtual" language, importing the Greek captions:
> \babelprovide[captions=el]{mylanguage}).
That's very LaTeX-specific and will be limited to LaTeX export.
I do not see any problem since we have to support languages defined by
language code anyway, for backwards compatibility.
> In case it helps you, on page. 19 of the Babel manual there is an
> exhaustive list of all the languages codes, and on p. 22 a list of
> supported (human readable) language names for loading ini files. The
> language names of the old ldf files are on p. 49:
>
> https://CTAN/macros/latex/required/babel/base/babel.pdf
Thanks!
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
@ 2023-09-10 21:15 10% ` Juan Manuel Macías
2023-09-11 8:32 5% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-10 21:15 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> For context, I plan to provide a global language-identifier alist that
> will link human-readable language names to abbreviations like "de",
> "de-de", etc. These abbreviations are not unique to LaTeX, but also used
> elsewhere, so there is no guarantee that babel .ini files will always
> use a consistent set of language abbreviations.
Is the code you're working on in a public repository, to keep an eye on?
As I mentioned in previous messages, that seems like a great improvement
to me. I think it was not a happy decision at the time to use languages
codes to declare the language of the document in Org. Language codes can
be useful at a low level (although they can also lead to confusion), but
I think that for a user level it is more practical to use human-readable
names, as is done in babel or polyglossia, and in general, any user
interface outside of LaTeX. Although babel also allows language codes as
a value for some \babelprovide options (for example, I can define a new
"virtual" language, importing the Greek captions:
\babelprovide[captions=el]{mylanguage}).
In case it helps you, on page. 19 of the Babel manual there is an
exhaustive list of all the languages codes, and on p. 22 a list of
supported (human readable) language names for loading ini files. The
language names of the old ldf files are on p. 49:
https://CTAN/macros/latex/required/babel/base/babel.pdf
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-10 11:06 3% ` Juan Manuel Macías
@ 2023-09-10 13:36 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-10 13:36 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The fact of avoiding copy/paste is already an advantage. New patch
> attached with your suggestions.
Thanks!
Applied, onto main.
I amended the commit message, removing the statement about list of
language identifiers and adding a link to this discussion.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=893c5d085
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-10 7:55 5% ` Ihor Radchenko
@ 2023-09-10 11:06 3% ` Juan Manuel Macías
2023-09-10 13:36 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-10 11:06 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Max Nikulin
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
Ihor Radchenko writes:
> It is not that complex, really. I suggested the above approach because:
> 1. It is easy to read - clearly, ,@de-plist and ,@de-plist are the same
> thing.
> 2. If we ever need to change de-plist, we should only do it in a single
> place.
The fact of avoiding copy/paste is already an advantage. New patch
attached with your suggestions. I have simply modified the variable name
a little. de-plist may seem a bit confusing, because there is also de-at
(Austrian German). I have set de-default-plist, since for babel and
polyglossia German (de) and German from Germany (de-de) are the default
variant. The same with the case of the Chinese (Chinese = Chinese
Simplified).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: 0001-ox-latex.el-Fixes-and-improvements-in-org-latex-lang.patch --]
[-- Type: text/x-patch, Size: 22021 bytes --]
From 73057fc06990f861468c397c94b7076d025acbc8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 8 Sep 2023 19:33:25 +0200
Subject: [PATCH] ox-latex.el: Fixes and improvements in
`org-latex-language-alist'.
* (org-latex-language-alist): Fix a language code (`de-de') removed
when `org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' were merged. To allow language
codes that can have a similar translation in `babel' or `polyglossia'
now in each element of `org-latex-language-alist' car can also be a
list of language codes. New admitted properties: `:babel-ini-alt',
`:script' and `:script-tag'. Add language code for ancient Greek.
Fix Afrikaans (was previously removed). New languages: Chinese
Simplified and Traditional. Correction of some typos, errors and
inaccuracies. `let' bindings suggested by Ihor Radchenko.
* (org-latex-guess-babel-language): Some necessary modifications.
---
lisp/ox-latex.el | 197 ++++++++++++++++++++++++++---------------------
1 file changed, 109 insertions(+), 88 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 241ef603a..14105c7cc 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -177,94 +177,105 @@
;;; Internal Variables
(defconst org-latex-language-alist
- '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
- ("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
- ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
- ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
- ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
- ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
- ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton")
- ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
- ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
- ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech")
- ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
- ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish")
- ("de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
- ("de-at" :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
- ("dsb" :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
- ("dv" :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
- ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek")
- ("el-polyton" :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
- ("en" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
- ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
- ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
- ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
- ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
- ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
- ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
- ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
- ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
- ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque")
- ("fa" :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
- ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
- ("fr" :babel "french" :polyglossia "french" :lang-name "French")
- ("fr-ca" :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
- ("fur" :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
- ("ga" :babel "irish" :polyglossia "irish" :lang-name "Irish")
- ("gd" :babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic")
- ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician")
- ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew")
- ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi")
- ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian")
- ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian")
- ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar")
- ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian")
- ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua")
- ("id" :babel-ini-only "bahasai" :polyglossia "bahasai" :lang-name "Bahasai")
- ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic")
- ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian")
- ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada")
- ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin")
- ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin")
- ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin")
- ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin")
- ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao")
- ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian")
- ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian")
- ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam")
- ("mr" :babel-ini-only "maranthi" :polyglossia "maranthi" :lang-name "Maranthi")
- ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål")
- ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch")
- ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk")
- ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian")
- ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan")
- ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish")
- ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese")
- ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges")
- ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges")
- ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh")
- ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian")
- ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian")
- ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit")
- ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak")
- ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene")
- ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian")
- ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian")
- ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish")
- ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac")
- ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil")
- ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu")
- ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai")
- ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen")
- ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish")
- ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian")
- ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu")
- ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese"))
+ (let ((de-default-plist '(:babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn"))
+ (zh-default-plist '(:babel-ini-only "chinese" :polyglossia "chinese" :polyglossia-variant "simplified" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans")))
+ `(("af" :babel "afrikaans" :polyglossia "afrikaans" :lang-name "Afrikaans" :script "latin" :script-tag "latn")
+ ("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic" :script "ethiopic" :script-tag "ethi")
+ ("ar" :babel-ini-only "arabic" :polyglossia "arabic" :lang-name "Arabic" :script "arabic" :script-tag "arab")
+ ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian" :script "latin" :script-tag "latn")
+ ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian" :script "cyrillic" :script-tag "cyrl")
+ ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali" :script "bengali" :script-tag: "beng")
+ ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan" :script "tibetan" :script-tag "tib")
+ ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton" :script "latin" :script-tag "latn")
+ ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan" :script "latin" :script-tag "latn")
+ ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic" :script "coptic" :script-tag "copt")
+ ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech" :script "latin" :script-tag "latn")
+ ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh" :script "latin" :script-tag "latn")
+ ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish" :script "latin" :script-tag "latn")
+ ("de" ,@de-default-plist)
+ ("de-de" ,@de-default-plist)
+ ("de-at" :babel "naustrian" :babel-ini-alt "german-austria" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German" :script "latin" :script-tag "latn")
+ ("dsb" :babel "lowersorbian" :babel-ini-alt "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian" :script "latin" :script-tag "latn")
+ ("dv" :polyglossia "divehi" :lang-name "Dhivehi" :script "latin" :script-tag "latn")
+ ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek" :script "greek" :script-tag "grek")
+ ("el-polyton" :babel "polutonikogreek" :babel-ini-alt "polytonicgreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek" :script "greek" :script-tag "grek")
+ ("grc" :babel "greek.ancient" :babel-ini-alt "ancientgreek" :polyglossia "greek" :polyglossia-variant "ancient" :lang-name "Ancient Greek" :script "greek" :script-tag "grek")
+ ("en" :babel "english" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-ca" :babel "canadian" :polyglossia "english" :polyglossia-variant "canadian" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :script-tag "latn")
+ ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto" :script "latin" :script-tag "latn")
+ ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish" :script "latin" :script-tag "latn")
+ ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish" :script "latin" :script-tag "latn")
+ ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian" :script "latin" :script-tag "latn")
+ ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque" :script "latin" :script-tag "latn")
+ ("fa" :babel "persian" :polyglossia "persian" :lang-name "Persian" :script "arabic" :script-tag "arab")
+ ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish" :script "latin" :script-tag "latn")
+ ("fr" :babel "french" :polyglossia "french" :lang-name "French" :script "latin" :script-tag "latn")
+ ("fr-ca" :babel "canadien" :babel-ini-alt "canadian" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French" :script "latin" :script-tag "latn")
+ ("fur" :babel "friulian" :polyglossia "friulian" :lang-name "Friulian" :script "latin" :script-tag "latn")
+ ("ga" :babel "irish" :polyglossia "gaelic" :polyglossia-variant "irish" :lang-name "Irish Gaelic" :script "latin" :script-tag "latn")
+ ("gd" :babel "scottish" :polyglossia "gaelic" :polyglossia-variant "scottish" :lang-name "Scottish Gaelic" :script "latin" :script-tag "latn")
+ ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician" :script "latin" :script-tag "latn")
+ ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew" :script "hebrew" :script-tag "hebr")
+ ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi" :script "devanagari" :script-tag "deva")
+ ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian" :script "latin" :script-tag "latn")
+ ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian" :script "latin" :script-tag "latn")
+ ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar" :script "latin" :script-tag "latn")
+ ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian" :script "armenian" :script-tag "armn")
+ ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua" :script "latin" :script-tag "latn")
+ ("id" :babel "indonesian" :polyglossia "malay" :polyglossia-variant "indonesian" :lang-name "Indonesian" :script "latin" :script-tag "latn")
+ ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic" :script "latin" :script-tag "latn")
+ ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian" :script "latin" :script-tag "latn")
+ ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada" :script "kannada" :script-tag "knda")
+ ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin" :script "latin" :script-tag "latn")
+ ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin" :script "latin" :script-tag "latn")
+ ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin" :script "latin" :script-tag "latn")
+ ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin" :script "latin" :script-tag "latn")
+ ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao" :script "lao" :script-tag "lao")
+ ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian" :script "latin" :script-tag "latn")
+ ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian" :script "latin" :script-tag "latn")
+ ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam" :script "malayalam" :script-tag "mlym")
+ ("mr" :babel-ini-only "marathi" :polyglossia "marathi" :lang-name "Marathi" :script "devanagari" :script-tag "deva")
+ ("ms" :babel "malay" :polyglossia "malay" :polyglossia-variant "malaysian" :lang-name "Malay" :script "latin" :script-tag "latn")
+ ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål" :script "latin" :script-tag "latn")
+ ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch" :script "latin" :script-tag "latn")
+ ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk" :script "latin" :script-tag "latn")
+ ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian" :script "latin" :script-tag "latn")
+ ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan" :script "latin" :script-tag "latn")
+ ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish" :script "latin" :script-tag "latn")
+ ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese" :script "latin" :script-tag "latn")
+ ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges" :script "latin" :script-tag "latn")
+ ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges" :script "latin" :script-tag "latn")
+ ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh" :script "latin" :script-tag "latn")
+ ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian" :script "latin" :script-tag "latn")
+ ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian" :script "cyrillic" :script-tag "cyrl")
+ ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit" :script "devanagari" :script-tag "deva")
+ ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak" :script "latin" :script-tag "latn")
+ ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene" :script "latin" :script-tag "latn")
+ ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian" :script "latin" :script-tag "latn")
+ ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian" :script "latin" :script-tag "latn")
+ ("sr-cyrl" :babel-ini-only "serbian-cyrl" :polyglossia "serbian" :lang-name "Serbian" :script "cyrillic" :script-tag "cyrl")
+ ("sr-latn" :babel-ini-only "serbian-latin" :polyglossia "serbian" :lang-name "Serbian" :script "latin" :script-tag "latn")
+ ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish" :script "latin" :script-tag "latn")
+ ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac" :script "syriac" :script-tag "syrc")
+ ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil" :script "tamil" :script-tag "taml")
+ ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu" :script "telugu" :script-tag "telu")
+ ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai" :script "thai" :script-tag "thai")
+ ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen" :script "latin" :script-tag "latn")
+ ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish" :script "latin" :script-tag "latn")
+ ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian" :script "cyrillic" :script-tag "cyrl")
+ ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu" :script "arabic" :script-tag "arab")
+ ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese" :script "latin" :script-tag "latn")
+ ("zh" ,@zh-default-plist)
+ ("zh-cn" ,@zh-default-plist)
+ ("zh-tw" :babel-ini-only "chinese-traditional" :polyglossia "chinese" :polyglossia-variant "traditional" :lang-name "Chinese Traditional" :script "hant" :script-tag "hant")))
"Alist between language code and its properties for LaTeX export.
-In each element of the list car is always the code of the
-language and cdr is a property list. Valid keywords for this
-list can be:
+In each element of the list car is always the language code and
+cdr is a property list. Valid keywords for this list can be:
- `:babel' the name of the language loaded by the Babel LaTeX package
@@ -275,9 +286,17 @@ list can be:
exclusively through the new ini files method. See
`http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf'
+- `:babel-ini-alt' an alternative language name when it is loaded
+ using ini files
+
- `:polyglossia-variant' the language variant loaded by Polyglossia
-- `:lang-name' the actual name of the language.")
+- `:lang-name' the actual name of the language
+
+- `:script' the script name
+
+- `:script-tag' the script otf tag.")
+
(defconst org-latex-line-break-safe "\\\\[0pt]"
"Linebreak protecting the following [...].
@@ -1660,6 +1679,7 @@ Return the new header."
(assoc language-code org-latex-language-alist)))
(language (plist-get plist :babel))
(language-ini-only (plist-get plist :babel-ini-only))
+ (language-ini-alt (plist-get plist :babel-ini-alt))
;; If no language is set, or Babel package is not loaded, or
;; LANGUAGE keyword value is a language served by Babel
;; exclusively through ini files, return HEADER as-is.
@@ -1691,7 +1711,8 @@ Return the new header."
(replace-regexp-in-string (format
"\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
(format "\\1\\2%s}"
- (or language language-ini-only))
+ (if language-ini-alt language-ini-alt
+ (or language language-ini-only)))
header t)
header)))))
--
2.42.0
^ permalink raw reply related [relevance 3%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-09 23:59 11% ` Juan Manuel Macías
@ 2023-09-10 7:55 5% ` Ihor Radchenko
2023-09-10 11:06 3% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-10 7:55 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> (let ((de-plist '(...)))
>> `(...
>> ("de" ,@de-plist)
>> ("de-de" ,@de-plist)
>> ...))
>>
>> This is copy-paste-proof and does not require breaking changes in the
>> value structure.
>
> I like the idea because it avoids errors, but I don't know if
> it's worth it, there being only two cases (at the moment).
It is not that complex, really. I suggested the above approach because:
1. It is easy to read - clearly, ,@de-plist and ,@de-plist are the same
thing.
2. If we ever need to change de-plist, we should only do it in a single
place.
> ... This other
> possibility occurred to me, just to make it easier to read and not have
> to navigate to the list of variables:
>
> (let* ((basic-code)
> (shared-plist (lambda (&rest plist)
> (setq basic-code plist))))
> `(...
> ("de" ,(funcall shared-plist :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn"))
> ("de-de" ,@basic-code)
> ...
> ("zh" ,(funcall shared-plist :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans"))
> ("zh-cn" ,@basic-code)))
This is less readable compared to having ",@de-plist" - ",@de-plist".
One would need to put extra effort to understand the equality of
(funcall shared-plist ...) and ,@basic-code.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-09 11:33 6% ` Ihor Radchenko
@ 2023-09-09 23:59 11% ` Juan Manuel Macías
2023-09-10 7:55 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-09 23:59 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Max Nikulin
Ihor Radchenko writes:
> I am thinking about something like
>
> (let ((de-plist '(...)))
> `(...
> ("de" ,@de-plist)
> ("de-de" ,@de-plist)
> ...))
>
> This is copy-paste-proof and does not require breaking changes in the
> value structure.
I like the idea because it avoids errors, but I don't know if
it's worth it, there being only two cases (at the moment). This other
possibility occurred to me, just to make it easier to read and not have
to navigate to the list of variables:
(let* ((basic-code)
(shared-plist (lambda (&rest plist)
(setq basic-code plist))))
`(...
("de" ,(funcall shared-plist :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn"))
("de-de" ,@basic-code)
...
("zh" ,(funcall shared-plist :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans"))
("zh-cn" ,@basic-code)))
Likewise, there being two cases (even in the case of Chinese you could
perfectly omit zh-cn, because it is a new language and there is no
danger of regression), I would say that it is not worth complicating the
code so much.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-09 10:36 12% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
@ 2023-09-09 11:33 6% ` Ihor Radchenko
2023-09-09 23:59 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-09 11:33 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I am not sure if making a breaking change to public constant is the best
>> approach.
>> What about simply adding an extra entry:
>> ("de" ....)
>> ("de-de" <copy of "de" property list>)
>> ?
>
> At first I had done it with extra entries, but I was wondering if there
> wasn't a more "economical" way... If you don't mind having extra entries
> with identical plists, then I do it that way. After all, there are only
> two cases (Chinese and German).
I am thinking about something like
(let ((de-plist '(...)))
`(...
("de" ,@de-plist)
("de-de" ,@de-plist)
...))
This is copy-paste-proof and does not require breaking changes in the
value structure.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fixes and improvements in org-latex-language-alist
2023-09-09 9:11 6% ` Ihor Radchenko
@ 2023-09-09 10:36 12% ` Juan Manuel Macías
2023-09-09 11:33 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-09 10:36 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode, Max Nikulin
Ihor Radchenko writes:
>> I don't know if it's a valid path to allow the car of each element to
>> also be a list of languages codes, but I couldn't think of a better
>> solution for the "de"/"de-de" cases. A similar case is in Chinese
>> Simplified (new language added), where the possible language codes are
>> zh and zh-cn, if I'm not wrong.
>
> I am not sure if making a breaking change to public constant is the best
> approach.
> What about simply adding an extra entry:
> ("de" ....)
> ("de-de" <copy of "de" property list>)
> ?
At first I had done it with extra entries, but I was wondering if there
wasn't a more "economical" way... If you don't mind having extra entries
with identical plists, then I do it that way. After all, there are only
two cases (Chinese and German).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6)
2023-09-08 19:02 3% ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Juan Manuel Macías
@ 2023-09-09 9:11 6% ` Ihor Radchenko
2023-09-09 10:36 12% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2023-09-09 9:11 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode, Max Nikulin
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think that with this patch the possible regressions are removed. I
> took the opportunity to add some improvements (the :babel-ini-alt,
> :script and :script-tag properties) and correct some errors and typos.
>
> I don't know if it's a valid path to allow the car of each element to
> also be a list of languages codes, but I couldn't think of a better
> solution for the "de"/"de-de" cases. A similar case is in Chinese
> Simplified (new language added), where the possible language codes are
> zh and zh-cn, if I'm not wrong.
I am not sure if making a breaking change to public constant is the best
approach.
What about simply adding an extra entry:
("de" ....)
("de-de" <copy of "de" property list>)
?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6)
2023-09-08 14:42 10% ` Juan Manuel Macías
@ 2023-09-08 19:02 3% ` Juan Manuel Macías
2023-09-09 9:11 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-08 19:02 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Max Nikulin, Ihor Radchenko
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
I think that with this patch the possible regressions are removed. I
took the opportunity to add some improvements (the :babel-ini-alt,
:script and :script-tag properties) and correct some errors and typos.
I don't know if it's a valid path to allow the car of each element to
also be a list of languages codes, but I couldn't think of a better
solution for the "de"/"de-de" cases. A similar case is in Chinese
Simplified (new language added), where the possible language codes are
zh and zh-cn, if I'm not wrong.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: 0001-ox-latex.el-Fixes-and-improvements-in-org-latex-lang.patch --]
[-- Type: text/x-patch, Size: 22948 bytes --]
From 52f17bc841241562a52e91159cb1531dbe5684e1 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 8 Sep 2023 19:33:25 +0200
Subject: [PATCH] ox-latex.el: Fixes and improvements in
`org-latex-language-alist'.
* (org-latex-language-alist): Fix a language code (`de-de') removed
when `org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' were merged. To allow language
codes that can have a similar translation in `babel' or `polyglossia'
now in each element of `org-latex-language-alist' car can also be a
list of language codes. New admitted properties: `:babel-ini-alt',
`:script' and `:script-tag'. Add language code for ancient Greek.
Fix Afrikaans (was previously removed). New languages: Chinese
Simplified and Traditional. Correction of some typos, errors and
inaccuracies.
* (org-latex-guess-babel-language): Some necessary modifications.
* (org-latex-guess-polyglossia-language): Some necessary modifications.
---
lisp/ox-latex.el | 208 +++++++++++++++++++++++++++--------------------
1 file changed, 118 insertions(+), 90 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 241ef603a..d6790ea27 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -177,94 +177,102 @@
;;; Internal Variables
(defconst org-latex-language-alist
- '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
- ("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
- ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
- ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
- ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
- ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
- ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton")
- ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
- ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
- ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech")
- ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
- ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish")
- ("de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
- ("de-at" :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
- ("dsb" :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
- ("dv" :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
- ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek")
- ("el-polyton" :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
- ("en" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
- ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
- ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
- ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
- ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
- ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
- ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
- ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
- ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
- ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque")
- ("fa" :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
- ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
- ("fr" :babel "french" :polyglossia "french" :lang-name "French")
- ("fr-ca" :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
- ("fur" :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
- ("ga" :babel "irish" :polyglossia "irish" :lang-name "Irish")
- ("gd" :babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic")
- ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician")
- ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew")
- ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi")
- ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian")
- ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian")
- ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar")
- ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian")
- ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua")
- ("id" :babel-ini-only "bahasai" :polyglossia "bahasai" :lang-name "Bahasai")
- ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic")
- ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian")
- ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada")
- ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin")
- ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin")
- ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin")
- ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin")
- ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao")
- ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian")
- ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian")
- ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam")
- ("mr" :babel-ini-only "maranthi" :polyglossia "maranthi" :lang-name "Maranthi")
- ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål")
- ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch")
- ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk")
- ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian")
- ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan")
- ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish")
- ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese")
- ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges")
- ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges")
- ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh")
- ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian")
- ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian")
- ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit")
- ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak")
- ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene")
- ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian")
- ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian")
- ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish")
- ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac")
- ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil")
- ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu")
- ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai")
- ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen")
- ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish")
- ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian")
- ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu")
- ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese"))
+ '(("af" :babel "afrikaans" :polyglossia "afrikaans" :lang-name "Afrikaans" :script "latin" :script-tag "latn")
+ ("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic" :script "ethiopic" :script-tag "ethi")
+ ("ar" :babel-ini-only "arabic" :polyglossia "arabic" :lang-name "Arabic" :script "arabic" :script-tag "arab")
+ ("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian" :script "latin" :script-tag "latn")
+ ("bg" :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian" :script "cyrillic" :script-tag "cyrl")
+ ("bn" :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali" :script "bengali" :script-tag: "beng")
+ ("bo" :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan" :script "tibetan" :script-tag "tib")
+ ("br" :babel "breton" :polyglossia "breton" :lang-name "Breton" :script "latin" :script-tag "latn")
+ ("ca" :babel "catalan" :polyglossia "catalan" :lang-name "Catalan" :script "latin" :script-tag "latn")
+ ("cop" :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic" :script "coptic" :script-tag "copt")
+ ("cs" :babel "czech" :polyglossia "czech" :lang-name "Czech" :script "latin" :script-tag "latn")
+ ("cy" :babel "welsh" :polyglossia "welsh" :lang-name "Welsh" :script "latin" :script-tag "latn")
+ ("da" :babel "danish" :polyglossia "danish" :lang-name "Danish" :script "latin" :script-tag "latn")
+ (("de" "de-de") :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn")
+ ("de-at" :babel "naustrian" :babel-ini-alt "german-austria" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German" :script "latin" :script-tag "latn")
+ ("dsb" :babel "lowersorbian" :babel-ini-alt "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian" :script "latin" :script-tag "latn")
+ ("dv" :polyglossia "divehi" :lang-name "Dhivehi" :script "latin" :script-tag "latn")
+ ("el" :babel "greek" :polyglossia "greek" :lang-name "Greek" :script "greek" :script-tag "grek")
+ ("el-polyton" :babel "polutonikogreek" :babel-ini-alt "polytonicgreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek" :script "greek" :script-tag "grek")
+ ("grc" :babel "greek.ancient" :babel-ini-alt "ancientgreek" :polyglossia "greek" :polyglossia-variant "ancient" :lang-name "Ancient Greek" :script "greek" :script-tag "grek")
+ ("en" :babel "english" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-au" :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-ca" :babel "canadian" :polyglossia "english" :polyglossia-variant "canadian" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-gb" :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-nz" :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English" :script "latin" :script-tag "latn")
+ ("en-us" :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :script-tag "latn")
+ ("eo" :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto" :script "latin" :script-tag "latn")
+ ("es" :babel "spanish" :polyglossia "spanish" :lang-name "Spanish" :script "latin" :script-tag "latn")
+ ("es-mx" :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish" :script "latin" :script-tag "latn")
+ ("et" :babel "estonian" :polyglossia "estonian" :lang-name "Estonian" :script "latin" :script-tag "latn")
+ ("eu" :babel "basque" :polyglossia "basque" :lang-name "Basque" :script "latin" :script-tag "latn")
+ ("fa" :babel "persian" :polyglossia "persian" :lang-name "Persian" :script "arabic" :script-tag "arab")
+ ("fi" :babel "finnish" :polyglossia "finnish" :lang-name "Finnish" :script "latin" :script-tag "latn")
+ ("fr" :babel "french" :polyglossia "french" :lang-name "French" :script "latin" :script-tag "latn")
+ ("fr-ca" :babel "canadien" :babel-ini-alt "canadian" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French" :script "latin" :script-tag "latn")
+ ("fur" :babel "friulian" :polyglossia "friulian" :lang-name "Friulian" :script "latin" :script-tag "latn")
+ ("ga" :babel "irish" :polyglossia "gaelic" :polyglossia-variant "irish" :lang-name "Irish Gaelic" :script "latin" :script-tag "latn")
+ ("gd" :babel "scottish" :polyglossia "gaelic" :polyglossia-variant "scottish" :lang-name "Scottish Gaelic" :script "latin" :script-tag "latn")
+ ("gl" :babel "galician" :polyglossia "galician" :lang-name "Galician" :script "latin" :script-tag "latn")
+ ("he" :babel "hebrew" :polyglossia "hebrew" :lang-name "Hebrew" :script "hebrew" :script-tag "hebr")
+ ("hi" :babel "hindi" :polyglossia "hindi" :lang-name "Hindi" :script "devanagari" :script-tag "deva")
+ ("hr" :babel "croatian" :polyglossia "croatian" :lang-name "Croatian" :script "latin" :script-tag "latn")
+ ("hsb" :babel "uppersorbian" :polyglossia "sorbian" :polyglossia-variant "upper" :lang-name "Upper Sorbian" :script "latin" :script-tag "latn")
+ ("hu" :babel "magyar" :polyglossia "magyar" :lang-name "Magyar" :script "latin" :script-tag "latn")
+ ("hy" :babel-ini-only "armenian" :polyglossia "armenian" :lang-name "Armenian" :script "armenian" :script-tag "armn")
+ ("ia" :babel "interlingua" :polyglossia "interlingua" :lang-name "Interlingua" :script "latin" :script-tag "latn")
+ ("id" :babel "indonesian" :polyglossia "malay" :polyglossia-variant "indonesian" :lang-name "Indonesian" :script "latin" :script-tag "latn")
+ ("is" :babel "icelandic" :polyglossia "icelandic" :lang-name "Icelandic" :script "latin" :script-tag "latn")
+ ("it" :babel "italian" :polyglossia "italian" :lang-name "Italian" :script "latin" :script-tag "latn")
+ ("kn" :babel-ini-only "kannada" :polyglossia "kannada" :lang-name "Kannada" :script "kannada" :script-tag "knda")
+ ("la" :babel "latin" :polyglossia "latin" :lang-name "Latin" :script "latin" :script-tag "latn")
+ ("la-classic" :babel "classiclatin" :polyglossia "latin" :polyglossia-variant "classic" :lang-name "Classic Latin" :script "latin" :script-tag "latn")
+ ("la-medieval" :babel "medievallatin" :polyglossia "latin" :polyglossia-variant "medieval" :lang-name "Medieval Latin" :script "latin" :script-tag "latn")
+ ("la-ecclesiastic" :babel "ecclesiasticlatin" :polyglossia "latin" :polyglossia-variant "ecclesiastic" :lang-name "Ecclesiastic Latin" :script "latin" :script-tag "latn")
+ ("lo" :babel-ini-only "lao" :polyglossia "lao" :lang-name "Lao" :script "lao" :script-tag "lao")
+ ("lt" :babel "lithuanian" :polyglossia "lithuanian" :lang-name "Lithuanian" :script "latin" :script-tag "latn")
+ ("lv" :babel "latvian" :polyglossia "latvian" :lang-name "Latvian" :script "latin" :script-tag "latn")
+ ("ml" :babel-ini-only "malayalam" :polyglossia "malayalam" :lang-name "Malayalam" :script "malayalam" :script-tag "mlym")
+ ("mr" :babel-ini-only "marathi" :polyglossia "marathi" :lang-name "Marathi" :script "devanagari" :script-tag "deva")
+ ("ms" :babel "malay" :polyglossia "malay" :polyglossia-variant "malaysian" :lang-name "Malay" :script "latin" :script-tag "latn")
+ ("nb" :babel "norsk" :polyglossia "norwegian" :polyglossia-variant "bokmal" :lang-name "Norwegian Bokmål" :script "latin" :script-tag "latn")
+ ("nl" :babel "dutch" :polyglossia "dutch" :lang-name "Dutch" :script "latin" :script-tag "latn")
+ ("nn" :babel "nynorsk" :polyglossia "norwegian" :polyglossia-variant "nynorsk" :lang-name "Norwegian Nynorsk" :script "latin" :script-tag "latn")
+ ("no" :babel "norsk" :polyglossia "norsk" :lang-name "Norwegian" :script "latin" :script-tag "latn")
+ ("oc" :babel "occitan" :polyglossia "occitan" :lang-name "Occitan" :script "latin" :script-tag "latn")
+ ("pl" :babel "polish" :polyglossia "polish" :lang-name "Polish" :script "latin" :script-tag "latn")
+ ("pms" :babel "piedmontese" :polyglossia "piedmontese" :lang-name "Piedmontese" :script "latin" :script-tag "latn")
+ ("pt" :babel "portuges" :polyglossia "portuges" :lang-name "Portuges" :script "latin" :script-tag "latn")
+ ("pt-br" :babel "brazilian" :polyglossia "brazilian" :lang-name "Portuges" :script "latin" :script-tag "latn")
+ ("rm" :babel-ini-only "romansh" :polyglossia "romansh" :lang-name "Romansh" :script "latin" :script-tag "latn")
+ ("ro" :babel "romanian" :polyglossia "romanian" :lang-name "Romanian" :script "latin" :script-tag "latn")
+ ("ru" :babel "russian" :polyglossia "russian" :lang-name "Russian" :script "cyrillic" :script-tag "cyrl")
+ ("sa" :babel-ini-only "sanskrit" :polyglossia "sanskrit" :lang-name "Sanskrit" :script "devanagari" :script-tag "deva")
+ ("sk" :babel "slovak" :polyglossia "slovak" :lang-name "Slovak" :script "latin" :script-tag "latn")
+ ("sl" :babel "slovene" :polyglossia "slovene" :lang-name "Slovene" :script "latin" :script-tag "latn")
+ ("sq" :babel "albanian" :polyglossia "albanian" :lang-name "Albanian" :script "latin" :script-tag "latn")
+ ("sr" :babel "serbian" :polyglossia "serbian" :lang-name "Serbian" :script "latin" :script-tag "latn")
+ ("sr-cyrl" :babel-ini-only "serbian-cyrl" :polyglossia "serbian" :lang-name "Serbian" :script "cyrillic" :script-tag "cyrl")
+ ("sr-latn" :babel-ini-only "serbian-latin" :polyglossia "serbian" :lang-name "Serbian" :script "latin" :script-tag "latn")
+ ("sv" :babel "swedish" :polyglossia "swedish" :lang-name "Swedish" :script "latin" :script-tag "latn")
+ ("syr" :babel-ini-only "syriac" :polyglossia "syriac" :lang-name "Syriac" :script "syriac" :script-tag "syrc")
+ ("ta" :babel-ini-only "tamil" :polyglossia "tamil" :lang-name "Tamil" :script "tamil" :script-tag "taml")
+ ("te" :babel-ini-only "telugu" :polyglossia "telugu" :lang-name "Telugu" :script "telugu" :script-tag "telu")
+ ("th" :babel "thai" :polyglossia "thai" :lang-name "Thai" :script "thai" :script-tag "thai")
+ ("tk" :babel "turkmen" :polyglossia "turkmen" :lang-name "Turkmen" :script "latin" :script-tag "latn")
+ ("tr" :babel "turkish" :polyglossia "turkish" :lang-name "Turkish" :script "latin" :script-tag "latn")
+ ("uk" :babel "ukrainian" :polyglossia "ukrainian" :lang-name "Ukrainian" :script "cyrillic" :script-tag "cyrl")
+ ("ur" :babel-ini-only "urdu" :polyglossia "urdu" :lang-name "Urdu" :script "arabic" :script-tag "arab")
+ ("vi" :babel "vietnamese" :polyglossia "vietnamese" :lang-name "Vietnamese" :script "latin" :script-tag "latn")
+ (("zh" "zh-cn") :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans")
+ ("zh-tw" :babel-ini-only "chinese-traditional" :polyglossia "chinese" :polyglossia-variant "traditional" :lang-name "Chinese Traditional" :script "hant" :script-tag "hant"))
"Alist between language code and its properties for LaTeX export.
-In each element of the list car is always the code of the
-language and cdr is a property list. Valid keywords for this
-list can be:
+In each element of the list car is always the language code or a
+list of languages codes and cdr is a property list. Valid
+keywords for this list can be:
- `:babel' the name of the language loaded by the Babel LaTeX package
@@ -275,9 +283,17 @@ list can be:
exclusively through the new ini files method. See
`http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf'
+- `:babel-ini-alt' an alternative language name when it is loaded
+ using ini files
+
- `:polyglossia-variant' the language variant loaded by Polyglossia
-- `:lang-name' the actual name of the language.")
+- `:lang-name' the actual name of the language
+
+- `:script' the script name
+
+- `:script-tag' the script otf tag.")
+
(defconst org-latex-line-break-safe "\\\\[0pt]"
"Linebreak protecting the following [...].
@@ -1657,9 +1673,15 @@ already loaded.
Return the new header."
(let* ((language-code (plist-get info :language))
(plist (cdr
- (assoc language-code org-latex-language-alist)))
+ (cl-assoc-if (lambda (x)
+ (or (and (stringp x)
+ (string= language-code x))
+ (and (listp x)
+ (member language-code x))))
+ org-latex-language-alist)))
(language (plist-get plist :babel))
(language-ini-only (plist-get plist :babel-ini-only))
+ (language-ini-alt (plist-get plist :babel-ini-alt))
;; If no language is set, or Babel package is not loaded, or
;; LANGUAGE keyword value is a language served by Babel
;; exclusively through ini files, return HEADER as-is.
@@ -1691,7 +1713,8 @@ Return the new header."
(replace-regexp-in-string (format
"\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
(format "\\1\\2%s}"
- (or language language-ini-only))
+ (if language-ini-alt language-ini-alt
+ (or language language-ini-only)))
header t)
header)))))
@@ -1736,7 +1759,12 @@ Return the new header."
(mapconcat
(lambda (l)
(let* ((plist (cdr
- (assoc language org-latex-language-alist)))
+ (cl-assoc-if (lambda (x)
+ (or (and (stringp x)
+ (string= language x))
+ (and (listp x)
+ (member language x))))
+ org-latex-language-alist)))
(polyglossia-variant (plist-get plist :polyglossia-variant))
(polyglossia-lang (plist-get plist :polyglossia))
(l (if (equal l language)
--
2.42.0
^ permalink raw reply related [relevance 3%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-08 10:30 0% ` Max Nikulin
@ 2023-09-08 14:42 10% ` Juan Manuel Macías
2023-09-08 19:02 3% ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-08 14:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> I am still unsure that de and de-de should be mapped to different
> babel language configurations.
I think that for practical purposes de and de-de should be treated the
same in both babel and polyglossia. In the new fixed version of
org-babel-language-alist I thought it would be useful to support a list
of languages codes as car for each element, in addition to a simple
string. In such a way:
(("de" "de-de") :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag "latn")
I've had to make some small modifications to
org-latex-guess-babel/polyglossia-language, to get that to work.
:babel-ini-alt refers to an alternative name that is used only if
\babelprovide is present. I'm also adding the :script and :script-tag
properties for each language.
I have done something similar with the case of Chinese Simplified (a new
language that I have added):
(("zh" "zh-cn") :babel-ini-only "chinese" :polyglossia "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans")
Between today and tomorrow I will try to send the patch. I saw that
org-latex-language-alist had a few typos as well, some inherited from
the previous lists that were merged.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-07 14:49 6% ` Max Nikulin
@ 2023-09-08 10:30 0% ` Max Nikulin
2023-09-08 14:42 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-08 10:30 UTC (permalink / raw)
To: emacs-orgmode
On 07/09/2023 21:49, Max Nikulin wrote:
> On 07/09/2023 21:19, Juan Manuel Macías wrote:
>> I think I can introduce some fixes to org-latex-language-alist to
>> restore the removed language codes
>
> I have no idea why in
>
> 393f2f5ae 2012-06-14 12:57:35 +0200 Nicolas Goaziou: org-e-latex: Set
> Babel language according to LANGUAGE keyword
https://list.orgmode.org/871umay444.fsf@med.uni-goettingen.de/
Andreas Leha <andreas.leha@med.uni-goettingen.de> Re: new (LaTeX)
exporter and date formatting. Wed, 23 May 2012 23:33:31 +0200
contains a table that is likely a source for Nicolas' commit:
> this list of LaTeX-babel supported languages from
> http://www.tug.org/texlive/Contents/live/texmf-dist/doc/generic/babel/babel.pdf:
>
> | LaTeX babel | lang symbol |
> |--------------+-------------|
> | austrian | de-at |
> | german | de |
> | germanb | de |
> | ngerman | de-de |
Contemporary babel.pdf contains another table (1.13 ini files)
de-1901 German
de-1996 German
de-AT-1901 Austrian German
de-AT-1996 Austrian German
de-AT Austrian German
de-CH-1901 Swiss High German
de-CH-1996 Swiss High German
de-CH Swiss High German
I am still unsure that de and de-de should be mapped to different babel
language configurations.
^ permalink raw reply [relevance 0%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-07 12:04 9% ` Juan Manuel Macías
@ 2023-09-08 7:42 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-09-08 7:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I am not sure if I like "russian*" idea. May you explain a bit more
>> about how onchar works? What if language characters are intersecting,
>> and not using exactly the same char sets?
>
> Basically, it's like I said above. According to the Babel Manual:
>
> #+begin_quote
> onchar= ids | fonts | letters
>
> This option is much like an ‘event’ called when a character belonging to
> the script of this locale is found (as its name implies, it acts on
> characters, not on spaces). There are currently two ‘actions’, which can
> be used at the same time (separated by a space): with ids the \language
> and the \localeid are set to the values of this locale; with fonts, the
> fonts are changed to those of this locale (as set with \babelfont).
> Characters can be added or modified with \babelcharproperty.
>
> [...] Option letters restricts the ‘actions’ to letters, in the TEX
> sense (i. e., with catcode 11). Digits and punctuation are then
> considered part of current locale (as set by a selector). This option is
> useful when the main script is non-Latin and there is a secondary one
> whose script is Latin.
> #+end_quote
Thanks for the explanation!
Then, language* it is. I have no better idea.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-07 14:19 12% ` Juan Manuel Macías
@ 2023-09-07 14:49 6% ` Max Nikulin
2023-09-08 10:30 0% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-07 14:49 UTC (permalink / raw)
To: emacs-orgmode
On 07/09/2023 21:19, Juan Manuel Macías wrote:
> I think I can introduce some fixes to org-latex-language-alist to
> restore the removed language codes
I have no idea why in
393f2f5ae 2012-06-14 12:57:35 +0200 Nicolas Goaziou: org-e-latex: Set
Babel language according to LANGUAGE keyword
new "ngerman" was used for de-de, while older "germanb" was chosen for
"de". From my point of view modern ngerman rules should be used in both
cases. Those who really need older style may specify germanb explicitly,
not through #+language mapping. Difference de-de vs. de is rather subtle
to rely on it.
^ permalink raw reply [relevance 6%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-07 11:50 6% ` Ihor Radchenko
@ 2023-09-07 14:19 12% ` Juan Manuel Macías
2023-09-07 14:49 6% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-07 14:19 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
>> In both lists the language code for German is simply "de". Of course,
>> I'm no expert on the subject, so if I'm wrong in this case, I should
>> revert the change. I understand that de-de is German of Germany (="de"?); on
>> org-latex-language-alist exists de-at (Austrian German). The babel ini
>> file for german babel/locale/de/babel-de.ini has this id:
>
> I understand the motivation, but the end result is a clear regression.
> May you please review 97cfb959d and recover the removed language names
> to put into #+language as aliases to their correct names?
I think I can introduce some fixes to org-latex-language-alist to
restore the removed language codes, without breaking the new and
maintaining compatibility with the old. As soon as I have some time I
will send a patch. Probably this weekend.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-07 10:22 5% ` Ihor Radchenko
@ 2023-09-07 12:04 9% ` Juan Manuel Macías
2023-09-08 7:42 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-07 12:04 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> May we explicitly set the needed font around language environments?
>
> Something like
>
> \setfontforrussian
> \selectlanguage{russian}
> ....
>
> \setfontforbulgarian
> \selectlanguage{bulgarian}
> ....
There's no need. With \babelfont you can associate a font with a
language (declared with both the classic syntax and \babelprovide. And
when you use \selectlanguage, \foreignlanguage or any other babel
command or environment to switch languages, the associated font is
activated for that language. For example:
\babelprovide[import]{russian}
\babelprovide[import]{bulgarian}
\babelfont[russian]{rm}[]{Old Standard}
\babelfont[bulgarian]{rm}[]{Freeserif}
and then:
\selectlanguage{russian}
...
\selectlanguage{bulgarian}
...
\babelprovide supports several properties. Adding the onchar=ids
fonts/letters property equates language and script, and everything in
that script is associated with a font. This would only make sense to use
when there is only one language in the document that has that script, as
we discussed before. In case like russian/bulgarian, the source of the
last babelprovide is overwritten for all cases where that script
appears.
>
>> In any case (to organize myself mentally) I thought that it could be
>> done on two levels:
>>
>> - Level 0: The fonts associated with each script are loaded (from a
>> defcustom list) if luatex is the current engine. And low-level code is
>> generated in Lua with the luaotfload.add_fallback function. That code
>> can be in a Lua file or directly within the preamble, enclosed in the
>> \directlua primitive (mode=harf means that HarfBuzz is used as otf
>> rendering):
>> ...
>
> Sounds reasonable.
>
>> - Level 1: The user can load language properties and associate fonts
>> with each language using Babel's high-level code (via keywords in Org,
>> as we have commented in previous messages). Here you can also modify
>> the default fonts (also, as we mentioned before): main, mono, sans and
>> math. If the language is declared with an asterisk (for example:
>> russian*) the onchar=etc property will be included in the preamble,
>> and it would not be necessary to switch to russian explicitly. It is
>> assumed that in this scenario the only language with Cyrillic script
>> would be Russian. For language swithcing, in the rest of the cases,
>> some babel command would have to be used using @@latex:@@, special
>> blocks, etc. When Org already has its own language switching
>> mechanism, this would be used instead. Wdyt?
>
> I am not sure if I like "russian*" idea. May you explain a bit more
> about how onchar works? What if language characters are intersecting,
> and not using exactly the same char sets?
Basically, it's like I said above. According to the Babel Manual:
#+begin_quote
onchar= ids | fonts | letters
This option is much like an ‘event’ called when a character belonging to
the script of this locale is found (as its name implies, it acts on
characters, not on spaces). There are currently two ‘actions’, which can
be used at the same time (separated by a space): with ids the \language
and the \localeid are set to the values of this locale; with fonts, the
fonts are changed to those of this locale (as set with \babelfont).
Characters can be added or modified with \babelcharproperty.
[...] Option letters restricts the ‘actions’ to letters, in the TEX
sense (i. e., with catcode 11). Digits and punctuation are then
considered part of current locale (as set by a selector). This option is
useful when the main script is non-Latin and there is a secondary one
whose script is Latin.
#+end_quote
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-06 22:20 8% ` Juan Manuel Macías
2023-09-07 10:38 5% ` Max Nikulin
@ 2023-09-07 11:50 6% ` Ihor Radchenko
2023-09-07 14:19 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-07 11:50 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Max Nikulin writes:
>
>> I consider the following as an issue rather close to the discussion in
>> the thread
>> Juan Manuel Macías. Fallback fonts in LaTeX export for non latin
>> scripts. Wed, 30 Aug 2023 08:25:53 +0000.
>> https://list.orgmode.org/878r9t7x7y.fsf@posteo.net
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
>> elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug
>> report logs
>>
>> I am unsure if the change was intentional.
>
> I seem to remember that when I made org-latex-language-alist I made some
> corrections to a few language codes. I was guided by page 19 of the
> Babel manual and by
>
> https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
> In both lists the language code for German is simply "de". Of course,
> I'm no expert on the subject, so if I'm wrong in this case, I should
> revert the change. I understand that de-de is German of Germany (="de"?); on
> org-latex-language-alist exists de-at (Austrian German). The babel ini
> file for german babel/locale/de/babel-de.ini has this id:
I understand the motivation, but the end result is a clear regression.
May you please review 97cfb959d and recover the removed language names
to put into #+language as aliases to their correct names?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-06 22:20 8% ` Juan Manuel Macías
@ 2023-09-07 10:38 5% ` Max Nikulin
2023-09-07 11:50 6% ` Ihor Radchenko
1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2023-09-07 10:38 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
On 07/09/2023 05:20, Juan Manuel Macías wrote:
> Maybe it should be corrected like this:
>
> ("de-de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
> ("de" :babel-ini-only "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
Sorry, I have only used basic babel configuration, so I am unaware of
real differences of .ldf and .ini ways. My expectation is that in
absence of "de-de" definition a fallback to "de" should be used.
Perhaps .ldf vs. .ini should be an orthogonal setting independent of
locale selection.
Frankly speaking, I am a bit confused by locale definitions in general:
ls /usr/share/locale/ | grep '^de'
de
de_CH
de_DE
de@hebrew
ls /usr/share/i18n/locales/ | grep '^de'
de_AT
de_AT@euro
de_BE
de_BE@euro
de_CH
de_DE
de_DE@euro
de_IT
de_LI
de_LU
de_LU@euro
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-06 14:58 8% ` Juan Manuel Macías
@ 2023-09-07 10:22 5% ` Ihor Radchenko
2023-09-07 12:04 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-07 10:22 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Do I understand correctly that onchar=id will not break anything if text
>> is correctly marked with \selectlanguage{<lang>}?
>
> To load language features (hyphen rules, captions, etc.) there is no
> problem. But to load a font associated with a language, the font of the
> last declared language will always be loaded.
May we explicitly set the needed font around language environments?
Something like
\setfontforrussian
\selectlanguage{russian}
....
\setfontforbulgarian
\selectlanguage{bulgarian}
....
> In any case (to organize myself mentally) I thought that it could be
> done on two levels:
>
> - Level 0: The fonts associated with each script are loaded (from a
> defcustom list) if luatex is the current engine. And low-level code is
> generated in Lua with the luaotfload.add_fallback function. That code
> can be in a Lua file or directly within the preamble, enclosed in the
> \directlua primitive (mode=harf means that HarfBuzz is used as otf
> rendering):
> ...
Sounds reasonable.
> - Level 1: The user can load language properties and associate fonts
> with each language using Babel's high-level code (via keywords in Org,
> as we have commented in previous messages). Here you can also modify
> the default fonts (also, as we mentioned before): main, mono, sans and
> math. If the language is declared with an asterisk (for example:
> russian*) the onchar=etc property will be included in the preamble,
> and it would not be necessary to switch to russian explicitly. It is
> assumed that in this scenario the only language with Cyrillic script
> would be Russian. For language swithcing, in the rest of the cases,
> some babel command would have to be used using @@latex:@@, special
> blocks, etc. When Org already has its own language switching
> mechanism, this would be used instead. Wdyt?
I am not sure if I like "russian*" idea. May you explain a bit more
about how onchar works? What if language characters are intersecting,
and not using exactly the same char sets?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: ox-latex language handling in Org-9.5 vs 9.6
2023-09-06 14:55 5% ox-latex language handling in Org-9.5 vs 9.6 Max Nikulin
@ 2023-09-06 22:20 8% ` Juan Manuel Macías
2023-09-07 10:38 5% ` Max Nikulin
2023-09-07 11:50 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-06 22:20 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> I consider the following as an issue rather close to the discussion in
> the thread
> Juan Manuel Macías. Fallback fonts in LaTeX export for non latin
> scripts. Wed, 30 Aug 2023 08:25:53 +0000.
> https://list.orgmode.org/878r9t7x7y.fsf@posteo.net
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
> elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug
> report logs
>
> I am unsure if the change was intentional.
I seem to remember that when I made org-latex-language-alist I made some
corrections to a few language codes. I was guided by page 19 of the
Babel manual and by
https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
In both lists the language code for German is simply "de". Of course,
I'm no expert on the subject, so if I'm wrong in this case, I should
revert the change. I understand that de-de is German of Germany (="de"?); on
org-latex-language-alist exists de-at (Austrian German). The babel ini
file for german babel/locale/de/babel-de.ini has this id:
[identification]
charset = utf8
version = 1.3
date = 2020-06-30
name.local = Deutsch
name.english = German
name.babel = german
name.polyglossia = german
tag.bcp47 = de
language.tag.bcp47 = de
tag.bcp47.likely = de-Latn-DE
tag.opentype = DEU
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
level = 1
encodings = T1 OT1 LY1
derivate = no
and babel-de-AT.ini:
[identification]
charset = utf8
version = 1.3
date = 2020-06-30
name.local = Deutsch
name.english = German
name.babel = austrian german-austria german-at
name.polyglossia = german
tag.bcp47 = de-AT
language.tag.bcp47 = de
tag.opentype = DEU
region.local = Österreich
region.english = Austria
region.tag.bcp47 = AT
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
polyglossia.variant = austrian
polyglossia.spelling = new
level = 1
encodings = T1 OT1 LY1
derivate = no
ini files use german and german-at, but in classic babel nomenclature
(ldf files) we have ngerman and naustrian.
Maybe it should be corrected like this:
("de-de" :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
("de" :babel-ini-only "german" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
The case of de-at is more problematic because a single language code
serves for naustrian (ldf) and (ini:) austrian, german-at and
german-austria. Some new property, something like :babel-ini-alt, would
have to be introduced . There are other similar cases on the list, such
as el-polyton, which points to polutonikogreek (ldf). In general, except
in cases where only the ini file exists, I used the ldf nomenclature for
backward compatibility.
In any case, these dances of language names between some places and
others make the list of language names that Ihor is working on
increasingly necessary.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 8%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-06 9:29 6% ` Ihor Radchenko
@ 2023-09-06 14:58 8% ` Juan Manuel Macías
2023-09-07 10:22 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-06 14:58 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko
Ihor Radchenko writes:
> Do I understand correctly that onchar=id will not break anything if text
> is correctly marked with \selectlanguage{<lang>}?
To load language features (hyphen rules, captions, etc.) there is no
problem. But to load a font associated with a language, the font of the
last declared language will always be loaded. Well, it is not a problem,
because if in a document there are texts in Russian and Bulgarian, for
example, the natural thing is that they go in the same font, since both
languages share the Cyrillic script. But there may be cases when the
author needs different fonts. In such a case, the user should not use
the onchar = etc property:
https://i.imgur.com/vmsCNkP.png
In any case (to organize myself mentally) I thought that it could be
done on two levels:
- Level 0: The fonts associated with each script are loaded (from a
defcustom list) if luatex is the current engine. And low-level code is
generated in Lua with the luaotfload.add_fallback function. That code
can be in a Lua file or directly within the preamble, enclosed in the
\directlua primitive (mode=harf means that HarfBuzz is used as otf
rendering):
\directlua
{luaotfload.add_fallback("orgfallback",
{
"oldstandard:mode=harf;script=grek;",
"oldstandard:mode=harf;script=cyrl;",
"freeserif:mode=harf;script=arab;",
"freeserif:mode=harf;script=dev2;",
etc., etc.
})
}
And, to load the fallback fonts:
\setmainfont{latinmodernroman}[RawFeature={fallback=orgfallback}]
At this level per-language properties are not loaded, but at least
readability is ensured. The user cannot modify the fonts associated
with each script within the document, but can modify, of course, the
defcustom.
- Level 1: The user can load language properties and associate fonts
with each language using Babel's high-level code (via keywords in Org,
as we have commented in previous messages). Here you can also modify
the default fonts (also, as we mentioned before): main, mono, sans and
math. If the language is declared with an asterisk (for example:
russian*) the onchar=etc property will be included in the preamble,
and it would not be necessary to switch to russian explicitly. It is
assumed that in this scenario the only language with Cyrillic script
would be Russian. For language swithcing, in the rest of the cases,
some babel command would have to be used using @@latex:@@, special
blocks, etc. When Org already has its own language switching
mechanism, this would be used instead. Wdyt?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 8%]
* ox-latex language handling in Org-9.5 vs 9.6
@ 2023-09-06 14:55 5% Max Nikulin
2023-09-06 22:20 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-06 14:55 UTC (permalink / raw)
To: emacs-orgmode
Hi,
I consider the following as an issue rather close to the discussion in
the thread
Juan Manuel Macías. Fallback fonts in LaTeX export for non latin
scripts. Wed, 30 Aug 2023 08:25:53 +0000.
https://list.orgmode.org/878r9t7x7y.fsf@posteo.net
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug
report logs
I am unsure if the change was intentional.
#+language: de-de
#+latex_header: \usepackage[AUTO]{babel}
is exported to
\usepackage[ngerman]{babel}
% ...
\hypersetup{
% ...
pdflang={Ngerman}}
by Org-9.5 and as
\usepackage[]{babel}
% ...
\hypersetup{
% ...
pdflang={De-De}}
by Org-9.6. Similar user expectation should be had in mind during
planning of further changes.
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-05 18:33 12% ` Juan Manuel Macías
@ 2023-09-06 9:29 6% ` Ihor Radchenko
2023-09-06 14:58 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-06 9:29 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode, Ihor Radchenko
Juan Manuel Macías <maciaschain@posteo.net> writes:
> True. Thanks for pointing it out. Indeed, \babelprovide with the
> ochar=id fonts option only makes sense when 1 foreign language = 1
> script. For example, different variants of Greek cannot be combined
> without an explicit switch.
>
> And something like this wouldn't work either:
>
> \babelprovide[import,onchar=id fonts]{russian}
> \babelprovide[import,onchar=id fonts]{bulgarian}
> \babelfont[russian]{rm}[Color=blue]{Old Standard}
> \babelfont[bulgarian]{rm}[Color=green]{FreeSerif}
>
> because bulgarian overwrites russian.
>
> Well, another added complication :-(.
AFAIU, there is simply no way to solve this unless the user manually
indicates the indented language.
Do I understand correctly that onchar=id will not break anything if text
is correctly marked with \selectlanguage{<lang>}?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-05 16:42 6% ` Max Nikulin
@ 2023-09-05 18:33 12% ` Juan Manuel Macías
2023-09-06 9:29 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-05 18:33 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode, Ihor Radchenko
Max Nikulin writes:
> Cyrillic letters may appear not only in Russian just as French and
> Spanish use Latin script. So language detection based on symbol code
> points works only for distinct enough languages. Explicit markup may
> still be necessary to switch hyphenation rules, dash styles, etc.
True. Thanks for pointing it out. Indeed, \babelprovide with the
ochar=id fonts option only makes sense when 1 foreign language = 1
script. For example, different variants of Greek cannot be combined
without an explicit switch.
And something like this wouldn't work either:
\babelprovide[import,onchar=id fonts]{russian}
\babelprovide[import,onchar=id fonts]{bulgarian}
\babelfont[russian]{rm}[Color=blue]{Old Standard}
\babelfont[bulgarian]{rm}[Color=green]{FreeSerif}
because bulgarian overwrites russian.
Well, another added complication :-(.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-04 22:22 7% ` Juan Manuel Macías
2023-09-05 10:44 5% ` Ihor Radchenko
@ 2023-09-05 16:42 6% ` Max Nikulin
2023-09-05 18:33 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2023-09-05 16:42 UTC (permalink / raw)
To: emacs-orgmode
On 05/09/2023 05:22, Juan Manuel Macías wrote:
> \usepackage[english,french,spanish,provide*=*]{babel}
>
> but in that line we cannot put Russian with onchar, etc.
Cyrillic letters may appear not only in Russian just as French and
Spanish use Latin script. So language detection based on symbol code
points works only for distinct enough languages. Explicit markup may
still be necessary to switch hyphenation rules, dash styles, etc.
I have a couple of bookmarks for language detection libraries (not for
Emacs), but I am unsure if they may work for texts containing fragments
written in different languages.
^ permalink raw reply [relevance 6%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-04 22:22 7% ` Juan Manuel Macías
@ 2023-09-05 10:44 5% ` Ihor Radchenko
2023-09-20 14:03 5% ` Juan Manuel Macías
2023-09-05 16:42 6% ` Max Nikulin
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-05 10:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> The idea is to allow
>>
>> #+language: Austrian German, Greek
>> as a valid specifier, in addition to
>>
>> #+language: de-at, el
>>
>> Then, across Org, we will make use of the standardized language
>> abbreviations.
>
> In LaTeX, as I mentioned, things are complicated. There is Babel and
> Polyglossia, and there is LuaTeX and XeTeX. In addition, there is also
> pdfTeX, which is still the default engine and (to be honest) is the
> engine used by a high percentage of LaTeX users. Although perhaps things
> will change soon to the detriment of LuaTeX. Both babel and polyglossia
> could be supported, but that means more work, more code, and more
> complications. And we are not sure that polyglossia is no longer
> maintained. After all, babel is the official LaTeX package for language
> support, and polyglossia appeared at a time when babel had no support
> for the new unicode engines. Now Babel supports all of that and is much
> more powerful, but its interface has also grown in complexity. There is
> the problem of the double syntax for loading languages: the old one,
> which loads traditional ldf files, and the modern one (\babelprovide),
> which loads languages using ini files. It is more powerful, with more
> options, but has added more verbosity to babel. I have taken advantage
> of \babelprovide, specifically its onchar=id fonts property, to
> automatically apply fonts to non-Latin scripts.
> ...
> multilingual support that does not exist as such. It is more like font
> support for non-Latin languages. And only in LaTeX, and specifically in
> LuaLaTeX. Furthermore, the user could mix languages that in Babel are
> loaded through ldf and others through ini files. For example, something
> like this:
>
> #+language: spanish, english, french, russian
>
> in Babel it would be:
>
> \usepackage[english,french,spanish]{babel}
>
> and here we need babelprovide for the font (and load Russian via ini
> file):
>
> \babelprovide[onchar=id fonts, import]{russian}
> \babelfont[russian]{rm}[options]{somefont}
>
> Org would have to discern which name refers to a non-Latin language
> (which wouldn't be complicated with the functionality you're working on)
> and then apply the default font by adding a line with \babelprovide.
>
> Of course, English, French and Spanish can also be loaded via ini files:
>
> \babelprovide[main,import]{spanish}
> \babelprovide[import]{french}
> \babelprovide[import]{english}
>
> Even babel also supports:
>
> \usepackage[english,french,spanish,provide*=*]{babel}
>
> but in that line we cannot put Russian with onchar, etc. And then there
> is pdfTeX, where only the classic babel syntax is allowed, without any
> "*provide".
Aren't we already handling this problem in `org-latex-make-preamble'?
>> My idea was that
>>
>> #+language: ancientgreek russian arabic
>>
>> implies "use default font for arabic", unless #+latex_font is specified.
>
> This seems the most consistent to me for Org, but, as I mentioned in the
> other email, I have some concerns. Currently, what we are talking about
> is simply font support for non-Latin languages. If it is allowed, in the
> current state of things, that #+language can accept a list of language
> names, we can give the user a wrong perception of reality. That is:
<complications with full support not being possible in all the LaTeX flavors>
> In short, I find everything very confusing. I am not opposed to doing it
> as you propose (in fact, it is the option I like the most, especially
> when org is polyglot in the future), but I also want to warn of possible
> complications.
>
> Therefore, since we are, for now, with fonts for non-Latin languages, I
> think it should be made clear that the keyword is about fonts (and about
> LuaLaTeX). Maybe through two keywords:
>
> #+lualatex_fonts_for: language(s)
> #+lualatex_fonts[language(s)]: "font" options
>
> ?
>
> I think it's ugly, but I can't think of anything else.
Maybe just
#+lualatex_fonts[languages(s)]: default
to force the default.
> By the way, and as a side note, is it currently possible in Org to
> define a keyword within :options-alist of the style #+foo[anything] or
> would something like org-collect-keywords have to be modified?
We will need to add things to `org-element-dual-keywords' and make sure
that the code expects the keyword value to be a list, as returned by the
parser. AFAIU, it should be enough.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-04 8:09 4% ` Ihor Radchenko
@ 2023-09-04 22:22 7% ` Juan Manuel Macías
2023-09-05 10:44 5% ` Ihor Radchenko
2023-09-05 16:42 6% ` Max Nikulin
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-09-04 22:22 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Timothy
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> #+language: ancientgreek russian arabic
>>
>> Of course, this syntax would be the most appropriate and consistent
>> within Org. The problem is LaTeX, specifically babel, and that certain
>> inconsistencies would be created with the rest of the backends. At first
>> some pitfalls come to mind:
>>
>> - The keyword #+language accepts for now only language codes (es, en,
>> el, ar, ru, etc.). Consistency with other backends should
>> be maintained in this regard: ancientgreek is not a valid language
>> code, but a name that only babel understands. If we put something
>> like (a valid language code):
>>
>> #+language: el-polyton
>>
>> this could be translated in babel as polutonikogreek (in the classic
>> syntax, that is, the languages that are loaded in the options of
>> \usepackage[options]{babel}), or, in the new syntax, ancientgreek and
>> polytonicgreek, which are actually two different languages: the first
>> is ancient polytonic Greek and the second modern polytonic Greek. To
>> add more confusion to the matter, in classical babel syntax
>> greek.ancient and greek.polytonic are also supported. But neither of
>> these things can be deduced by simply putting el-polyton, unless
>> breaking the consistency with the other backends.
>
> I am now working on unifying Org translation system as discussed in
> https://orgmode.org/list/87o7iw8yem.fsf@bzg.fr
> As a part of the effort, I plan to introduce a new constant that will
> unify language abbreviations across Org and also associate them with
> more human-readable names.
>
> (defconst org-language-abbrevs
> '(("am". "Amharic")
> ("ar" . "Arabic")
> ("ast" . "Asturian")
> ("bg" . "Bulgarian")
> ("bn" . "Bengali")
> ...))
>
> The idea is to allow
>
> #+language: Austrian German, Greek
> as a valid specifier, in addition to
>
> #+language: de-at, el
>
> Then, across Org, we will make use of the standardized language
> abbreviations.
Great! I think it's great news. Yes, I agree with what you say below. I
think Org should move towards a multilingual support that is 100% native
to Org. That is, Org had its own "selectlanguage" mechanism, to be able
to delimit text segments in other languages and have control over them,
both within Org and when exporting to the different backends. That
scenario seems very desirable to me, and I would like to contribute my
help to the best of my ability (and time).
In LaTeX, as I mentioned, things are complicated. There is Babel and
Polyglossia, and there is LuaTeX and XeTeX. In addition, there is also
pdfTeX, which is still the default engine and (to be honest) is the
engine used by a high percentage of LaTeX users. Although perhaps things
will change soon to the detriment of LuaTeX. Both babel and polyglossia
could be supported, but that means more work, more code, and more
complications. And we are not sure that polyglossia is no longer
maintained. After all, babel is the official LaTeX package for language
support, and polyglossia appeared at a time when babel had no support
for the new unicode engines. Now Babel supports all of that and is much
more powerful, but its interface has also grown in complexity. There is
the problem of the double syntax for loading languages: the old one,
which loads traditional ldf files, and the modern one (\babelprovide),
which loads languages using ini files. It is more powerful, with more
options, but has added more verbosity to babel. I have taken advantage
of \babelprovide, specifically its onchar=id fonts property, to
automatically apply fonts to non-Latin scripts.
>> I like this idea, but with the exception that in the two examples you
>> give the user is declaring two fonts for both languages. In my example
>> there was also Arabic, where the default font for the Arabic script is
>> used.
>
> My idea was that
>
> #+language: ancientgreek russian arabic
>
> implies "use default font for arabic", unless #+latex_font is specified.
This seems the most consistent to me for Org, but, as I mentioned in the
other email, I have some concerns. Currently, what we are talking about
is simply font support for non-Latin languages. If it is allowed, in the
current state of things, that #+language can accept a list of language
names, we can give the user a wrong perception of reality. That is:
multilingual support that does not exist as such. It is more like font
support for non-Latin languages. And only in LaTeX, and specifically in
LuaLaTeX. Furthermore, the user could mix languages that in Babel are
loaded through ldf and others through ini files. For example, something
like this:
#+language: spanish, english, french, russian
in Babel it would be:
\usepackage[english,french,spanish]{babel}
and here we need babelprovide for the font (and load Russian via ini
file):
\babelprovide[onchar=id fonts, import]{russian}
\babelfont[russian]{rm}[options]{somefont}
Org would have to discern which name refers to a non-Latin language
(which wouldn't be complicated with the functionality you're working on)
and then apply the default font by adding a line with \babelprovide.
Of course, English, French and Spanish can also be loaded via ini files:
\babelprovide[main,import]{spanish}
\babelprovide[import]{french}
\babelprovide[import]{english}
Even babel also supports:
\usepackage[english,french,spanish,provide*=*]{babel}
but in that line we cannot put Russian with onchar, etc. And then there
is pdfTeX, where only the classic babel syntax is allowed, without any
"*provide".
In short, I find everything very confusing. I am not opposed to doing it
as you propose (in fact, it is the option I like the most, especially
when org is polyglot in the future), but I also want to warn of possible
complications.
Therefore, since we are, for now, with fonts for non-Latin languages, I
think it should be made clear that the keyword is about fonts (and about
LuaLaTeX). Maybe through two keywords:
#+lualatex_fonts_for: language(s)
#+lualatex_fonts[language(s)]: "font" options
?
I think it's ugly, but I can't think of anything else.
By the way, and as a side note, is it currently possible in Org to
define a keyword within :options-alist of the style #+foo[anything] or
would something like org-collect-keywords have to be modified?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 7%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-03 11:05 6% ` Juan Manuel Macías
@ 2023-09-04 8:09 4% ` Ihor Radchenko
2023-09-04 22:22 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-04 8:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> #+language: ancientgreek russian arabic
>
> Of course, this syntax would be the most appropriate and consistent
> within Org. The problem is LaTeX, specifically babel, and that certain
> inconsistencies would be created with the rest of the backends. At first
> some pitfalls come to mind:
>
> - The keyword #+language accepts for now only language codes (es, en,
> el, ar, ru, etc.). Consistency with other backends should
> be maintained in this regard: ancientgreek is not a valid language
> code, but a name that only babel understands. If we put something
> like (a valid language code):
>
> #+language: el-polyton
>
> this could be translated in babel as polutonikogreek (in the classic
> syntax, that is, the languages that are loaded in the options of
> \usepackage[options]{babel}), or, in the new syntax, ancientgreek and
> polytonicgreek, which are actually two different languages: the first
> is ancient polytonic Greek and the second modern polytonic Greek. To
> add more confusion to the matter, in classical babel syntax
> greek.ancient and greek.polytonic are also supported. But neither of
> these things can be deduced by simply putting el-polyton, unless
> breaking the consistency with the other backends.
I am now working on unifying Org translation system as discussed in
https://orgmode.org/list/87o7iw8yem.fsf@bzg.fr
As a part of the effort, I plan to introduce a new constant that will
unify language abbreviations across Org and also associate them with
more human-readable names.
(defconst org-language-abbrevs
'(("am". "Amharic")
("ar" . "Arabic")
("ast" . "Asturian")
("bg" . "Bulgarian")
("bn" . "Bengali")
...))
The idea is to allow
#+language: Austrian German, Greek
as a valid specifier, in addition to
#+language: de-at, el
Then, across Org, we will make use of the standardized language
abbreviations.
> - Added to this is that Babel has two ways to load languages: the
> classic syntax and the \babelprovide command, which is the one we are
> interested in here for languages with non-Latin scripts, because the
> onchar=ids fonts property must be added here. And what happens if the
> user has already defined several languages with babel, using the
> current procedure: \usepackage[french, english, AUTO]{babel}?
For LaTeX specifically, `org-latex-language-alist', will be re-used to
map whatever is allowed in #+language keyword to its name in
babel/polyglossia.
Does it make sense?
> Therefore, the least complicated thing, in my opinion, is to leave the
> syntax of the keyword #+language as it is. It is not necessary for the
> user to explicitly define secondary non-latin languages. The idea is
> that Org is responsible for generating the necessary babel code by
> simply giving a command like enable font for X language. What we are
> talking about here is ensuring readability using a series of fonts that
> LaTeX does not load by default, not even LuaLaTeX. And, after all, Org
> is monolingual: it does not have multilingual support at the moment;
> that is, there is nothing in Org to switch languages in the middle of
> the document. What happens is that here we take advantage of the
> functionality that Babel has to automatically apply a font for a
> non-Latin language/script, also loading its properties (hyphen rules,
> captions, etc.).
>
> A new keyword #+latex_language could be created, which would understand
> the babel names, but I think it is unnecessary and would add more
> complexity. As I said before, defining the necessary fonts would be
> enough, since my idea in this is a basic practicality to ensure the
> readability of the documents. And anyone looking for more advanced
> functions would have to enter LaTeX code explicitly.
I think that we should move towards multi-language support.
Such support would practically simplify WORG and orgmode.org translation
process, and may also be used as a basis to allow translating the
Org manual.
My rough idea is to allow specifying language as affiliated
keyword and, in future, allow selective export to certain target
language.
Multi-language documents are another potential target to support.
>> #+latex_font[ancientgreek]: "Linux Libertine O" Scale=MatchLowercase
>>
>> #+latex_font[russian]: "FreeSerif" Numbers=Lowercase,Color=blue
>
> I like this idea, but with the exception that in the two examples you
> give the user is declaring two fonts for both languages. In my example
> there was also Arabic, where the default font for the Arabic script is
> used.
My idea was that
#+language: ancientgreek russian arabic
implies "use default font for arabic", unless #+latex_font is specified.
> #+latex_font[arabic]: "FreeSerif" Numbers=Lowercase,Color=blue
>
> This last syntax would also be valid to modify the main default fonts:
>
> #+latex_font[main]: "FreeSerif" Numbers=Lowercase
> #+latex_font[sans]: "some font"
> #+latex_font[mono]: "some font"
> #+latex_font[math]: "some font"
>
> A practical use case. Suppose a user has a document in Spanish, which
> includes passages in Greek and Russian. It would be enough to use the
> Old Standard font (included in TeX live) for the entire document,
> ensuring consistency:
>
> #+latex_header: \usepackage[AUTO]{babel}
> #+language:es
> #+latex_font[main,greek,russian]: Old Standard
Looks reasonable.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 4%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-03 7:22 5% ` Ihor Radchenko
@ 2023-09-03 11:05 6% ` Juan Manuel Macías
2023-09-04 8:09 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-03 11:05 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode, Timothy
Thanks for your comments!
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Finally I can upload some usable code here, in this case to be able to
>> load and manage fonts for languages with non-Latin scripts, through
>> babel and fontspec (in LuaLaTeX). It is an attempt to simplify from Org
>> the multiform syntax of babel + fontspec. Of course, it is more limited,
>> but for regular use I think it may be enough.
>
> I can see that you did not add defaults for Chinese, which is one of the
> problematic scripts for LaTeX. Can you add it?
In that first proof of concept I only put a few scripts, less
problematic, simply to show the functionality. In CJK languages things
are a little more complicated, but it can be done too. The idea is to
cover all scripts. In the next code I submit, when I redo the current
one, I will try to introduce the case of CJK scripts.
>> ;; #+LaTeX_Header: % !enable-fonts-for ancientgreek:Linux Libertine O(Scale=MatchLowercase)
>> ;; #+LaTeX_Header: % !enable-fonts-for russian:FreeSerif(Numbers=Lowercase,Color=blue) :: arabic
>
> I do not like this approach.
I'm not a big fan of doing it like that either. I chose this option
because I didn't have to define a new keyword and to be less "intrusive"
with the actual code. But on the other hand it adds a new syntax. Well,
I discard it, to the detriment of an idea that you mention below.
> Would be more consistent to allow multiple languages in #+language +
> #+LATEX_FONT keyword to optionally specify per-language font:
> #+language: ancientgreek russian arabic
Of course, this syntax would be the most appropriate and consistent
within Org. The problem is LaTeX, specifically babel, and that certain
inconsistencies would be created with the rest of the backends. At first
some pitfalls come to mind:
- The keyword #+language accepts for now only language codes (es, en,
el, ar, ru, etc.). Consistency with other backends should
be maintained in this regard: ancientgreek is not a valid language
code, but a name that only babel understands. If we put something
like (a valid language code):
#+language: el-polyton
this could be translated in babel as polutonikogreek (in the classic
syntax, that is, the languages that are loaded in the options of
\usepackage[options]{babel}), or, in the new syntax, ancientgreek and
polytonicgreek, which are actually two different languages: the first
is ancient polytonic Greek and the second modern polytonic Greek. To
add more confusion to the matter, in classical babel syntax
greek.ancient and greek.polytonic are also supported. But neither of
these things can be deduced by simply putting el-polyton, unless
breaking the consistency with the other backends.
- Added to this is that Babel has two ways to load languages: the
classic syntax and the \babelprovide command, which is the one we are
interested in here for languages with non-Latin scripts, because the
onchar=ids fonts property must be added here. And what happens if the
user has already defined several languages with babel, using the
current procedure: \usepackage[french, english, AUTO]{babel}?
Therefore, the least complicated thing, in my opinion, is to leave the
syntax of the keyword #+language as it is. It is not necessary for the
user to explicitly define secondary non-latin languages. The idea is
that Org is responsible for generating the necessary babel code by
simply giving a command like enable font for X language. What we are
talking about here is ensuring readability using a series of fonts that
LaTeX does not load by default, not even LuaLaTeX. And, after all, Org
is monolingual: it does not have multilingual support at the moment;
that is, there is nothing in Org to switch languages in the middle of
the document. What happens is that here we take advantage of the
functionality that Babel has to automatically apply a font for a
non-Latin language/script, also loading its properties (hyphen rules,
captions, etc.).
A new keyword #+latex_language could be created, which would understand
the babel names, but I think it is unnecessary and would add more
complexity. As I said before, defining the necessary fonts would be
enough, since my idea in this is a basic practicality to ensure the
readability of the documents. And anyone looking for more advanced
functions would have to enter LaTeX code explicitly.
> #+latex_font[ancientgreek]: "Linux Libertine O" Scale=MatchLowercase
>
> #+latex_font[russian]: "FreeSerif" Numbers=Lowercase,Color=blue
I like this idea, but with the exception that in the two examples you
give the user is declaring two fonts for both languages. In my example
there was also Arabic, where the default font for the Arabic script is
used. Note that each script would have default fonts, which the user can
change or not change in their document. A user could simply put
something like "enable the default fonts for ancientgreek, russian,
malayalam, georgian, chinese". And nothing more. Or choose some other
font with or without options for a specific lang.
Could be:
#+latex_font: ancientgreek, russian, malayalam, sanskrit-devanagari
beside:
#+latex_font[arabic]: "FreeSerif" Numbers=Lowercase,Color=blue
This last syntax would also be valid to modify the main default fonts:
#+latex_font[main]: "FreeSerif" Numbers=Lowercase
#+latex_font[sans]: "some font"
#+latex_font[mono]: "some font"
#+latex_font[math]: "some font"
A practical use case. Suppose a user has a document in Spanish, which
includes passages in Greek and Russian. It would be enough to use the
Old Standard font (included in TeX live) for the entire document,
ensuring consistency:
#+latex_header: \usepackage[AUTO]{babel}
#+language:es
#+latex_font[main,greek,russian]: Old Standard
> Also, I think that it may still make sense to have some kind of fallback
> font if the specified fonts are not sufficient. For example, when using
> emoji symbols, which do not correspond to any language.
Yes I agree. That could also be included in the generated preamble.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 6%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-02 21:39 4% ` Juan Manuel Macías
@ 2023-09-03 7:22 5% ` Ihor Radchenko
2023-09-03 11:05 6% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-03 7:22 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode, Timothy
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Finally I can upload some usable code here, in this case to be able to
> load and manage fonts for languages with non-Latin scripts, through
> babel and fontspec (in LuaLaTeX). It is an attempt to simplify from Org
> the multiform syntax of babel + fontspec. Of course, it is more limited,
> but for regular use I think it may be enough.
I can see that you did not add defaults for Chinese, which is one of the
problematic scripts for LaTeX. Can you add it?
> ;; #+LaTeX_Header: % !enable-fonts-for ancientgreek:Linux Libertine O(Scale=MatchLowercase)
> ;; #+LaTeX_Header: % !enable-fonts-for russian:FreeSerif(Numbers=Lowercase,Color=blue) :: arabic
I do not like this approach.
Would be more consistent to allow multiple languages in #+language +
#+LATEX_FONT keyword to optionally specify per-language font:
#+LANGUAGE: <main language> <other languages...>
#+LATEX_FONT[lang]: font
#+language: ancientgreek russian arabic
#+latex_font[ancientgreek]: "Linux Libertine O" Scale=MatchLowercase
#+latex_font[russian]: "FreeSerif" Numbers=Lowercase,Color=blue
Also, I think that it may still make sense to have some kind of fallback
font if the specified fonts are not sufficient. For example, when using
emoji symbols, which do not correspond to any language.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-09-01 9:18 5% ` Ihor Radchenko
@ 2023-09-02 21:39 4% ` Juan Manuel Macías
2023-09-03 7:22 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-09-02 21:39 UTC (permalink / raw)
To: orgmode; +Cc: Ihor Radchenko, Timothy
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
Finally I can upload some usable code here, in this case to be able to
load and manage fonts for languages with non-Latin scripts, through
babel and fontspec (in LuaLaTeX). It is an attempt to simplify from Org
the multiform syntax of babel + fontspec. Of course, it is more limited,
but for regular use I think it may be enough.
Since this code is mostly a proof of concept and the names of many
things (and the things themselves) are still tentative, I thought it
would be more useful to attach it in an *.el file, rather than a regular
patch. Loading that file everything should work fine. I also attach an
org document with some examples of use. In any case, there are more
explanations inside the .el file.
One of the big problems I have encountered when trying to create a
"(LaTeX) Babel interface in Org" is the *horrible* multiplicity that
Babel has for language names. That is the reason for the :babel-alt
property in 'org-latex-language-alist', which collects the names that
babel supports for \babelprovide, which are not always the same as the
'classic' babel syntax.
Finally, I find this way more useful (that is, loading fonts with
language support), instead of a fallback font system based only on the
Unicode scripts. It is less 'automatic', but more precise, and it also
does not require much 'specialized' intervention on the part of the
user.
Best regards,
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: test-lang.org --]
[-- Type: application/vnd.lotus-organizer, Size: 2866 bytes --]
[-- Attachment #3: unicode-font-support.el --]
[-- Type: text/plain, Size: 8721 bytes --]
;; -*- lexical-binding: t; -*-
;; A proof of concept for Unicode font support in LaTeX export, using
;; babel and fontspec, with luatex as the default compiler.
;; Use example:
;; It is not necessary to load languages with non-Latin alphabet in babel options:
;; #+LaTeX_Header: \usepackage[AUTO]{babel}
;; Languages and fonts (there may be multiple lines):
;; #+LaTeX_Header: % !enable-fonts-for ancientgreek:Linux Libertine O(Scale=MatchLowercase)
;; #+LaTeX_Header: % !enable-fonts-for russian:FreeSerif(Numbers=Lowercase,Color=blue) :: arabic
;; Explanation:
;; - lang = enable default font for lang
;; - lang:font = enable font for lang in current document
;; - lanf:font(options) = enable font for lang in this document with options
;; - :: = separator
;; code
;; This is supposed to be a defcustom.
(setq org-latex-uc-fonts-support t)
;; A mini version of `org-latex-language-alist', for this proof of
;; concept. Babel uses various names for languages. The ones that
;; interest us here are those collected in `:babel-alt', which is
;; always a list. The names sometimes match the `classic' babel name
;; and other times they don't. And in the case of "el-polyton" there
;; are two possible names. For a list of these names see:
;; [[https://CTAN/macros/latex/required/babel/base/babel.pdf]],
;; p. 22.
(defconst org-latex-language-alist
'(("en" :babel "american" :babel-alt ("english-unitedstates") :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English" :script "latin" :code "latn")
("ar" :babel "arabic" :babel-alt ("arabic") :polyglossia "arabic" :lang-name "Arabic" :script "arabic" :code "arab")
("el" :babel "greek" :babel-alt ("greek") :polyglossia "greek" :lang-name "Greek" :script "greek" :code "grk")
("el-polyton" :babel "polutonikogreek" :babel-alt ("ancientgreek" "polytonicgreek") :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek" :script "greek" :code "grk")
("ru" :babel "russian" :babel-alt ("russian") :polyglossia "russian" :lang-name "Russian" :script "cyrillic" :code "cyrl"))
"TODO")
;; This is supposed to be a defcustom for the main fonts. `'default'
;; means 'use the main default fonts'. Otherwise, the value must be
;; a plist. Valid props. are:
;; - :main = roman font
;; - :sans = sans font
;; - :mono = mono font
;; - :math = math font
;; - :...-options = font options
;; For the font options and the fontspec package syntax, see
;; [[https://CTAN/macros/unicodetex/latex/fontspec/fontspec.pdf]]
(setq org-latex-uc-fonts-support-default-main-fonts
'(:main "FreeSerif" :mono "inconsolatan" :mono-options "Scale=0.95"))
;; This is supposed to be a defcustom. Each element has the structure:
;; script - font - (optional) font options
(setq org-latex-uc-fonts-support-default-scripts-fonts
'(("greek" "Linux Libertine")
("cyrillic" "Old Standard")
("arabic" "FreeSerif")))
;; Get main fonts (declared in
;; `org-latex-uc-fonts-support-default-main-fonts')
(defun org-latex-uc-fonts-support-get-main-fonts (plist prop)
(let ((format))
(if (not
(plist-member plist prop))
(ignore)
(let* ((value (plist-get plist prop))
(prop-name
(replace-regexp-in-string ":" "" (symbol-name prop)))
(options (plist-get
plist
(intern
(format
":%s-options"
prop-name)))))
(setq format
(format
"\\\\set%sfont{%s}[%s]"
prop-name value
(if options options "")
))))
format))
;; get non latin fonts explicitly added
(defun org-latex-uc-fonts-support-get-fonts-other-languages (header)
(interactive)
(let ((format-str)
(lines))
(with-temp-buffer
(insert header)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "%\s+!enable-fonts-for\s+\\(.+\\)" nil t)
(add-to-list 'lines (match-string 1)))))
(let* ((lines-list
(mapcar
(lambda (x)
(split-string x "::"))
lines))
(flat (flatten-list lines-list))
(format-list (mapcar
(lambda (x)
(org-latex-uc-fonts-support-format-font-for-language (string-trim x)))
flat)))
(setq format-str (mapconcat #'identity format-list "\n\n")))
format-str))
;; format each lang/font
(defun org-latex-uc-fonts-support-format-font-for-language (lang)
(let* ((regexp "\\([^:]+\\):*\\([^()]*\\)(*\\([^()]*\\))*")
(lang-name (when (string-match regexp lang)
(match-string 1 lang)))
(lang-explicit-font (when (string-match regexp lang)
(match-string 2 lang)))
(lang-explicit-font-opts (when (string-match regexp lang)
(match-string 3 lang)))
(lang-alias (let ((candidato))
(mapc (lambda (x)
(when (member :babel-alt x)
(let* ((plist (cdr x))
(babel-alt (plist-get plist :babel-alt)))
(when (member lang-name babel-alt)
(setq candidato (car x))))))
org-latex-language-alist)
candidato))
(plist (cdr (assoc lang-alias org-latex-language-alist)))
(script (plist-get plist :script))
(default-script-font (assoc script org-latex-uc-fonts-support-default-scripts-fonts))
(default-font (nth 1 default-script-font))
(default-font-options (nth 2 default-script-font))
(default-font-options? (if default-font-options
default-font-options
"")))
(format
"\\\\babelprovide[onchar=ids fonts]{%s}\n
\\\\babelfont[%s]{rm}[%s]{%s}\n"
lang-name
lang-name
(if (not (equal lang-explicit-font-opts "")) lang-explicit-font-opts default-font-options?)
(if (not (equal lang-explicit-font "")) lang-explicit-font default-font))))
;; make preamble definitions. This is supposed to be part of
;; `org-latex-guess-babel-language', as in the modified version below
(defun org-latex-uc-fonts-support-make-preamble (header)
(let* ((main-fonts (unless (eq 'org-latex-uc-fonts-support-default-main-fonts 'default)
(mapconcat #'identity
(cl-remove-if-not #'identity
(mapcar
(lambda (elt)
(let ((str (org-latex-uc-fonts-support-get-main-fonts
org-latex-uc-fonts-support-default-main-fonts
elt)))
(when str str)))
(list :main :sans :mono :math)))
"\n")))
(other-fonts-per-language
(org-latex-uc-fonts-support-get-fonts-other-languages header))
(preamble (with-temp-buffer
(insert "\n\n")
(when main-fonts
(insert main-fonts))
(insert "\n\n")
(when other-fonts-per-language
(insert other-fonts-per-language))
(buffer-string))))
preamble))
(defun org-latex-guess-babel-language (header info)
"Modified version for this proof of concept"
(let* ((language-code (plist-get info :language))
(plist (cdr
(assoc language-code org-latex-language-alist)))
(language (plist-get plist :babel))
(language-ini-only (plist-get plist :babel-ini-only))
;; If no language is set, or Babel package is not loaded, or
;; LANGUAGE keyword value is a language served by Babel
;; exclusively through ini files, return HEADER as-is.
(header (if (or language-ini-only
(not (stringp language-code))
(not (string-match "\\\\usepackage\\[\\(.*\\)\\]{babel}" header)))
header
(let ((options (save-match-data
(org-split-string (match-string 1 header) ",[ \t]*"))))
;; If LANGUAGE is already loaded, return header
;; without AUTO. Otherwise, replace AUTO with language or
;; append language if AUTO is not present. Languages that are
;; served in Babel exclusively through ini files are not added
;; to the babel argument, and must be loaded using
;; `\babelprovide'.
(replace-match
(mapconcat (lambda (option) (if (equal "AUTO" option) language option))
(cond ((member language options) (delete "AUTO" options))
((member "AUTO" options) options)
(t (append options (list language))))
", ")
t nil header 1)))))
;;; adition:
(when org-latex-uc-fonts-support
(setq header (let ((form (org-latex-uc-fonts-support-make-preamble header)))
(replace-regexp-in-string
"\\(\\\\usepackage\\[?.*\\]?{babel}\\)"
(format "\n\\\\usepackage{fontspec}\n\n\\1\n%s" form)
header))))
;;;
;; If `\babelprovide[args]{AUTO}' is present, AUTO is
;; replaced by LANGUAGE.
(if (not (string-match "\\\\babelprovide\\[.*\\]{\\(.+\\)}" header))
header
(let ((prov (match-string 1 header)))
(if (equal "AUTO" prov)
(replace-regexp-in-string (format
"\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
(format "\\1\\2%s}"
(or language language-ini-only))
header t)
header)))))
^ permalink raw reply [relevance 4%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-08-31 11:42 7% ` Juan Manuel Macías
@ 2023-09-01 9:18 5% ` Ihor Radchenko
2023-09-02 21:39 4% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-09-01 9:18 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Timothy, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ...In any
> case, the fonts issue is the most delicate part. What default fonts to
> add to the list? Here the user's taste or preferences would influence.
Commonly available libre fonts look like a good candidate.
> It must also be taken into account that if one has typographical
> scruples, not all fonts match each other. For design purposes, I mean.
> The Computer Modern, which is a modern style font (similar to the Didot
> or Bodoni), does not usually pair well with (for example) a Garamond,
> which is in the Renaissance style. That's why I think the best solution
> would be to offer a basic defcustom, based on the purely utilitarian,
> and let the user modify or extend it according to their taste,
> preferences or convenience.
+1.
> Another thing to keep in mind is the following. Offering basic
> readability based on the unicode scripts means that we rely on scripts
> and not languages. For example, the Cyrillic script covers several
> languages, as you well know: Russian, Bulgarian, etc. The Latin script
> is used for languages as diverse as English or Vietnamese. The choice of
> font based on the script is a low-level LuaTeX functionality, that is,
> it does not add features specific to each language, such as hyphenation
> patterns. This means that long texts in (for example) Cyrillic or Greek
> are not justified well because LaTeX does not know how hyphenate them:
> ...
> There is another possibility that I am working on in parallel: relying
> on languages instead of scripts. This would add both readability and
> support for each particular language. There could be two options for the
> user: a basic one (the low level one, based on scripts: ensures
> readability but the document may not look pretty) and an advanced one,
> based on language support. Something like this occurred to me:
>
> #+LaTeX_Header: % !enable-fonts-for ancientgreek russian:Old Standard
> arabic
We already have #+language keyword and
`org-latex-guess-babel-language'/`org-latex-guess-polyglossia-language'.
May as well have default fonts for a given language.
As for multiple languages, do we actually support this?
>> What will happen if LuaTeX is not installed on the system?
>
> Yes, there should be some kind of warning. Also it's not just LuaTeX,
> but certain packages for fonts and multilingual support. The problem is
> that the different versions of TeX live cooked in the distros
> usually name these packages differently. This is another added problem...
> Arch or Gentoo offer a more vanilla TeX live.
We might use `org-latex-known-warnings'.
>> Also, just to double check, is LuaTeX fully compatible to LaTeX? That
>> is, if we have an existing org file using LaTeX-specific commands and
>> packages, will it work with LuaTeX?
>
> Yes, it is fully compatible, except that LuaLaTeX does not need to load
> the fontenc or inputenc packages. LuaTeX is intended to be the natural
> replacement for pdfTeX. The latest edition of The LaTeX Companion is
> already very focused on LuaTeX. And 90% of the new LaTeX packages that
> are uploaded to CTAN only work in LuaLaTeX. One of the essential
> advantages of LuaTeX is that TeX now (finally!) has a simple scripting
> language. With a little Lua you can achieve very low level things in TeX
> that were horribly complicated in 'pure TeX'.
Then, we might even consider LuaTeX as the new default for
`org-latex-compiler'.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-08-31 8:17 5% ` Ihor Radchenko
@ 2023-08-31 11:42 7% ` Juan Manuel Macías
2023-09-01 9:18 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-31 11:42 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Timothy, orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> The idea is to start from a defcustom that is an alist where each element
>> has the structure (script font). There would also be a default script +
>> font, for example ("latin" "Linux Libertine"). At the moment it would
>> only work for the default roman font, but it can be extended to default
>> sans serif, mono, etc.
>
> Are the fonts you have in mind shipped with LuaTeX distribution?
Yes, in fact the complete installation of TeX live includes a wide
catalog of free opentype fonts with good coverage for non-Latin scripts.
Added to that, more free (as in freedom) easily accessible fonts can be
recommended. Even many GNU/Linux distros already include them. In any
case, the fonts issue is the most delicate part. What default fonts to
add to the list? Here the user's taste or preferences would influence.
It must also be taken into account that if one has typographical
scruples, not all fonts match each other. For design purposes, I mean.
The Computer Modern, which is a modern style font (similar to the Didot
or Bodoni), does not usually pair well with (for example) a Garamond,
which is in the Renaissance style. That's why I think the best solution
would be to offer a basic defcustom, based on the purely utilitarian,
and let the user modify or extend it according to their taste,
preferences or convenience.
Another thing to keep in mind is the following. Offering basic
readability based on the unicode scripts means that we rely on scripts
and not languages. For example, the Cyrillic script covers several
languages, as you well know: Russian, Bulgarian, etc. The Latin script
is used for languages as diverse as English or Vietnamese. The choice of
font based on the script is a low-level LuaTeX functionality, that is,
it does not add features specific to each language, such as hyphenation
patterns. This means that long texts in (for example) Cyrillic or Greek
are not justified well because LaTeX does not know how hyphenate them:
https://i.imgur.com/PSja3x2.png
However, this may be sufficient for documents containing words or small
texts in non latin scripts, rather than long texts.
There is another possibility that I am working on in parallel: relying
on languages instead of scripts. This would add both readability and
support for each particular language. There could be two options for the
user: a basic one (the low level one, based on scripts: ensures
readability but the document may not look pretty) and an advanced one,
based on language support. Something like this occurred to me:
#+LaTeX_Header: % !enable-fonts-for ancientgreek russian:Old Standard
arabic
This means: enable default fonts for ancient Greek and Arabic
(associated with Greek and Arabic scripts). For Russian, enable the Old
Standard font (included in TeX live). And in the case of Arabic, enable
'bidi' (bidirectional text). If the user added that line it would be
enough to do the magic. I hope :-)
>> The functionality would not be activated by default. When activated, it
>> also enables LuaTeX as the default LaTeX engine, and on each export a
>> list of non-latin scripts in the buffer is extracted. Perhaps with
>> some code like this, which checks for any non-latin characters:
>>
>> (let ((scripts))
>> (save-excursion
>> (goto-char (point-min))
>> (while
>> (re-search-forward "\\([^\u0000-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
>> (let ((script (aref char-script-table
>> (string-to-char (match-string 1)))))
>> (add-to-list 'scripts script)
>> (setq script-list scripts))))
>> script-list)
>>
>> ?
>>
>> Once the list has been extracted, an ad hoc preamble would be formatted
>> assigning each script the chosen font.
>>
>> WDYT? Do you think this would be a viable path? I think that in a few
>> days I can offer something usable for discussion.
>
> Adding Timothy to CC. His WIP conditional preamble branch looks suitable
> to add the proposed functionality.
Great!
> What will happen if LuaTeX is not installed on the system?
Yes, there should be some kind of warning. Also it's not just LuaTeX,
but certain packages for fonts and multilingual support. The problem is
that the different versions of TeX live cooked in the distros
usually name these packages differently. This is another added problem...
Arch or Gentoo offer a more vanilla TeX live.
> Also, just to double check, is LuaTeX fully compatible to LaTeX? That
> is, if we have an existing org file using LaTeX-specific commands and
> packages, will it work with LuaTeX?
Yes, it is fully compatible, except that LuaLaTeX does not need to load
the fontenc or inputenc packages. LuaTeX is intended to be the natural
replacement for pdfTeX. The latest edition of The LaTeX Companion is
already very focused on LuaTeX. And 90% of the new LaTeX packages that
are uploaded to CTAN only work in LuaLaTeX. One of the essential
advantages of LuaTeX is that TeX now (finally!) has a simple scripting
language. With a little Lua you can achieve very low level things in TeX
that were horribly complicated in 'pure TeX'.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 7%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-27 17:25 10% ` Juan Manuel Macías
@ 2023-08-31 9:15 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-08-31 9:15 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> And what about drawers? Don't they fit the idea of "detached" element?
>
> But drawers would not serve as a "detached section"... Although they are
> certainly very versatile. I usually use drawers to export as small
> "containers". And when I don't export them, they are very useful for
> temporarily saving all kinds of "things". In Spanish we have the term
> "cajón de sastre" (lit.: "a tailor drawer") to refer to something where
> you can store everything :-)
I am not sure here. It looks like having a new special block type
#+begin_inlinesection
...
#+end_inlinesection
would be sufficient. Given that we cannot nest inlinesections anyway.
Or special drawer
:inlinesection:
...
:end:
Although, drawers will be less powerful because, unlike special blocks,
you cannot have a different drawer type inside. For special blocks, a
different special block is perfectly fine.
I do not see any clear benefit of having a dedicated, separate markup
for inlinesection, apart from philosophical.
> As for the inlinetask (or whatever they may be called in the future),
> the fact that they are a kind of hybrid between a section (unrelated to
> the level hierarchy) and a drawer seems very interesting to me. Apart
> from the scenario of the anonymous sections that I mentioned before, I
> can think of a few more. For example, something like this:
>
> *************** WORKING Complete this :noexport:
> DEADLINE: <2023-08-27 dom>
> Content
> *************** END
>
> And the combination of org-store-link with org-transclusion can also be
> interesting.
>
> Or, for example this other example, which is not possible now, but with
> some modification in org-mime-org-subtree-htmlize I think it is:
>
> *************** TODO Email this
> DEADLINE: <2023-08-27 dom>
> :PROPERTIES:
> :mail_to: mail address
> :mail_subject: mail subject
> :END:
> Content
> *************** END
We can get the same functionality if we allow arbitrary properties and
tags assigned to non-headline elements.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Fallback fonts in LaTeX export for non latin scripts
2023-08-30 8:25 10% Fallback fonts in LaTeX export for non latin scripts Juan Manuel Macías
@ 2023-08-31 8:17 5% ` Ihor Radchenko
2023-08-31 11:42 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-31 8:17 UTC (permalink / raw)
To: Juan Manuel Macías, Timothy; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> These days I'm working on some experimental code to try to provide Org
> with some sort of fallbacks fonts on LaTeX export. The functionality
> would (for now) be linked to LuaTeX + babel package, since XeTeX,
> although it has the ucharclasses package, is more limited.
Thanks! That would be a welcome addition.
> The idea is to start from a defcustom that is an alist where each element
> has the structure (script font). There would also be a default script +
> font, for example ("latin" "Linux Libertine"). At the moment it would
> only work for the default roman font, but it can be extended to default
> sans serif, mono, etc.
Are the fonts you have in mind shipped with LuaTeX distribution?
> The functionality would not be activated by default. When activated, it
> also enables LuaTeX as the default LaTeX engine, and on each export a
> list of non-latin scripts in the buffer is extracted. Perhaps with
> some code like this, which checks for any non-latin characters:
>
> (let ((scripts))
> (save-excursion
> (goto-char (point-min))
> (while
> (re-search-forward "\\([^\u0000-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
> (let ((script (aref char-script-table
> (string-to-char (match-string 1)))))
> (add-to-list 'scripts script)
> (setq script-list scripts))))
> script-list)
>
> ?
>
> Once the list has been extracted, an ad hoc preamble would be formatted
> assigning each script the chosen font.
>
> WDYT? Do you think this would be a viable path? I think that in a few
> days I can offer something usable for discussion.
Adding Timothy to CC. His WIP conditional preamble branch looks suitable
to add the proposed functionality.
What will happen if LuaTeX is not installed on the system?
Also, just to double check, is LuaTeX fully compatible to LaTeX? That
is, if we have an existing org file using LaTeX-specific commands and
packages, will it work with LuaTeX?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Fallback fonts in LaTeX export for non latin scripts
@ 2023-08-30 8:25 10% Juan Manuel Macías
2023-08-31 8:17 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-30 8:25 UTC (permalink / raw)
To: orgmode
The Unicode TeX engines, LuaTeX and XeTeX, have certain features to
apply fonts to scripts (Greek, Cyrillic, Arabic, etc.), without the need
to switch fonts explicitly. But LaTeX does not include any functionality
for loading 'fallback fonts' out of the box. Seeing things from TeX and
LaTeX this is understandable: since LaTeX is a typographic tool, the
user has the responsibility of choosing the fonts and knowing which
fonts to use. But from the Org side things may look different, as the
average user (who may not be interested in typographical or font
complexities) is looking for immediate readability of their texts when
exporting to any format. We know that, when exporting to LaTeX, this
does not always happen, if texts include non-Latin scripts.
These days I'm working on some experimental code to try to provide Org
with some sort of fallbacks fonts on LaTeX export. The functionality
would (for now) be linked to LuaTeX + babel package, since XeTeX,
although it has the ucharclasses package, is more limited.
The idea is to start from a defcustom that is an alist where each element
has the structure (script font). There would also be a default script +
font, for example ("latin" "Linux Libertine"). At the moment it would
only work for the default roman font, but it can be extended to default
sans serif, mono, etc.
The functionality would not be activated by default. When activated, it
also enables LuaTeX as the default LaTeX engine, and on each export a
list of non-latin scripts in the buffer is extracted. Perhaps with
some code like this, which checks for any non-latin characters:
(let ((scripts))
(save-excursion
(goto-char (point-min))
(while
(re-search-forward "\\([^\u0000-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
(let ((script (aref char-script-table
(string-to-char (match-string 1)))))
(add-to-list 'scripts script)
(setq script-list scripts))))
script-list)
?
Once the list has been extracted, an ad hoc preamble would be formatted
assigning each script the chosen font.
WDYT? Do you think this would be a viable path? I think that in a few
days I can offer something usable for discussion.
Best regards,
Juan Manuel
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-27 9:21 5% ` Ihor Radchenko
@ 2023-08-27 17:25 10% ` Juan Manuel Macías
2023-08-31 9:15 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-27 17:25 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> Although, the name "inlinetask" is actually awkward in such use case.
> Something like inlinesection would fit better. Or inlineheading.
Completely agree. I like inlinesection and inlineheading equally.
> And what about drawers? Don't they fit the idea of "detached" element?
But drawers would not serve as a "detached section"... Although they are
certainly very versatile. I usually use drawers to export as small
"containers". And when I don't export them, they are very useful for
temporarily saving all kinds of "things". In Spanish we have the term
"cajón de sastre" (lit.: "a tailor drawer") to refer to something where
you can store everything :-)
As for the inlinetask (or whatever they may be called in the future),
the fact that they are a kind of hybrid between a section (unrelated to
the level hierarchy) and a drawer seems very interesting to me. Apart
from the scenario of the anonymous sections that I mentioned before, I
can think of a few more. For example, something like this:
*************** WORKING Complete this :noexport:
DEADLINE: <2023-08-27 dom>
Content
*************** END
And the combination of org-store-link with org-transclusion can also be
interesting.
Or, for example this other example, which is not possible now, but with
some modification in org-mime-org-subtree-htmlize I think it is:
*************** TODO Email this
DEADLINE: <2023-08-27 dom>
:PROPERTIES:
:mail_to: mail address
:mail_subject: mail subject
:END:
Content
*************** END
Well, it's some scattered ideas. In general I think that "inlinesection/-heading"
is an element that could be very productive in certain cases, since it
allows to "locally" suspend the (necessary) rigidity of the tree hierarchy.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 19:19 10% ` Juan Manuel Macías
@ 2023-08-27 9:21 5% ` Ihor Radchenko
2023-08-27 17:25 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-27 9:21 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> In other words, it is not the section itself, but other
>> headline/inlinetask features, like todo keywords, tags, planning. Right?
>
> No, it is the section itself (or the concept of "section", with its toys
> in Org, of course) that is important to me in this case...
So, this is a vote in favour of having a separate syntax element.
Although, the name "inlinetask" is actually awkward in such use case.
Something like inlinesection would fit better. Or inlineheading.
And what about drawers? Don't they fit the idea of "detached" element?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:43 5% ` Ihor Radchenko
@ 2023-08-26 19:19 10% ` Juan Manuel Macías
2023-08-27 9:21 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-26 19:19 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> In other words, it is not the section itself, but other
> headline/inlinetask features, like todo keywords, tags, planning. Right?
No, it is the section itself (or the concept of "section", with its toys
in Org, of course) that is important to me in this case. I am not
emphasizing so much how or in which way an element can be exported, but
what (semantic) role that element plays in the logical structure of an
Org document. To get a little philosophical, the Org document (where I
work and write) would be the idea, and the export to any format a
possible concrete realization. I mean, I find it comfortable and
productive to view an Org document as agnostic of any format. This use
of inlinetasks that I'm discussing here occurred to me a long time ago
because if I stop to think about an untitled, detached section of the
level hierarchy, this Org element is a perfect candidate. It is true
that you can use a special block, or another element (org is very
versatile, and supports role swapping between elements), but if I have
to think of a logical candidate, inlinetasks are the closest to that
concept. If inlinetasks didn't exist, I'd probably use special blocks
for that purpose. When I'm writing inside Org I'm not thinking about the
export (at least not simultaneously), that is, about the format; I think
more of the structure of the document, as something abstract.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:31 11% ` Juan Manuel Macías
2023-08-26 17:43 5% ` Ihor Radchenko
@ 2023-08-26 18:01 6% ` Russell Adams
1 sibling, 0 replies; 200+ results
From: Russell Adams @ 2023-08-26 18:01 UTC (permalink / raw)
To: emacs-orgmode
On Sat, Aug 26, 2023 at 05:31:46PM +0000, Juan Manuel Macías wrote:
> Ihor Radchenko writes:
>
> *************** TODO anonsec :tag:
> Content that has neither a title nor a section number.
> *************** END
>
> and a construction that for the purposes of parceling out the text
> behaves like a section. The problem is the LaTeX side. Since there is no
> support for anonymous sections in LaTeX (I seem to remember that some
> special class like Koma had some command to introduce anonymous breaks,
> but I only use the standard classes), I had to define an environment. It
> is not inconvenient, since after all what appears in LaTeX is the
> typographical result. For the Org side I can use TODO keywords, tags,
> deadlines, etc.
Why not just put the TODO heading in a code block with type org?
Then you get all the toys, ignored by the main file.
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
https://www.adamsinfoserv.com/
^ permalink raw reply [relevance 6%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 17:31 11% ` Juan Manuel Macías
@ 2023-08-26 17:43 5% ` Ihor Radchenko
2023-08-26 19:19 10% ` Juan Manuel Macías
2023-08-26 18:01 6% ` Russell Adams
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-26 17:43 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Why not simply
>>
>> #+begin_anonsection
>> ...
>> #+end_anonsection
>>
>> ?
> ... The problem is the LaTeX side. Since there is no
> support for anonymous sections in LaTeX (I seem to remember that some
> special class like Koma had some command to introduce anonymous breaks,
> but I only use the standard classes), I had to define an environment. It
> is not inconvenient, since after all what appears in LaTeX is the
> typographical result. For the Org side I can use TODO keywords, tags,
> deadlines, etc.
In other words, it is not the section itself, but other
headline/inlinetask features, like todo keywords, tags, planning. Right?
Custom blocks can be exported to anything (not necessarily
\begin{foo}...), similar to how you did custom export for inlinetasks.
There was also an idea to make custom block export more customizeable,
similar to link. Like what
https://github.com/alhassy/org-special-block-extras does.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 16:33 6% ` Ihor Radchenko
@ 2023-08-26 17:31 11% ` Juan Manuel Macías
2023-08-26 17:43 5% ` Ihor Radchenko
2023-08-26 18:01 6% ` Russell Adams
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-26 17:31 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> Why not simply
>
> #+begin_anonsection
> ...
> #+end_anonsection
>
> ?
Because with an inlinetask I can have something like this:
*************** TODO anonsec :tag:
Content that has neither a title nor a section number.
*************** END
and a construction that for the purposes of parceling out the text
behaves like a section. The problem is the LaTeX side. Since there is no
support for anonymous sections in LaTeX (I seem to remember that some
special class like Koma had some command to introduce anonymous breaks,
but I only use the standard classes), I had to define an environment. It
is not inconvenient, since after all what appears in LaTeX is the
typographical result. For the Org side I can use TODO keywords, tags,
deadlines, etc.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 14:21 9% ` Juan Manuel Macías
@ 2023-08-26 16:33 6% ` Ihor Radchenko
2023-08-26 17:31 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-26 16:33 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Do you mean section in LaTeX sense or in Org sense?
>
> In Org sense, I think. If an author adds an 'anonymous' break (through
> some customary symbol) and continues writing, the content that follows
> belongs (for Org) to the current section. By using an inlenitask, you
> can have control over the inlinetask content, for any purpose, for
> example with some export filter, etc.
>
> On the other hand, for my own writing I usually use this:
>
> #+begin_src emacs-lisp
> (defun my-org-latex-format-inlinetask-default-function
> (todo _todo-type priority title tags contents _info)
> (if (string-match-p "anonsec" title)
> (concat
> "\n\\begin{anonsection}\n"
> (org-string-nw-p contents)
> "\n\\end{anonsection}\n")
> (org-string-nw-p contents)))
Why not simply
#+begin_anonsection
...
#+end_anonsection
?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 12:33 5% ` Ihor Radchenko
@ 2023-08-26 14:21 9% ` Juan Manuel Macías
2023-08-26 16:33 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-26 14:21 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I think that would not be expected, since an anonymous section is just a
>> break in the text that has neither a title nor a section number.
>> ... Anonymous breaks using asterisks or other symbols is usually the applied
>> remedy. The advantage of enclosing the content of the anonymous section
>> in an inlinetask is that we have a 'true' section with content (over
>> which you have control). That would not happen if the author explicitly
>> added a break symbol and continue writing.
>
> Do you mean section in LaTeX sense or in Org sense?
In Org sense, I think. If an author adds an 'anonymous' break (through
some customary symbol) and continues writing, the content that follows
belongs (for Org) to the current section. By using an inlenitask, you
can have control over the inlinetask content, for any purpose, for
example with some export filter, etc.
On the other hand, for my own writing I usually use this:
#+begin_src emacs-lisp
(defun my-org-latex-format-inlinetask-default-function
(todo _todo-type priority title tags contents _info)
(if (string-match-p "anonsec" title)
(concat
"\n\\begin{anonsection}\n"
(org-string-nw-p contents)
"\n\\end{anonsection}\n")
(org-string-nw-p contents)))
(defun mi-org-odt-format-inlinetask-default-function
(todo todo-type priority name tags contents)
(if (string-match-p "anonsec" name)
(concat
contents
"<text:p text:style-name=\"OrgCenter\">* * *</text:p>")))
#+end_src
And for LaTeX I have defined this:
#+begin_src latex
\newcommand\dinkus{\mbox{\textasteriskcentered\space\textasteriskcentered\space\textasteriskcentered}}
\newcommand\anonsectionmark{\dinkus}
%% require the needspace package
\newcommand\anonsectionbreak{%
\nopagebreak[4]
\bigskip%
{\centering
\anonsectionmark\par}
\Needspace*{2\bigskipamount}
\bigskip}
\newenvironment{anonsection}{%
\anonsectionbreak%
}
{%
\par}
#+end_src
>> Anonymous breaks are also widely used in essay or narrative texts. An
>> essay text, published as a blog entry or as an article, can be perfectly
>> structured into anonymous sections:
>> ...
>> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>>
>> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
>
> This one I know. But it can work fine with normal headings, because such
> texts are nothing but a sequence of "scenes" - nothing "inline" when we
> have one scene, interrupted by other, then coming back to the first one.
Actually, I think any anonymous text break or sectioning can be
accomplished using Org headings and some trickery to ignore the heading on
export, but I think inlinetasks lends itself quite well to this
constructions and others I've seen discussed in this thread. In general,
for any 'piece' (section = something that is sectioned) of text that
needs to be separated in some way from the main text, without a
hierarchy of levels, inlinetasks are a great, versatile and simple tool
(IMHO).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 9%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 11:42 10% ` Juan Manuel Macías
@ 2023-08-26 12:33 5% ` Ihor Radchenko
2023-08-26 14:21 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-26 12:33 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>
>> May they contain sub-sections?
>
> I think that would not be expected, since an anonymous section is just a
> break in the text that has neither a title nor a section number.
> ... Anonymous breaks using asterisks or other symbols is usually the applied
> remedy. The advantage of enclosing the content of the anonymous section
> in an inlinetask is that we have a 'true' section with content (over
> which you have control). That would not happen if the author explicitly
> added a break symbol and continue writing.
Do you mean section in LaTeX sense or in Org sense?
> Anonymous breaks are also widely used in essay or narrative texts. An
> essay text, published as a blog entry or as an article, can be perfectly
> structured into anonymous sections:
> ...
> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>
> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
This one I know. But it can work fine with normal headings, because such
texts are nothing but a sequence of "scenes" - nothing "inline" when we
have one scene, interrupted by other, then coming back to the first one.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-26 10:58 6% ` Ihor Radchenko
@ 2023-08-26 11:42 10% ` Juan Manuel Macías
2023-08-26 12:33 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-26 11:42 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
>> ... They
>> behave like a true section, except that they are not headed by titles or
>> level numbers.
>
> May they contain sub-sections?
I think that would not be expected, since an anonymous section is just a
break in the text that has neither a title nor a section number. There
are many possible scenarios. Let's imagine, for example, that an author
is working on a section of an article. And at the end of various
subsections he/she wants to make some text breaks that, for whatever
reason, don't deserve either a title or a subsubsection number.
Anonymous breaks using asterisks or other symbols is usually the applied
remedy. The advantage of enclosing the content of the anonymous section
in an inlinetask is that we have a 'true' section with content (over
which you have control). That would not happen if the author explicitly
added a break symbol and continue writing.
Anonymous breaks are also widely used in essay or narrative texts. An
essay text, published as a blog entry or as an article, can be perfectly
structured into anonymous sections:
contents 1
***
contents 2
***
etc
See:
https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
--
Juan Manuel Macías
^ permalink raw reply [relevance 10%]
* Re: [DISCUSSION] Re-design of inlinetasks
2023-08-25 17:58 9% ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
@ 2023-08-26 10:58 6% ` Ihor Radchenko
2023-08-26 11:42 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-26 10:58 UTC (permalink / raw)
To: Juan Manuel Macías
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think inlinetasks may also have a use for those sections that are not
> "nested". In typography they are usually called "anonymous sections" and
> they are separated by some symbol (asterisks, dinkus[1], etc.).
This is a very interesting idea. Thanks for sharing!
> ... They
> behave like a true section, except that they are not headed by titles or
> level numbers.
May they contain sub-sections?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [DISCUSSION] Re-design of inlinetasks
@ 2023-08-25 17:58 9% ` Juan Manuel Macías
2023-08-26 10:58 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-25 17:58 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Bastien Guerry, Fraga, Eric, Samuel Wales, Max Nikulin,
emacs-orgmode@gnu.org
Ihor Radchenko writes:
> 1. Inlinetasks should be exported as "boxes" - something similar to
> margin or inline notes
> - Can be used as a memo TODO in draft publication printout
> - As Samuel suggested, inlinetasks could be a basis of review
> comments - like what GDocs/Office provides in margin "chat"
I think inlinetasks may also have a use for those sections that are not
"nested". In typography they are usually called "anonymous sections" and
they are separated by some symbol (asterisks, dinkus[1], etc.). They
behave like a true section, except that they are not headed by titles or
level numbers. I think Org's support for these types of sections would
be useful and novel, since there is (as far as I know) nothing similar
in other lightweight markup languages. Anonymous sections can be useful
not only in print or PDF texts but also on web pages.
https://en.wikipedia.org/wiki/Dinkus
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [Tip] Popup-menu with several actions for a link
2023-08-20 7:23 6% ` Ihor Radchenko
@ 2023-08-20 10:13 10% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-20 10:13 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> ... Also, I don't usually use the mouse
>> much (actually I only use it in Gimp and the like) and the combination
>> of popup.el with hyperbole is more comfortable and keyboard-centric for
>> me.
>
> By default, context menu is bound to S-<F10>. Who cares about mouse XD
Oh I see. Very interesting. But I have seen that, at least by default,
there is no autocomplete feature. What I like about popup.el is, in
addition to autocompletion, the ability to easily create menus for
anything. Some time ago I defined a popup-menu[1] that shows me all the
header levels from where I am to the first one, defaulting to the
current level. It helps me situate myself in deep levels (other options
like imenu or org-sidebar give me too much information and I get lost).
I'm going to investigate if something similar can be done with
context-menu-mode...
Thank you for all the info!
[1] https://i.imgur.com/KoAZtIz.png
┌────
│ (defun my-org-where-i-am-popup ()
│ (interactive)
│ (setq org-heading-titles-list nil)
│ (org-with-wide-buffer
│ (save-excursion
│ (save-restriction
│ (org-back-to-heading t)
│ (if (eq (org-element-property :level (org-element-at-point)) 1)
│ (message "First level")
│ (push (cons (org-link-display-format
│ (nth 4 (org-heading-components)))
│ (point))
│ org-heading-titles-list)
│ (while
│ (ignore-errors (outline-up-heading 1 t))
│ (push (cons (org-link-display-format
│ (nth 4 (org-heading-components)))
│ (point))
│ org-heading-titles-list))))))
│ (org-with-wide-buffer
│ (save-excursion
│ (save-restriction
│ (goto-char
│ (popup-menu* (mapcar
│ (lambda (x)
│ (popup-make-item (car x) :value (cdr x)))
│ org-heading-titles-list)
│ :isearch t
│ :initial-index (length org-heading-titles-list)))
│ (org-tree-to-indirect-buffer)))))
└────
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [Tip] Popup-menu with several actions for a link
2023-08-19 20:29 11% ` Juan Manuel Macías
@ 2023-08-20 7:23 6% ` Ihor Radchenko
2023-08-20 10:13 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-20 7:23 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Since Emacs 28, Emacs has built-in context menu. (terminal is also
>> supported) Moreover, major modes are encouraged to add support for
>> context menus.
>
> Thanks for the information. Do you mean context-menu-mode?
Yes.
> ... I'll keep an
> eye on it. When you say terminal support, do you mean terminal emulators
> or TTY?
Both.
> ... Also, I don't usually use the mouse
> much (actually I only use it in Gimp and the like) and the combination
> of popup.el with hyperbole is more comfortable and keyboard-centric for
> me.
By default, context menu is bound to S-<F10>. Who cares about mouse XD
>> May you explain more about how you attach to an email/upload?
>
> Sure! But they are very simple functions, which I don't use much.
> Although they work fine for what I want:
>
> The first requires the imgur.el package; the second one needs gnus-dired-mode:
I see. I thought that you are using built-in functionality.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [Tip] Popup-menu with several actions for a link
2023-08-19 19:53 6% ` Ihor Radchenko
@ 2023-08-19 20:29 11% ` Juan Manuel Macías
2023-08-20 7:23 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-19 20:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> I’ve been experimenting for a while with the popup.el library
>> (<https://github.com/auto-complete/popup-el>), which offers an easy way
>> to create popup menus (even cascading menus), with auto-completion
>> functions. I’m sharing here a popup menu that I’ve defined to perform
>> various actions on an Org link, in case anyone finds it useful.
>
> Since Emacs 28, Emacs has built-in context menu. (terminal is also
> supported) Moreover, major modes are encouraged to add support for
> context menus.
Thanks for the information. Do you mean context-menu-mode? I'll keep an
eye on it. When you say terminal support, do you mean terminal emulators
or TTY? Because I often use Emacs on the linux framebuffer with fbterm,
and popup.el works fine on the tty. Also, I don't usually use the mouse
much (actually I only use it in Gimp and the like) and the combination
of popup.el with hyperbole is more comfortable and keyboard-centric for
me.
>> In this list I store the functions that I am writing to manipulate links
>> (open the link with eww, open the file with an external application,
>> attach it to an email, upload it to Imgur, copy it to another directory
>> or move it, visit the file directory, etc.). Something like this:
>
> May you explain more about how you attach to an email/upload?
Sure! But they are very simple functions, which I don't use much.
Although they work fine for what I want:
The first requires the imgur.el package; the second one needs gnus-dired-mode:
(defun my-org-link-to-ingur ()
(interactive)
(let* ((path (org-element-property :path (org-element-context))))
(imgur-upload-image (expand-file-name path) nil t)))
(defun my-org-link-to-mail-attachment ()
(interactive)
(let* ((path (org-element-property :path (org-element-context))))
(gnus-dired-attach (list (expand-file-name path)))))
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [Tip] Popup-menu with several actions for a link
2023-08-18 18:27 10% [Tip] Popup-menu with several actions for a link Juan Manuel Macías
@ 2023-08-19 19:53 6% ` Ihor Radchenko
2023-08-19 20:29 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-19 19:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I’ve been experimenting for a while with the popup.el library
> (<https://github.com/auto-complete/popup-el>), which offers an easy way
> to create popup menus (even cascading menus), with auto-completion
> functions. I’m sharing here a popup menu that I’ve defined to perform
> various actions on an Org link, in case anyone finds it useful.
Since Emacs 28, Emacs has built-in context menu. (terminal is also
supported) Moreover, major modes are encouraged to add support for
context menus.
> In this list I store the functions that I am writing to manipulate links
> (open the link with eww, open the file with an external application,
> attach it to an email, upload it to Imgur, copy it to another directory
> or move it, visit the file directory, etc.). Something like this:
May you explain more about how you attach to an email/upload?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* [Tip] Popup-menu with several actions for a link
@ 2023-08-18 18:27 10% Juan Manuel Macías
2023-08-19 19:53 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-18 18:27 UTC (permalink / raw)
To: orgmode
Hi,
I’ve been experimenting for a while with the popup.el library
(<https://github.com/auto-complete/popup-el>), which offers an easy way
to create popup menus (even cascading menus), with auto-completion
functions. I’m sharing here a popup menu that I’ve defined to perform
various actions on an Org link, in case anyone finds it useful.
In this list I store the functions that I am writing to manipulate links
(open the link with eww, open the file with an external application,
attach it to an email, upload it to Imgur, copy it to another directory
or move it, visit the file directory, etc.). Something like this:
┌────
│ (setq my-org-link-actions-list
│ '(("Action 1" . function1)
│ ("Action 2" . function2)
│ ("etc..." . etc)))
└────
Then, I have defined this popup-menu that is displayed on a link:
┌────
│ (defun my-org-actions-link-popup ()
│ (interactive)
│ (funcall
│ (popup-menu*
│ (mapcar
│ (lambda (x)
│ (popup-make-item (car x) :value (cdr x)))
│ my-org-link-actions-list)
│ :isearch t)))
└────
And a little addendum. Being a Hyperbole user, it occurred to me a while
ago that a ’secondary action key’ could be very useful to me in certain
contexts. So I defined this:
┌────
│ (defvar my-hyp-alt-act nil)
│
│ (defun my-hyp-action-key-alt ()
│ (interactive)
│ (let ((my-hyp-alt-act t))
│ (action-key)))
└────
If `C-c i' is for the ’primary’ action key, `C-c I' is for the
’secondary’ action:
┌────
│ (global-set-key (kbd "C-c I") #'mi-hyp-action-key-alt)
└────
And then I’ve modified hyperbole `org-link' a bit:
┌────
│ (defact org-link (&optional link)
│ "Follows an optional Org mode LINK to its target.
│ If LINK is nil, follows any link at point. Otherwise, triggers an error."
│ (if (not my-hyp-alt-act)
│ (if (stringp link)
│ (org-link-open-from-string link)
│ (org-open-at-point))
│ (hact #'my-org-actions-link-popup)))
└────
In this way, if I have the point over the link and press `C-c i', the
link opens. If I press `C-c I' the popup-menu is displayed.
Best regards,
Juan Manuel
--
--
------------------------------------------------------
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-17 20:17 7% ` Juan Manuel Macías
@ 2023-08-18 8:44 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-08-18 8:44 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Subject: [PATCH] lisp/ox-latex.el: Add the `:literal' attribute to verse
> block.
Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2eb4fd890
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-17 10:35 6% ` Ihor Radchenko
@ 2023-08-17 20:17 7% ` Juan Manuel Macías
2023-08-18 8:44 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-17 20:17 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]
Ihor Radchenko writes:
> Thanks!
>
>> * (org-latex-verse-block): now the treatment of blank lines is
>> consistent with the syntax of the LaTeX `verse' environment, and the
>> one provided by the `verse' package. If the `:literal' attribute is
>> used, all blank lines are preserved and exported as
>
> Please use double space between sentences and start sentences with
> capital letter.
>
>> +- =:literal= :: With value t, all blank lines are preserved and
>> + exported as =\vspace*{\baselineskip}=, including the blank lines
>> + before or after contents. Note that without the =:literal=
>> + attribute, one or more blank lines between stanzas are exported as a
>> + single blank line, and any blank lines before or after the content
>> + are removed, which is more consistent with the syntax of the LaTeX
>> + `verse' environment, and the one provided by the `verse' package.
>> + If the =verse= package is loaded, the vertical spacing between all
>> + stanzas can be controlled by the global length =\stanzaskip= (see
>> + https://www.ctan.org/pkg/verse).
>
> s/`verse'/=verse=/
>
> And you need to update `test-ox-latex/verse' test - it is currently failing.
Sorry for the typos... Here goes the corrected patch again, with the
updated test.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-the-literal-attribute-to-verse-.patch --]
[-- Type: text/x-patch, Size: 6513 bytes --]
From bd956aa947e080ef10aa851f339414dc1cda1baf Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Aug 2023 21:48:58 +0200
Subject: [PATCH] lisp/ox-latex.el: Add the `:literal' attribute to verse
block.
* (org-latex-verse-block): Now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `:literal' attribute is
used, all blank lines are preserved and exported as
`\vspace*{\baselineskip}', including the blank lines before or after
contents. The rx code has been suggested by Ihor Radchenko, to
improve readability.
* doc/org-manual.org (Verse blocks in LaTeX export): The new feature
is documented.
* testing/lisp/test-ox-latex.el (test-ox-latex/verse): Updated.
---
doc/org-manual.org | 18 ++++++++++++++----
lisp/ox-latex.el | 36 ++++++++++++++++++++++++++---------
testing/lisp/test-ox-latex.el | 8 ++++----
3 files changed, 45 insertions(+), 17 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..ce0521dee 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14425,10 +14425,10 @@ The LaTeX export backend converts horizontal rules by the specified
#+cindex: verse blocks, in @LaTeX{} export
#+cindex: @samp{ATTR_LATEX}, keyword
-The LaTeX export backend accepts four attributes for verse blocks:
-=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
-require the external LaTeX package =verse.sty=, which is an extension
-of the standard LaTeX environment.
+The LaTeX export backend accepts five attributes for verse blocks:
+=:lines=, =:center=, =:versewidth=, =:latexcode= and =:literal=. The
+three first require the external LaTeX package =verse.sty=, which is
+an extension of the standard LaTeX environment.
- =:lines= :: To add marginal verse numbering. Its value is an
integer, the sequence in which the verses should be numbered.
@@ -14440,6 +14440,16 @@ of the standard LaTeX environment.
verse.
- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
included within a LaTeX =verse= environment.
+- =:literal= :: With value t, all blank lines are preserved and
+ exported as =\vspace*{\baselineskip}=, including the blank lines
+ before or after contents. Note that without the =:literal=
+ attribute, one or more blank lines between stanzas are exported as a
+ single blank line, and any blank lines before or after the content
+ are removed, which is more consistent with the syntax of the LaTeX
+ `verse' environment, and the one provided by the =verse= package.
+ If the =verse= package is loaded, the vertical spacing between all
+ stanzas can be controlled by the global length =\stanzaskip= (see
+ https://www.ctan.org/pkg/verse).
A complete example with Shakespeare's first sonnet:
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..d11e3befa 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,10 +4116,11 @@ contextual information."
(let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
(latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
(cent (org-export-read-attribute :attr_latex verse-block :center))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
(attr (concat
- (if cent "[\\versewidth]" "")
- (if lin (format "\n\\poemlines{%s}" lin) "")
- (if latcode (format "\n%s" latcode) "")))
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) "")))
(versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
(vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
(linreset (if lin "\n\\poemlines{0}" "")))
@@ -4128,20 +4129,37 @@ contextual information."
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
- ;; into a space of 1 em. Also change each blank line with
- ;; a vertical space of 1 em.
+ ;; into a normal space, calculated with `\fontdimen2\font'. One
+ ;; or more blank lines between lines are exported as a single
+ ;; blank line. If the `:lines' attribute is used, the last
+ ;; verse of each stanza ends with the string `\\!', according to
+ ;; the syntax of the `verse' package. The separation between
+ ;; stanzas can be controlled with the length `\stanzaskip', of
+ ;; the aforementioned package. If the `:literal' attribute is
+ ;; used, all blank lines are preserved and exported as
+ ;; `\vspace*{\baselineskip}', including the blank lines before
+ ;; or after CONTENTS.
(format "%s\\begin{verse}%s\n%s\\end{verse}%s"
vwidth
attr
(replace-regexp-in-string
- "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+ "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (if (not lit)
+ (rx-to-string
+ `(seq (group ,org-latex-line-break-safe "\n")
+ (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n"))))
+ (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ (if (not lit)
+ (if lin "\\\\!\n\n" "\n\n")
+ "\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ (if (not lit)
+ (concat (org-trim contents t) "\n")
+ contents)
+ nil t)
nil t)
nil t)
linreset)
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index adb3a60ea..79ef8793b 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -61,11 +61,11 @@ lorem ipsum dolor
(search-forward
"\\begin{verse}
lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor
+
lorem ipsum dolor\\\\[0pt]
-\\vspace*{1em}
-lorem ipsum dolor\\\\[0pt]
-lorem ipsum dolor\\\\[0pt]
-\\vspace*{1em}
+lorem ipsum dolor
+
lorem ipsum dolor\\\\[0pt]
lorem ipsum dolor\\\\[0pt]
\\end{verse}"))))
--
2.41.0
^ permalink raw reply related [relevance 7%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-16 14:10 7% ` Juan Manuel Macías
@ 2023-08-17 10:35 6% ` Ihor Radchenko
2023-08-17 20:17 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-17 10:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Here is the modified patch.
Thanks!
> * (org-latex-verse-block): now the treatment of blank lines is
> consistent with the syntax of the LaTeX `verse' environment, and the
> one provided by the `verse' package. If the `:literal' attribute is
> used, all blank lines are preserved and exported as
Please use double space between sentences and start sentences with
capital letter.
> +- =:literal= :: With value t, all blank lines are preserved and
> + exported as =\vspace*{\baselineskip}=, including the blank lines
> + before or after contents. Note that without the =:literal=
> + attribute, one or more blank lines between stanzas are exported as a
> + single blank line, and any blank lines before or after the content
> + are removed, which is more consistent with the syntax of the LaTeX
> + `verse' environment, and the one provided by the `verse' package.
> + If the =verse= package is loaded, the vertical spacing between all
> + stanzas can be controlled by the global length =\stanzaskip= (see
> + https://www.ctan.org/pkg/verse).
s/`verse'/=verse=/
And you need to update `test-ox-latex/verse' test - it is currently failing.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-16 8:10 6% ` Ihor Radchenko
@ 2023-08-16 14:10 7% ` Juan Manuel Macías
2023-08-17 10:35 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-16 14:10 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I think the best thing is to rethink the :literal attribute, as I
>> commented at the end of my other email:
>>
>> - without :literal --> verse environment with a more "canonical" syntax.
>>
>> - with :literal --> verse environment seen in the "old (org) style",
>> preserving the blank lines. In that context \vspace does work.
>
> +1
Here is the modified patch.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-add-the-literal-attribute-to-verse-.patch --]
[-- Type: text/x-patch, Size: 5856 bytes --]
From 8c77b42404ef5d96b2944e8e43bbc6c9412ad808 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Aug 2023 21:48:58 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
block.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `:literal' attribute is
used, all blank lines are preserved and exported as
`\vspace*{\baselineskip}', including the blank lines before or after
contents. The rx code has been suggested by Ihor Radchenko, to
improve readability.
* doc/org-manual.org (Verse blocks in LaTeX export): the new feature
is documented.
---
doc/org-manual.org | 18 ++++++++++++++----
lisp/ox-latex.el | 36 +++++++++++++++++++++++++++---------
2 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..e52792183 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14425,10 +14425,10 @@ The LaTeX export backend converts horizontal rules by the specified
#+cindex: verse blocks, in @LaTeX{} export
#+cindex: @samp{ATTR_LATEX}, keyword
-The LaTeX export backend accepts four attributes for verse blocks:
-=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
-require the external LaTeX package =verse.sty=, which is an extension
-of the standard LaTeX environment.
+The LaTeX export backend accepts five attributes for verse blocks:
+=:lines=, =:center=, =:versewidth=, =:latexcode= and =:literal=. The
+three first require the external LaTeX package =verse.sty=, which is
+an extension of the standard LaTeX environment.
- =:lines= :: To add marginal verse numbering. Its value is an
integer, the sequence in which the verses should be numbered.
@@ -14440,6 +14440,16 @@ of the standard LaTeX environment.
verse.
- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
included within a LaTeX =verse= environment.
+- =:literal= :: With value t, all blank lines are preserved and
+ exported as =\vspace*{\baselineskip}=, including the blank lines
+ before or after contents. Note that without the =:literal=
+ attribute, one or more blank lines between stanzas are exported as a
+ single blank line, and any blank lines before or after the content
+ are removed, which is more consistent with the syntax of the LaTeX
+ `verse' environment, and the one provided by the `verse' package.
+ If the =verse= package is loaded, the vertical spacing between all
+ stanzas can be controlled by the global length =\stanzaskip= (see
+ https://www.ctan.org/pkg/verse).
A complete example with Shakespeare's first sonnet:
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..d11e3befa 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,10 +4116,11 @@ contextual information."
(let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
(latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
(cent (org-export-read-attribute :attr_latex verse-block :center))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
(attr (concat
- (if cent "[\\versewidth]" "")
- (if lin (format "\n\\poemlines{%s}" lin) "")
- (if latcode (format "\n%s" latcode) "")))
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) "")))
(versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
(vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
(linreset (if lin "\n\\poemlines{0}" "")))
@@ -4128,20 +4129,37 @@ contextual information."
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
- ;; into a space of 1 em. Also change each blank line with
- ;; a vertical space of 1 em.
+ ;; into a normal space, calculated with `\fontdimen2\font'. One
+ ;; or more blank lines between lines are exported as a single
+ ;; blank line. If the `:lines' attribute is used, the last
+ ;; verse of each stanza ends with the string `\\!', according to
+ ;; the syntax of the `verse' package. The separation between
+ ;; stanzas can be controlled with the length `\stanzaskip', of
+ ;; the aforementioned package. If the `:literal' attribute is
+ ;; used, all blank lines are preserved and exported as
+ ;; `\vspace*{\baselineskip}', including the blank lines before
+ ;; or after CONTENTS.
(format "%s\\begin{verse}%s\n%s\\end{verse}%s"
vwidth
attr
(replace-regexp-in-string
- "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+ "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (if (not lit)
+ (rx-to-string
+ `(seq (group ,org-latex-line-break-safe "\n")
+ (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n"))))
+ (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ (if (not lit)
+ (if lin "\\\\!\n\n" "\n\n")
+ "\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ (if (not lit)
+ (concat (org-trim contents t) "\n")
+ contents)
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 7%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-15 14:25 11% ` Juan Manuel Macías
@ 2023-08-16 8:10 6% ` Ihor Radchenko
2023-08-16 14:10 7% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-16 8:10 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I think the best thing is to rethink the :literal attribute, as I
> commented at the end of my other email:
>
> - without :literal --> verse environment with a more "canonical" syntax.
>
> - with :literal --> verse environment seen in the "old (org) style",
> preserving the blank lines. In that context \vspace does work.
+1
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-15 11:53 6% ` Ihor Radchenko
@ 2023-08-15 14:25 11% ` Juan Manuel Macías
2023-08-16 8:10 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-15 14:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Sure, but look at the pdf. The generated pdfs are not different for some
> reason.
Ah, sorry. It was a foolish oversight of mine. The point is that a
\vspace after a line break in normal text has no effect. This does work:
lorem ipsum\\
\vspace*{10ex}\\
dolor
but it's a dirty workaround. In addition, there are more problems that I
had not noticed. If it is normal text, LaTeX indents the first line. A
\parindent=0 should be added, but that means complicating things
unnecessarily...
I think the best thing is to rethink the :literal attribute, as I
commented at the end of my other email:
- without :literal --> verse environment with a more "canonical" syntax.
- with :literal --> verse environment seen in the "old (org) style",
preserving the blank lines. In that context \vspace does work.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 11%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-15 11:50 10% ` Juan Manuel Macías
@ 2023-08-15 11:53 6% ` Ihor Radchenko
2023-08-15 14:25 11% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-15 11:53 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> The output is not different, which it should be, AFAIU. Am I missing something?
>
> I have tried your examples and I think both give the expected result.
> Look at this screenshot:
>
> https://i.imgur.com/ofl8Z9f.png
Sure, but look at the pdf. The generated pdfs are not different for some
reason.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-15 10:08 6% ` Ihor Radchenko
@ 2023-08-15 11:50 10% ` Juan Manuel Macías
2023-08-15 11:53 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-15 11:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Thanks!
> I tested the patch with
>
> #+attr_latex: :literal t
>
> #+begin_verse
>
> This is just a test.
> ASF.
>
> #+end_verse
>
>
> and then with
>
> #+attr_latex: :literal t
>
> #+begin_verse
>
> This is just a test.
>
> ASF.
>
> #+end_verse
>
> The output is not different, which it should be, AFAIU. Am I missing something?
I have tried your examples and I think both give the expected result.
Look at this screenshot:
https://i.imgur.com/ofl8Z9f.png
Note one important thing: the only horizontal spaces that are exported
"literally" (ie with \hspace...) are the ones at the beginning of the
line. This is the same as the old behavior, and works with both :literal
and the verse environment. Spaces between words are not exported. Well,
they are exported, but not as \hspace, so LaTeX resolves one or more
space to a single space. It could be an interesting feature that spaces
between words are also preserved, but none of the other backends do
that... Actually the :literal attribute has effect only on blank lines.
(Anyway, I think that without exporting the spaces between words, the
:literal attribute is a bit incomplete. But if those spaces are
exported, it would break compatibility with the other backends. The
horizontal space before the line makes sense for verses, because these
can often be indented arbitrarily in a poem. The other possibility is
that the :literal attribute also exports to a verse environment. In that
case, it would not break compatibility [the verse block in LaTeX would
just have two "modes": one more coherent with the syntax of the verse
environment and another one more similar to the behavior of the rest of
the backends and the "old" verse block behavior in LaTeX export]).
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-14 20:10 7% ` Juan Manuel Macías
@ 2023-08-15 10:08 6% ` Ihor Radchenko
2023-08-15 11:50 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-15 10:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> Looks reasonable in general. Of course, we will also need to document
>> the new attribute.
>
> Here is the modified patch (with your suggestions, including the `rx' code)
> and the documentation of the new attribute.
Thanks!
I tested the patch with
#+attr_latex: :literal t
#+begin_verse
This is just a test.
ASF.
#+end_verse
and then with
#+attr_latex: :literal t
#+begin_verse
This is just a test.
ASF.
#+end_verse
The output is not different, which it should be, AFAIU. Am I missing something?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-12 7:56 5% ` Ihor Radchenko
2023-08-12 11:28 10% ` Juan Manuel Macías
@ 2023-08-14 20:10 7% ` Juan Manuel Macías
2023-08-15 10:08 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-14 20:10 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
Ihor Radchenko writes:
> Looks reasonable in general. Of course, we will also need to document
> the new attribute.
Here is the modified patch (with your suggestions, including the `rx' code)
and the documentation of the new attribute.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-add-the-literal-attribute-to-verse-.patch --]
[-- Type: text/x-patch, Size: 5506 bytes --]
From 463e4a984b0ccc9bc1fdde699cb5cfed1ac59613 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Aug 2023 21:48:58 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
block.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `:literal' attribute is
used, the content is not exported within a `verse' environment, but
as-is, preserving horizontal spaces, line breaks, and blank lines.
The rx code has been suggested by Ihor Radchenko, to improve
readability.
* doc/org-manual.org (Verse blocks in LaTeX export): the new feature
is documented.
---
doc/org-manual.org | 12 ++++++++++--
lisp/ox-latex.el | 43 ++++++++++++++++++++++++++++++-------------
2 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e59efc417..b640bbc7c 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14425,8 +14425,8 @@ The LaTeX export backend converts horizontal rules by the specified
#+cindex: verse blocks, in @LaTeX{} export
#+cindex: @samp{ATTR_LATEX}, keyword
-The LaTeX export backend accepts four attributes for verse blocks:
-=:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
+The LaTeX export backend accepts five attributes for verse blocks:
+=:lines=, =:center=, =:versewidth=, =:latexcode= and =:literal=. The three first
require the external LaTeX package =verse.sty=, which is an extension
of the standard LaTeX environment.
@@ -14440,6 +14440,14 @@ of the standard LaTeX environment.
verse.
- =:latexcode= :: It accepts any arbitrary LaTeX code that can be
included within a LaTeX =verse= environment.
+- =:literal= :: With value t, the block is not exported to a =verse=
+ environment; instead, the content is exported as-is, preserving all
+ white lines as =\vspace{\baselineskip}=. Note that in the =verse=
+ environment, one or more blank lines between stanzas are exported as
+ a single blank line, and any blank lines before or after the content
+ are removed. If the =verse= package is loaded, the vertical spacing
+ between stanzas can be controlled by the length =\stanzaskip= (see
+ https://www.ctan.org/pkg/verse).
A complete example with Shakespeare's first sonnet:
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..fcf22f87d 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,32 +4116,49 @@ contextual information."
(let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
(latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
(cent (org-export-read-attribute :attr_latex verse-block :center))
- (attr (concat
- (if cent "[\\versewidth]" "")
- (if lin (format "\n\\poemlines{%s}" lin) "")
- (if latcode (format "\n%s" latcode) "")))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
+ (attr (if (not lit)
+ (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) ""))
+ ""))
(versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
- (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
- (linreset (if lin "\n\\poemlines{0}" "")))
+ (vwidth (if (and versewidth (not lit)) (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
+ (linreset (if (and lin (not lit)) "\n\\poemlines{0}" "")))
(concat
(org-latex--wrap-label
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
- ;; into a space of 1 em. Also change each blank line with
- ;; a vertical space of 1 em.
- (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ ;; into a normal space, calculated with `\fontdimen2\font'.
+ ;; One or more blank lines between lines are exported as a
+ ;; single blank line. If the `:literal' attribute is used,
+ ;; CONTENTS is exported as is, with no environment, preserving
+ ;; line breaks and vertical and horizontal spaces.
+ (format (if (not lit)
+ "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ "%s%s\n%s%s")
vwidth
attr
(replace-regexp-in-string
- "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+ "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (if (not lit)
+ (rx-to-string
+ `(seq (group ,org-latex-line-break-safe "\n")
+ (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n"))))
+ (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ (if (not lit)
+ (if lin "\\\\!\n\n" "\n\n")
+ "\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ (if (not lit)
+ (concat (org-trim contents t) "\n")
+ contents)
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 7%]
* Re: [patch] Fix inner smart quotes in French
2023-08-10 21:50 10% ` Juan Manuel Macías
@ 2023-08-13 9:20 6% ` Bastien Guerry
0 siblings, 0 replies; 200+ results
From: Bastien Guerry @ 2023-08-13 9:20 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Max Nikulin, orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> In any case (apart from LaTeX), it is clear that I was wrong when I said
> that the inner quotes that my patch 'corrects' were 'incorrect'.
Indeed, and thanks for the discussion, interesting.
> What I
> don't know is why babel-french defaults to the « “inner” » style. Is it
> the most used currently in France? If the « « inner » » style is more
> canonical, I don't mind having my patch 'fix' reverted.
It's difficult to say what's more common but since we cannot expect
the « « inner » » style to be correctly implemented in, say, HTML, and
since, even in LaTeX, babel-french defaults to the « “inner” » style,
I suggest we stick to the « “inner” » style (this is a defcustom and
users can change it.)
Thanks!
--
Bastien Guerry
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-12 11:28 10% ` Juan Manuel Macías
@ 2023-08-13 8:06 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-08-13 8:06 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>>> + (concat "\\("
>>> + (regexp-quote org-latex-line-break-safe)
>>> + "\n\\)"
>>> + "\\(^[ \t]*"
>>> + (regexp-quote org-latex-line-break-safe)
>>> + "\n"
>>> + "\\)+")
>>> + (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
>>
>> May also use rx for better readability.
>
> I remember that I tried rx a while ago and found it very useful and
> comfortable, but then I haven't done anything with it. The fact is that
> over time I have ended up getting used to suffering from the classic
> regexp and it is hard for me to get out of there :-). Of course, with rx
> it would be clearer but I would have to refresh my memory.
You can refer to [[info:elisp#Rx Constructs][elisp#Rx Constructs]]
I think your regexp in rx should look like
(rx-to-string `(seq (group ,org-latex-line-break-safe "\n")
(1+ (group line-start (0+ space) ,org-latex-line-break "\n"))))
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-12 7:56 5% ` Ihor Radchenko
@ 2023-08-12 11:28 10% ` Juan Manuel Macías
2023-08-13 8:06 6% ` Ihor Radchenko
2023-08-14 20:10 7% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-12 11:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> + (vwidth (if (not lit)
>> + (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")
>> + ""))
>
> Can just do (if (and versewidth (not lit)) (format ...) "")
>
>> + (linreset (if (not lit)
>> + (if lin "\n\\poemlines{0}" "")
>> + "")))
>
> (if (and lin (not lit)) ...)
Thanks for the suggestions. Yes, it's simpler that way.
>> (concat
>> (org-latex--wrap-label
>> verse-block
>> ;; In a verse environment, add a line break to each newline
>> ;; character and change each white space at beginning of a line
>> - ;; into a space of 1 em. Also change each blank line with
>> - ;; a vertical space of 1 em.
>> - (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
>> + ;; into a normal space, calculated with `\fontdimen2\font'.
>> + ;; One or more blank lines between lines are exported as a
>> + ;; single blank line. If the `:literal' attribute is used,
>> + ;; CONTENTS is exported as is, with no environment, preserving
>> + ;; line breaks and vertical and horizontal spaces.
>> + (format (if (not lit)
>> + "%s\\begin{verse}%s\n%s\\end{verse}%s"
>> + "%s%s\n%s%s")
>
> In the case of lit vwidth and attr are always empty. So, you are
> inserting an extra newline in front. Is it intentional?
I used that procedure because an extra blank line before (in the LaTeX
code) it has no effect in LaTeX compilation. And in case the :literal
attribute is present, vertical spaces are achieved by explicit
\vspace*{}. One or more empty lines before it just marks the beginning
of a new paragraph.
Naturally, if :literal is used the rest of attributes are meaningless
because they are intended for the verse environment. They can even give
some error in the compilation. So I opted to disable them with the mere
presence of :literal, leaving them 'empty' (so as not to manipulate the
function further).
>> + (concat "\\("
>> + (regexp-quote org-latex-line-break-safe)
>> + "\n\\)"
>> + "\\(^[ \t]*"
>> + (regexp-quote org-latex-line-break-safe)
>> + "\n"
>> + "\\)+")
>> + (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
>
> May also use rx for better readability.
I remember that I tried rx a while ago and found it very useful and
comfortable, but then I haven't done anything with it. The fact is that
over time I have ended up getting used to suffering from the classic
regexp and it is hard for me to get out of there :-). Of course, with rx
it would be clearer but I would have to refresh my memory.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-11 18:52 8% ` Juan Manuel Macías
@ 2023-08-12 7:56 5% ` Ihor Radchenko
2023-08-12 11:28 10% ` Juan Manuel Macías
2023-08-14 20:10 7% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2023-08-12 7:56 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> How about this (pre-)patch? With the `:literal' attr., the content of the
> block is exported "as is", with all manual formatting preserved.
Looks reasonable in general.
Of course, we will also need to document the new attribute.
> I have made some modifications in the horizontal and vertical spaces (in
> case :literal is used)...
Makes sense to me.
> + (vwidth (if (not lit)
> + (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")
> + ""))
Can just do (if (and versewidth (not lit)) (format ...) "")
> + (linreset (if (not lit)
> + (if lin "\n\\poemlines{0}" "")
> + "")))
(if (and lin (not lit)) ...)
> (concat
> (org-latex--wrap-label
> verse-block
> ;; In a verse environment, add a line break to each newline
> ;; character and change each white space at beginning of a line
> - ;; into a space of 1 em. Also change each blank line with
> - ;; a vertical space of 1 em.
> - (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
> + ;; into a normal space, calculated with `\fontdimen2\font'.
> + ;; One or more blank lines between lines are exported as a
> + ;; single blank line. If the `:literal' attribute is used,
> + ;; CONTENTS is exported as is, with no environment, preserving
> + ;; line breaks and vertical and horizontal spaces.
> + (format (if (not lit)
> + "%s\\begin{verse}%s\n%s\\end{verse}%s"
> + "%s%s\n%s%s")
In the case of lit vwidth and attr are always empty. So, you are
inserting an extra newline in front. Is it intentional?
> + (concat "\\("
> + (regexp-quote org-latex-line-break-safe)
> + "\n\\)"
> + "\\(^[ \t]*"
> + (regexp-quote org-latex-line-break-safe)
> + "\n"
> + "\\)+")
> + (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
May also use rx for better readability.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-11 10:00 6% ` Ihor Radchenko
@ 2023-08-11 18:52 8% ` Juan Manuel Macías
2023-08-12 7:56 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-11 18:52 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> ... In any case, the fact that the verse block can also be used to
>> literally export line breaks and horizontal/vertical spaces is
>> interesting. Something occurred to me that I don't know if it's a bit
>> foolhardy: how about a LaTeX attribute ':literal t'? If used, it would
>> not export to a verse environment (specialized in poetry) but to normal
>> text, without environment, but with line breaks and horizontal and
>> vertical spacing preserved... wdyt?
>
> If one uses verse blocks to export to multiple backends, your suggestion
> sounds reasonable. That way, export results will look closer across
> different export backends.
How about this (pre-)patch? With the `:literal' attr., the content of the
block is exported "as is", with all manual formatting preserved.
I have made some modifications in the horizontal and vertical spaces (in
case :literal is used), because the em does not seem the correct length
to me. The em equals the font size in points, and, vertically, it would
not equal a blank line (line spacing is usually 120% of the em), so it's
safest to use \baselineskip. Thus, \vspace*{\baselineskip} is identical
to leaving an empty line. As for the horizontal space, the em is greater
than the normal space. The closest thing would be to use
\fontdimen2\font. So, if one puts 6 manual spaces (with the spacebar
key), it is exported as \hspace*{6\fontdimen2\font}
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-add-the-literal-attribute-to-verse-.patch --]
[-- Type: text/x-patch, Size: 3962 bytes --]
From baf9cc50313bb7df94e8173349db9c834f1ccf64 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 11 Aug 2023 19:57:49 +0200
Subject: [PATCH] lisp/ox-latex.el: add the `:literal' attribute to verse
block.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package. If the `':literal attribute is
used, the content is not exported within a `verse' environment, but as-is,
preserving horizontal spaces, line breaks, and blank lines.
---
lisp/ox-latex.el | 52 ++++++++++++++++++++++++++++++++++++------------
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..557ceee1b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4116,32 +4116,58 @@ contextual information."
(let* ((lin (org-export-read-attribute :attr_latex verse-block :lines))
(latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
(cent (org-export-read-attribute :attr_latex verse-block :center))
- (attr (concat
- (if cent "[\\versewidth]" "")
- (if lin (format "\n\\poemlines{%s}" lin) "")
- (if latcode (format "\n%s" latcode) "")))
+ (lit (org-export-read-attribute :attr_latex verse-block :literal))
+ (attr (if (not lit)
+ (concat
+ (if cent "[\\versewidth]" "")
+ (if lin (format "\n\\poemlines{%s}" lin) "")
+ (if latcode (format "\n%s" latcode) ""))
+ ""))
(versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
- (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
- (linreset (if lin "\n\\poemlines{0}" "")))
+ (vwidth (if (not lit)
+ (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) "")
+ ""))
+ (linreset (if (not lit)
+ (if lin "\n\\poemlines{0}" "")
+ "")))
(concat
(org-latex--wrap-label
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
- ;; into a space of 1 em. Also change each blank line with
- ;; a vertical space of 1 em.
- (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ ;; into a normal space, calculated with `\fontdimen2\font'.
+ ;; One or more blank lines between lines are exported as a
+ ;; single blank line. If the `:literal' attribute is used,
+ ;; CONTENTS is exported as is, with no environment, preserving
+ ;; line breaks and vertical and horizontal spaces.
+ (format (if (not lit)
+ "%s\\begin{verse}%s\n%s\\end{verse}%s"
+ "%s%s\n%s%s")
vwidth
attr
(replace-regexp-in-string
- "^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
+ "^[ \t]+" (lambda (m) (format "\\hspace*{%d\\fontdimen2\\font}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (if (not lit)
+ (concat "\\("
+ (regexp-quote org-latex-line-break-safe)
+ "\n\\)"
+ "\\(^[ \t]*"
+ (regexp-quote org-latex-line-break-safe)
+ "\n"
+ "\\)+")
+ (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+ (if (not lit)
+ (if lin "\\\\!\n\n" "\n\n")
+ "\\vspace*{\\baselineskip}")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ (if (not lit)
+ ;; Remove any blank lines before and after CONTENTS.
+ (concat (org-trim contents t) "\n")
+ contents)
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 8%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-10 10:39 10% ` Juan Manuel Macías
@ 2023-08-11 10:00 6% ` Ihor Radchenko
2023-08-11 18:52 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-11 10:00 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> ... In any case, the fact that the verse block can also be used to
> literally export line breaks and horizontal/vertical spaces is
> interesting. Something occurred to me that I don't know if it's a bit
> foolhardy: how about a LaTeX attribute ':literal t'? If used, it would
> not export to a verse environment (specialized in poetry) but to normal
> text, without environment, but with line breaks and horizontal and
> vertical spacing preserved... wdyt?
If one uses verse blocks to export to multiple backends, your suggestion
sounds reasonable. That way, export results will look closer across
different export backends.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fix inner smart quotes in French
2023-08-10 14:49 0% ` Bastien
@ 2023-08-10 21:50 10% ` Juan Manuel Macías
2023-08-13 9:20 6% ` Bastien Guerry
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-10 21:50 UTC (permalink / raw)
To: Bastien; +Cc: Max Nikulin, orgmode
Bastien writes:
> Yes, this is also what the French national printing press ("Imprimerie
> nationale"), which is quite authoritative in this matter, recommends.
>
> Note that the Full recommendation of the Imprimerie nationale is to
> repeat second-level quotation marks at the beginning and of each line
> when the text spans over several lines, like this:
>
> Then X reported : « This is what Y said : « Here is
> « a quotation with a paragraph spaning over several
> « lines, with each line starting with a quotation mark
> « until the end of the quotation. »
>
> (The unique » at the end is intentional, the rule is to not repeat.)
I've been looking at the babel-french documentation (LaTeX)
(http://mirrors.ctan.org/macros/latex/contrib/babel-contrib/french/frenchb.pdf),
which claims to be based on "Lexique des règles typographiques en usage
à l’Imprimerie Nationale, troisième édition (1994)"; p. 3 is about
quotation marks and the different options:
-----
with all engines: the inner quotation is surrounded by double quotes
(“texte”) unless option InnerGuillSingle=true, then a) the inner
quotation is printed as ‹ texte › and b) if the inner quotation spreads
over more than one paragraph, every paragraph included in the inner
quotation starts with a ‹ or a › or nothing, depending on option
EveryParGuill=open (default) or =close or =none.
with LuaTeX based engines, it is possible to add a French opening or
closing guillemet (« or ») at the beginning of every line of the inner
quotation using option EveryLineGuill=open or =close; note that with any
of these options, the inner quotation is surrounded by French guillemets
(« and ») regardless option InnerGuillSingle; the default is
EveryLineGuill=none so that \frquote{} behaves as with non-LuaTeX
engines.
-----
I have tried this example with quotes per line:
https://i.imgur.com/od4HwUs.png
In any case (apart from LaTeX), it is clear that I was wrong when I said
that the inner quotes that my patch 'corrects' were 'incorrect'. What I
don't know is why babel-french defaults to the « “inner” » style. Is it
the most used currently in France? If the « « inner » » style is more
canonical, I don't mind having my patch 'fix' reverted.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] Fix inner smart quotes in French
2023-08-10 14:10 0% ` Max Nikulin
@ 2023-08-10 14:49 0% ` Bastien
2023-08-10 21:50 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Bastien @ 2023-08-10 14:49 UTC (permalink / raw)
To: Max Nikulin; +Cc: Juan Manuel Macías, orgmode
Max Nikulin <manikulin@gmail.com> writes:
> On 04/08/2023 18:09, Bastien wrote:
>> Juan Manuel Macías writes:
>>
>>> In the meantime, I'm submitting this patch with a fix for second-level
>>> French `smart quotes': the correct quotes should be “” (without spaces,
>>> as in Spanish or Greek) (please, some francophone correct me, if I'm
>>> wrong...).
>> Applied, thanks!
>
> I am not a francophone, I just have tried to look into sources I found
> during discussion on Greek quotes.
>
> https://en.wikipedia.org/wiki/Quotation_mark#French
> says that there are different styles of inner quotes.
>
> I am more worry that Unicode CLDR defines the same character for
> quotes.
Yes, this is also what the French national printing press ("Imprimerie
nationale"), which is quite authoritative in this matter, recommends.
Note that the Full recommendation of the Imprimerie nationale is to
repeat second-level quotation marks at the beginning and of each line
when the text spans over several lines, like this:
Then X reported : « This is what Y said : « Here is
« a quotation with a paragraph spaning over several
« lines, with each line starting with a quotation mark
« until the end of the quotation. »
(The unique » at the end is intentional, the rule is to not repeat.)
I don't have a strong opinion on this. I find the non-French
(e.g. canadian?) convention more sensible for digital documents (vs
printed ones): I expect repeating the quotation mark at the beginning
of each line is something software don't do. (Perhaps there is a
LaTeX package doing so, I've not checked.)
So I'd rather use this:
Then X reported : « This is what Y said : ”Here is
a quotation with a paragraph spaning over several
lines, with each line starting with a quotation mark
until the end of the quotation."»
WDYT?
--
Bastien
^ permalink raw reply [relevance 0%]
* Re: [patch] Fix inner smart quotes in French
2023-08-04 11:09 6% ` Bastien
@ 2023-08-10 14:10 0% ` Max Nikulin
2023-08-10 14:49 0% ` Bastien
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-08-10 14:10 UTC (permalink / raw)
To: Bastien, Juan Manuel Macías; +Cc: orgmode
On 04/08/2023 18:09, Bastien wrote:
> Juan Manuel Macías writes:
>
>> In the meantime, I'm submitting this patch with a fix for second-level
>> French `smart quotes': the correct quotes should be “” (without spaces,
>> as in Spanish or Greek) (please, some francophone correct me, if I'm
>> wrong...).
>
> Applied, thanks!
I am not a francophone, I just have tried to look into sources I found
during discussion on Greek quotes.
https://en.wikipedia.org/wiki/Quotation_mark#French
says that there are different styles of inner quotes.
I am more worry that Unicode CLDR defines the same character for quotes.
However inner quotes varies across languages:
fr.xml: <quotationStart>«</quotationStart>
fr.xml: <quotationEnd>»</quotationEnd>
fr.xml: <alternateQuotationStart>«</alternateQuotationStart>
fr.xml: <alternateQuotationEnd>»</alternateQuotationEnd>
fr_CA.xml: <alternateQuotationStart>”</alternateQuotationStart>
fr_CA.xml: <alternateQuotationEnd>“</alternateQuotationEnd>
fr_CH.xml: <alternateQuotationStart>‹</alternateQuotationStart>
fr_CH.xml: <alternateQuotationEnd>›</alternateQuotationEnd>
I would prefer to keep consistency with CLDR.
^ permalink raw reply [relevance 0%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-10 9:27 5% ` Ihor Radchenko
@ 2023-08-10 10:39 10% ` Juan Manuel Macías
2023-08-11 10:00 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-10 10:39 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Well. Technically, we already warn users that the blank lines are
> preserved in the verse blocks:
>
> 12.1 Paragraphs
> ===============
>
> Paragraphs are separated by at least one empty line. If you need to
> enforce a line break within a paragraph, use ‘\\’ at the end of a line.
>
> To preserve the line breaks, indentation and blank lines in a region,
> but otherwise use normal formatting, you can use this construct, which
> can also be used to format poetry.
>
>
> #+BEGIN_VERSE
> Great clouds overhead
> Tiny black birds rise and fall
> Snow covers Emacs
>
> ---AlexSchroeder
> #+END_VERSE
>
> So, I now think that while extra cleanups might be OK for ox-latex, we
> may not want to ignore empty lines universally in all the verse blocks.
hmm, I don't know if phrased like that (as read in the documentation)
it's clear enough that the empty lines before and after the content are
also preserved. I would understand not, but it could also be a habit that
I inherited from LaTeX: I usually leave a blank line between the
#+begin/#+end directives and the content because it makes it easier for
me to read. I don't know if it is a widespread habit among other
users...
Anyway, I don't mind leaving things as they are in the other backends,
but in the case of LaTeX, with my patch modifications, it would be
necessary to remove the blank lines before and after the content.
Otherwise it would produce something like:
\begin{verse}
\\[0pt]
\\[0pt]
\\[0pt]
\\[0pt]
\\[0pt]
lorem ipsum dolor
\end{verse}
which would return the error "There's no line here to end".
Also, the LaTeX 'verse' environment has its own syntax for vertical
spaces. It is not necessary to put an explicit \vspace just to separate
stanzas.
... In any case, the fact that the verse block can also be used to
literally export line breaks and horizontal/vertical spaces is
interesting. Something occurred to me that I don't know if it's a bit
foolhardy: how about a LaTeX attribute ':literal t'? If used, it would
not export to a verse environment (specialized in poetry) but to normal
text, without environment, but with line breaks and horizontal and
vertical spacing preserved... wdyt?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 10%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-09 8:41 12% ` Juan Manuel Macías
@ 2023-08-10 9:27 5% ` Ihor Radchenko
2023-08-10 10:39 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-10 9:27 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Do you mean that people use extra leading/trailing spaces just to get
>> extra vertical space before/after the verse block in _latex_ export?
>
> No, I don't think people use it for that purpose. I meant that if
> someone puts a space before or after the content (which can be usual,
> for clarity):
>
> #+begin_verse
>
> blah...
>
> #+end_verse
>
> that vertical space appears in the export, which shouldn't.
Well. Technically, we already warn users that the blank lines are
preserved in the verse blocks:
12.1 Paragraphs
===============
Paragraphs are separated by at least one empty line. If you need to
enforce a line break within a paragraph, use ‘\\’ at the end of a line.
To preserve the line breaks, indentation and blank lines in a region,
but otherwise use normal formatting, you can use this construct, which
can also be used to format poetry.
#+BEGIN_VERSE
Great clouds overhead
Tiny black birds rise and fall
Snow covers Emacs
---AlexSchroeder
#+END_VERSE
So, I now think that while extra cleanups might be OK for ox-latex, we
may not want to ignore empty lines universally in all the verse blocks.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-09 7:57 6% ` Ihor Radchenko
@ 2023-08-09 8:41 12% ` Juan Manuel Macías
2023-08-10 9:27 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-09 8:41 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>>> I see nothing that would prevent merging this patch.
>>> However, I believe that removing blank lines before/after content is
>>> something we may want to do in other built-in backends as well. WDYT?
>>
>> I think you're right. My impression is that the blank lines before/after
>> content is not a desired feature, but rather a consequence of
>> substituting line breaks to create the space between stanzas.
>
> Do you mean that people use extra leading/trailing spaces just to get
> extra vertical space before/after the verse block in _latex_ export?
No, I don't think people use it for that purpose. I meant that if
someone puts a space before or after the content (which can be usual,
for clarity):
#+begin_verse
blah...
#+end_verse
that vertical space appears in the export, which shouldn't.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-07 17:23 9% ` Juan Manuel Macías
@ 2023-08-09 7:57 6% ` Ihor Radchenko
2023-08-09 8:41 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-09 7:57 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I see nothing that would prevent merging this patch.
>> However, I believe that removing blank lines before/after content is
>> something we may want to do in other built-in backends as well. WDYT?
>
> I think you're right. My impression is that the blank lines before/after
> content is not a desired feature, but rather a consequence of
> substituting line breaks to create the space between stanzas.
Do you mean that people use extra leading/trailing spaces just to get
extra vertical space before/after the verse block in _latex_ export?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-07 11:40 6% ` Ihor Radchenko
@ 2023-08-07 17:23 9% ` Juan Manuel Macías
2023-08-09 7:57 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-07 17:23 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> Rationale for this patch: the treatment of blank lines in
>> `org-latex-verse-block' is inconsistent with the syntax of the `verse'
>> environment, both the one that includes LaTeX and the one provided by
>> the `verse' package as a replacement for the former.
>> ...
>> So, after this patch:
>>
>> • Any blank line before and/or after the content is removed;
>>
>> • One or more blank lines between stanzas are exported as a single blank
>> line, leaving the previous final verse without the linebreak mark
>> `\\';
>>
>> • When verse numbering is enabled via the `:lines' attribute (for the
>> `verse' package), the last verses of each stanza are marked with
>> `\\!', according to the verse package syntax (this was not necessary
>> with the previous behavior).
>
> I see nothing that would prevent merging this patch.
> However, I believe that removing blank lines before/after content is
> something we may want to do in other built-in backends as well. WDYT?
I think you're right. My impression is that the blank lines before/after
content is not a desired feature, but rather a consequence of
substituting line breaks to create the space between stanzas. I think
the space before/after is better removed because it doesn't make sense
and adds unnecessary direct formatting[1]. Maybe it could be changed to
`(org-trim contents t) in all cases, like in this patch?
[1] However, the horizontal 'verbatim' space that can be added before
each line/verse seems like a great feature to me, since verses can also
be indented arbitrarily. This block it's a gem, and it has some really
cool features, not just to quote poetry.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: [patch] ox-latex.el: fix blank lines behavior in verse block
2023-08-06 12:03 8% [patch] ox-latex.el: fix blank lines behavior in verse block Juan Manuel Macías
@ 2023-08-07 11:40 6% ` Ihor Radchenko
2023-08-07 17:23 9% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-07 11:40 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Rationale for this patch: the treatment of blank lines in
> `org-latex-verse-block' is inconsistent with the syntax of the `verse'
> environment, both the one that includes LaTeX and the one provided by
> the `verse' package as a replacement for the former.
> ...
> So, after this patch:
>
> • Any blank line before and/or after the content is removed;
>
> • One or more blank lines between stanzas are exported as a single blank
> line, leaving the previous final verse without the linebreak mark
> `\\';
>
> • When verse numbering is enabled via the `:lines' attribute (for the
> `verse' package), the last verses of each stanza are marked with
> `\\!', according to the verse package syntax (this was not necessary
> with the previous behavior).
I see nothing that would prevent merging this patch.
However, I believe that removing blank lines before/after content is
something we may want to do in other built-in backends as well. WDYT?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* [patch] ox-latex.el: fix blank lines behavior in verse block
@ 2023-08-06 12:03 8% Juan Manuel Macías
2023-08-07 11:40 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-06 12:03 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]
Rationale for this patch: the treatment of blank lines in
`org-latex-verse-block' is inconsistent with the syntax of the `verse'
environment, both the one that includes LaTeX and the one provided by
the `verse' package as a replacement for the former.
Currently, each blank line is exported to LaTeX as an explicit vertical
space: \vspace*{1em}. This can return unexpected results. For example,
this:
┌────
│ #+begin_verse
│
│ lorem
│ ipsum
│ dolor
|
│ #+end_verse
└────
is exported to LaTeX as:
┌────
│ \begin{verse}
│ \vspace*{1em}
│ lorem\\[0pt]
│ ipsum\\[0pt]
│ dolor\\[0pt]
│ \vspace*{1em}
│ \end{verse}
└────
In the LaTeX `verse' environment, spaces before and after the content
are not taken into account.
As for the separation between stanzas, this is marked with at least one
blank line between the stanzas, as in normal paragraphs (not with an
explicit vertical space). Also it is not necessar y that the last verse
of each stanza ends with the linebreak mark `\\'.
So, after this patch:
• Any blank line before and/or after the content is removed;
• One or more blank lines between stanzas are exported as a single blank
line, leaving the previous final verse without the linebreak mark
`\\';
• When verse numbering is enabled via the `:lines' attribute (for the
`verse' package), the last verses of each stanza are marked with
`\\!', according to the verse package syntax (this was not necessary
with the previous behavior).
This way, the `verse' block is exported to LaTeX with the correct
syntax. This also brings the advantage of being able to globally control
the spacing between stanzas via the verse package’s \stanzaskip command.
Example:
┌────
│ #+begin_verse
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│ #+end_verse
└────
LaTeX:
┌────
│ \begin{verse}
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ \end{verse}
└────
And with verse numbers:
┌────
│ #+ATTR_LaTeX: :lines 5
│ #+begin_verse
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│
│ Lorem ipsum dolor
│ lorem ipsum dolor
│ lorem ipsum dolor
│ #+end_verse
└────
LaTeX:
┌────
│ \begin{verse}
│ \poemlines{5}
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\!
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\!
│
│ Lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ lorem ipsum dolor\\[0pt]
│ \end{verse}
│ \poemlines{0}
└────
N.B.: the `\\[0pt]' mark of the last verse does not affect the final result.
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-fix-blank-lines-behavior-in-verse-b.patch --]
[-- Type: text/x-patch, Size: 1944 bytes --]
From 0c8a352567333d0d743b5235b68e9cd5d513f615 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 6 Aug 2023 12:42:36 +0200
Subject: [PATCH] lisp/ox-latex.el: fix blank lines behavior in verse block
export.
* (org-latex-verse-block): now the treatment of blank lines is
consistent with the syntax of the LaTeX `verse' environment, and the
one provided by the `verse' package.
---
lisp/ox-latex.el | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 31cad1dc4..26827537a 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -4128,20 +4128,28 @@ contextual information."
verse-block
;; In a verse environment, add a line break to each newline
;; character and change each white space at beginning of a line
- ;; into a space of 1 em. Also change each blank line with
- ;; a vertical space of 1 em.
+ ;; into a space of 1 em. One or more blank lines between lines
+ ;; are exported as a single blank line.
(format "%s\\begin{verse}%s\n%s\\end{verse}%s"
vwidth
attr
(replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
- (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$")
- "\\vspace*{1em}"
+ (concat "\\("
+ (regexp-quote org-latex-line-break-safe)
+ "\n\\)"
+ "\\(^[ \t]*"
+ (regexp-quote org-latex-line-break-safe)
+ "\n"
+ "\\)+")
+ (if lin "\\\\!\n\n" "\n\n")
(replace-regexp-in-string
"\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
(concat org-latex-line-break-safe "\n")
- contents nil t)
+ ;; Remove any blank lines before and after CONTENTS.
+ (concat (org-trim contents t) "\n")
+ nil t)
nil t)
nil t)
linreset)
--
2.41.0
^ permalink raw reply related [relevance 8%]
* Re: [patch] Fix inner smart quotes in French
2023-08-05 10:51 12% ` Juan Manuel Macías
@ 2023-08-05 13:19 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2023-08-05 13:19 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> And it looks like at least on of the test conditions is not trivial to
>> fix without knowing French. May you or somebody familiar with French
>> punctuation take a look?
>
> I'm afraid I'm not very familiar with the syntax and usage of tests, so
> I have to study that part. I've been looking at
> `test-org-export/activate-smart-quotes', and I have a question: does it
> only include tests for English and French cases?
Yes, currently.
> First level quotes for French are «» with spaces, and second level ones
> (if I'm not mistaken) should be “”, without spaces (my patch fix).
> Therefore, I understand that a line like:
>
> (equal '( "« outer « inner » outer »")
>
> should it be changed like this
>
> (equal '( "« outer “inner” outer »")
>
> ?
That was exactly the piece of information I was missing.
I have no notion of "inner" quotes being different from "outer" in the
languages I am familiar with.
I now managed to fix the tests.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e4f127437
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fix inner smart quotes in French
2023-08-05 7:08 6% ` Ihor Radchenko
@ 2023-08-05 10:51 12% ` Juan Manuel Macías
2023-08-05 13:19 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-08-05 10:51 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor,
Ihor Radchenko writes:
> Welcome back :)
thanks! :-)
>> In the meantime, I'm submitting this patch with a fix for second-level
>> French `smart quotes': the correct quotes should be “” (without spaces,
>> as in Spanish or Greek) (please, some francophone correct me, if I'm
>> wrong...).
>
> The patch does not update the tests. So, we now have
> FAILED 644/1151 test-org-export/activate-smart-quotes
>
> And it looks like at least on of the test conditions is not trivial to
> fix without knowing French. May you or somebody familiar with French
> punctuation take a look?
I'm afraid I'm not very familiar with the syntax and usage of tests, so
I have to study that part. I've been looking at
`test-org-export/activate-smart-quotes', and I have a question: does it
only include tests for English and French cases?
First level quotes for French are «» with spaces, and second level ones
(if I'm not mistaken) should be “”, without spaces (my patch fix).
Therefore, I understand that a line like:
(equal '( "« outer « inner » outer »")
should it be changed like this
(equal '( "« outer “inner” outer »")
?
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
^ permalink raw reply [relevance 12%]
* Re: [patch] Fix inner smart quotes in French
2023-08-04 7:25 12% [patch] Fix inner smart quotes in French Juan Manuel Macías
2023-08-04 11:09 6% ` Bastien
@ 2023-08-05 7:08 6% ` Ihor Radchenko
2023-08-05 10:51 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-08-05 7:08 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> These last months I have been disconnected from the list for family
> reasons. Now, trying to catch up with the news on the list and pending
> things that I left here :-).
Welcome back :)
> In the meantime, I'm submitting this patch with a fix for second-level
> French `smart quotes': the correct quotes should be “” (without spaces,
> as in Spanish or Greek) (please, some francophone correct me, if I'm
> wrong...).
The patch does not update the tests. So, we now have
FAILED 644/1151 test-org-export/activate-smart-quotes
And it looks like at least on of the test conditions is not trivial to
fix without knowing French. May you or somebody familiar with French
punctuation take a look?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [patch] Fix inner smart quotes in French
2023-08-04 7:25 12% [patch] Fix inner smart quotes in French Juan Manuel Macías
@ 2023-08-04 11:09 6% ` Bastien
2023-08-10 14:10 0% ` Max Nikulin
2023-08-05 7:08 6% ` Ihor Radchenko
1 sibling, 1 reply; 200+ results
From: Bastien @ 2023-08-04 11:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Hi Juan,
Juan Manuel Macías <maciaschain@posteo.net> writes:
> In the meantime, I'm submitting this patch with a fix for second-level
> French `smart quotes': the correct quotes should be “” (without spaces,
> as in Spanish or Greek) (please, some francophone correct me, if I'm
> wrong...).
Applied, thanks!
--
Bastien
^ permalink raw reply [relevance 6%]
* [patch] Fix inner smart quotes in French
@ 2023-08-04 7:25 12% Juan Manuel Macías
2023-08-04 11:09 6% ` Bastien
2023-08-05 7:08 6% ` Ihor Radchenko
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2023-08-04 7:25 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi,
These last months I have been disconnected from the list for family
reasons. Now, trying to catch up with the news on the list and pending
things that I left here :-).
In the meantime, I'm submitting this patch with a fix for second-level
French `smart quotes': the correct quotes should be “” (without spaces,
as in Spanish or Greek) (please, some francophone correct me, if I'm
wrong...).
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[-- Attachment #2: 0001-lisp-ox.el-fix-inner-smart-quotes-in-French.patch --]
[-- Type: text/x-patch, Size: 1195 bytes --]
From 202a085ce9e0e3e7c0e67bcdde91e706050fd976 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 4 Aug 2023 09:04:03 +0200
Subject: [PATCH] lisp/ox.el: fix inner smart quotes in French.
* (org-export-smart-quotes-alist): the correct French second level
quotation marks are added.
---
lisp/ox.el | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 3a6dd8ded..473bd927c 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5840,11 +5840,8 @@ transcoding it."
(primary-closing
:utf-8 " »" :html " »" :latex "\\fg{}"
:texinfo "@tie{}@guillemetright{}")
- (secondary-opening
- :utf-8 "« " :html "« " :latex "\\og "
- :texinfo "@guillemetleft{}@tie{}")
- (secondary-closing :utf-8 " »" :html " »" :latex "\\fg{}"
- :texinfo "@tie{}@guillemetright{}")
+ (secondary-opening :utf-8 "“" :html "“" :latex "``" :texinfo "``")
+ (secondary-closing :utf-8 "”" :html "”" :latex "''" :texinfo "''")
(apostrophe :utf-8 "’" :html "’"))
("is"
(primary-opening
--
2.41.0
^ permalink raw reply related [relevance 12%]
* Re: How to tell `org-html-link' to create a link with some HTML class?
@ 2023-06-20 16:30 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-06-20 16:30 UTC (permalink / raw)
To: emacs-orgmode
On 20/06/2023 11:42, Marcin Borkowski wrote:
>
> as I mentioned some time ago, I'm writing a custom exporter (actually,
> a very thin wrapper around the HTML exporter). I'd like `org-html-link'
> to add some class to the links it generates. Is that possible?
I do not have a ready to use recipe. Some links to mailing list threads:
https://list.orgmode.org/t8q71r$mgv$1@ciao.gmane.io/
Max Nikulin. [BUG] manual: confusing example of adding attributes to a
link (affiliated keywords) Mon, 20 Jun 2022 23:25:29 +0700
Unfortunately
#+attr_html: :class something
adds class to the whole following paragraph as well. Notice a link to a
John Kitchin blog post. Another thread with the same link:
https://list.orgmode.org/87im8k3be8.fsf@posteo.net/
Juan Manuel Macías. Re: [tip] Export subfigures to LaTeX (and HTML).
Tue, 29 Dec 2020 16:00:31 +0100
I have not tried to implement an idea with a parse-tree export filter
that transfers attributes from links having a custom type to following
objects (Ihor is against such approach):
Max Nikulin. Re: About 'inline special blocks' Tue, 24 May 2022 22:09:33
+0700. https://list.orgmode.org/t6isfe$c50$1@ciao.gmane.io
^ permalink raw reply [relevance 5%]
* Re: how to add special glyphs
2023-03-07 15:54 6% ` Max Nikulin
@ 2023-03-08 0:29 0% ` Rob Sargent
0 siblings, 0 replies; 200+ results
From: Rob Sargent @ 2023-03-08 0:29 UTC (permalink / raw)
To: emacs-orgmode
On 3/7/23 08:54, Max Nikulin wrote:
> On 06/03/2023 22:42, Rob Sargent wrote:
>> I have added a "boxed x" and "CHECK MARK" to my document, but they do
>> not get exported to pdf output.
>
> LuaLaTeX may be instructed to use fallback fonts, see e.g.
>
> https://list.orgmode.org/87bktus666.fsf_-_@posteo.net/
> Juan Manuel Macías. Fallback fonts in LuaTeX via
> 'luaotfload.add_fallback' (was "Fontsets"). Tue, 12 Jul 2022 15:26:57
> +0000
>
> https://list.orgmode.org/orgmode/scuirf$m7o$1@ciao.gmane.io/
> Maxim Nikulin. Re: org-mode export to (latex) PDF. Sat, 17 Jul 2021
> 19:35:57 +0700
>
> To my taste it is too low level.
That I placed the unicode into the text was "too low level"? I could
argue that "it's a UTF doc", or that "\ding{55}" is bizarrely high
level. Other's have shown methods which maximize the cross export
experience. I'll consider those. I'm not sure LuaLaTex is an option
for me.
rjs
^ permalink raw reply [relevance 0%]
* Re: how to add special glyphs
@ 2023-03-07 15:54 6% ` Max Nikulin
2023-03-08 0:29 0% ` Rob Sargent
0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2023-03-07 15:54 UTC (permalink / raw)
To: Rob Sargent, emacs-orgmode
On 06/03/2023 22:42, Rob Sargent wrote:
> I have added a "boxed x" and "CHECK MARK" to my document, but they do
> not get exported to pdf output.
LuaLaTeX may be instructed to use fallback fonts, see e.g.
https://list.orgmode.org/87bktus666.fsf_-_@posteo.net/
Juan Manuel Macías. Fallback fonts in LuaTeX via
'luaotfload.add_fallback' (was "Fontsets"). Tue, 12 Jul 2022 15:26:57 +0000
https://list.orgmode.org/orgmode/scuirf$m7o$1@ciao.gmane.io/
Maxim Nikulin. Re: org-mode export to (latex) PDF. Sat, 17 Jul 2021
19:35:57 +0700
To my taste it is too low level.
^ permalink raw reply [relevance 6%]
* Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated
@ 2023-03-05 11:12 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-03-05 11:12 UTC (permalink / raw)
To: emacs-orgmode
On 18/02/2023 17:18, Ihor Radchenko wrote:
> In https://orgmode.org/worg/org-faq.html#org60202b9, the answer uses
> obsolete function `org-add-link-type'. We should change it to
> `org-link-set-parameters'.
Confirmed.
A newer recipe:
Juan Manuel Macías to emacs-orgmode… Re: how to export red colored TeX
to latex. Tue, 30 Nov 2021 16:56:00 +0000.
https://list.orgmode.org/87bl21vazj.fsf@posteo.net
Likely should be modified a bit to support derived backends.
The following package might be mentioned:
Colours section in org-special-block-extras
https://alhassy.com/org-special-block-extras/#Colours
Other files:
- org-tutorials/org-R/org-variables-counts.org
- org-tutorials/org-R/variable-popcon.org
Need review:
- org-hacks.org
mid: links for org-gnus (not ol-gnus) and org-occur example
- exporters/anno-bib-template-worg.org
citations using ebib
Outdated:
- org-tutorials/org-latex-export.org
Org < 8.0
- org-configs/org-customization-survey.org
- org-configs/org-customization-survey-2013.org
^ permalink raw reply [relevance 5%]
* Re: OS advice
2023-01-07 22:22 7% ` Juan Manuel Macías
@ 2023-01-07 22:28 7% ` Ypo
0 siblings, 0 replies; 200+ results
From: Ypo @ 2023-01-07 22:28 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]
Wow! Thanks Juan Manuel!
El 07/01/2023 a las 23:22, Juan Manuel Macías escribió:
> Ypo writes:
>
>> Hi
>>
>> Orgmode is sometimes desperately slow on my PC:
>>
>> Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100 Mhz
>>
>> (RAM) 4,00 GB
>>
>> I am running Windows 10, everything I use works OK, but Orgmode.
>>
>> Do you think that if I install a Linux OS, Orgmode would run fast? Any
>> OS suggestion?
> I've read somewhere that Emacs performance on windows tends to be slow,
> but I can't assure you because the last windows I suffered was W98, and
> at that time I didn't even use Emacs. According to the official GNU
> Emacs website:
>
> #+begin_quote
>
> The reason for GNU Emacs's existence is to provide a powerful editor for
> the GNU operating system. Versions of GNU, such as GNU/Linux, are the
> primary platforms for Emacs development.
>
> However, GNU Emacs includes support for some other systems that
> volunteers choose to support.
>
> [...]
>
> #+end_quote
>
> I don't know what specific performance problems you have with Emacs
> under Windows, but you can post them on the Emacs-devel mailing list to
> help improve Emacs performance on windows.
>
> However, if you are not tied to windows for work reasons or for a
> specific application, my recommendation is that you migrate to
> GNU/Linux. But I also recommend that you try to avoid falling into the
> clutches of distro hopping, at least to begin with :-). In general, any
> of the popular distributions (Ubuntu, Fedora, etc.) is a good choice.
> Even if you want the latest of the latest software, EndeavourOS is an
> excellent derivative of Arch Linux (much better than Manjaro) with a
> very simple graphical installer. Arch itself also has a graphical
> installer, if you want to install it, but I would start with Endeavour.
> In Linux you also have the possibility of installing light desktop
> environments or window managers, which run well with the specifications
> of your PC. Lxde and Lxqt are good options, they have openbox as a
> window manager, which is robust and highly configurable. But if you
> don't want to complicate your life, xfce is a good option. Or Plasma,
> which despite being very attractive, I remember that it did not consume
> too many resources. And later, if you want to come in the world of
> tiling-style window managers, you have a vast territory to explore. I
> was very comfortable with BSPWM for a long time, until I migrated to
> EXWM (Emacs X Window Manager), which is what I've been using now for a
> few years.
>
> Best regards,
>
> Juan Manuel
[-- Attachment #2: Type: text/html, Size: 3055 bytes --]
^ permalink raw reply [relevance 7%]
* Re: OS advice
@ 2023-01-07 22:22 7% ` Juan Manuel Macías
2023-01-07 22:28 7% ` Ypo
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2023-01-07 22:22 UTC (permalink / raw)
To: Ypo; +Cc: orgmode
Ypo writes:
> Hi
>
> Orgmode is sometimes desperately slow on my PC:
>
> Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz, 3100 Mhz
>
> (RAM) 4,00 GB
>
> I am running Windows 10, everything I use works OK, but Orgmode.
>
> Do you think that if I install a Linux OS, Orgmode would run fast? Any
> OS suggestion?
I've read somewhere that Emacs performance on windows tends to be slow,
but I can't assure you because the last windows I suffered was W98, and
at that time I didn't even use Emacs. According to the official GNU
Emacs website:
#+begin_quote
The reason for GNU Emacs's existence is to provide a powerful editor for
the GNU operating system. Versions of GNU, such as GNU/Linux, are the
primary platforms for Emacs development.
However, GNU Emacs includes support for some other systems that
volunteers choose to support.
[...]
#+end_quote
I don't know what specific performance problems you have with Emacs
under Windows, but you can post them on the Emacs-devel mailing list to
help improve Emacs performance on windows.
However, if you are not tied to windows for work reasons or for a
specific application, my recommendation is that you migrate to
GNU/Linux. But I also recommend that you try to avoid falling into the
clutches of distro hopping, at least to begin with :-). In general, any
of the popular distributions (Ubuntu, Fedora, etc.) is a good choice.
Even if you want the latest of the latest software, EndeavourOS is an
excellent derivative of Arch Linux (much better than Manjaro) with a
very simple graphical installer. Arch itself also has a graphical
installer, if you want to install it, but I would start with Endeavour.
In Linux you also have the possibility of installing light desktop
environments or window managers, which run well with the specifications
of your PC. Lxde and Lxqt are good options, they have openbox as a
window manager, which is robust and highly configurable. But if you
don't want to complicate your life, xfce is a good option. Or Plasma,
which despite being very attractive, I remember that it did not consume
too many resources. And later, if you want to come in the world of
tiling-style window managers, you have a vast territory to explore. I
was very comfortable with BSPWM for a long time, until I migrated to
EXWM (Emacs X Window Manager), which is what I've been using now for a
few years.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 7%]
* Re: Filter for HTML (cite) footnotes?
@ 2023-01-07 17:12 6% ` M. ‘quintus’ Gülker
0 siblings, 0 replies; 200+ results
From: M. ‘quintus’ Gülker @ 2023-01-07 17:12 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Dear all,
I ought to drive this thread to its completion. What I intend to do is
better covered by the new callback functions provided by citeproc-el:
<https://github.com/andras-simonyi/citeproc-el/issues/111>
-quintus
Am Dienstag, dem 08. März 2022 schrieb Juan Manuel Macías:
> M. ‘quintus’ Gülker writes:
>
>> That is, what I am after effectively, is post-processing the results
>> generated by org-cite resp. citeproc.el. I have names in my
>> bibliographic database like “Axel von Hellfeld”, which contain the
>> German name particle “von”. Some (not all) citation customs require
>> “von” to be abbreviated to “v.” so that the cited name becomes
>> “v. Hellfeld”. This is not possible with CSL, so I look for another
>> way to automate this during the export process.
>
> I see. Have you tried using `org-export-filter-final-output-functions'?
> You can try a find/replace function for the footnotes of final
> output. The drawback is that the scope here is broader and
> care should be taken with false positives...
>
> Best regards,
>
> Juan Manuel
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland | kontakt@guelker.eu | O<
^ permalink raw reply [relevance 6%]
* Re: LaTeX tutorial (focused on what Org exports) ??
2023-01-02 18:31 5% ` William Denton
@ 2023-01-03 3:25 0% ` David Masterson
0 siblings, 0 replies; 200+ results
From: David Masterson @ 2023-01-03 3:25 UTC (permalink / raw)
To: William Denton; +Cc: emacs-orgmode
William Denton <wtd@pobox.com> writes:
> On 30 December 2022, Thomas S. Dye wrote:
>
>> Org's latex exporter is exceptionally capable. AFAICT, it doesn't
>> have practical limits on the LaTeX it produces, at least for my
>> academic use case. I'm able to use all of the LaTeX packages I've
>> ever wanted to use.
>
> Me too, and the more I use Org with LaTeX, the more I'm seeing how I
> can use Org as a way to organize a large publishing project: use
> literate programming and export the LaTeX piece by piece, documenting
> what I'm doing; use source blocks to run necessary code to prepare
> images or files before inclusion; and so on.
>
> Using Org (simple markup plus some +latex_header lines) and exporting
> to LaTeX is straightforward enough ... managing a project, with the
> LaTeX as code to be generated, can get a lot more complicated, but on
> the other hand, Org makes that kind of thing simpler. (Of course,
> anything involving LaTeX is bound to get complicated pretty soon.)
>
> I've learned a lot from several regulars on this mailing list,
> including Juan Manuel Macías, who does remarkable work on dictionaries
> and translations. Here's an example:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00348.html
>
> Along with all the other recommendations, it's worth looking at the
> user guide for the memoir class, which is great for books:
>
> https://www.ctan.org/pkg/memoir
>
> It'll be somewhere on your system as memman.pdf. I learned a lot
> about page design and LaTeX from it.
I'll have to make time for this. Thanks.
--
David Masterson
^ permalink raw reply [relevance 0%]
* Re: LaTeX tutorial (focused on what Org exports) ??
@ 2023-01-02 18:31 5% ` William Denton
2023-01-03 3:25 0% ` David Masterson
0 siblings, 1 reply; 200+ results
From: William Denton @ 2023-01-02 18:31 UTC (permalink / raw)
To: David Masterson; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
On 30 December 2022, Thomas S. Dye wrote:
> Org's latex exporter is exceptionally capable. AFAICT, it doesn't have
> practical limits on the LaTeX it produces, at least for my academic use case.
> I'm able to use all of the LaTeX packages I've ever wanted to use.
Me too, and the more I use Org with LaTeX, the more I'm seeing how I can use Org
as a way to organize a large publishing project: use literate programming and
export the LaTeX piece by piece, documenting what I'm doing; use source blocks
to run necessary code to prepare images or files before inclusion; and so on.
Using Org (simple markup plus some +latex_header lines) and exporting to LaTeX
is straightforward enough ... managing a project, with the LaTeX as code to be
generated, can get a lot more complicated, but on the other hand, Org makes that
kind of thing simpler. (Of course, anything involving LaTeX is bound to get
complicated pretty soon.)
I've learned a lot from several regulars on this mailing list, including Juan
Manuel Macías, who does remarkable work on dictionaries and translations.
Here's an example:
https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00348.html
Along with all the other recommendations, it's worth looking at the user guide
for the memoir class, which is great for books:
https://www.ctan.org/pkg/memoir
It'll be somewhere on your system as memman.pdf. I learned a lot about page
design and LaTeX from it.
Cheers,
Bill
--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
^ permalink raw reply [relevance 5%]
* Macro: exporting roman numerals formatted as small-caps
@ 2022-12-08 12:38 5% Carlos Martínez
0 siblings, 0 replies; 200+ results
From: Carlos Martínez @ 2022-12-08 12:38 UTC (permalink / raw)
To: emacs-orgmode
Hello everyone!,
I am working in a paper written in org mode. There are lots of roman
numerals referring to centuries. In Spanish, those are written in
roman numerals and small caps. I want to export my paper both to odt
and to LaTeX.
I found a macro by Juan Manuel Macías which helped me to export the
numerals surrounded by \textsc{} when exporting to pdf, but I struggle
to do the same when exporting to odt. This is the macro:
#+MACRO: sc (eval (if (org-export-derived-backend-p
org-export-current-backend 'latex) (concat "@@latex:\\textsc{@@" $1
"@@latex:}@@") (concat "@@odt:<text:span
text:style-name=\"T1\">@@"$1"@@odt:</text:span>@@")))
I want to achieve something like this: "When exporting to LaTeX (o
derived formats), surround the argument with \textsc{}; if any other
format [it will always be odt], do the same with the proper odt code.
Thanks everyone, and my apologies if this is a noob question (but I am
actually a noob).
Best regards
N.B.: I extracted the odt snippet looking at the contents.xml inside
the odt file.
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex: fix `org-latex-guess-babel-language'
2022-11-17 14:48 10% ` Juan Manuel Macías
@ 2022-11-18 8:31 6% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-11-18 8:31 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Thanks!
>> Could you also add a test to testing/lisp/test-ox-latex.el?
>
> I'm afraid I'm not going to be able to do it in the short term, because
> these days I'm going through a serious family problem, my mother is
> admitted to the hospital, and I don't think I'm going to have time to
> attend to this list.
Sorry to hear this.
I applied your patch as is. It is anyway an improvement.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fcf63fb31
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [PATCH] ox-latex: fix `org-latex-guess-babel-language'
2022-11-15 1:54 6% ` Ihor Radchenko
@ 2022-11-17 14:48 10% ` Juan Manuel Macías
2022-11-18 8:31 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-17 14:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Hi, Ihor, sorry for the late replay,
Ihor Radchenko writes:
>> If the user puts a string other than AUTO as an argument to
>> `\babelprovide', it gives an error when exporting. For example:
>>
>> `#+LaTeX_Header: \babelprovide[<options>]{hebrew}'
>>
>> I am attaching a patch to fix that behaviour.
>
> Thanks!
> Could you also add a test to testing/lisp/test-ox-latex.el?
I'm afraid I'm not going to be able to do it in the short term, because
these days I'm going through a serious family problem, my mother is
admitted to the hospital, and I don't think I'm going to have time to
attend to this list.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-14 22:25 8% ` Juan Manuel Macías
@ 2022-11-15 2:46 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-11-15 2:46 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> Ihor Radchenko writes:
>
>> However, the PDF (see the attached) is erroneous:
>> 1. Title "Temp" is written RTL
>> 2. Year and date (numbers!) are written RTL
>> 3. The python code is written RTL!!
>>
>> Just the equation is rendered LTR as expected and the ordinary Hebrew
>> text is rendered RTL.
>
> I'd say that's expected behavior. Note that if you declare Hebrew as the
> main language, the LaTeX classes (in this case article.cls) will put
> whatever is necessary in Hebrew and use the Hebrew (and RTL) typographic
> rules where necessary, and that includes the title, the date, and the
> various literal strings as the table of contents, figure counters,
> captions, etc.
I agree about year, title, and date. However, not the code. I'd expect
code snippets to use LTR by default. Maybe with an export flag to switch
to RTL.
> To use Hebrew in another context, it would have to be declared as a
> secondary language. The latest versions of Babel allow you to associate
> languages to scripts when it comes to non-Latin alphabets (Cyrillic,
> Greek, Arabic, etc.), and also to associate fonts. In this way it would
> not be necessary to indicate the language explicitly by means of a
> \selectlanguage{} or \foreignlanguage{}{}. For example, suppose that my
> document has Spanish as its main language, but I also add parts in
> Hebrew, which would be automatically recognized by Babel, by putting
> this:
>
> #+LaTeX_Header: \usepackage{fontspec}
> #+LaTeX_Header: \setmainfont{FreeSerif}
> #+LaTeX_Header: \usepackage[AUTO,bidi=basic]{babel}
> #+LaTeX_Header: \babelprovide[onchar=ids,import]{hebrew}
> #+language: es
Should we allow #+language to have multiple values like
#+language: es en ru uk
with first value defining primary language and the rest being secondary?
Also, what does bidi=basic do?
Finally, may it be useful to provide a syntax (affiliated keyword) that
will set a language for specific paragraph?
> Perhaps a FONTS item could be added in "LaTeX specific export settings"?
Do we have #+FONTS setting? I'd say that it is worth adding.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [PATCH] ox-latex: fix `org-latex-guess-babel-language'
2022-11-14 22:46 9% [PATCH] ox-latex: fix `org-latex-guess-babel-language' Juan Manuel Macías
@ 2022-11-15 1:54 6% ` Ihor Radchenko
2022-11-17 14:48 10% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-15 1:54 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> If the user puts a string other than AUTO as an argument to
> `\babelprovide', it gives an error when exporting. For example:
>
> `#+LaTeX_Header: \babelprovide[<options>]{hebrew}'
>
> I am attaching a patch to fix that behaviour.
Thanks!
Could you also add a test to testing/lisp/test-ox-latex.el?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 6%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-13 13:27 4% ` Juan Manuel Macías
@ 2022-11-14 2:38 5% ` Ihor Radchenko
2022-11-14 22:25 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-14 2:38 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> ! Package polyglossia Error: The current latin font does not contain the "Hebr
>> ew" script!
>> (polyglossia) Please define \hebrewfont with \newfontfamily comm
>> and.
>
> hmm, yes, I forgot to mention it before... It is necessary to load a
> font that has support for Hebrew script, via fontspec package, otherwise
> it will return an error, both with Polyglossia and with Babel. It should
> be added:
>
> \usepackage{fontspec}
> \setmainfont{FreeSerif}
Ok. Now, I am at least able to get the pdf. Hooray! :)
#+title: Temp
#+LATEX_COMPILER: lualatex
#+LANGUAGE: he
#+LaTeX_Header: \usepackage[AUTO]{polyglossia}
#+LaTeX_Header: \setmainfont{FreeSerif}
\begin{equation}
f(x) = \frac{8}{7}
\end{equation}
#+begin_src python :exports code
for i in range(3):
print("hello")
#+end_src
However, the PDF (see the attached) is erroneous:
1. Title "Temp" is written RTL
2. Year and date (numbers!) are written RTL
3. The python code is written RTL!!
Just the equation is rendered LTR as expected and the ordinary Hebrew
text is rendered RTL.
[-- Attachment #2: bug.pdf --]
[-- Type: application/pdf, Size: 26980 bytes --]
[-- Attachment #3: Type: text/plain, Size: 1266 bytes --]
> The use of the fontspec package (https://www.ctan.org/pkg/fontspec) is
> ubiquitous in LuaTeX or XeTeX as long as one wants to have control
> over fonts and use extended languages and characters. LuaTeX and XeTeX
> use by default (for debatable historical reasons[1]) a Unicode variant
> of the Computern Modern font, which has limited language coverage. I
> remember that it was commented in a previous thread the possibility of
> offering (for example, through a series of variables), a minimum
> coverage of fonts to ensure that the documents, at least, are compiled
> well and are readable. The user could redefine those variables to use
> their preferred fonts. Or have the option that this part of the
> preamble is not created, to have full control. I remember that I
> proposed this, but there were other interesting proposals. For
> example, Timothy commented on the possibility of using fontsets.
I hope that it can be implemented some day.
For now, we should detail important things, like setting suitable font,
in the manual.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-14 2:38 5% ` Ihor Radchenko
@ 2022-11-14 22:25 8% ` Juan Manuel Macías
2022-11-15 2:46 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-14 22:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Ihor Radchenko writes:
> However, the PDF (see the attached) is erroneous:
> 1. Title "Temp" is written RTL
> 2. Year and date (numbers!) are written RTL
> 3. The python code is written RTL!!
>
> Just the equation is rendered LTR as expected and the ordinary Hebrew
> text is rendered RTL.
I'd say that's expected behavior. Note that if you declare Hebrew as the
main language, the LaTeX classes (in this case article.cls) will put
whatever is necessary in Hebrew and use the Hebrew (and RTL) typographic
rules where necessary, and that includes the title, the date, and the
various literal strings as the table of contents, figure counters,
captions, etc.
To use Hebrew in another context, it would have to be declared as a
secondary language. The latest versions of Babel allow you to associate
languages to scripts when it comes to non-Latin alphabets (Cyrillic,
Greek, Arabic, etc.), and also to associate fonts. In this way it would
not be necessary to indicate the language explicitly by means of a
\selectlanguage{} or \foreignlanguage{}{}. For example, suppose that my
document has Spanish as its main language, but I also add parts in
Hebrew, which would be automatically recognized by Babel, by putting
this:
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \setmainfont{FreeSerif}
#+LaTeX_Header: \usepackage[AUTO,bidi=basic]{babel}
#+LaTeX_Header: \babelprovide[onchar=ids,import]{hebrew}
#+language: es
(...And curiously I just realized with this example that it is necessary
to fix `org-latex-guess-babel-language', because in the current state it
returns an error if a string other than AUTO is put as argument of
babelprovide. I'll open another thread to submit a patch to fix that).
>> The use of the fontspec package (https://www.ctan.org/pkg/fontspec) is
>> ubiquitous in LuaTeX or XeTeX as long as one wants to have control
>> over fonts and use extended languages and characters. LuaTeX and XeTeX
>> use by default (for debatable historical reasons[1]) a Unicode variant
>> of the Computern Modern font, which has limited language coverage. I
>> remember that it was commented in a previous thread the possibility of
>> offering (for example, through a series of variables), a minimum
>> coverage of fonts to ensure that the documents, at least, are compiled
>> well and are readable. The user could redefine those variables to use
>> their preferred fonts. Or have the option that this part of the
>> preamble is not created, to have full control. I remember that I
>> proposed this, but there were other interesting proposals. For
>> example, Timothy commented on the possibility of using fontsets.
>
> I hope that it can be implemented some day.
> For now, we should detail important things, like setting suitable font,
> in the manual.
Perhaps a FONTS item could be added in "LaTeX specific export settings"?
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* [PATCH] ox-latex: fix `org-latex-guess-babel-language'
@ 2022-11-14 22:46 9% Juan Manuel Macías
2022-11-15 1:54 6% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-14 22:46 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
If the user puts a string other than AUTO as an argument to
`\babelprovide', it gives an error when exporting. For example:
`#+LaTeX_Header: \babelprovide[<options>]{hebrew}'
I am attaching a patch to fix that behaviour.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-fix-org-latex-guess-babel-language.patch --]
[-- Type: text/x-patch, Size: 1450 bytes --]
From 6dcba41f58b355296c3cacf97be9508581e1a10a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 14 Nov 2022 23:33:16 +0100
Subject: [PATCH] lisp/ox-latex.el: fix `org-latex-guess-babel-language'
* (org-latex-guess-babel-language): If the user puts a string other
than AUTO as an argument to `\babelprovide', it gives an error when
exporting. For example:
`#+LaTeX_Header: \babelprovide[onchar=ids,import]{hebrew}'
---
lisp/ox-latex.el | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 9bdb9fb63..095f6b51c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1669,12 +1669,13 @@ Return the new header."
(if (not (string-match "\\\\babelprovide\\[.*\\]{\\(.+\\)}" header))
header
(let ((prov (match-string 1 header)))
- (when (equal "AUTO" prov)
- (replace-regexp-in-string (format
- "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
- (format "\\1\\2%s}"
- (or language language-ini-only))
- header t))))))
+ (if (equal "AUTO" prov)
+ (replace-regexp-in-string (format
+ "\\(\\\\babelprovide\\[.*\\]\\)\\({\\)%s}" prov)
+ (format "\\1\\2%s}"
+ (or language language-ini-only))
+ header t)
+ header)))))
(defun org-latex-guess-polyglossia-language (header info)
"Set the Polyglossia language according to the LANGUAGE keyword.
--
2.38.1
^ permalink raw reply related [relevance 9%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-13 4:09 3% ` Ihor Radchenko
@ 2022-11-13 13:27 4% ` Juan Manuel Macías
2022-11-14 2:38 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-13 13:27 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Ihor Radchenko writes:
> On Gentoo, the required package is dev-texlive/texlive-langarabic.
>
> However, installing the package is not yet enough!
>
> With the same file, I am getting missing font errors:
>
> Setting \if@calendar@hebrew
> (/usr/share/texmf-dist/tex/latex/polyglossia/babel-hebrewalph.def)) (./bug.aux
>
> ! Package polyglossia Error: The current latin font does not contain the "Hebr
> ew" script!
> (polyglossia) Please define \hebrewfont with \newfontfamily comm
> and.
hmm, yes, I forgot to mention it before... It is necessary to load a
font that has support for Hebrew script, via fontspec package, otherwise
it will return an error, both with Polyglossia and with Babel. It should
be added:
\usepackage{fontspec}
\setmainfont{FreeSerif}
FreeSerif would work, if we do the test with otfinfo:
┌────
│ otfinfo -s /path/to/FreeSerif.ttf
│
│ DFLT Default
│ arab Arabic
│ beng Bengali
│ bng2 Bengali v.2
│ copt Coptic
│ cyrl Cyrillic
│ dev2 Devanagari v.2
│ glag Glagolitic
│ goth Gothic
│ grek Greek
│ hano Hanunoo
│ hebr Hebrew
│ latn Latin
│ latn.NLD Latin/Dutch
│ latn.TRK Latin/Turkish
│ mlym Malayalam
│ taml Tamil
│ thai Thai
└────
The use of the fontspec package (https://www.ctan.org/pkg/fontspec) is
ubiquitous in LuaTeX or XeTeX as long as one wants to have control
over fonts and use extended languages and characters. LuaTeX and XeTeX
use by default (for debatable historical reasons[1]) a Unicode variant
of the Computern Modern font, which has limited language coverage. I
remember that it was commented in a previous thread the possibility of
offering (for example, through a series of variables), a minimum
coverage of fonts to ensure that the documents, at least, are compiled
well and are readable. The user could redefine those variables to use
their preferred fonts. Or have the option that this part of the
preamble is not created, to have full control. I remember that I
proposed this, but there were other interesting proposals. For
example, Timothy commented on the possibility of using fontsets.
In LuaTeX you can define fallback fonts at a low level, using
luaotfload, for example:
┌────
│ \directlua
│ {luaotfload.add_fallback
│ ("myfallback",
│ {
│ "freeserif:mode=harf;script=grek",
│ "freeserif:mode=harf;script=cyrl",
│ "freeserif:mode=harf;script=arab",
│ "freeserif:mode=harf;script=hebr",
│ }
│ )
│ }
│
│ \setmainfont{latinmodernroman}[RawFeature={fallback=myfallback}]
└────
In the example above, it is defined Free Serif as fallback font for
Cyrillic, Greek, Arabic and Hebrew scripts. And HarfBuzz is used as
the OpenType rendering engine. As an example, it is valid, although it
is still a typographical aberration, since Free Serif and Latin Modern
are incompatible by design. But that is already an aesthetic issue :-)
I think that doing something similar in Org would be a bit complicated,
since it would be necessary to guess what languages and scripts are used
in each document. But a number of basic variables like
’defaultromanfont’, ’defaultmonofont’, etc. could be enough. But leaving
the possibility for the user with advanced knowledge of LuaTeX or XeTeX
to have full control, since the configuration of fonts and languages can
become very complex and extensive in multilingual documents.
[1] My admiration for Donald Knuth is limitless, but in the case of the
Computern Modern font I think Knuth (IMHO) was not inspired. It is a
font with many design flaws, difficult to read on the screen. I
understand that it is hard to get rid of such a TeX hallmark as
Computern Modern, but it would be necessary, especially now that TeX
can use truetype and opentype fonts and metafont has been obsolete. The
CM font is also the reason why many people who have never used LaTeX
think that all LaTeX documents look alike.
^ permalink raw reply [relevance 4%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-11 15:08 8% ` Juan Manuel Macías
@ 2022-11-13 4:09 3% ` Ihor Radchenko
2022-11-13 13:27 4% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-13 4:09 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I start by comment the error that you get when compiling. Is it possible
> that you have an incomplete TeX Live installation? Distro repositories
> usually offer TeX live in a modular way. On Arch Linux and its
> derivatives, the texlive-lang and texlive-lang-extra packages should be
> installed for non-Latin language support (this would include the luabidi
> package). In the Ubuntu/Debian family I think the required package is
> called texlive-lang-arabic. Anyway, I recommend installing TeX live in
> its entirety (the drawback is that it takes up more space). I think that
> in Ubuntu and family the meta-package is called texlive-full. Another
> possibility that I recommend, especially on distros that package older
> versions of TeX live, is to install the official TeX live distribution:
> https://tug.org/texlive/acquire.html (this has the advantage of being
> able to update everything more regularly via TeX live's own package
> manager). If you want to keep the official packages of your distro, but
> also want to try new things, it is also possible to create a portable
> installation of TeX live on a pen drive:
> https://tug.org/texlive/archive/portable-anchor.html
Thanks for the detailed explanation! We may put something similar (or
shorter) into the manual (maybe as a footnote).
On Gentoo, the required package is dev-texlive/texlive-langarabic.
However, installing the package is not yet enough!
With the same file, I am getting missing font errors:
Setting \if@calendar@hebrew
(/usr/share/texmf-dist/tex/latex/polyglossia/babel-hebrewalph.def)) (./bug.aux
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.19 \selectlanguage *{hebrew}
) (/usr/share/texmf-dist/tex/latex/base/ts1cmr.fd)
(/usr/share/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/usr/share/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
(/usr/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
(/usr/share/texmf-dist/tex/latex/hyperref/nameref.sty
(/usr/share/texmf-dist/tex/latex/refcount/refcount.sty)
(/usr/share/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty))
(./bug.out) (./bug.out)
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.25 \begin{document}
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd)
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.28 \tableofcontents
(./bug.toc
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.1 \selectlanguage *{hebrew}
)
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.32 \end{equation}
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.34 \begin{verbatim}
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.34 \begin{verbatim}
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.38 \end{document}
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.38 \end{document}
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./bug.aux
! Package polyglossia Error: The current latin font does not contain the "Hebr
ew" script!
(polyglossia) Please define \hebrewfont with \newfontfamily comm
and.
See the polyglossia package documentation for explanation.
Type H <return> for immediate help.
...
l.19 \selectlanguage *{hebrew}
))
(see the transcript file for additional information)
537 words of node memory still in use:
6 hlist, 2 vlist, 2 rule, 2 glue, 4 kern, 1 glyph, 8 attribute, 61 glue_spec
, 8 attribute_list, 1 write nodes
avail lists: 2:132,3:70,4:3,5:46,6:14,7:406,8:20,9:104,10:2
</usr/share/texmf-dist/fonts/opentype/public/lm/lmmono10-regular.otf></usr/shar
e/texmf-dist/fonts/opentype/public/lm/lmroman10-regular.otf></usr/share/texmf-d
ist/fonts/opentype/public/lm/lmroman12-bold.otf></usr/share/texmf-dist/fonts/op
entype/public/lm/lmroman12-regular.otf></usr/share/texmf-dist/fonts/opentype/pu
blic/lm/lmroman17-regular.otf></usr/share/texmf-dist/fonts/type1/public/amsfont
s/cm/cmmi10.pfb></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
>
Output written on bug.pdf (1 page, 28185 bytes).
Transcript written on bug.log.
Latexmk: Log file says output to 'bug.pdf'
Latexmk: Summary of warnings from last run of *latex:
=====Latex reported missing or unavailable character(s).
=====See log file for details.
Collected error summary (may duplicate other messages):
lualatex: Command for 'lualatex' gave return code 1
Refer to 'bug.log' for details
Latexmk: Examining 'bug.log'
=== TeX engine is 'LuaHBTeX'
Latexmk: Errors, in force_mode: so I tried finishing targets
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 3%]
* Re: Help with a (query) replacement
2022-11-12 16:04 6% ` Juan Manuel Macías
@ 2022-11-12 16:29 12% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-12 16:29 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Juan Manuel Macías writes:
> In the case of PDFs, I would use pdftotext. It converts the PDF to plain
> text and (in theory) removes hyphens from the PDF after conversion. The
> resulting plain text is somewhat ugly (page numbers and other elements
> are preserved), but if you just want to copy/paste text, I think it's
> enough.
And if you don't want to mess with the command line, you can also use
calibre here to convert from PDF to plain text or even Epub (the latter
is better because Epub is a tagged format and then you can have more
control over how to process that, for example by converting it to Org or
Markdown with pandoc). Calibre will do its best to preserve the
structure of the PDF, removing hyphens and other unnecessary elements.
But keep in mind that this process is largely heuristic, and the
conversion is not 100% perfect. However, it works acceptably well.
https://calibre-ebook.com/about
^ permalink raw reply [relevance 12%]
* Re: Help with a (query) replacement
2022-11-12 15:12 7% ` Ypo
@ 2022-11-12 16:04 6% ` Juan Manuel Macías
2022-11-12 16:29 12% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-12 16:04 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Ypo writes:
> Thanks, Juan Manuel.
>
> I normally study using PDF books. Their typography is like
> "hardcoded", so a post-processing using Orgmode is needed, I think.
If it's a PDF then forget what I told you about pandoc, because here
pandoc would have nothing to do. I thought you were referring to files
in epub format, sorry.
In the case of PDFs, I would use pdftotext. It converts the PDF to plain
text and (in theory) removes hyphens from the PDF after conversion. The
resulting plain text is somewhat ugly (page numbers and other elements
are preserved), but if you just want to copy/paste text, I think it's
enough.
The command:
pdftotext my-file.pdf
https://man.archlinux.org/man/pdftotext.1.en
https://en.wikipedia.org/wiki/Pdftotext
^ permalink raw reply [relevance 6%]
* Re: Help with a (query) replacement
2022-11-12 15:23 12% ` Juan Manuel Macías
@ 2022-11-12 15:25 6% ` Ypo
0 siblings, 0 replies; 200+ results
From: Ypo @ 2022-11-12 15:25 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Org-mode
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
ummm, so you copy-paste from nov.el into an org buffer and then format
would be maintained... interesting.
Thanks
El 12/11/2022 a las 16:23, Juan Manuel Macías escribió:
> Juan Manuel Macías writes:
>
>> I think it will be more practical for you to use pandoc:
>>
>> With this command you can convert an epub format to org:
>>
>> pandoc my-epub.epub -o my.epub.org
>>
>> (https://pandoc.org)
>>
>> You can also install calibre and convert your epubs to plain text from
>> there.
> PS: And you can also open epubs in Emacs with the nov.el package
> (https://github.com/wasamasa/nov.el) and copy whatever text you want
> from there.
[-- Attachment #2: Type: text/html, Size: 1380 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Help with a (query) replacement
2022-11-12 15:10 10% ` Juan Manuel Macías
2022-11-12 15:12 7% ` Ypo
@ 2022-11-12 15:23 12% ` Juan Manuel Macías
2022-11-12 15:25 6% ` Ypo
1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-12 15:23 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Juan Manuel Macías writes:
> I think it will be more practical for you to use pandoc:
>
> With this command you can convert an epub format to org:
>
> pandoc my-epub.epub -o my.epub.org
>
> (https://pandoc.org)
>
> You can also install calibre and convert your epubs to plain text from
> there.
PS: And you can also open epubs in Emacs with the nov.el package
(https://github.com/wasamasa/nov.el) and copy whatever text you want
from there.
^ permalink raw reply [relevance 12%]
* Re: Help with a (query) replacement
2022-11-12 15:10 10% ` Juan Manuel Macías
@ 2022-11-12 15:12 7% ` Ypo
2022-11-12 16:04 6% ` Juan Manuel Macías
2022-11-12 15:23 12% ` Juan Manuel Macías
1 sibling, 1 reply; 200+ results
From: Ypo @ 2022-11-12 15:12 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: Org-mode
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
Thanks, Juan Manuel.
I normally study using PDF books. Their typography is like "hardcoded",
so a post-processing using Orgmode is needed, I think.
El 12/11/2022 a las 16:10, Juan Manuel Macías escribió:
> Ypo writes:
>
>> Hi
>>
>> I am copy-pasting e-books into org-mode to read and study them.
>>
>> Usually, words come hyphenated, like "ato- mized", that I wanted to
>> transform into "atomized".
>>
>> I am trying with query replace, but I am starting to think that it is
>> not the correct tool for this job.
>> I tried "query-replace [a-z]-" but I don't know how to exclude the
>> letter before the "-".
>>
>> What would you advise?
> I think it will be more practical for you to use pandoc:
>
> With this command you can convert an epub format to org:
>
> pandoc my-epub.epub -o my.epub.org
>
> (https://pandoc.org)
>
> You can also install calibre and convert your epubs to plain text from
> there.
>
> Best regards,
>
> Juan Manuel
[-- Attachment #2: Type: text/html, Size: 1589 bytes --]
^ permalink raw reply [relevance 7%]
* Re: Help with a (query) replacement
@ 2022-11-12 15:10 10% ` Juan Manuel Macías
2022-11-12 15:12 7% ` Ypo
2022-11-12 15:23 12% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-12 15:10 UTC (permalink / raw)
To: Ypo; +Cc: Org-mode
Ypo writes:
> Hi
>
> I am copy-pasting e-books into org-mode to read and study them.
>
> Usually, words come hyphenated, like "ato- mized", that I wanted to
> transform into "atomized".
>
> I am trying with query replace, but I am starting to think that it is
> not the correct tool for this job.
> I tried "query-replace [a-z]-" but I don't know how to exclude the
> letter before the "-".
>
> What would you advise?
I think it will be more practical for you to use pandoc:
With this command you can convert an epub format to org:
pandoc my-epub.epub -o my.epub.org
(https://pandoc.org)
You can also install calibre and convert your epubs to plain text from
there.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 10%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-11 2:04 4% ` Ihor Radchenko
@ 2022-11-11 15:08 8% ` Juan Manuel Macías
2022-11-13 4:09 3% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-11 15:08 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Hi, Ihor,
I start by comment the error that you get when compiling. Is it possible
that you have an incomplete TeX Live installation? Distro repositories
usually offer TeX live in a modular way. On Arch Linux and its
derivatives, the texlive-lang and texlive-lang-extra packages should be
installed for non-Latin language support (this would include the luabidi
package). In the Ubuntu/Debian family I think the required package is
called texlive-lang-arabic. Anyway, I recommend installing TeX live in
its entirety (the drawback is that it takes up more space). I think that
in Ubuntu and family the meta-package is called texlive-full. Another
possibility that I recommend, especially on distros that package older
versions of TeX live, is to install the official TeX live distribution:
https://tug.org/texlive/acquire.html (this has the advantage of being
able to update everything more regularly via TeX live's own package
manager). If you want to keep the official packages of your distro, but
also want to try new things, it is also possible to create a portable
installation of TeX live on a pen drive:
https://tug.org/texlive/archive/portable-anchor.html
Ihor Radchenko writes:
> Aha! I missed that part in the newer manual.
>
> Note that the manual only talks about setting
> `org-latex-packages-alist'. Not the keyword.
>
> Maybe we can add the #+LATEX_HEADER example to the manual.
There are examples included in 'LaTeX header and sectioning structure'.
Perhaps it would be nice to add some more examples in the case of Bidi
languages, Chinese, Japanese, etc.? In the case of CJK languages, I
think additional LaTeX packages are required.
>> BTW I've noticed that the value of #+language is not case-agnostic. You
>> should put "he". Should it be case-agnostic? In the previous
>> implementation, when there were two language lists for babel and
>> polyglossia, neither was it.
>
> I think that it is a good idea. I do not recall common language
> abbreviations to be case-sensitive in other software.
>
I totally agree: that's something I missed when I made the previous
patch...
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
2022-11-10 12:40 9% ` Juan Manuel Macías
@ 2022-11-11 2:04 4% ` Ihor Radchenko
2022-11-11 15:08 8% ` Juan Manuel Macías
0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2022-11-11 2:04 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: emacs-orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> And exported to pdf (C-c C-e l o).
>> Surprisingly, the output is in English.
>>
>> Am I missing something?
>
> You need to explicitly load babel or polyglossia:
>
> For polyglossia (`org-latex-guess-polyglossia-language'):
>
> #+LaTeX_Header: \usepackage[AUTO]{polyglossia}
Aha! I missed that part in the newer manual.
Note that the manual only talks about setting
`org-latex-packages-alist'. Not the keyword.
Maybe we can add the #+LATEX_HEADER example to the manual.
> BTW I've noticed that the value of #+language is not case-agnostic. You
> should put "he". Should it be case-agnostic? In the previous
> implementation, when there were two language lists for babel and
> polyglossia, neither was it.
I think that it is a good idea. I do not recall common language
abbreviations to be case-sensitive in other software.
---------
Now, let me continue to act like an ordinary user and follow your
suggestion :)
I tried to add the header:
#+title: Temp
#+LATEX_COMPILER: lualatex
#+LANGUAGE: he
#+LaTeX_Header: \usepackage[AUTO]{polyglossia}
\begin{equation}
f(x) = \frac{8}{7}
\end{equation}
#+begin_src python :exports code
for i in range(3):
print("hello")
#+end_src
Then, C-c C-e l o
And I get an error...
Rc files read:
NONE
Latexmk: This is Latexmk, John Collins, 29 September 2020, version: 4.70b.
Rule 'lualatex': File changes, etc:
Changed files, or newly in use since previous run(s):
'bug.tex'
------------
Run number 1 of rule 'lualatex'
------------
------------
Running 'lualatex -interaction=nonstopmode -recorder -output-directory="." "bug.tex"'
------------
Set environment variable BIBINPUTS='.:'
Set environment variable TEXINPUTS='.:'
Latexmk: applying rule 'lualatex'...
This is LuaHBTeX, Version 1.13.0 (TeX Live 2021 Gentoo Linux)
restricted system commands enabled.
(./bug.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-18>
(/usr/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
[clipped]
(/usr/share/texmf-dist/tex/luatex/luatexbase/luatexbase.sty
(/usr/share/texmf-dist/tex/luatex/ctablestack/ctablestack.sty))
(/usr/share/texmf-dist/tex/latex/polyglossia/gloss-latex.ldf))
(/usr/share/texmf-dist/tex/latex/polyglossia/gloss-hebrew.ldf
! LaTeX Error: File `luabidi.sty' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
<read *>
l.3 \RequireBidi
440 words of node memory still in use:
3 hlist, 1 rule, 1 dir, 3 kern, 1 glyph, 4 attribute, 58 glue_spec, 4 attrib
ute_list, 1 if_stack, 1 write nodes
avail lists: 2:13,3:2,4:1,5:2,7:2,9:2
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on bug.log.
Latexmk: Missing input file: 'luabidi.sty' from line
'! LaTeX Error: File `luabidi.sty' not found.'
Failure to make 'bug.pdf'
Collected error summary (may duplicate other messages):
lualatex: Command for 'lualatex' gave return code 1
Refer to 'bug.log' for details
Latexmk: Examining 'bug.log'
=== TeX engine is 'LuaHBTeX'
Latexmk: Errors, in force_mode: so I tried finishing targets
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 4%]
* Re: [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)]
@ 2022-11-10 12:40 9% ` Juan Manuel Macías
2022-11-11 2:04 4% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-10 12:40 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
Ihor Radchenko writes:
> I am trying to look into RTL language exports.
>
> I tried the following simple-minded Org file:
>
> #+title: Temp
> #+LATEX_COMPILER: lualatex
>
> #+LANGUAGE: HE
>
> \begin{equation}
> f(x) = \frac{8}{7}
> \end{equation}
>
> #+begin_src python :exports code
> for i in range(3):
> print("hello")
> #+end_src
>
> And exported to pdf (C-c C-e l o).
> Surprisingly, the output is in English.
>
> Am I missing something?
You need to explicitly load babel or polyglossia:
For polyglossia (`org-latex-guess-polyglossia-language'):
#+LaTeX_Header: \usepackage[AUTO]{polyglossia}
For babel (`org-latex-guess-babel-language'):
#+LaTeX_Header: \usepackage[bidi=basic]{babel}
#+LaTeX_Header: \babelprovide[import, main]{AUTO}
There was a discussion in an old thread about the possibility of loading
babel or polyglossia automatically (I think Maxim was in favor of it,
and brought up some possibilities). The problem is that babel's syntax
is somewhat more complex than polyglossia's, and admits many variants.
Also in babel there are languages that are loaded using the new ini file
system with the command \babelprovide. Currently,
org-latex-guess-babel-language supports babelprovide, but you need to
load the command explicitly:
#+LaTeX_Header: \babelprovide[options]{AUTO}
BTW I've noticed that the value of #+language is not case-agnostic. You
should put "he". Should it be case-agnostic? In the previous
implementation, when there were two language lists for babel and
polyglossia, neither was it.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 9%]
* Re: Can :packages and :headers arguments in latex SRC blocks be made affect EXPORT blocks of results?
@ 2022-11-09 17:30 8% ` Juan Manuel Macías
0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-09 17:30 UTC (permalink / raw)
To: hugo; +Cc: emacs-orgmode
hugo@heagren.com writes:
> Is there a way around this? Either to export the src block another way,
> or to add metadata to the to the resulting EXPORT block (or just text,
> though I'm not sure how that would work for `:packages', since they
> require text to be added to the resulting exported LaTeX file in a
> different place from where the text of the block goes).
If I have understood correctly what you want to do, maybe a solution
would be this. You can starting from a single block that includes
the preamble for both preview and export:
#+NAME: preamble
#+begin_src latex :exports none
\usepackage{tikz}
\usetikzlibrary{calc,positioning,patterns}
#+end_src
This block returns the above as a simple string:
#+NAME: pre
#+begin_src emacs-lisp :exports none :results silent :var x = preamble
(with-temp-buffer
(insert x)
(LaTeX-mode)
(setq preamble-prev (buffer-string)))
#+end_src
And this one adds the necessary LaTeX headers when you export the
document, so LaTeX doesn't crash when compiling.
#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <<preamble>>
#+end_src
And the final block:
#+header: :results (if (org-export-derived-backend-p org-export-current-backend 'latex) "latex" "file raw")
#+header: :file (if (org-export-derived-backend-p org-export-current-backend 'latex) nil "foo.png")
#+header: :imagemagick t :fit t
#+header: :headers `(,(progn (org-babel-ref-resolve "pre") preamble-prev))
#+begin_src latex
\begin{tikzpicture}[on grid,
font=\footnotesize,
level distance=2.5cm,
sibling distance=2.5cm,
every node/.style={circle,draw,fill=white},
touch/.style={circle,draw=red!100,fill=red!40,thick},
invirtueof/.style={circle,draw=red!50,fill=red!20,very thick}]
\node [invirtueof] {Car}
child {node {wheel}}
child {node [invirtueof] {body}
child {node {driver door}}
child {node [invirtueof] {passenger door}
child {node [touch] {region of door}}}};
\end{tikzpicture}
#+end_src
#+RESULTS:
[[file:foo.png]]
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-11-04 5:40 5% ` Max Nikulin
0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-11-04 5:40 UTC (permalink / raw)
To: emacs-orgmode
On 04/11/2022 11:23, Ihor Radchenko wrote:
> Max Nikulin writes:
>>> Ihor Radchenko writes:
>>>
>>>> These arguments mean that auto-cleaning \\[0pt] is not always safe and
>>>> may be a subject of surrounding LaTeX context.
>>
>> I still believe that
>>
>> something\\[0pt]%__ORG_EXPORT__
>>
>> is quite safe to remove (depending on the following character) and
>> unlikely harmful if remained for some reason.
>
> What about the side effect you mentioned in a previous email?
>
>> TeX reads
>>
>> "a% comment
>> b"
>>
>> as "ab", dropping newline and starting spaces.
Unlike in Org, in TeX "a\\b" still contains a line break. Besides exotic
packages and user setups it should just work. After all, during normal
operation all "%__ORG_EXPORT__" should be stripped by a filter. They are
just marks where a decision is necessary whether to retain "[0pt]" or to
remove it.
On 03/11/2022 22:48, Juan Manuel Macías wrote:
> Max Nikulin writes:
>
>> I have not managed to convince even the tabularray developer. And I
>> have not tried to find a way to reach more LaTeX developers.
>
> I think that people from the LaTeX team and the authors of the most
> popular packages are often very active on tex.stackexchange.com
Stackexchange is for questions, not for discussions and bugs. At certain
point I was going to ask a question there, I even prepared a draft.
After that I decided to try a command expanding to nothing and found
\empty. I was not aware that tabularray uses a different approach to
parsing.
> And the repo on GitHub for the LaTeX project: https://github.com/latex3
https://github.com/latex3/latex3/issues may be an appropriate place,
thank you.
^ permalink raw reply [relevance 5%]
* Re: Docstrings and literate programming (good practices?)
2022-11-03 20:54 5% ` Rudolf Adamkovič
@ 2022-11-04 3:03 0% ` Samuel Wales
0 siblings, 0 replies; 200+ results
From: Samuel Wales @ 2022-11-04 3:03 UTC (permalink / raw)
To: Rudolf Adamkovič; +Cc: Juan Manuel Macías, orgmode
i wonder if emacs or org has what you might call semi-literate or
etaretil docstring functions?
for example, you have a body of non-literate elisp code, and you have
a manual. it could be redundant to describe commands and what they do
and their options, if the docstrings are good.
why not include the docstrings of all commands in some nice format in
the .org manual via some mechanism?
would that be a good practice? seems useful abstractly.
On 11/3/22, Rudolf Adamkovič <salutis@me.com> wrote:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
> Hello Juan!
>
>> I can duplicate the text, but it seems to be a bit redundant, right?
>> So what is the best way to proceed when doing literate programming
>> with any language that supports docstrings? Apologies in advance if
>> the question is a bit silly, but I'm not a professional programmer and
>> don't have an academic background in it, so I don't know if there is
>> any good practice on these things :-)
>
> A "bit silly" question? I find your question rather profound. Thank
> you for bringing it up!
>
> Personally, I recommend to use both docstrings and literate programming
> idiomatically, not mixing them.
>
> Literate programming exposes thinking and exploration.
>
> For example, the literate portion can show different approaches you
> tried but abandoned, something that does not belong to the function
> itself, nor in its docstring. Or, it can include examples, piece-wise
> performance analysis, computer science background, mathematical model,
> citations of prior work, and so on. Add some assertions and you will
> have literate tests as well.
>
> A docstring describes the function from the outside, as a black box, and
> if you did a good job with it, it makes it simpler for the consumer to
> use your function.
>
> Literate programming, on the other hand, goes deeper. It describes the
> thinking that went into the function, comfortably exposing its insides
> and opening the black box of its abstraction.
>
> Rudy
> --
> "Strange as it may sound, the power of mathematics rests on its evasion
> of all unnecessary thought and on its wonderful saving of mental
> operations."
> -- Ernst Mach, 1838-1916
>
> Rudolf Adamkovič <salutis@me.com> [he/him]
> Studenohorská 25
> 84103 Bratislava
> Slovakia
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [relevance 0%]
* Re: Docstrings and literate programming (good practices?)
@ 2022-11-03 20:54 5% ` Rudolf Adamkovič
2022-11-04 3:03 0% ` Samuel Wales
1 sibling, 1 reply; 200+ results
From: Rudolf Adamkovič @ 2022-11-03 20:54 UTC (permalink / raw)
To: Juan Manuel Macías, orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
Hello Juan!
> I can duplicate the text, but it seems to be a bit redundant, right?
> So what is the best way to proceed when doing literate programming
> with any language that supports docstrings? Apologies in advance if
> the question is a bit silly, but I'm not a professional programmer and
> don't have an academic background in it, so I don't know if there is
> any good practice on these things :-)
A "bit silly" question? I find your question rather profound. Thank
you for bringing it up!
Personally, I recommend to use both docstrings and literate programming
idiomatically, not mixing them.
Literate programming exposes thinking and exploration.
For example, the literate portion can show different approaches you
tried but abandoned, something that does not belong to the function
itself, nor in its docstring. Or, it can include examples, piece-wise
performance analysis, computer science background, mathematical model,
citations of prior work, and so on. Add some assertions and you will
have literate tests as well.
A docstring describes the function from the outside, as a black box, and
if you did a good job with it, it makes it simpler for the consumer to
use your function.
Literate programming, on the other hand, goes deeper. It describes the
thinking that went into the function, comfortably exposing its insides
and opening the black box of its abstraction.
Rudy
--
"Strange as it may sound, the power of mathematics rests on its evasion
of all unnecessary thought and on its wonderful saving of mental
operations."
-- Ernst Mach, 1838-1916
Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
^ permalink raw reply [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
2022-11-03 15:33 5% ` Max Nikulin
@ 2022-11-03 15:48 6% ` Juan Manuel Macías
1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-11-03 15:48 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
Max Nikulin writes:
> I have not managed to convince even the tabularray developer. And I
> have not tried to find a way to reach more LaTeX developers.
I think that people from the LaTeX team and the authors of the most
popular packages are often very active on tex.stackexchange.com
And the repo on GitHub for the LaTeX project: https://github.com/latex3
^ permalink raw reply [relevance 6%]
* Re: Line breaks and brackets in LaTeX export
2022-11-03 15:00 8% ` Juan Manuel Macías
@ 2022-11-03 15:33 5% ` Max Nikulin
2022-11-03 15:48 6% ` Juan Manuel Macías
0 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2022-11-03 15:33 UTC (permalink / raw)
To: emacs-orgmode
> Ihor Radchenko writes:
>
>> These arguments mean that auto-cleaning \\[0pt] is not always safe and
>> may be a subject of surrounding LaTeX context.
I still believe that
something\\[0pt]%__ORG_EXPORT__
is quite safe to remove (depending on the following character) and
unlikely harmful if remained for some reason. Even tabularray
regexp-based parser ignores comments. To be perfect,
"\\[0pt]%__ORG_EXPORT__" emitted by user code should be escaped to e.g.
"\\[0pd]%__ORG_EXPORT____ORG_EXPORT__", but I have no idea if it can be
implemented in a reliable way.
An alternative is a new export framework.
On 03/11/2022 22:00, Juan Manuel Macías wrote:
>
> BTW, I also hope that one day this LaTeX problem, which has been there
> for so many years, will be solved (because it should be considered a
> LaTeX bug, or a LaTeX design flaw, as Maxim commented in another
> message).
I have not managed to convince even the tabularray developer. And I have
not tried to find a way to reach more LaTeX developers.
^ permalink raw reply [relevance 5%]
* Re: Line breaks and brackets in LaTeX export
@ 2022-11-03 15:00 8% ` Juan Manuel Macías
2022-11-03 15:33 5% ` Max Nikulin
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-03 15:00 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode
Ihor Radchenko writes:
> These arguments mean that auto-cleaning \\[0pt] is not always safe and
> may be a subject of surrounding LaTeX context. Moreover, there is no
> clear alternative to \\[0pt] that is guaranteed to work.
> Thus, the whole idea with cleaning up the generated LaTeX cannot be
> enabled by default, and I am not even sure if it is something we want to
> implement in the core.
>
> Juan, maybe you have some good alternative suggestions?
I'm afraid not. I've been trying to follow the thread these past few
days and frankly I can't think of anything beyond all the options that
have already been discussed.
I agree that the safest solution (or the least compromised, depending on
how we look at it) is to add [0pt] in all cases. I believe this should
not bring any unexpected consequences. At least I've tried all the
tabular environments related packages that I know of and there don't
seem to be any problems. And in the case of the verse package and verse
numberings, the solution is ad hoc with the patch that I have planned (I
hope to find a gap these days to finish it and test it...): The idea of
the patch is to replace the current separation between stanzas that Org
adds (\vspace) with a white line, and (only) in that case it would be
necessary to ensure that the last verse of the stanza ends in \\!.
On the other hand, if 'factory-cleaning' unnecessary instances of [0pt]
is going to be problematic, I also agree not to add that action to the
exporter. I think it would be better to leave these things up to the
users, depending on their use cases. After all, it is not difficult to
do it using a specific export filter. Maybe add some tips and examples
of basic filters in the documentation, especially for users who don't
have a lot of experience writing filters?
BTW, I also hope that one day this LaTeX problem, which has been there
for so many years, will be solved (because it should be considered a
LaTeX bug, or a LaTeX design flaw, as Maxim commented in another
message).
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
* Re: Docstrings and literate programming (good practices?)
2022-11-02 15:20 8% ` Juan Manuel Macías
@ 2022-11-03 7:38 5% ` Ihor Radchenko
0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2022-11-03 7:38 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Can you elaborate about "paragraph is exported as verbatim"?
>
> Sorry for the conciseness in my previous explanation. I meant something
> like this:
>
> : foo
>
> is exported to LaTeX as
>
> \begin{verbatim}
> foo
> \end{verbatim}
>
> (and what i want is for it to be exported as 'normal text').
You can just
#+name: foo
foo
that will be exported with all the markup.
> By the way, thinking about it, I don't know if a hypothetical header arg
> called :docstring would be ok, something like:
>
> #+NAME: foo
> #+begin_<SPECIAL BLOCK NAME>
> blah
> #+end_<SPECIAL BLOCK NAME>
>
> #+begin_src emacs-lisp :docstring foo
> (defun foo ()
> (message "hello world"))
> #+end_src
>
> And the docstring would be formatted and placed depending on the
> language and the code (https://en.wikipedia.org/wiki/Docstring).
That's asking for too much. Supporting :docstring header argument in
such form will require babel backends to parse the code, which may not
be trivial. Or consider odd cases with polymorphic functions with the
same name.
However, note one past feature request about escaping text in noweb
references:
https://orgmode.org/list/82897e7d-f987-11f4-f7f5-fa1b8e462c0c@posteo.eu
Sébastien Miquel <sebastien.miquel@posteo.eu> (2021-05-03) (2021 emacs-orgmode.gnu.org maillist nolist)
Subject: [Feature request] String escaped noweb expansion
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [relevance 5%]
* Re: Docstrings and literate programming (good practices?)
@ 2022-11-02 15:20 8% ` Juan Manuel Macías
2022-11-03 7:38 5% ` Ihor Radchenko
0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2022-11-02 15:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Can you elaborate about "paragraph is exported as verbatim"?
Sorry for the conciseness in my previous explanation. I meant something
like this:
: foo
is exported to LaTeX as
\begin{verbatim}
foo
\end{verbatim}
(and what i want is for it to be exported as 'normal text').
>> Actually I don't know if it's good practice to do it like this, hence my
>> doubts about how to 'marry' the literate programming concept with
>> languages that support docstring, which, somehow, are largely
>> self-documenting (thanks to the existence of the docstring itself) . The
>> scenario would rather be in long, multi-paragraph docstrings. Then this
>> dilemma comes to me: if I am doing literate programming and I want to
>> explain in detail what the function x does, I write it in the main text
>> as part of the documentation. But also that explanation should be a
>> docstring, in the source file. I understand that the docstring would not
>> appear in the PDF (to avoid redundancy), but I don't know if it would be
>> a good practice either, since the docstring belongs to the code...
>>
>> In short, my dilemma is: how to do good literate programming with a
>> language like Elisp, which is almost self-documenting in its code? (So
>> one can learn a lot about Elisp just by reading the code in the *.el
>> files, without going to the documentation (which is a great strength of
>> Elisp, by the way).
>
> I'd do something like the following:
> 1. Use normal Org text for docstring marked with some kind of block
> container (#+begin_docstring..#+end_docstring) or a dedicated
> headline.
> 2. Extend Org with some fancy links specific to docstring. That way, the
> original document can be read with active links to, say, other
> functions and variables. (I think Doom is using something like this
> for its new docs. Timothy is working on this)
> 3. Those links will be transformed to online documentation links on
> normal export.
> 4. For docstrings, on tangle, the links will be processed via
> `org-export-string-as' with a specialized backend that can escape
> what is needed for the target language docstring and transform Org
> links into whatever the docstring format is used for internal
> docstring references.
> 5. For docstrings, on export, the noweb will generate something like
> "[docstring is detailed in the text]", maybe even with a hyperlink to
> the docstring in text.
>
> Hope it makes sense.
I like the idea, because of the possibility of being able to use links.
That would also be respectful of the docstring as a legitimate part of
the code (in my approach, removing the docstring during export leaves an
empty line in the code, which is weird). Anyway, I think that with my
approach using org blocks and noweb references, links can also be used,
although more at a user/home-made level, with some export filter, I
suppose, that would convert the noweb reference into a normal link.
By the way, thinking about it, I don't know if a hypothetical header arg
called :docstring would be ok, something like:
#+NAME: foo
#+begin_<SPECIAL BLOCK NAME>
blah
#+end_<SPECIAL BLOCK NAME>
#+begin_src emacs-lisp :docstring foo
(defun foo ()
(message "hello world"))
#+end_src
And the docstring would be formatted and placed depending on the
language and the code (https://en.wikipedia.org/wiki/Docstring).
I don't know if something like this would make sense; although, thinking
about it, I like your idea of using special links better because it is
more versatile and (I guess) simpler to implement.
Best regards,
Juan Manuel
^ permalink raw reply [relevance 8%]
Results 201-400 of ~1600 next (older) | prev (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-01-29 16:03 org-attach-git don't automatically commit changes Juan Manuel Macías
2021-01-30 5:10 ` Ihor Radchenko
2021-01-30 13:38 ` Juan Manuel Macías
2021-01-31 3:33 ` Ihor Radchenko
2021-01-31 10:29 ` Juan Manuel Macías
2021-01-31 10:52 ` Ihor Radchenko
2021-01-31 13:16 ` Juan Manuel Macías
2021-01-31 13:40 ` Ihor Radchenko
2021-01-31 14:36 ` Juan Manuel Macías
2024-01-10 16:05 6% ` Ihor Radchenko
2022-02-18 0:47 Pandoc and nested emhases Juan Manuel Macías
2023-10-11 16:11 6% ` Max Nikulin
2023-10-22 19:15 10% ` Juan Manuel Macías
2022-03-05 15:40 Filter for HTML footnotes? M. ‘quintus’ Gülker
2022-03-06 4:03 ` Juan Manuel Macías
2022-03-08 7:40 ` Filter for HTML (cite) footnotes? M. ‘quintus’ Gülker
2022-03-08 10:14 ` Juan Manuel Macías
2023-01-07 17:12 6% ` M. ‘quintus’ Gülker
2022-10-15 21:35 [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX Juan Manuel Macías
2022-10-16 15:04 ` Max Nikulin
2022-10-16 17:14 ` Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17 9:04 ` Ihor Radchenko
2022-10-17 11:30 ` Line breaks and brackets in LaTeX export Juan Manuel Macías
2022-10-17 15:01 ` Juan Manuel Macías
2022-10-17 16:46 ` Max Nikulin
2022-10-18 4:39 ` Ihor Radchenko
2022-10-19 17:12 ` Max Nikulin
2022-10-20 5:07 ` Ihor Radchenko
2022-10-20 17:15 ` Max Nikulin
2022-10-21 3:41 ` Ihor Radchenko
2022-10-21 16:32 ` Max Nikulin
2022-10-22 5:15 ` Ihor Radchenko
2022-10-22 15:55 ` Max Nikulin
2022-11-01 1:51 ` Ihor Radchenko
2022-11-01 16:07 ` Max Nikulin
2022-11-02 6:44 ` Ihor Radchenko
2022-11-02 6:46 ` Ihor Radchenko
2022-11-02 15:27 ` Max Nikulin
2022-11-03 6:15 ` Ihor Radchenko
2022-11-03 15:00 8% ` Juan Manuel Macías
2022-11-03 15:33 5% ` Max Nikulin
2022-11-03 15:48 6% ` Juan Manuel Macías
2022-11-04 4:23 ` Ihor Radchenko
2022-11-04 5:40 5% ` Max Nikulin
2022-11-01 14:07 Docstrings and literate programming (good practices?) Juan Manuel Macías
2022-11-02 7:13 ` Ihor Radchenko
2022-11-02 12:49 ` Juan Manuel Macías
2022-11-02 13:05 ` Ihor Radchenko
2022-11-02 15:20 8% ` Juan Manuel Macías
2022-11-03 7:38 5% ` Ihor Radchenko
2022-11-03 20:54 5% ` Rudolf Adamkovič
2022-11-04 3:03 0% ` Samuel Wales
2022-11-08 23:04 Can :packages and :headers arguments in latex SRC blocks be made affect EXPORT blocks of results? hugo
2022-11-09 17:30 8% ` Juan Manuel Macías
2022-11-10 6:11 [BUG] LaTeX export in non-English language [9.6-pre (release_9.5.5-1087-g620a96.dirty @ /home/yantar92/.emacs.d/straight/build/org/)] Ihor Radchenko
2022-11-10 12:40 9% ` Juan Manuel Macías
2022-11-11 2:04 4% ` Ihor Radchenko
2022-11-11 15:08 8% ` Juan Manuel Macías
2022-11-13 4:09 3% ` Ihor Radchenko
2022-11-13 13:27 4% ` Juan Manuel Macías
2022-11-14 2:38 5% ` Ihor Radchenko
2022-11-14 22:25 8% ` Juan Manuel Macías
2022-11-15 2:46 5% ` Ihor Radchenko
2022-11-12 14:42 Help with a (query) replacement Ypo
2022-11-12 15:10 10% ` Juan Manuel Macías
2022-11-12 15:12 7% ` Ypo
2022-11-12 16:04 6% ` Juan Manuel Macías
2022-11-12 16:29 12% ` Juan Manuel Macías
2022-11-12 15:23 12% ` Juan Manuel Macías
2022-11-12 15:25 6% ` Ypo
2022-11-14 22:46 9% [PATCH] ox-latex: fix `org-latex-guess-babel-language' Juan Manuel Macías
2022-11-15 1:54 6% ` Ihor Radchenko
2022-11-17 14:48 10% ` Juan Manuel Macías
2022-11-18 8:31 6% ` Ihor Radchenko
2022-12-08 12:38 5% Macro: exporting roman numerals formatted as small-caps Carlos Martínez
2022-12-30 21:29 LaTeX tutorial (focused on what Org exports) ?? David Masterson
2022-12-31 1:18 ` Thomas S. Dye
2023-01-02 18:31 5% ` William Denton
2023-01-03 3:25 0% ` David Masterson
2023-01-06 19:46 OS advice Ypo
2023-01-07 22:22 7% ` Juan Manuel Macías
2023-01-07 22:28 7% ` Ypo
2023-02-18 10:18 [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated Ihor Radchenko
2023-03-05 11:12 5% ` Max Nikulin
2023-03-06 15:42 how to add special glyphs Rob Sargent
2023-03-07 15:54 6% ` Max Nikulin
2023-03-08 0:29 0% ` Rob Sargent
2023-03-21 3:36 org-ctags land grab Nick Dokos
2023-08-08 8:48 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Ihor Radchenko
2023-08-08 13:29 ` Bastien Guerry
2023-08-11 9:44 ` Ihor Radchenko
2023-08-12 12:46 ` Bastien Guerry
2023-08-12 22:18 ` Samuel Wales
2023-08-14 13:19 ` Fraga, Eric
2023-08-22 15:15 ` Bastien Guerry
2023-08-23 9:33 ` Ihor Radchenko
2023-08-24 11:39 ` Bastien Guerry
2023-08-24 11:44 ` Ihor Radchenko
2023-08-24 12:08 ` Bastien Guerry
2023-08-24 12:15 ` Ihor Radchenko
2023-08-24 12:36 ` Bastien Guerry
2023-08-24 12:40 ` Ihor Radchenko
2023-08-24 12:48 ` Bastien Guerry
2023-08-24 12:56 ` Ihor Radchenko
2023-08-24 13:02 ` Bastien Guerry
2023-08-24 13:36 ` Ihor Radchenko
2023-08-24 14:08 ` Bastien Guerry
2023-08-25 9:44 ` [DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?) Ihor Radchenko
2023-08-25 17:58 9% ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
2023-08-26 10:58 6% ` Ihor Radchenko
2023-08-26 11:42 10% ` Juan Manuel Macías
2023-08-26 12:33 5% ` Ihor Radchenko
2023-08-26 14:21 9% ` Juan Manuel Macías
2023-08-26 16:33 6% ` Ihor Radchenko
2023-08-26 17:31 11% ` Juan Manuel Macías
2023-08-26 17:43 5% ` Ihor Radchenko
2023-08-26 19:19 10% ` Juan Manuel Macías
2023-08-27 9:21 5% ` Ihor Radchenko
2023-08-27 17:25 10% ` Juan Manuel Macías
2023-08-31 9:15 5% ` Ihor Radchenko
2023-08-26 18:01 6% ` Russell Adams
2023-06-20 4:42 How to tell `org-html-link' to create a link with some HTML class? Marcin Borkowski
2023-06-20 16:30 5% ` Max Nikulin
2023-08-04 7:25 12% [patch] Fix inner smart quotes in French Juan Manuel Macías
2023-08-04 11:09 6% ` Bastien
2023-08-10 14:10 0% ` Max Nikulin
2023-08-10 14:49 0% ` Bastien
2023-08-10 21:50 10% ` Juan Manuel Macías
2023-08-13 9:20 6% ` Bastien Guerry
2023-08-05 7:08 6% ` Ihor Radchenko
2023-08-05 10:51 12% ` Juan Manuel Macías
2023-08-05 13:19 6% ` Ihor Radchenko
2023-08-06 12:03 8% [patch] ox-latex.el: fix blank lines behavior in verse block Juan Manuel Macías
2023-08-07 11:40 6% ` Ihor Radchenko
2023-08-07 17:23 9% ` Juan Manuel Macías
2023-08-09 7:57 6% ` Ihor Radchenko
2023-08-09 8:41 12% ` Juan Manuel Macías
2023-08-10 9:27 5% ` Ihor Radchenko
2023-08-10 10:39 10% ` Juan Manuel Macías
2023-08-11 10:00 6% ` Ihor Radchenko
2023-08-11 18:52 8% ` Juan Manuel Macías
2023-08-12 7:56 5% ` Ihor Radchenko
2023-08-12 11:28 10% ` Juan Manuel Macías
2023-08-13 8:06 6% ` Ihor Radchenko
2023-08-14 20:10 7% ` Juan Manuel Macías
2023-08-15 10:08 6% ` Ihor Radchenko
2023-08-15 11:50 10% ` Juan Manuel Macías
2023-08-15 11:53 6% ` Ihor Radchenko
2023-08-15 14:25 11% ` Juan Manuel Macías
2023-08-16 8:10 6% ` Ihor Radchenko
2023-08-16 14:10 7% ` Juan Manuel Macías
2023-08-17 10:35 6% ` Ihor Radchenko
2023-08-17 20:17 7% ` Juan Manuel Macías
2023-08-18 8:44 6% ` Ihor Radchenko
2023-08-18 18:27 10% [Tip] Popup-menu with several actions for a link Juan Manuel Macías
2023-08-19 19:53 6% ` Ihor Radchenko
2023-08-19 20:29 11% ` Juan Manuel Macías
2023-08-20 7:23 6% ` Ihor Radchenko
2023-08-20 10:13 10% ` Juan Manuel Macías
2023-08-30 8:25 10% Fallback fonts in LaTeX export for non latin scripts Juan Manuel Macías
2023-08-31 8:17 5% ` Ihor Radchenko
2023-08-31 11:42 7% ` Juan Manuel Macías
2023-09-01 9:18 5% ` Ihor Radchenko
2023-09-02 21:39 4% ` Juan Manuel Macías
2023-09-03 7:22 5% ` Ihor Radchenko
2023-09-03 11:05 6% ` Juan Manuel Macías
2023-09-04 8:09 4% ` Ihor Radchenko
2023-09-04 22:22 7% ` Juan Manuel Macías
2023-09-05 10:44 5% ` Ihor Radchenko
2023-09-20 14:03 5% ` Juan Manuel Macías
2023-09-21 9:00 4% ` Ihor Radchenko
2023-09-24 18:24 12% ` Juan Manuel Macías
2023-09-26 10:37 5% ` Ihor Radchenko
2023-09-05 16:42 6% ` Max Nikulin
2023-09-05 18:33 12% ` Juan Manuel Macías
2023-09-06 9:29 6% ` Ihor Radchenko
2023-09-06 14:58 8% ` Juan Manuel Macías
2023-09-07 10:22 5% ` Ihor Radchenko
2023-09-07 12:04 9% ` Juan Manuel Macías
2023-09-08 7:42 6% ` Ihor Radchenko
2023-09-06 14:55 5% ox-latex language handling in Org-9.5 vs 9.6 Max Nikulin
2023-09-06 22:20 8% ` Juan Manuel Macías
2023-09-07 10:38 5% ` Max Nikulin
2023-09-07 11:50 6% ` Ihor Radchenko
2023-09-07 14:19 12% ` Juan Manuel Macías
2023-09-07 14:49 6% ` Max Nikulin
2023-09-08 10:30 0% ` Max Nikulin
2023-09-08 14:42 10% ` Juan Manuel Macías
2023-09-08 19:02 3% ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Juan Manuel Macías
2023-09-09 9:11 6% ` Ihor Radchenko
2023-09-09 10:36 12% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
2023-09-09 11:33 6% ` Ihor Radchenko
2023-09-09 23:59 11% ` Juan Manuel Macías
2023-09-10 7:55 5% ` Ihor Radchenko
2023-09-10 11:06 3% ` Juan Manuel Macías
2023-09-10 13:36 6% ` Ihor Radchenko
2023-09-10 16:15 ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Max Nikulin
2023-09-10 16:52 ` Ihor Radchenko
2023-09-10 21:15 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
2023-09-11 8:32 5% ` Ihor Radchenko
2023-09-11 17:06 ` [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) Max Nikulin
2023-09-12 9:05 ` Ihor Radchenko
2023-09-12 15:22 ` Max Nikulin
2023-09-12 18:12 10% ` [patch] Fixes and improvements in org-latex-language-alist Juan Manuel Macías
2023-09-15 9:54 6% ` Ihor Radchenko
2023-09-16 18:00 10% [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
2023-09-17 10:02 6% ` Ihor Radchenko
2023-09-17 17:23 6% ` Timothy
2023-09-22 16:38 5% ` Max Nikulin
2023-09-24 18:42 12% ` Juan Manuel Macías
2023-09-25 13:58 5% ` Max Nikulin
2023-09-25 18:49 9% ` Juan Manuel Macías
2023-09-25 21:57 7% ` Thomas S. Dye
2023-09-26 15:39 0% ` Max Nikulin
2023-09-26 19:12 9% ` Juan Manuel Macías
2023-09-28 10:07 4% ` Max Nikulin
2023-09-28 12:31 9% ` Juan Manuel Macías
2023-09-29 2:38 5% ` Max Nikulin
2023-10-01 16:32 5% ` Max Nikulin
2023-09-28 15:36 ` AW
2023-10-01 16:02 ` Max Nikulin
2023-10-01 17:48 11% ` Juan Manuel Macías
2023-10-02 10:42 5% ` Max Nikulin
2023-09-21 7:46 Sanskrit/Devanagari fonts not exported to org-pdf output Zenny
2023-09-21 8:24 13% ` Juan Manuel Macías
2023-09-21 13:46 5% ` Zenny
2023-09-21 15:33 5% ` Juan Manuel Macías
2023-09-21 17:53 5% ` Zenny
2023-09-21 18:28 13% ` Juan Manuel Macías
2023-09-21 18:44 4% ` Zenny
2023-09-21 19:32 6% ` Juan Manuel Macías
2023-09-21 20:26 4% ` Zenny
2023-09-21 20:39 0% ` Zenny
2023-09-21 20:41 0% ` Zenny
2023-09-21 21:19 12% ` Juan Manuel Macías
2023-09-22 7:04 4% ` Zenny
2023-09-22 8:00 10% ` Juan Manuel Macías
2023-09-22 8:07 4% ` Zenny
2023-09-22 8:09 0% ` Zenny
2023-09-22 8:41 6% ` Juan Manuel Macías
2023-09-22 8:49 4% ` Zenny
2023-09-22 8:54 0% ` Zenny
2023-09-22 8:54 6% ` Juan Manuel Macías
2023-09-22 8:58 4% ` Zenny
2023-09-22 9:06 6% ` Juan Manuel Macías
2023-09-22 9:37 4% ` Zenny
2023-09-22 10:02 6% ` Juan Manuel Macías
2023-09-22 12:59 6% ` Zenny
2023-09-22 15:12 6% ` Juan Manuel Macías
2023-09-22 17:51 5% ` Zenny
2023-09-22 8:18 6% ` Juan Manuel Macías
2023-09-22 8:30 4% ` Zenny
2023-10-01 15:08 7% Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? Juan Manuel Macías
2023-10-01 18:07 12% ` Juan Manuel Macías
2023-10-02 13:10 5% ` Ihor Radchenko
2023-10-02 14:55 9% ` Juan Manuel Macías
2023-10-04 9:12 5% ` Ihor Radchenko
2023-10-04 14:34 11% ` Juan Manuel Macías
2023-10-06 16:29 5% ` Ihor Radchenko
2023-10-06 18:35 5% ` Juan Manuel Macías
2023-10-06 19:49 5% ` Ihor Radchenko
2023-10-06 8:07 11% [proof of concept, tip] 'Templates with arguments' using org src blocks Juan Manuel Macías
2023-10-13 16:00 5% ` Max Nikulin
2023-10-22 21:12 9% Are 'placement' and 'float' "obsolete terms" in inline images export Juan Manuel Macías
2023-10-23 9:27 5% ` Ihor Radchenko
2023-10-23 19:00 10% ` Juan Manuel Macías
2023-10-26 9:14 5% ` Ihor Radchenko
2024-01-02 21:43 11% ` Juan Manuel Macías
2023-11-02 9:29 Regression in latex export of tables? Fraga, Eric
2023-11-03 0:58 ` Vikas Rawal
2023-11-03 2:30 5% ` Max Nikulin
2023-11-11 15:54 Links & images with different attributes in the same paragraph Max Nikulin
2023-12-05 13:46 ` Ihor Radchenko
2023-12-12 11:08 ` Max Nikulin
2023-12-12 13:18 ` Ihor Radchenko
2023-12-13 11:50 ` Max Nikulin
2023-12-14 15:23 ` Ihor Radchenko
2023-12-16 8:06 5% ` Max Nikulin
2023-12-16 14:44 0% ` Ihor Radchenko
2023-12-19 14:39 0% ` Max Nikulin
2024-01-02 23:46 11% [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
2024-01-13 15:08 6% ` Ihor Radchenko
2024-01-13 16:05 10% ` Juan Manuel Macías
2024-01-13 18:28 5% ` Ihor Radchenko
2024-01-13 20:22 8% ` Juan Manuel Macías
2024-01-14 12:33 6% ` Ihor Radchenko
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).