Re: Experimental public branch for inline special blocks
Ihor Radchenko writes: > Juan Manuel Macías writes: > >> The latest added to the branch are Maxim's proposals (and code) for >> backend control. See this thread: >> >> https://list.orgmode.org/?t=20240321102752 >> >> And this other thread, continuation of the previous one: >> >> https://list.orgmode.org/877ciavnwo.fsf...@posteo.net/ > > I have seen these two branches and my comments account for them. Ok. Although I will try to answer all your comments in detail [if it's okay, I can start a new thread called "inline-special-block: general discussion"] I can anticipate that I would be in favor of removing global attributes (:smallcaps, :lang, :color). At first I didn't think it was a bad idea to have certain «pre-cooked» attributes. But later I realized that the implementation of each backend where it makes sense to apply these attributes is unnecessarily complicated. Furthermore, the very flexibility of the new object allows the same goal to be achieved. Well, next week I will continue commenting. I will try to stay up to date with everything that is being discussed here. By the way, if someone wants to collaborate on the branch, I can add them as a contributor (I'm afraid it is necessary to have a GitLab account, if I'm not mistaken).
Re: Experimental public branch for inline special blocks
Ihor Radchenko writes:
> Max Nikulin writes:
>
>> On 09/04/2024 15:52, Ihor Radchenko wrote:
>>> Aside: It looks like your public branch is not up-to-date as the time
>>>of writing this email - I do not see commits changing the syntax to
>>>@foo{...} and @@{...} yet,
>>
>> Do you have in your local copy the following?
>> ...
>
> I do now. Apparently, I somehow reviewed an earlier local copy of the
> branch.
Hi, Ihor. Thanks for all your comments. I will try to answer each of the
questions you have raised. Let's see if I can find a space next week...
The latest added to the branch are Maxim's proposals (and code) for
backend control. See this thread:
https://list.orgmode.org/?t=20240321102752
And this other thread, continuation of the previous one:
https://list.orgmode.org/877ciavnwo.fsf...@posteo.net/
Best regards,
Juan Manuel
Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
Ihor Radchenko writes:
> We may introduce \apostrophe entity.
>
> "two articles: 'my friends\apostrophe party' and 'the students\apostrophe
> papers'"
>
> "A Greek folk song says: \apostrophe{}να \apostrophe{}ρθώ το βράδυ'"
It's not a bad idea to use entities. I just discovered that an \rsquo
entity already exists. Right single quotation mark is the Unicode
recommended character for the apostrophe, and it is also the character
used in org-export-smart-quotes-alist[1].
Anyway, I think a) your patch could be a major improvement; b) perhaps a
brief note in the manual (I can send a tiny patch) should be added to
warn of possible ambiguities, and possible solutions.
[1] Although there are arguments against this Unicode recommendation,
see: https://en.wikipedia.org/wiki/Right_single_quotation_mark
Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> ━━━
>> #+OPTIONS: ':t
>> #+language:es
>>
>> "my friends' party and the students' papers"
>> ━━━
>>
>> the above produces in LaTeX:
>>
>> \guillemotleft{}my friends'' party and the students''
>> papers\guillemotright{}
>> ...
>> Perhaps a possible solution would be to allow the use of a specific,
>> customizable character, other than an apostrophe, for second-level
>> quotes. Or at least add some brief warning in the manual: in certain
>> contexts it is safer to use a explicit Unicode character for the
>> apostrophe.
>
> I think that we can address examples like this simply by not replacing
> unbalanced quotes. There is already some effort in the code towards such
> treatment, but it is not complete.
>
> Can you try the attached patch?
Hi, Ihor,
The patch works fine, and I think it can prevent a lot of cases. But
false positives can still appear. Consider (second level quotes open
after the colon):
"two articles: 'my friends' party' and 'the students' papers'"
"A Greek folk song says: 'να 'ρθώ το βράδυ'"
==>
\guillemotleft{}two articles: ``my friends'' party' and ``the students''
papers'\guillemotright{}
\guillemotleft{}A Greek folk song says: 'να ``ρθώ το βράδυ''\guillemotright{}
I think the only solution here would be to introduce a Unicode
apostrophe (’). Or allow an optional, alternative character for
second-level quotes:
"... `my friends' party` ..."
[bug] Smart quotes: confusion of apostrophe with second level quotes
Hi,
I don't know if this is a known issue, but I haven't been able to find
any mention of it. I think this is partly because in English it can go
perfectly unnoticed, since for English the values of secondary-closing
and apostrophe are identical:
(secondary-closing :utf-8 "’" :html "" :latex "'" :texinfo "'")
(apostrophe :utf-8 "’" :html "")
However, consider the following example:
━━━
#+OPTIONS: ':t
#+language:es
"my friends' party and the students' papers"
━━━
the above produces in LaTeX:
\guillemotleft{}my friends'' party and the students'' papers\guillemotright{}
In Spanish, as in other similar cases, the issue is easier to reproduce
because:
(secondary-closing :utf-8 "”" :html "" :latex "''" :texinfo "''")
(apostrophe :utf-8 "’" :html "")
I don't know whether to consider this a bug or a limitation in the
current implementation, originating from how Org interprets an
apostrophe. Although I suspect it has a difficult solution: how to
differentiate an apostrophe from a second-level quote in certain
scenarios, when the approach seems to be essentially heuristic? Let us
also consider cases in which the apostrophe can be placed at the
beginning of a word, as in Greek:
"να 'ρθώ το βράδυ"
(Org would confuse the apostrophe in the word 'ρθώ with second-level
opening quotes)
Perhaps a possible solution would be to allow the use of a specific,
customizable character, other than an apostrophe, for second-level
quotes. Or at least add some brief warning in the manual: in certain
contexts it is safer to use a explicit Unicode character for the
apostrophe.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks)
Max Nikulin writes:
> I am afraid that :export will cause confusion with :exports for source
> code blocks. Its name differs by just "s" but possible values have
> nothing common.
I agree. At the moment two alternative names come to mind: :backends or
:export-rules
> Another issue is more general and should apply e.g. to HTML attributes
> as well. Consider
>
> --- 8< ---
>
> #+options: inline-special-block-aliases:(("kbd" :export "html*"
> :html-tag kbd))
>
> @kbd{Default} and @kbd[:export "latex*"]{LaTeX}
> --- >8 ---
>
> It exports to
>
> \nDefault and LaTeX
>
> I would expect that "html*" is inherited from the parent declaration and
> "latex*" does not override it, so
>
> \nDefault and LaTeX
But it is the expected result in all attributes. If an attribute of the
same type as the one declared in the alias is added, the value is
overwritten.
In any case, since in this case the attribute allows cumulative values,
I think the approach should be at the level of the attribute name itself
and not the code to manage the export rules. For example:
:export [or whatever new name we give it] ==> normal behavior, overwrites the
values
:export+ ==> adds the new values to the values defined in the alias
This syntax could also be extended to other cases. Perhaps we want
attributes like :prelatex, :postlatex, or :html to support accumulating
values. It could be easily solved from the functions of each backend. In
other cases, of course, it wouldn't make sense (a block can't have two
languages at the same time), but in that scenario, if someone puts
:lang+, it simply wouldn't be taken into account. Wdyt?
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Max Nikulin writes: > Would you mind against new thread as an umbrella for next bunch of > topics? Current one becomes too large from my point of view. Ok, I agree. I suggest that from now any new thread related to the new object have as subject: "inline-special-block: specific topic to discuss". Tomorrow I will try to answer all the latest questions related to the export rules.
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Max Nikulin writes: > An update with a couple of bugs fixed. Now it is possible to specify > different export rules for a backend and all its derivatives: I have implemented your code in the last commit. I think it is a great improvement, thanks a lot. As I mentioned in a past email, these days I will be somewhat busy, but I will try to keep up to date with your comments. Although it may take a while to respond.
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Max Nikulin writes: > (ignore > (pp > (let ((rules > (org-export--inline-special-block-make-backend-alist > (org-split-string "latex/ html./ ascii+ *" > (mapcar (lambda (backend) > (list backend > (org-export--inline-special-block-export-decision > rules backend))) > '(odt latex beamer html md ascii) > > Gives > > ((odt content) > (latex nil) > (beamer nil) > (html nil) > (md content) > (ascii full)) > > Function definitions: > > (defun org-export--inline-special-block-make-backend-alist > (rules) > (nconc >(let (result) > (dolist (spec rules) >(if (string-match > > "\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'" > spec) >(let ((name (match-string 1 spec)) > (inherit (match-string 3 spec)) > (what (or (match-string 2 spec) >(match-string 4 spec >(push (cons > (if (string-equal "" name) '@ (intern name)) > (cons (or (not inherit) (string-equal inherit "=")) > (if what (string-to-char what) ?+))) > result)) >(message "invalid :export specification %S" spec))) > result))) > > (defun org-export--inline-special-block-export-decision > (rules-alist backend) > (when (symbolp backend) > (setq backend (org-export-get-backend backend))) > (let* ((rule (assoc (org-export-backend-name backend) rules-alist)) >(decision (and rule (cddr rule > (while (and (not decision) > (setq backend (org-export-backend-parent backend))) > (setq backend (org-export-get-backend backend)) > (when (and (setq rule (assq (org-export-backend-name backend) > rules-alist)) > rule > (cadr rule)) > (setq decision (cddr rule > (unless decision > (setq rule (assq '@ rules-alist)) > (setq decision (and rule (cddr rule > (pcase decision > (?+ 'full) > (?* 'content) > (?/ nil) > (_ 'full I've been testing your code and it works very well. It is certainly finer than the current approach. I think it could be implemented, and we are testing that. Tomorrow I will make a new commit with your code. -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Thank you for your comments. Max Nikulin writes: > On 15/03/2024 09:19, Juan Manuel Macías wrote: >> The attribute supports one or more elements separated by a space. Each >> element can be any of the following signs: "*" (export only the >> content), "-" (do not export), "=" (export the rest normally), "=*" >> (export the rest, but only the content), "=-" (do not export the rest). >> Additionally, backend names can be given explicitly, alone or >> accompanied by the "*" or "-" signs, that is (where "backend" equals the >> name of the backend): > > 1. "-" is a valid backend name and valid last character of backend name I had not thought of it. Can + also be a valid character? > 2. From the description it is not clear to me what is effect of "rest" > specified for more than one backend. 'rest' (=) is equivalent to the rest of the backends that have not been explicitly set. What happens is that, with my current approach, if you want to export only one backend, you must enter: :export backend =- (that is, export this backend and not the rest) This is not ideal. It should be enough to just put: :export backend but I am not able to achieve it. > I have had into the code. I would expect something like the following > (characters may be changed, the code is not heavily tested). Two > characters from the following groups may be appended to backend name: > > + full (default) > * content > / skip > (these ones may be used without backed name to specify fallback action) > > = this and derived backends (default) > . this, but not derived backends > Perhaps it is necessary to add possibility that > these rules may coexist (use loop instead of assoc) OK. How about the following? - Single characters (they affect everything, if backend name is not specified, or the rest, if backend name is specified: * content / skip . never export derived backends = full, this and derived backends (default) - And in combination with backend names (some examples): :export latex* > content to LaTeX, normal to the rest :export latex/ > do not export to LaTeX :export latex. > do not export to LaTeX derived backends :export latex . > export normally to LaTeX but do not export the derived backends in the rest of the cases etc. These days I'm going to be a little short on time, due to work, and I don't know if I'll be able to attend to the list. I want to calmly take a look at the code you share.
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
To summarize the latest improvements and modifications to the `:export'
attribute...
The attribute supports one or more elements separated by a space. Each
element can be any of the following signs: "*" (export only the
content), "-" (do not export), "=" (export the rest normally), "=*"
(export the rest, but only the content), "=-" (do not export the rest).
Additionally, backend names can be given explicitly, alone or
accompanied by the "*" or "-" signs, that is (where "backend" equals the
name of the backend):
backend: export normally for that backend and its derived backends;
backend-: do not export for that backend or its derived backends.
backend*: export only the content for that backend and its derived
backends.
Some examples with valid combinations:
@foo[:export *]{lorem ipsum}
==> export only the content
@foo[:export -]{lorem ipsum}
==> do not export
@foo[:export latex-]{lorem ipsum}
==> do not export to LaTeX
@foo[:export latex- html* =]{lorem ipsum}
==> do not export to LaTeX, export only the content to html and export the
rest normally.
@foo[:export latex =*]{lorem ipsum}
==> export normally to LaTeX but export only the content to the rest
@foo[:export latex =-]{lorem ipsum}
==> export normally to LaTeX and not export to the rest
And below is a complete example based on a possible use case that Max
had exposed:
To see a demo of the Fairlight CMI, watch @@[:export html =-]{this
video} @@[:export
html-]{[[https://www.youtube.com/watch?v=am0GBuS_7cE][this video]]}
with Peter Vogel.
#+begin_export html
https://www.youtube.com/embed/am0GBuS_7cE?si=X7pghJhtdfOT1hby;
title="YouTube video player"
frameborder="0"
allow="accelerometer;
autoplay; clipboard-write; encrypted-media; gyroscope;
picture-in-picture; web-share"
allowfullscreen>
#+end_export
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Juan Manuel Macías writes:
> It was necessary with the previous implementation, which excessively
> abused regexp. Not now (I want to do a few more tests and I'll make a
> new commit with the changes). With the new implementation, now:
>
> - do not export
>
> * export only the content
>
> = rest (full)
>
> =* rest (contents only)
>
> backend- do not export this backend (and the backends derived from it)
>
> backend+ (or, perhaps, just "backend") export this backend (idem)
>
> backend* export this backend (contents only) (idem)
>
> I think your example with the video link would also be possible with the
> new implementation.
Please try the latest commit:
@@[:export html-]{Watch [[https://youtube.com/...][Org mode in action demo]]
video.}
#+begin_export html
https://youtube.com/embed/...;
title="Org mode in action demo"
width="..." height="...">
#+end_export
It would not be exported to html or its derived backends.
(In your example you used `-html' instead of `html-'. I have no
preference for one variant or another).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Max Nikulin writes: >> how about the following: >> - "--" :: do not export >> - "**" :: export only the content >> - "==" :: rest (full) >> - "=*" :: rest (only the content) >> - "!backend-name+ :: export this backend (full) >> - "!backend-name*" :: export this backend (only the content) >> - "!backend-name- :: do not export this backend > > I do not see why operator should be duplicated for backends that are not > specified explicitly. Single "+" (default) or "-" should be enough. I > have not got your idea with leading "!". From my point of view it is > redundant. It was necessary with the previous implementation, which excessively abused regexp. Not now (I want to do a few more tests and I'll make a new commit with the changes). With the new implementation, now: - do not export * export only the content = rest (full) =* rest (contents only) backend- do not export this backend (and the backends derived from it) backend+ (or, perhaps, just "backend") export this backend (idem) backend* export this backend (contents only) (idem) I think your example with the video link would also be possible with the new implementation. -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Max Nikulin writes: > It is not clear for me how to achieve the following. Add a link > > [[https://youtube.com/...][Org mode in action demo (video)]] > > for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because > there is an #+export_html block with player embedded using an iframe. Sorry, I don't quite understand this. Could you please elaborate? > Instead of "noexport" and "rest" that may be confused with backend > names I would consider "+" and "*" without any name. I would consider > some characters like "-", "_", "!", "~" to express "do not export to > this and derived backends" and "do not export for specified backend > only". how about the following: - "--" :: do not export - "**" :: export only the content - "==" :: rest (full) - "=*" :: rest (only the content) - "!backend-name+ :: export this backend (full) - "!backend-name*" :: export this backend (only the content) - "!backend-name- :: do not export this backend ? -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
In the last commit I have introduced some changes. Now this new feature
is no longer hardcoded in each backend but is controlled by an external
function in ox.el. I think this can simplify the implementation for
other backends.
As Stefan Nobis proposed, the "+" sign is now not necessary:
backend-name = full export
backend-name* = only contents
And the "rest" option is introduced, with the same syntax as before.
Examples:
@foo[:export noexport]{lorem ipsum dolor}
==> does not export anything
@foo[:export contents]{lorem ipsum dolor}
==> only contents
@foo[:export latex]{lorem ipsum dolor}
==> exports only to LaTeX
@foo[:export latex odt* html*]{lorem ipsum dolor}
==> exports everything to LaTeX, but to odt and HTML only the content
@foo[:export latex* rest]{lorem ipsum dolor}
==> content to LaTeX but full export to the rest of the backends
@foo[:export latex rest*]{lorem ipsum dolor}
==> the opposite of the above.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> Your example uses a closed list of backends while "not (html or
> latex)" may be applicable to ascii, rst, some wiki dialects, etc.
Makes sense.
> Backend-specific markup may be more complex and content of fallback
> option may be different from text used in export snippets. Perhaps I
> shouldn't give so simple example.
I think I have understood the essentials, but perhaps it would be good
to see a slightly more complex scenario.
> Side note: I expect that the new object will be more convenient than
> export snippets in most cases.
I think so. In any case, although this object is proving pleasantly
versatile for us, I think we should not lose sight of the fact that its
main purpose is to be an inline text container with export properties.
Exports snippets are more for literal code inclusion. There can be
border uses between both objects, as there can also be with macros and
links. I suppose the ideal is to always choose the feature that best
suits a given context. One can put, for example @esindex[:export
latex+]{some word}, but in this case it would be more comfortable to put
@@latex:\esindex{some word}@@ or even use a macro.
>> :export "latex+ html+ rest*"
>
> "rest" might be a valid backend name.
I will try to implement the "rest" option.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> On 10/03/2024 09:08, Juan Manuel Macías wrote:
>> I'm thinking about adding a new global attribute, `:export', that
>> would granularly control whether or not to export the object and how to
>> export it.
>
> I have a bit different expectations in respect to export predicates.
> It should be possible to express that some content should be exported
> by all backend except the given list. The use case is fallback for
> backends not covered by export snippets:
>
> @@latex:\textbf{\LaTeX() formatting}html:HTML
> formatting@@@[...]{*for other backends}
I think that in your example (if I understand the intentions correctly)
it would not even be necessary to use export snippets:
#+options: inline-special-block-aliases:(("strong" :latex-command textbf
:html-tag strong :export "latex+ html+ odt*" ))
@strong{formatting}
or even:
@strong{@@latex:\latex{}: html:HTML: @@ formatting}
As defined, it is exported to LaTeX and HTML with all the formatting,
but only the content is exported to odt. The rest are not exported.
Maybe an "rest" option could be added, to avoid verbosity:
:export "latex+ html+ rest*"
(the complete format is exported to LaTeX and html and only the content to the
rest).
However, I think that exporting this object to 'format-agnostic' backends,
such as plain text, would have to be implemented in a way that always
exports the content.
> Earlier I raised this issue during discussion of @@:...@@ syntax extension:
> Max Nikulin. Re: Org-syntax: Intra-word markup. Fri, 28 Jan 2022
> 21:52:17 +0700.
> https://list.orgmode.org/868df76e-69e0-1d14-ae8a-13b746982...@gmail.com
>
> Another case for backend predicates is whether it should be applicable
> to derived backends or just to explicitly specified ones.
I don't have a definite opinion. Maybe it would be nice to also take
into account derived backends...
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: Footnotes on line and not raised
Colin Baxter writes:
> Perhaps it's not possible because I see that .footref in css support is
> always .
You can modify a little so that it does not alter the paragraph
line spacing so much. In this example, with a value of 0em, it is
positioned on the baseline:
#+HTML_HEAD: sup {vertical-align: baseline;position: relative;bottom:
0em;}
Another slightly dirtier way is with an export filter in your document.
The sub tag is removed and the reference number is enclosed in square
brackets, separated by a space from the previous word:
#+BIND: org-export-filter-footnote-reference-functions (footnote-sup-filter)
#+begin_src emacs-lisp :exports results :results none
(defun footnote-sup-filter (text backend info)
(when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "" "" text)
#+end_src
screenshot:
https://i.ibb.co/CBRnfXG/pantallazo-79248380551244229p8.png
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
Juan Manuel Macías writes:
> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.
>
> Possible values: "noexport", "contents" (it would export only the content)
> or the backends to which you want to export, separated by spaces. Each
> backend should be followed by a "+" sign (= export all) or "*" (export
> content only). For example:
>
> @foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}
>
> This means that "lorem ipsum dolor" would be exported with color format
> to LaTeX, but only the content would be exported to odt and html.
I have implemented the new :export attribute in the last commit, to
experiment (in any case, it can always be reverted). The syntax and
usage are as described in the previous message. An example, where we
define an alias for inline comments and another for highlighted text: It
will only be exported as highlighted text to LaTeX (using the lua-ul
package for LuaLaTeX); only the content will be exported to HTML; and it
will not be exported to the rest of the backends.
#+options: inline-special-block-aliases:(("comment" :export "noexport")("hl"
:export "latex+ html*" :latex-command "highLight"))
#+latex_header: \usepackage{xcolor,luacolor,lua-ul}
#+latex_compiler: lualatex
@hl{this is highlighted text, only in LaTeX} @comment{this is a comment}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
`:export' attribute?: Re: Experimental public branch for inline special blocks
I'm thinking about adding a new global attribute, `:export', that
would granularly control whether or not to export the object and how to
export it.
Possible values: "noexport", "contents" (it would export only the content)
or the backends to which you want to export, separated by spaces. Each
backend should be followed by a "+" sign (= export all) or "*" (export
content only). For example:
@foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}
This means that "lorem ipsum dolor" would be exported with color format
to LaTeX, but only the content would be exported to odt and html.
Wdyt?
Best regards,
Juan Manuel
Re: false positives: Re: Experimental public branch for inline special blocks
Juan Manuel Macías writes:
> Max Nikulin writes:
>
>> However it is still gives
>>
>> (org-export-string-as "Alpha@Beta["
>> 'html
>> '(:export-options (body-only)))
>> Debugger entered--Lisp error: (wrong-type-argument
>> number-or-marker-p nil)
>
> I think the problem is the contents-begin variable. When it is nil it
> produces that error. I will make a new commit to fix the bug.
>
> Thanks for all the tests you're doing!
Well, I hope that in the last commit the two bugs that you mentioned
have been fixed. Please check:
Albha@Beta[
@sp@n{lorem ipsum}
{lorem ipsum}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: false positives: Re: Experimental public branch for inline special blocks
Max Nikulin writes: > However it is still gives > > (org-export-string-as "Alpha@Beta[" > 'html > '(:export-options (body-only))) > Debugger entered--Lisp error: (wrong-type-argument > number-or-marker-p nil) I think the problem is the contents-begin variable. When it is nil it produces that error. I will make a new commit to fix the bug. Thanks for all the tests you're doing! -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: false positives: Re: Experimental public branch for inline special blocks
Juan Manuel Macías escribió:
> Ok, I think you and Maxim are right. This is a clear bug. I hope it
> was fixed in the last commit.
Now:
(org-export-string-as "Alpha@Beta{" 'latex t))
==> Alpha@Beta\{
(org-export-string-as "Alpha@Beta{gamma}" 'latex t))
==> Alpha\Beta{gamma}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: false positives: Re: Experimental public branch for inline special blocks
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> Debugger entered--Lisp error: (wrong-type-argument
>>> number-or-marker-p nil)
>>
>> Maybe in that case you could add a zero width space character.
>>
>> In any case, if someone has reasons to write "Alpha@Beta{" they may also
>> have reasons to write "Alpha_Beta":
>
> 1. Parser must not throw errors on text files. Ever. Any text file is a
>valid Org file.
> 2. We should demand paired {...}, as we do for latex fragments,
>emphasis, inline export snippets, and all other container objects.
Ok, I think you and Maxim are right. This is a clear bug. I hope it
was fixed in the last commit.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: false positives: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> (org-export-string-as "Alpha@Beta{"
> 'html
> '(:export-options (body-only)))
> "\nAlpha{\n"
>
> (org-export-string-as "Alpha@Beta["
> 'html
> '(:export-options (body-only)))
> Debugger entered--Lisp error: (wrong-type-argument
> number-or-marker-p nil)
Maybe in that case you could add a zero width space character.
In any case, if someone has reasons to write "Alpha@Beta{" they may also
have reasons to write "Alpha_Beta":
(org-export-string-as "Alpha_beta"
'html
'(:export-options (body-only)))
Alphabeta
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: false positives: Re: Experimental public branch for inline special blocks
Juan Manuel Macías writes:
> Ihor Radchenko escribió:
>
>> I am wondering if @@[...]{...} would be better than @_...
>> It should be slightly easier to type.
>
> Another possibility would be @:[...]{...}, which is somewhat shorter.
>
> (I don't have any special preference, although @@ visually reminds me a
> bit of the export snippet).
Anyway, in the last commit I replaced _ with @. Let's see how it goes...
Now the anonymous variant is @@[...]{...}.
Re: false positives: Re: Experimental public branch for inline special blocks
Ihor Radchenko escribió:
> I am wondering if @@[...]{...} would be better than @_...
> It should be slightly easier to type.
Another possibility would be @:[...]{...}, which is somewhat shorter.
(I don't have any special preference, although @@ visually reminds me a
bit of the export snippet).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: false positives: Re: Experimental public branch for inline special blocks
Ihor Radchenko writes:
> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.)
I have modified the syntax in the last commit. Now:
@type[...]{...} (or @_[...]{...})
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: false positives: Re: Experimental public branch for inline special blocks
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> (org-export-string-as "Alpha{"
>> ...
>> mmm, right. And there may also be a problem with the subscripts:
>> &_{subscript}...
>>
>> Perhaps we should think about a structure less prone to ambiguities. For
>> example:
>>
>> &:type[attrs]{text} / &:_[attrs]{text}
>
> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.)
+1
(one character is always better than two)
Re: false positives: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> It seems the parser finds new objects where syntactical constructs are
> incomplete:
>
> (org-export-string-as "Alpha{"
> 'html
> '(:export-options (body-only)))
> "\nAlpha{\n"
mmm, right. And there may also be a problem with the subscripts:
&_{subscript}...
Perhaps we should think about a structure less prone to ambiguities. For
example:
&:type[attrs]{text} / &:_[attrs]{text}
(I think someone had suggested something like this in a past message,
but I can't find it, apologies).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: To avoid zero width space: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> However to produce clean export result elements should not be
> added if no attributes are specified. My expectation is
>
> "
> Example of intraword markup
> "
With the latest commit now the anonymous variant without attributes
simply returns the content (in LaTeX, HTML and odt). You can try:
&_{/lorem/}&_{*ipsum*}&_{_dolor_}
==> LaTeX: \emph{lorem}\textbf{ipsum}\uline{dolor}
==> HTML loremipsumdolor
==> ODT loremipsumdolor
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: To avoid zero width space: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> However to produce clean export result elements should not be
> added if no attributes are specified. My expectation is
>
> "
> Example of intraword markup
> "
It seems like a good idea to me. Currently, in LaTeX:
&_{lorem ipsum dolor} ==> LaTeX ==> lorem ipsum dolor
It can also be extended to html, odt and the rest of the backends.
That is, by default, the anonymous variant without attributes simply
returns the content.
Another possibility (with the current implementation):
#+options: inline-special-block-aliases:(("b" :html-tag "b")("i" :html-tag "i"))
{intra}{word}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: smallcaps: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> OK, just consider it as my dissenting opinion. I believe that it should
> be possible for the same Org document
>
>#+options: inline-special-block-aliases:(("definition" :smallcaps t))
>
>{Example} or &_[:smallcaps t]{ad-hoc}
>
> to export it as
>
>Example
>or ad-hoc
>
> or as
>
>Example
>or ad-hoc
>
> by adjusting of global settings. The former one be suitable for a CMS
> that does not allow user CSS and the latter one is preferable for a site
> under full user control and having CSS
>
>.definition, .small-capps { font-variant: small-caps; }
With the current implementation this:
#+options: inline-special-block-aliases:(("definition" :smallcaps t))
{Example}
produces:
Example
:smallcaps simply adds a (say) direct formatting layer. I am not a fan
of any form of direct formatting. But, as I already said, I think that
these types of global attributes can be useful for users who do not want
to bother with predefining styles, classes or commands in
odt/html/LaTeX, or because they do not know how to do it. They simply
want a text to be exported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).
I think an option could be added to disable global attributes or specify
which backend they should be used on. Anyway, I would not see it
necessary, but perhaps other users think differently.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: smallcaps: Re: Experimental public branch for inline special blocks
Max Nikulin escribió:
> If some type is used through the document multiple times then it is
> better to avoid style="font-variant:small-caps" and use a CSS class
> instead. Even for LaTeX it may be better to define a dedicated command
> to be closer to semantic markup.
>
> Moreover different decorations may be used in LaTeX and HTML. Some type
> may be typed in small caps in LaTeX, but in HTML it may use regular font
> and some color.
The "global attribute" concept implies that there should be (ideally)
the same result in all possible backends (naturally, if the output is
plain text, :color doesn't make much sense). Global attributes are a
quick and easy (for the user) way to create direct formatting, analogous
to the LaTeX commands \textcolor, \textsc, etc. Its casual use is the
most recommended, in my opinion. Let's imagine that a user wants to
color segments of text, in the same color, for LaTeX and odt, and does
not want to bother with predefined styles or macros in odt and LaTeX
respectively.
If a segment of text must have a different appearance, for example, in
LaTeX (small caps) and HTML (red color), you can put:
&_[:html style="color:red;" :prelatex \scshape{}]{text}
And if one wants to have more robust control, for example because many
text segments must have a certain treatment in HTML, odt or LaTeX,
styles, classes and macros can always be defined in the output format.
Additionally, there are the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination of direct formatting
and styles to suit the user.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: naming: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> Special blocks are really block-level elements. I see similarity,
> however with a better term we could avoid "inline" specifier. I think,
> the new beast may serve in some cases currently handled by macros.
> LaTeX snippets are named "fragments" in the manual.
>
> Custom fragment?
I think "custom" is an important part of defining the new object. Unlike
other elements/objects, such as emphasis marks, this one does not add
any (let's say) "logical or semantic" information. I mean, emphasis
marks (to continue with the example) are useful when reading an Org
document as it is. But the new object is rather a segment of text that
must be exported in a certain way to LaTeX, odt, HTML, etc. Something
like "{some text}" does not provide any information to the reader,
but rather to the exporters and the output format. So, how about
something like:
- Custom Export Fragment
- Custom Export Span
- Custom Export "Whatever"
- ...
?
(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdown).
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
[tip] Export to PDF with latexmk 'continuous preview' option
A little-known (and sometimes very useful) latexmk option is the -pvc option. According to the latexmk manual: [...] The second previewing option is the powerful -pvc option (mnemonic: "preview continuously"). In this case, latexmk runs continuously, regularly monitoring all the source files to see if any have changed. Every time a change is detected, latexmk runs all the programs necessary to generate a new version of the document. A good previewer will then automatically update its display. Thus the user can simply edit a file and, when the changes are written to disk, latexmk completely automates the cycle of updating the .dvi (and/or the .ps and .pdf) file, and refreshing the previewer's display. It's not quite WYSIWYG, but usefully close. In order to use this option from Org, I have defined a simple minor mode that runs latexmk with the -pvc option and creates a buffer to monitor the process. Every time the document, or any file involved, is saved, the PDF is updated. We can define in our `latexmkrc' our favorite external PDF viewer (Atril, Okular, Evince, etc.). I have this line: ┌ │ $pdf_previewer = "atril %O %S > /dev/null 2>&1 &"; └ And here's the code (for documents that are long, complex, or take a while to export, it may be better to use the asynchronous version of `org-latex-export-to-latex'): ┌ │ (defun my-org-compile-latexmk-interactive () │ (let* ((tex-file (org-export-output-file-name ".tex"))) │ (start-process-shell-command │ "latexmk" │ (format "*%s-latexmk-process*" (file-name-sans-extension tex-file)) │ (concat │ "latexmk -f -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape %S/' " │ tex-file │ │ (define-minor-mode org-interactive-compile-pdf-mode │ "TODO" │ :lighter " OrgInteractivePDF" │ (if org-interactive-compile-pdf-mode │ (progn │ (my-org-compile-latexmk-interactive) │ (add-hook 'after-save-hook #'org-latex-export-to-latex nil t)) │ (remove-hook 'after-save-hook #'org-latex-export-to-latex t) │ (when (equal (process-status "latexmk") 'run) │ (kill-process "latexmk" └ And a screencast: <https://cloud.disroot.org/s/ztFfa27kdsnNkGc> -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: naming: Re: Experimental public branch for inline special blocks
Max Nikulin writes: > In Org syntax, "elements" are paragraphs and larger parts, while parts > within paragraphs are named objects. I admit that for org-element > everything is element. In my initial message I used 'element' loosely. Note that inline-special-block is included in org-element-all-objects, where inline-src-block is also.
Re: naming: Re: Experimental public branch for inline special blocks
Ihor Radchenko writes: > Max Nikulin writes: > >> Does anybody have an idea of a better name for a feature? Maybe >> something like inline custom objects, snippets. "Objects" are used to >> describe syntax, but not used in the manual though. > > Custom inline markup. Custom span? I chose "inline special block" because special blocks, and because of the parallelism inline code block/code block. -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: Experimental public branch for inline special blocks
Hi, Stefan,
Stefan Nobis writes:
> first of all: Thank you for your great work. Looks really good.
You're welcome! :-)
> Just out of curiosity: Why a special syntax for alias expansion?
>
> From a syntax and user point of view, I think I would prefer a simpler
> syntax. So
>
> {text}
>
> would check if an alias is registered and if yes use it. This way it
> would be easier to change/add options later on without the need for
> changing all the inline-block commands and add a "!" (not a big deal,
> just two rather simple replace commands).
I think you're right. I have removed the need for "!" in the last
commit.
Now the syntax is:
{text}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Experimental public branch for inline special blocks
Hi,
Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:
<https://gitlab.com/maciaschain/org-mode.git>
The code incorporates fixes and modifications and I have also added some
ideas from Maxim Nikulin. The LaTeX and HTML backends are complete,
although of course it can still be perfected. Recapitulating the
necessary information:
The new element can be nested and supports other elements such as links,
macros, emphasis marks, etc.
The basic syntax:
┌
│ {lorem ipsum dolor}
└
produces in LaTeX:
┌
│ \foo{lorem ipsum dolor}
└
and in HTML:
┌
│ lorem ipsum dolor
└
There is also an anonymous variant:
┌
│ &_{lorem ipsum dolor}
└
Optional attributes in square brackets are supported. There are a series
of 'universal' attributes, common to each backend. At the moment:
`:lang', `:color' and `:smallcaps'. Example:
┌
│ [:color red :smallcaps t :lang it]{lorem ipsum dolor}
└
Specific to the LaTeX backend we have the `:prelatex' and `:postlatex'
attributes (which introduce arbitrary code before and after the content)
and `:latex-command', which overrides the exported command.
`:latex-command nocommand' does not export a command flag. Examples:
┌
│ [:prelatex [bar] :postlatex {baz} :lang it :latex-command blah]{lorem
ipsum dolor}
└
==>
┌
│ \foreignlanguage{italian}{\blah[bar]{lorem ipsum dolor}{baz}}
└
┌
│ &_[:prelatex \foo{bar} :color red]{lorem ipsum dolor}
└
==>
┌
│ {\color{red}\foo{bar}lorem ipsum dolor}
└
Likewise, for HTML we have the `:html-tag' and `:html-class' attributes
(which override the tags and the class name) and another one, more
generic, `:html', which introduces arbitrary code, such as
`style="..."'.
We can group lists of attributes as aliases. The syntax waould be:
┌
│ !{text}
└
and we can also combine aliases with more single attributes:
┌
│ ![more-attributes]{text}
└
An example: let's imagine that we want a specific block for short quotes
in Latin and italics (it is normative in some typographical traditions
that quotes in classical Latin are put in italics instead of quotation
marks):
┌
│ #+options: inline-special-block-aliases:(("latin" :lang "la" :latex-command
"textit" :html-tag "em"))
│
│ Caesar's famous quote: !{Alea iacta est}
│
│ Caesar's famous quote: ![:smallcaps t :color blue]{Alea iacta est}
└
==> LaTeX:
┌
│ Caesar's famous quote: \foreignlanguage{latin}{\textit{Alea iacta est}}
│
│ Caesar's famous quote:
{\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
└
== HTML:
┌
│ Caesar's famous quote: Alea iacta est
│
│ Caesar's famous quote: Alea iacta est
└
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [proof of concept] inline language blocks
Max Nikulin writes:
>> Anyway, I think your example only makes sense in HTML, or at least I
>> can't make sense of it in LaTeX. Why would anyone want {text} to be
>> passed to LaTeX as \bar{text}, instead of just {text}? In HTML it
>> does seem sensible to me that someone would want to change the tags.
>> Maybe with a :html-tag, or something like that.
>
> Consider a document aimed to be exported to different formats. It is
> unlikely that names of commands, elements, classes, etc. match for all
> of them.
It makes sense, although I have never encountered a case like this.
Usually (and returning to the example of the large special blocks), if
in org I put something like:
#+begin_foo
...
#+end_foo
I try to ensure that there is a "foo" environment in LaTeX, a "foo" class
in html or a "foo" style in odt (now I don't remember if the odt exporter
produces paragraph styles from special blocks. I don't think so).
In any case, on second thought, maybe someone wants to reuse a LaTeX
preamble, css style sheets or any odt templates. I see no problem, then,
in there being attributes like :latex-command, :html-tag, :odt-style
:html-attribute,
etc., which override the default values.
>> As for :latex-command, if I understand it correctly, I don't quite see
>> how useful this could be:
>> [:latex-command bar]{text} == LaTeX ==> \bar{text}
>> when it is simpler to put:
>> {text}
>
> Command may require additional arguments and it should be convenient
> to define shortcuts to the same command with different arguments:
>
> {text} => \foreignlanguage{latin}{text}
> {text} => \foreinglanguage{spanish}{text}
With the current implementation:
#+options: inline-special-block-aliases:(("bar" :prelatex [bar]) ("baz"
:prelatex [baz]))
[@bar@]{lorem ipsum} ==> \foo[bar]{lorem ipsum}
[@baz@]{lorem ipsum} ==> \foo[baz]{lorem ipsum}
Your example is less verbose, but with this implementation you can do
combinations, it's
more granular, I think:
[@bar@ :smallcaps t]{lorem ipsum} ==> {\scshape\foo[bar]{lorem ipsum}}
[@baz@ :lang it]{lorem ipsum} ==> \foo[baz]{\foreignlanguage{italian}{lorem
ipsum}}
I think this is quite flexible and leaves a great deal of freedom to the user.
>> The same thing happens with the anonymous variant:
>> &_[:latex-command foo]{text} == LaTeX ==> \foo{text}
>> which is identical to putting {text}
>> The anonymous variant would be equivalent in LaTeX to a
>> \begingroup...\endgroup, or rather to {...}. One could add all the
>> commands one wants within the group simply with :prelatex:
>> &_[:prelatex \foo\bar\vaz\blah{}]{text}
>> ==> {\foo\bar\vaz\blah{}text}
>
> The idea is to not add \begingroup and \endgroup if LaTeX command is
> specified (or to control it by a dedicated attribute). Again, consider
> a document suitable for multiple export formats.
Indeed, if the :latex-command attr is implemented should work in both
variants. In such a way, perhaps:
&_[:latex-command foo]{lorem} ==> \foo{lorem}
> I think, flexibility in respect to underlying
> commands/classes/elements allows to minimize changes in documents
> later. Sometimes it is necessary to switch to another LaTeX package,
> CSS framework, etc. It allows usage semantic names within Org
> documents despite they may be exported to the same command.
>
>> In any case, I think that my implementation leaves open the possibility
>> of extending it with everything you mentioned, or anything else.
>
> The question is proper balance of built-in features, flexibility,
> implementation complexity. It would be unfortunate if most of users
> will have to create custom backends even for basic documents.
We can continue the discussion when I publish my experimental branch and
share the link. I'm a little late because I want to make some
corrections to the code first.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [proof of concept] inline language blocks
Max Nikulin writes:
>> the user should expect something like {...} to produce \foo{...} or
>> ..., etc. The only difference is that there would
>> be an anonymous variant &_{...}.
>
> I do not try to dispute \foo and class="foo" as default behavior. I
> suggest to implement possibility to override default behavior of
> {text} to \bar{text} and text. The same is applicable
> for anonymous objects
>
> &_[:latex_command bar :html_element bar]{text}
Maxim, I insist that I follow the logic of the "large" special blocks.
Anyway, I think your example only makes sense in HTML, or at least I
can't make sense of it in LaTeX. Why would anyone want {text} to be
passed to LaTeX as \bar{text}, instead of just {text}? In HTML it
does seem sensible to me that someone would want to change the tags.
Maybe with a :html-tag, or something like that.
As for :latex-command, if I understand it correctly, I don't quite see
how useful this could be:
[:latex-command bar]{text} == LaTeX ==> \bar{text}
when it is simpler to put:
{text}
The same thing happens with the anonymous variant:
&_[:latex-command foo]{text} == LaTeX ==> \foo{text}
which is identical to putting {text}
The anonymous variant would be equivalent in LaTeX to a
\begingroup...\endgroup, or rather to {...}. One could add all the
commands one wants within the group simply with :prelatex:
&_[:prelatex \foo\bar\vaz\blah{}]{text}
==> {\foo\bar\vaz\blah{}text}
I'm not opposed to your ideas, I just can't find a use case for it. In
LaTeX, I mean. In the case of HTML I find it useful, indeed, to have
more control over the tags: , , etc.
In any case, I think that my implementation leaves open the possibility
of extending it with everything you mentioned, or anything else.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [proof of concept] inline language blocks
Max Nikulin writes:
> #+options: custom-object(:type la :latex_element foreignlanguage
> :latex_pre "{latin}")
mmm, I see it as not very flexible and perhaps too complicated for the user.
My idea with the concept of inline-special-block is that it is like the
inline version of its older brother. If something like
#+begin_foo
...
#+end_foo
produces things like
\begin{foo}
...
\end{foo}
or
...
the user should expect something like {...} to produce \foo{...} or
..., etc. The only difference is that there would
be an anonymous variant &_{...}.
The attributes syntax (in square brackets) adds verbosity, but I
understand that it is also very flexible and granular. It doesn't need
to be used always, but at least it's there when you need to use it.
Furthermore, the user can always define lists of attributes (styles or
aliases: I would have preferred the term "style", instead of "alias",
but I fear that it will be confused with the HTML attribute of the same
name). Furthermore, these lists of attributes can also be used in
combination with other single attributes, giving rise to a great
possibility of combinations. The fact that there are a number of
universal attributes such as :lang, :color, :smallcaps prevents the user
from having to figure out which code to use on each backend to produce
colored text, small caps or the correct language selector. ":lang ru",
for example, will always produce in LaTeX \foreignlanguage{russian}{}
(which, in addition, is a command shared by babel and polyglossia) and
in HTML lang="ru".
And ultimately you could also think about some kind of folding for the
attributes part.
I believe that this possible new element would solve the need for a
native, multipurpose inline text container with properties[1], which
until now could only be achieved through macros or links, with the
limitations of both elements.
Additionally, I think this approach is more flexible than having
specific purpose blocks (for languages, colors, etc.).
Of course, it would be best not to abuse the attributes. If in a
long document one needs to put a single sentence in red, I don't think
it is a verbosity problem to put something like &_[:color red]{lorem
ipsum dolor}. If you need to put a lot of sentences in red or any other
color, it may be a better idea to define some command in LaTeX
(\redtext), a class in HTML or a character style in odt. And then it
would be enough to use {lorem ipsum dolor}.
[1] Pandoc has the "bracketed spans". According to pandoc manual:
#+begin_quote
A bracketed sequence of inlines, as one would use to begin
a link, will be treated as a Span with attributes if it is followed
immediately by attributes:
[This is *some text*]{.class key="val"}
#+end_quote
Re: [proof of concept] inline language blocks
Max Nikulin writes:
> Juan Manuel your ":fr{}" and similar objects is a domain-specific
> language that is quite different from a generic element proposed by
> Samuel. Do you think it makes sense to modify your inline special
> block patch to allow creation of concise DSL?
>
> Juan Manuel Macías. [testing patch] inline-special-block with full
> implementation for LaTeX backend. Fri, 23 Feb 2024 23:50:52 +.
> https://list.orgmode.org/87ttlyloyr@posteo.net
>
> I mean {bonjour} defined using "#+options:" or some new keyword or
> a special block. A definition of "fr" may be (using a bit different
> names)
>
> :latex_element "foreignlanguage" :latex_prefix "french"
> :html_element "span" :html_attr (:lang "fr")
>
> {} is no heavier than :fr{}. The only drawback is necessity to
> define elements for each language used in the document. I do not
> think, even a dozen of declarations is a significant burden.
Hi, Maxim,
In the end I abandoned the concept of inline language block to the
detriment of the more general concept of inline special block (as,
rightly, proposed Ihor). I feel that at the beginning both concepts
overlapped. The patch you mention deals exclusively with the inline
special block concept, as well as the experimental branch that I hope to
publish shortly.
The syntax of my approach, summarized, would be:
-basic form: [optional attributes]{lorem ipsum dolor}
==> LaTeX \foo{lorem ipsum dolor} ; ==> HTML lorem
ipsum dolor
- anonymous variant: &_{lorem ipsum dolor}
Common to all backends (so far I have only implemented LaTeX and HTML)
are a series of universal attributes. At the moment I have thought about
the following: :lang, :smallcaps and :color. For example:
[:lang el :color blue :smallcaps t]{contents}
==> LaTeX:
{\scshape\color{blue}\foreignlanguage{greek}{\foo{contents}}}
==> HTML
contents
There is also the :html attribute and for LaTeX the :prelatex and
:postlatex attributes. Groups of attributes can also be defined, as if
they were styles, and combined with single attributes:
#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue
:prelatex "\\itshape " :html "style=\"font-style:italic;\""))
This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.
This is an example of Latin text with small caps: &_[@latin@ :smallcaps
t]{lorem ipsum dolor sit amet}.
==> LaTeX:
This is an example of Latin text: {\color{blue}\foreignlanguage{latin}{\itshape
lorem ipsum dolor sit amet}}.
This is an example of Latin text with small caps:
{\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit
amet}}
==> HTML:
This is an example of Latin text: lorem ipsum dolor sit amet.
This is an example of Latin text with small caps: lorem
ipsum dolor sit amet.
Re: A question about local/experimental branches
Hi, Bastien, Bastien Guerry writes: > Ihor Radchenko writes: > >> AFAIU, Juan does not have write access to savannah. >> Should we give it? Of course, if he is willing to use savannah. Any >> other public repo is also fine. > > Juan, let me know if you need access: > https://orgmode.org/worg/org-contribute.html#devs Thank you! I think for the moment I will use GitLab to publish my experimental branch, if it is not essential to do it in savannah (I am more used to gitlab). As soon as I publish it, I'll share the link. Best regards, Juan Manuel
Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix
Bastien writes: > Adding [BLOG] or [TIP] in the subject prefix allows for such messages > to be referenced on https://tracker.orgmode.org/news (along with [ANN] > messages). > > It will then be possible to include these posts in the orgmode.org > homepage, using e.g. https://tracker.orgmode.org/news.rss. > > This is experimental, let's see if this helps spread the word about > useful blogs. Great! Just one question: can articles be shared in languages other than English? In that case, would it be necessary to add some more prefixes, such as "Spanish", "French", "Italian", "Greek", etc.? (If I shared something in Spanish, I could translate the article in the body of the message). Best regards, Juan Manuel -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: A question about local/experimental branches
Ihor Radchenko writes: > P.S. Juan, I will need some time to review previous discussions on > inline special blocks before I can comment on your work in depth. No problem, Ihor. These days I had enough free time to develop my idea, translate it into code and get something usable from which it could be discussed. As I mentioned, the export to HTML and LaTeX is complete and works fine, but I'll probably stop there for a long time. I mean, I won't go any further and I will dedicate myself to continuing testing the code already written and fixing possible bugs. Partly because I don't have enough knowledge of odt to work on this backend, which would be the next step. Thanks for the info! -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
A question about local/experimental branches
Hi,
I've noticed that the code for my implementation of the new
'inline-special-block' experimental element is growing. In addition, I
introduce modifications and improvements daily. So I think it might be a
good idea to make my local branch public, in case someone wants to try
it or contribute to the project.
My question is if there is any set of good practices to do this, or is
it enough to publish the local branch 'as is'.
Currently I have completed, and are perfectly usable, the export to
LaTeX and HTML. I have also improved the syntax. Now, if aliases are
used for group optional attributes, it is not necessary to put :alias
foo, but @foo@. Example:
#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue
:prelatex "\\itshape " :html "style=\"font-style:italic;\""))
This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.
This is an example of Latin text with small caps: &_[@latin@ :smallcaps
t]{lorem ipsum dolor sit amet}.
LaTeX ==>
This is an example of Latin text:
{\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}.
This is an example of Latin text with small caps:
{\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit
amet}}
HTML ==>
This is an example of Latin text: lorem ipsum dolor sit amet.
This is an example of Latin text with small caps: lorem
ipsum dolor sit amet.
Related: https://list.orgmode.org/87ttlyloyr@posteo.net/
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[testing patch] inline-special-block with full implementation for LaTeX backend
This patch is for testing purposes only, although the implementation for
LaTeX backend is perfectly usable.
The basic syntax of the new element is:
{lorem ipsum dolor}
=> LaTeX: \foo{lorem ipsum dolor}
Nested elements are possible, as well as the inclusion of other elements
such as macros, links or emphasis marks.
The element also supports a list of optional arguments. For the LaTeX
backend there are two specific arguments: :prelatex and :postlatex.
Example:
[:prelatex [bar] :postlatex {baz}]{lorem ipsum dolor}
=> LaTeX: \foo[bar]{lorem ipsum dolor}{baz}
Additionally, there are a number of universal arguments that should be
equivalent between backends where it makes sense to use them (LaTeX,
HTML, odt...). At the moment you can use: :color, :lang and :smallcaps.
Example:
[:color red :smallcaps t :lang french :prelatex [bar] :postlatex
{baz}]{lorem ipsum dolor}
=> LaTeX: {\scshape{}\color{red}\foreignlanguage{french}{\foo[bar]{lorem ipsum
dolor}{baz}}}
The element also has an anonymous variant that only accepts universal
arguments. If set without arguments it simply returns the content
string. Example:
&_[:color blue :lang italian]{lorem ipsum dolor}
=> LaTeX: {\color{blue}\foreignlanguage{italian}{lorem ipsum dolor}}
We can define in the document a list of aliases that group several arguments:
#+options: inline-special-block-aliases:(("myalias" :color "magenta" :lang
"klingon") ("myalias2" :smallcaps t :color "blue" :prelatex "{2345}"))
&_[:alias myalias :smallcaps t]{lorem ipsum dolor}
=> LaTeX: {\scshape{}\color{magenta}\foreignlanguage{klingon}{lorem ipsum
dolor}}
[:alias myalias2]{lorem ipsum dolor}
=> LaTeX: {\scshape{}\color{blue}\foo{2345}{lorem ipsum dolor}}
There can only be one alias per element, but an alias can be combined
with other attributes. It is the closest thing to using styles,
and perhaps the most appropriate term would be ":style". But you can get
confused with the html "style" attribute.
Best regards,
Juan Manuel
>From d211bf601db0dd5c01a3edda74cd1b37f1f9448c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Wed, 21 Feb 2024 20:44:58 +0100
Subject: [PATCH] org-element.el: New element: Inline Special Block.
* lisp/ox-latex.el (org-latex-inline-special-block): A possible
function for the LaTeX backend.
* lisp/ox.el (org-export-read-inline-special-block-attributes): read
optional attributes.
* lisp/ox.el (org-export-inline-special-block-aliases): aliases for grouped attributes.
---
lisp/org-element.el | 55 -
lisp/ox-latex.el| 36 +
lisp/ox.el | 30 +
3 files changed, 120 insertions(+), 1 deletion(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6691ea44e..c430d934b 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -272,6 +272,8 @@ specially in `org-element--object-lex'.")
"\\|"))
;; Objects starting with "@": export snippets.
"@@"
+ ;; Objects starting with "&": inline-special-blocks.
+ "&"
;; Objects starting with "{": macro.
"{{{"
;; Objects starting with "<" : timestamp
@@ -313,7 +315,7 @@ specially in `org-element--object-lex'.")
"List of recursive element types aka Greater Elements.")
(defconst org-element-all-objects
- '(bold citation citation-reference code entity export-snippet
+ '(bold citation citation-reference code entity export-snippet inline-special-block
footnote-reference inline-babel-call inline-src-block italic line-break
latex-fragment link macro radio-target statistics-cookie strike-through
subscript superscript table-cell target timestamp underline verbatim)
@@ -440,6 +442,7 @@ Don't modify it, set `org-element-affiliated-keywords' instead.")
;; Ignore inline babel call and inline source block as formulas
;; are possible. Also ignore line breaks and statistics
;; cookies.
+ (inline-special-block ,@standard-set)
(table-cell citation export-snippet footnote-reference link macro
radio-target target timestamp ,@minimal-set)
(table-row table-cell)
@@ -3535,6 +3538,54 @@ Assume point is at the beginning of the entity."
(org-element-property :name entity)
(when (org-element-property :use-brackets-p entity) "{}")))
+ inline special block
+
+(defun org-element-inline-special-block-parser ()
+ "Parse inline special block at point.
+
+When at an inline special block, return a new syntax node of
+`inline-special-block' type containing `:begin', `:end', `:type',
+`:parameters', `:contents-begin', `:contents-end' and
+`:post-blank' as properties. Otherwise, return nil.
+
+Assum
Re: [proof of concept] inline-special-block
Juan Manuel Macías writes:
> Regarding the "optional parameters", there is nothing defined, although
> I think they should be adapted to each backend. A possible use that
> occurs to me:
>
> [prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]{blah blah}
>
> This should produce in LaTeX:
>
> \foo[lorem]{blah blah}{ipsum}
>
> and in HTML:
>
> blah blah
Just to add some more ideas about parameters, I can also think of an
"anonymous" variant that only supports "universal" arguments, independent of
the backend and previously defined (and extensible by the user). For
example:
&_[:color red :smallcaps t :lang it :size small]{Lorem ipsum dolor}
Aliases could also be defined for a set of arguments:
#+OPTIONS: inlineblocks:(("myblock" :smallcaps t :color "red" :lang "fr"))
&_[:myblock t]{Lorem ipsum dolor} etc.
==> latex: {\color{red}\scshape\foreignlanguage{french}{Lorem ipsum dolor}}
Universal arguments can also be added to a normal block along with each
backend's own arguments:
[:color red :prelatex [bar]]{lorem ipsum dolor}
==> latex: {\color{red}\foo[bar]{lorem ipsum dolor}}
and, of course, aliases could be combined with single arguments:
[:myblock t :prelatex [bar]]{lorem ipsum dolor}
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [proof of concept] inline-special-block
Juan Manuel Macías writes:
> Syntax:
>
> &[optional parameters]{contents}
Correction:
[optional parameters]{contents}
Re: [proof of concept] inline language blocks
Samuel Wales writes:
> for language feature, there are various options here which range from e.g.
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
>
To expand a little more... Another problem I see in your example is
nesting. In my proposal, the blocks can be nested:
:fr{text in French and :it{text in Italian}}
But I would find this difficult to read:
$[lang :fr "text in French and $[lang :it "text in italian"]"]
On the other hand, the structure that I have chosen is in part inspired
by the inline code block, which is the only case of "inline block" that
we have in Org.
Best regards,
Juan Manuel
Re: [proof of concept] inline language blocks
Samuel Wales writes:
> for language feature, there are various options here which range from e.g.
>
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
Thanks for your interesting comment. However, your example still seems
too verbose to me. There are two elements that, in my opinion, get in
the way: 'lang' and "bonjour" quotes. Imagine something like this for
emphasis (mutatis mutandis):
$[emphasis :italic "text in italic"]
instead of
/text in italic/.
That simplicity is what I intend to look for with this type of elements
inside the paragraph.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
[proof of concept] inline-special-block (was: [proof of concept] inline language blocks)
I am attaching a patch in case anyone wants to try this proposal. A
function for ox-latex is included.
Syntax:
&[optional parameters]{contents}
With this patch, something like {lorem ipsum dolor} is exported to
LaTeX as \foo{lorem ipsum dolor}.
Blocks can be nested, e.g.: {lorem ipsum {dolor}}.
Regarding the "optional parameters", there is nothing defined, although
I think they should be adapted to each backend. A possible use that
occurs to me:
[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]{blah blah}
This should produce in LaTeX:
\foo[lorem]{blah blah}{ipsum}
and in HTML:
blah blah
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From 587e77feb1c4e6881d527d1fd3a6e541efb596d4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Wed, 21 Feb 2024 20:44:58 +0100
Subject: [PATCH] org-element.el: New element: Inline Special Block (proof of
concept).
* lisp/ox-latex.el (org-latex-inline-special-block): A possible
function for the LaTeX backend.
---
lisp/org-element.el | 55 -
lisp/ox-latex.el| 10 +
2 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6691ea44e..2f9436df2 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -272,6 +272,8 @@ specially in `org-element--object-lex'.")
"\\|"))
;; Objects starting with "@": export snippets.
"@@"
+ ;; Objects starting with "&": inline-special-blocks.
+ "&"
;; Objects starting with "{": macro.
"{{{"
;; Objects starting with "<" : timestamp
@@ -313,7 +315,7 @@ specially in `org-element--object-lex'.")
"List of recursive element types aka Greater Elements.")
(defconst org-element-all-objects
- '(bold citation citation-reference code entity export-snippet
+ '(bold citation citation-reference code entity export-snippet inline-special-block
footnote-reference inline-babel-call inline-src-block italic line-break
latex-fragment link macro radio-target statistics-cookie strike-through
subscript superscript table-cell target timestamp underline verbatim)
@@ -440,6 +442,7 @@ Don't modify it, set `org-element-affiliated-keywords' instead.")
;; Ignore inline babel call and inline source block as formulas
;; are possible. Also ignore line breaks and statistics
;; cookies.
+ (inline-special-block ,@standard-set)
(table-cell citation export-snippet footnote-reference link macro
radio-target target timestamp ,@minimal-set)
(table-row table-cell)
@@ -3535,6 +3538,54 @@ Assume point is at the beginning of the entity."
(org-element-property :name entity)
(when (org-element-property :use-brackets-p entity) "{}")))
+ inline special block
+
+(defun org-element-inline-special-block-parser ()
+ "Parse inline special block at point.
+
+When at an inline special block, return a new syntax node of
+`inline-special-block' type containing `:begin', `:end', `:type',
+`:parameters', `:contents-begin', `:contents-end' and
+`:post-blank' as properties. Otherwise, return nil.
+
+Assume point is at the beginning of the block."
+ (save-excursion
+(when (looking-at "&\\([A-Za-z]+\\)[{[]")
+ (goto-char (- (match-end 0) 1))
+ (let* ((begin (match-beginning 0))
+ (parameters
+ (let ((p (org-element--parse-paired-brackets ?\[)))
+(and (org-string-nw-p p)
+ (replace-regexp-in-string "\n[ \t]*" " " (org-trim p)
+ (contents-begin (when (looking-at-p "{") (+ (point) 1)))
+ (type (org-element--get-cached-string
+(match-string-no-properties 1)))
+ (contents-end
+ (progn
+(goto-char (- contents-begin 1))
+(org-element--parse-paired-brackets ?\{)
+(- (point) 1)))
+ (post-blank (skip-chars-forward " \t"))
+ (end (point)))
+(when contents-end
+ (org-element-create
+ 'inline-special-block
+ (list :type type
+ :parameters parameters
+ :contents-begin contents-begin
+ :contents-end contents-end
+ :begin begin
+ :end end
+ :post-blank post-blank)))
+
+(defun org-element-inline-special-block-interpreter (inline-special-block contents)
+ "Interpret INLINE SPECIAL BLOCK object as Org syntax."
+ (let ((type (org-element-property :type inline-special-block))
+(opts (org-element-property :parameters
Re: [proof of concept] inline language blocks
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Ihor Radchenko writes:
>>> This is a good idea, although it would be better to make this new markup
>>> element within the framework of more general inline special block we
>>> discussed in the past:
>>> https://list.orgmode.org/orgmode/87a6b8pbhg@posteo.net/
>>
>> Fun fact: the local branch is called inline-special-block, because I
>> originally had that idea in mind when I created it. Then, halfway
>> through, I doubted whether it wouldn't be better to have a specific
>> inline language selector, whose use would be as direct as an emphasis
>> mark. So in the branch there is also a "proto"-inline-special-block with
>> similar syntax: {}.
>>
>> I opted for the -language-block version because, as I said, its use is
>> very 'direct' and covers a common need to segment multilingual text
>> within the paragraph.
>
> My main point is that we should use the same syntax with inline special
> blocks. Similar to how #+begin_verse uses the same syntax as special
> blocks.
>
> We need to finalize inline special block syntax first, and then talk
> about special cases like inline language markup you propose.
As I already said, in my local branch I have both elements created,
based on the same syntax:
- language block: :lang{text}
- special block {text}
the latter would be exported, for example, to html as text or to LaTeX as \type{text}
I like the syntax because it is minimalist and not verbose at all. That
could serve as a basis (at least it is good to have a starting point,
because otherwise everything will be diluted in discussions). Then we
can start thinking about whether to add options and how to add them.
>> I think at the time we also discussed whether or not it would be a good
>> idea to provide the inline special blocks with options and attributes,
>> like their older brothers. And how to do it. My biggest concern here is
>> the (let's say) latexification of the paragraph. I mean, one of the
>> great things about Org versus heavier markup like LaTeX is that when org
>> wants to be verbose it uses dedicated lines, but usually keeps the
>> paragraphs clean and readable. I think that any element inside the
>> paragraph should tend to be as "transparent" as simple emphasis marks.
>>
>> I remember that there was also discussion about puting the options
>> outside the paragraph, using some type of identifier. It doesn't seem
>> like a bad idea to me, but I think it adds an extra complication for the
>> user. It would be very tedious for me to write like this (even more
>> tedious than writing in LaTeX).
>
> I still believe that we should /allow/ options inside inline block-type
> markup. This is often necessary in practice. For example, I recommend
> studying
> https://en.wikipedia.org/wiki/Help:Wikitext#Templates_and_transcluding_pages
> and how they had to use ugly |... extensions to provide options.
>
> But it does not mean that users /have to/ use these options. In fact, we
> might design the inline language blocks to ignore options.
The wiki language is for a specific purpose, and I wouldn't consider it
a lightweight markup language, although it is certainly less thick than
html.
Actually I'm just expressing my concerns and doubts, I'm not objecting
to anything. I remember reading in the pandoc issues, a long time ago,
similar discussions every time they talked about extending the markup. I
don't know if it's a good idea to stick to a certain point to preserve
the nature of a lightweight markup language and accept certain intrinsic
limitations instead of providing options that probably have very little
use or can be resolved by some export filter. I don't have a definite
opinion, I'm just raising my doubts. Although I really value simplicity
and minimalism.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [proof of concept] inline language blocks
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> I'm dedicating a local branch to developing this proof of concept and
>> testing it in my workflow, so far with good results. The basic idea is
>> to provide Org with multilingual features and various methods for
>> selecting languages.
>>
>> The inline-language-block is intended for small segments of text in a
>> language other than the main language. They can span several lines but
>> not more than a paragraph. They can be used for in-line textual quotes,
>> glosses, etc. They are constructions equivalent to, for example, LaTeX
>> \foreignlanguage{french}{text} or HTML text.
>>
>> I have thought of a syntax that is as least intrusive as possible, so as
>> not to make reading uncomfortable. I have tried the following:
>>
>> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
>>
>> You can also use a literal term instead of a language code:
>>
>> :klingon!{some text in Klingon}
>>
>> The blocks can be nested:
>>
>> :klingon!{Some text in Klingon with :it{some text in Italian}}
>>
>> And they may include other elements:
>>
>> :el{Some text in Greek with a {{{macro}}} and a [[link]]}
>
> This is a good idea, although it would be better to make this new markup
> element within the framework of more general inline special block we
> discussed in the past:
> https://list.orgmode.org/orgmode/87a6b8pbhg@posteo.net/
Fun fact: the local branch is called inline-special-block, because I
originally had that idea in mind when I created it. Then, halfway
through, I doubted whether it wouldn't be better to have a specific
inline language selector, whose use would be as direct as an emphasis
mark. So in the branch there is also a "proto"-inline-special-block with
similar syntax: {}.
I opted for the -language-block version because, as I said, its use is
very 'direct' and covers a common need to segment multilingual text
within the paragraph.
I think at the time we also discussed whether or not it would be a good
idea to provide the inline special blocks with options and attributes,
like their older brothers. And how to do it. My biggest concern here is
the (let's say) latexification of the paragraph. I mean, one of the
great things about Org versus heavier markup like LaTeX is that when org
wants to be verbose it uses dedicated lines, but usually keeps the
paragraphs clean and readable. I think that any element inside the
paragraph should tend to be as "transparent" as simple emphasis marks.
I remember that there was also discussion about puting the options
outside the paragraph, using some type of identifier. It doesn't seem
like a bad idea to me, but I think it adds an extra complication for the
user. It would be very tedious for me to write like this (even more
tedious than writing in LaTeX).
Best regards,
--
Juan Manuel Macías
Re: [proof of concept] inline language blocks
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> We need to finalize inline special block syntax first, and then talk
>>> about special cases like inline language markup you propose.
>>
>> As I already said, in my local branch I have both elements created,
>> based on the same syntax:
>>
>> - language block: :lang{text}
>>
>> - special block {text}
>>
>> the latter would be exported, for example, to html as > class="type">text or to LaTeX as \type{text}
>>
>> I like the syntax because it is minimalist and not verbose at all. That
>> could serve as a basis (at least it is good to have a starting point,
>> because otherwise everything will be diluted in discussions). Then we
>> can start thinking about whether to add options and how to add them.
>
> We do not need to design the inline special block markup fully to
> introduce it. However, we do need to make sure that whatever simple
> version of inline markup we introduce does not prevent further planned
> extensions.
My proposed syntax could be:
[options]{content}
> My main concern is the possibility to introduce multi-argument markup.
> Like @abbrev{EA}{example abbreviation}. This will be necessary to
> achieve parity with Texinfo markup.
> However, it is not yet clear about the best syntax to pass multiple
> arguments.
I imagine multiple arguments would depend on each backend, right?
Because I don't quite see much sense in html, for example. However, it
occurs to me to reuse content, and add some separator character:
[options]{arg1::arg2::etc}
or better:
[options and aditional args]{content}
to maintain a certain parallelism with the large blocks.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
[proof of concept] inline language blocks
Hi,
I'm dedicating a local branch to developing this proof of concept and
testing it in my workflow, so far with good results. The basic idea is
to provide Org with multilingual features and various methods for
selecting languages.
The inline-language-block is intended for small segments of text in a
language other than the main language. They can span several lines but
not more than a paragraph. They can be used for in-line textual quotes,
glosses, etc. They are constructions equivalent to, for example, LaTeX
\foreignlanguage{french}{text} or HTML text.
I have thought of a syntax that is as least intrusive as possible, so as
not to make reading uncomfortable. I have tried the following:
:fr{some text in French} :it{some text in Italian} :la{some text in Latin}
You can also use a literal term instead of a language code:
:klingon!{some text in Klingon}
The blocks can be nested:
:klingon!{Some text in Klingon with :it{some text in Italian}}
And they may include other elements:
:el{Some text in Greek with a {{{macro}}} and a [[link]]}
To this end, I have defined the following element:
#+begin_src emacs-lisp
(defun org-element-inline-language-block-parser ()
"Parse inline language block at point.
When at an inline language block, return a new syntax node of
`inline-language-block' type containing `:begin', `:end',
`:type', `:contents-begin', `:contents-end' and `:post-blank' as
properties. Otherwise, return nil.
Assume point is at the beginning of the block."
(save-excursion
(when (looking-at ":\\([A-Za-z!]+\\){")
(goto-char (match-end 0))
(let* ((begin (match-beginning 0))
(contents-begin (match-end 0))
(type (org-element--get-cached-string
(match-string-no-properties 1)))
(contents-end
(progn
(goto-char (- contents-begin 1))
(org-element--parse-paired-brackets ?\{)
(- (point) 1)))
(post-blank (skip-chars-forward " \t"))
(end (point)))
(when contents-end
(org-element-create
'inline-language-block
(list :type type
:contents-begin contents-begin
:contents-end contents-end
:begin begin
:end end
:post-blank post-blank)))
(defun org-element-inline-language-block-interpreter (inline-language-block
contents)
"Interpret INLINE LANGUAGE BLOCK object as Org syntax."
(format ":%s{%s}"
(org-element-property :type inline-language-block)
contents))
#+end_src
And, for now, this function for ox-latex:
#+begin_src emacs-lisp
(defun org-latex-inline-language-block (inline-language-block contents info)
"Transcode an INLINE LANGUAGE BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
(let ((type (org-element-property :type inline-language-block)))
(if (string-match-p "!" type)
(format "\\foreignlanguage{%s}{%s}"
(replace-regexp-in-string "!" "" type)
contents)
(let* ((plist (cdr
(assoc type 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))
(lang (or language language-ini-only language-ini-alt)))
(format "\\foreignlanguage{%s}{%s}" lang contents)
#+end_src
Opinions, suggestions, feedback, ideas?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: set italian language in LaTeX export
Luca Ferrari writes:
>> #+language:it
>> #+LaTeX_Header: \usepackage[AUTO]{babel}
>>
>
> Thanks, this solved the problem. Out of curiosity, why is not org-mode
> adding it automatically whenever a #+language setting is present?
> I'm just curious because it seems that, as an example, open-office
> exporting understands the language.
Hi, Luca. You may be interested in taking a look at this thread, where
this problem and other related issues such as fallback fonts in LaTeX
export are discussed:
https://list.orgmode.org/?t=20230830082719
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [patch] Add two new header args to LaTeX block
Ihor Radchenko writes: > Juan Manuel Macías writes: > >>> I'd prefer to refactor `org-babel-execute:latex' first, before adding >>> new header arguments. >> >> org-create-formula-image inserts LaTeX code: > > `org-create-formula-image' will be obsoleted after Timothy merges his > latex preview branch. If the new implementation turns out to be not > flexible enough, we can always refactor it further to meet ob-latex > needs. In that case, I think this patch could be considered canceled. -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: set italian language in LaTeX export
Luca Ferrari writes:
> #+language: it
>
> and I correctly got in the LaTeX buffer something like:
>
> pdflang={Italian}}
>
> but not something like:
>
> \usepackage[italian]{babel}
You must load the babel package with the AUTO option:
#+language:it
#+LaTeX_Header: \usepackage[AUTO]{babel}
(see 'LaTeX header and sectioning structure' in the Org Manual)
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [patch] Add two new header args to LaTeX block
Ihor Radchenko writes:
>> In any case, if the org-create-formula-image method is going to stay, I
>> think it is fine as it is (except for extending the allowed file formats
>> to more extensions, and not only .png). I also believe that the :process
>> argument is sufficient for the user to control the value of
>> org-latex-pdf-process or org-preview-latex-default-process, as
>> appropriate.
>
> My concern about your patch is that it creates even more divergence
> between different branches of code in `org-babel-execute:latex'.
> With the new proposed features only available to some code branches,
> `org-babel-execute:latex' will just become more messy and harder to
> maintain.
>
> I'd prefer to refactor `org-babel-execute:latex' first, before adding
> new header arguments.
org-create-formula-image inserts LaTeX code:
...
(with-temp-file texfile
(insert latex-header)
(insert "\n\\begin{document}\n"
"\\definecolor{fg}{rgb}{" fg "}%\n"
(if bg
(concat "\\definecolor{bg}{rgb}{" bg "}%\n"
"\n\\pagecolor{bg}%\n")
"")
"\n{\\color{fg}\n"
string
"\n}\n"
"\n\\end{document}\n"))
...
that, /in principle/, would make it incompatible with the :standalone
argument (in my patch), which allows writing all LaTeX code from scratch
in the block content.
Anyway, it is true that org-babel-execute:latex has grown in a somewhat
irregular way. For example, I don't quite understand why the simple
output to PDF and the conversion to an image with :imagemagick live in
the same conditional:
(or (string= "pdf" extension) imagemagick)
I would propose three main branches in this function:
- A PDF branch, using org-format-latex-header with its valid options,
and other sub-branches with conversion from the PDF, for example, the
use of :imagemagick. Or you could even think of any possible
conversion process using a hypothetical :pdf-postprocess
- A branch for orf-create-formula-image
- a third branch to export to html, with org-babel-latex-htlatex.
Having three clearly differentiated branches would make the code easier
to maintain.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: Exporting multiple #+AUTHOR keywords
ypuntot writes: > Is it related with AUTHOR property? > I am starting to add these properties to every book, and chapter of > the book, that I study. I hope this doesn't lead to a suboptimal > workflow. > > Doesn't this work? > > :PROPERTIES: > :AUTHOR: García-Ael, Cristina and Pérez-Garín, Daniel and Recio > Saboya, Patricia > :BTYPE:incollection > :BOOKTITLE: Psicología de los Grupos > :TITLE:Métodos y Técnicas de Investigación en Psicología de > los Grupos. > > :PUBLISHER: UNED > > :ADDRESS: C/ Bravo Murillo, 38; 28015; Madrid > :INSTITUTION: UNED > :YEAR: 2017 > :CHAPTER: 2 > :PAGES:49-83 > :END: What we are dealing with here is the keyword #+AUTHOR or the EXPORT_AUTHOR property (when exporting a subtree), that is, the author of the document (see 'Export settings' in the Org Manual), not the AUTHOR property of org-ref. Your workflow is correct.
Re: Retaking AUTO for \usepackage{fontenc}
Ihor Radchenko writes: > Juan Manuel Macías writes: > >> Pedro Andres Aranda Gutierrez writes: >> >>> neither do I, This is why I'm asking for people to tell me what they >>> use ;-) >> >> The babel ini files (why hadn't I thought of this before :-): look in the >> babel ini files: > > May it be that babel automatically loads fontenc with appropriate parameters? AFAIK, I'm afraid it's not possible. What is possible is to be able to select a language in the middle of the document, without declaring it before. But you need to load fontenc and the appropriate fontencodings. According to the babel manual (p. 8), this functionality is only limited to Latin, Cyrillic, Greek, Arabic, Hebrew, Cherokee, Armenian, and Georgian. Best regards, Juan Manuel -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: [patch] Add two new header args to LaTeX block
Ihor Radchenko writes: > Juan Manuel Macías writes: > >>> Moreover, it would be nice to unify handling .png and imagemagick >>> branches of the code. >> >> I agree. In any case, I still think that the coexistence of two methods >> to convert to images, when one of the methods has a scheme so different >> from the rest, becomes difficult: for the user as well as for >> maintaining the code. >> >> The first solution that occurs to me (I'm afraid it's too radical) is to >> leave only the :imagemagick method, and maintain the possibility of >> using the other one through a variable. Something like >> org-babel-latex-default-image-conversion-method or something similar. >> But I suppose this could cause unwanted inconveniences. We should see >> what more users think. > > I am not sure. > Conceptually, .png method is more flexible than imagemagick - it uses > `org-create-formula-image' that is handling (1) preamble; (2) conversion > not only to png but to svg and other arbitrary formats. > ob-latex is duplicating org-create-formula-image code, layering custom > latex preamble and more commands on top. > So, ideally, I'd prefer to obsolete the custom code in ob-latex and make > use of `org-create-formula-image', possibly extending it to fit ob-latex > needs. It is true that the "org-create-formula-image" method is much more complete. But, IMHO, I think it's a method focused on the buffer (rather than the block) or previewing LaTeX code in the buffer. In the case of the LaTeX block, I think the :imagemagick method is simpler. It depends on two simple processes: imagemagick and org-latex-pdf-process and parameters such as the width or height of the generated image, the density in dpi, etc. can be easily applied, via arguments. In the case of the other method, in addition to the value of org-preview-latex-default-process, there is that of org-format-latex-options. There are, in short, many parameters that are perfect for a file or an Emacs session but for a simple block I find overhelming. In any case, if the org-create-formula-image method is going to stay, I think it is fine as it is (except for extending the allowed file formats to more extensions, and not only .png). I also believe that the :process argument is sufficient for the user to control the value of org-latex-pdf-process or org-preview-latex-default-process, as appropriate. Best regards, Juan Manuel -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: Retaking AUTO for \usepackage{fontenc}
Pedro Andres Aranda Gutierrez writes: > neither do I, This is why I'm asking for people to tell me what they > use ;-) The babel ini files (why hadn't I thought of this before :-): look in the babel ini files: /tex/generic/babel/locale/ There you have all the information by language. For example, in babel-fr.ini: 8<-- ; This file is part of babel. For further details see: ; https://www.ctan.org/pkg/babel ; Data has been collected mainly from the following sources: ; * babel language styles (license LPPL): ; https://www.ctan.org/pkg/babel-contrib ; * Common Locale Data Repository (license Unicode): ; http://cldr.unicode.org/ ; http://unicode.org/copyright.html [identification] charset = utf8 version = 0.981 date = 2022-05-14 name.local = français name.english = French name.babel = french name.polyglossia = french tag.bcp47 = fr language.tag.bcp47 = fr tag.bcp47.likely = fr-Latn-FR tag.opentype = FRA script.name = Latin script.tag.bcp47 = Latn script.tag.opentype = latn level = 1 encodings = T1 OT1 LY1 <== derivate = no . -->8 -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: [patch] ox.latex.el: Add missing character warnings
Ihor Radchenko writes:
> Probably something to do with my Texlive technically having Chinese
> support.
>
> I am getting
>
> ! Package inputenc Error: Unicode character 你 (U+4F60)
> (inputenc)not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type H for immediate help.
> ...
>
> l.28 Hello. 你
>好.
>
> ! Package inputenc Error: Unicode character 好 (U+597D)
> (inputenc)not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type H for immediate help.
> ...
>
> l.28 Hello. 你好
I have fixed the org-latex-known-warnings regexp in the attached patch.
I think it should work fine now...
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From 742d67f2e8d4f1896d89f7543948facd65687ffe Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Tue, 13 Feb 2024 16:56:23 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..2fdc2afe8 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+("^!.+Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
@@ -4435,7 +4437,11 @@ encountered or nil if there was none."
(save-excursion
(goto-char (point-max))
(when (re-search-backward "^[ \t]*This is .*?TeX.*?Version" nil t)
- (if (re-search-forward "^!" nil t) 'error
+ (if (and
+ (re-search-forward "^!\\(.+\\)" nil t)
+ ;; This error is passed as missing character warning
+ (not (string-match-p "Unicode character" (match-string 1
+'error
(let ((case-fold-search t)
(warnings ""))
(dolist (warning org-latex-known-warnings)
--
2.43.1
Re: Retaking AUTO for \usepackage{fontenc}
Pedro Andres Aranda Gutierrez writes: > Hi, > > Next step, @all, please help me filling up the list of codings vs. > languages. I currently am somehow confident of the following: > > greek -> LGR > russian -> T2A The information is in the encguide PDF (you can run texdoc fontenc or texdoc encguide). You should look especially at section 2.3 256 glyph encodings. I don't know if some languages require more than one encoding. Cyrillic appears to be T2A, T2B and T2C. T4 is for "The African Latin fonts contain in their lower half (0–127) the same characters as the European Latin (T1-encoded) Fonts, while in their upper half (128–255) they contain letters and symbols for African languages that use extended Latin alphabets." etc. But I can't find a simpler list anywhere. Best regards, Juan Manuel -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: [patch] ox.latex.el: Add missing character warnings
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> When I try the patch with a simple file like
>>>
>>> Hello. 你好。
>>>
>>> I do not see any warnings or errors indicated.
>>
>> How weird... And don't they at least appear in the *Messages* buffer?
>> With your example, they appear to me with pdfLaTeX, lualatex and XelaTeX
>> (I have used the default value of org-latex-pdf-process):
>
> I did
>
> 1. Install your patch on top of the latest main
> 2. make repro
> 3. Open /tmp/1.org and enter
> Hello. 你好.
> 4. C-c C-e l o
>
> In *Messages* I see
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Org mode version 9.7-pre (release_9.6.18-1196-g8bd0dd @
> /home/yantar92/Git/org-mode/lisp/)
> (New file)
> Making completion list... [3 times]
> Loading quail/PY (native compiled elisp)...done
> Saving file /tmp/1.org...
> Wrote /tmp/1.org
> Wrote /tmp/1.tex
> Processing LaTeX file 1.tex...
> PDF file produced.
> Running xdg-open /tmp/1.pdf...done
>
> My `org-latex-pdf-process' is
> ("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
> since I have latexmk installed.
I have done the same, on a clean Emacs init. Warning appears.
And in *Messages*:
PDF file produced with warnings: [unicode character(s) not set up for use with
pdflatex. You can run lualatex or xelatex instead]
In *Org PDF LaTeX Output*:
! LaTeX Error: Unicode character 你 (U+4F60)
not set up for use with LaTeX.
(this error is the one that passes as a warning in my patch when
compiled with pdfLaTeX).
Re: [patch] ox.latex.el: Add missing character warnings
Sorry, the previous patch was incomplete. The attached patch is correct.
Best regards,
Juan Manuel
Juan Manuel Macías writes:
> Rationale for the attached patch: It seems that a common problem that
> users have with exporting to LaTeX is unicode characters that cannot be
> represented in pdfLaTeX or LuaLaTeX/XelaTeX. In the Unicode TeX engines
> the warning is insidious, since the missing character warning is not
> preceded by a 'warning' string.
>
> Naturally, the added Org warnings do not solve the problem, but at least
> they give some clues on how to properly adjust the document.
>From 19fb7b81d6ce3a657c86497707f590063b27683c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Mon, 12 Feb 2024 16:10:28 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..da4792c04 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+("LaTeX Error: Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
@@ -4435,7 +4437,11 @@ encountered or nil if there was none."
(save-excursion
(goto-char (point-max))
(when (re-search-backward "^[ \t]*This is .*?TeX.*?Version" nil t)
- (if (re-search-forward "^!" nil t) 'error
+ (if (and
+ (re-search-forward "^!\\(.+\\)" nil t)
+ ;; This error is passed as missing character warning
+ (not (string-match-p "Unicode character" (match-string 1
+'error
(let ((case-fold-search t)
(warnings ""))
(dolist (warning org-latex-known-warnings)
--
2.43.1
[patch] ox.latex.el: Add missing character warnings
Rationale for the attached patch: It seems that a common problem that
users have with exporting to LaTeX is unicode characters that cannot be
represented in pdfLaTeX or LuaLaTeX/XelaTeX. In the Unicode TeX engines
the warning is insidious, since the missing character warning is not
preceded by a 'warning' string.
Naturally, the added Org warnings do not solve the problem, but at least
they give some clues on how to properly adjust the document.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From 03c4c94c22f720e38f1ffb180aaa8a23abd90406 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Mon, 12 Feb 2024 16:10:28 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings
* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
lisp/ox-latex.el | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..80d992160 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
("Underfull \\hbox" . "[underfull hbox]")
("Overfull \\hbox" . "[overfull hbox]")
("Citation.*?undefined" . "[undefined citation]")
+("LaTeX Error: Unicode character" . "[character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
("Undefined control sequence" . "[undefined control sequence]"))
"Alist of regular expressions and associated messages for the user.
The regular expressions are used to find possible warnings in the
--
2.43.1
Re: [patch] Add two new header args to LaTeX block
Ihor Radchenko writes:
> Got it.
> Although, it is confusing to have different formats of :process
> value depending on :file extension.
Indeed. For that reason I changed the original name I gave from
":pdf-process" to simply ":process". IMHO this function has a tremendous
problem: two methods coexist to convert a PDF compiled with LaTeX to an
image: the method with :imagemagick and the method without :imagemagick,
although this can also use imagemagick, which in itself is a first mess.
I don't know if this state of affairs is clear to the user...
The method without :imagemagick, furthermore, is the only one that
depends on a different process (leaving aside the case of conversion to
html, where another process is used).
The method with :imagemagick is, like the rest, more "transparent" (it is
the one I use, and I think many users prefer it):
TeX file --> compilation --> PDF --> conversion --> image file
The method without :imagemagick, which depends on the value of
org-preview-latex-default-process could be schematized like this:
TeX file --> {compilation + PDF + conversion + params.} --> image file
That is, the compilation and conversion processes along with the
parameters are included in the same pack.
> It would make things easier for users if
> :results file :file foo.png :process '("lualatex -interaction nonstopmode
> -output-directory %o %f")
>
> worked as expected, automatically overriding :latex-compiler value in
> let-bound `org-preview-latex-process-alist'.
I think that can cause certain drawbacks. Suppose a user has dvipng
as the value of org-preview-latex-default-process. If he/she puts
":process '(luatex etc ...)"
he/she will not be able to create the image because dvipng has the
value of ":image-converter" as the dvipng program, which, to put it
briefly and without going into details, would not work well with LuaTeX.
It is the problem of the same pack that I mentioned before. That's why I
think the lesser evil would be to allow the user to control the
necessary parameters at will, if the output file is an image file and
":imagemagick" is not present. Anyway, see what I say below.
>> Anyway, I don't understand why that feature option (convert to an image
>> without :imagemagick method) is limited to .png, when other graphic files are
>> possible. I can define something like this:
>>
>> (setq org-preview-latex-default-process
>> '(my-process
>> :programs ("lualatex" "convert")
>> :description "pdf > jpg"
>> :image-input-type "pdf"
>> :image-output-type "jpg"
>> :latex-compiler ("lualatex -interaction nonstopmode -output-directory
>> %o %f")
>> :image-converter ("convert -density %D -trim -antialias %f -quality 100
>> %O")))
>>
>> But if I put :file foo.jpg nothing happens. Maybe that part should be
>> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..."
>> out-file)?
>
> I agree that it should be corrected.
> Moreover, it would be nice to unify handling .png and imagemagick
> branches of the code.
I agree. In any case, I still think that the coexistence of two methods
to convert to images, when one of the methods has a scheme so different
from the rest, becomes difficult: for the user as well as for
maintaining the code.
The first solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
But I suppose this could cause unwanted inconveniences. We should see
what more users think.
Another possibility is to clarify the names a little more (for the user):
:image-conv [possible values: default, imagemagick (= :imagemagick yes)]
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
Pedro Andres Aranda Gutierrez writes: > I agree it does not take advantage of the AUTO facility here, but I > nevertheless think it would > be interesting to show people how to do this. Until we expand the AUTO > facility to cope with > all quirks of multi-language in pdflatex (lualatex and xetex are a > different pair of shoes), a quick > and dirty alternative may be helpful for people. The introductory text > could be Pedro, the only problem I see with that is that it is an example of LaTeX rather than Org. The only Org part here is #+LaTeX_header, and in the entire section it's already made clear enough what it's used for. Perhaps a brief reminder (the AUTO facility of the previous examples is very limited) could be added first, and that if the users want to obtain more complex, or more specific results (like the case you exemplify for pdfLaTeX) they must put explicit LaTeX code, using LaTeX_header. And then your example would come, but emphasizing that the LaTeX documentation must be consulted. wdyt? My point is that if we abuse examples of this type (at the expense of "#+latex_header:something"), or "how is this done in LaTeX?", in the end a LaTeX manual is made instead of Org. I'm glad you enjoyed the jump to LuaTeX. :-) Best regards, Juan Manuel -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: [patch] Add two new header args to LaTeX block
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> I am attaching a new patch with this idea incorporated. I have also
>> changed the name from full-to-pdf to standalone.
>>
>> + (process (cdr (assq :process params)))
>> + (org-preview-latex-default-process (if (and process
>> + (string-suffix-p
>> ".png" out-file)
>> + (not imagemagick))
>
> Considering that 'imagemagick is one of the variants in
> `org-preview-latex-process-alist', it might be reasonable to allow
> :process imagemagick == :imagemagick yes
I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
Instead, «:process 'imagemagick» depends on:
(imagemagick :programs
("latex" "convert")
:description "pdf > png"
:message "you need to install the programs: latex and
imagemagick."
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("pdflatex -interaction nonstopmode
-output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f
-quality 100 %O"))
Also, one may want to put «:imagemagick yes» and compile the PDF
with another compiler or with a custom script:
:imagemagick yes :process '(...)
> Also, it feels incomplete to be able to define latex command for :file
> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
The ".png" method without ":imagemagick" does not depend on
'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
depends on the value of 'org-preview-latex-default-process':
...
((and (string-suffix-p ".png" out-file) (not imagemagick))
(let ((org-format-latex-header
(concat org-format-latex-header "\n"
(mapconcat #'identity headers "\n"
(org-create-formula-image
body out-file org-format-latex-options in-buffer)))
...
If you put :file foo.png without :imagemagick, and want to control the
process or change the compiler, you can do it with:
:process '(foo :latex-compiler ("some LaTeX command"))
since this syntax is what org-preview-latex-default-process expects.
In all other cases, including :imagemagick, the compilation process
depends on the value of org-latex-pdf-process.
Anyway, I don't understand why that feature option (convert to an image
without :imagemagick method) is limited to .png, when other graphic files are
possible. I can define something like this:
(setq org-preview-latex-default-process
'(my-process
:programs ("lualatex" "convert")
:description "pdf > jpg"
:image-input-type "pdf"
:image-output-type "jpg"
:latex-compiler ("lualatex -interaction nonstopmode -output-directory
%o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100
%O")))
But if I put :file foo.jpg nothing happens. Maybe that part should be
corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [patch] Add two new header args to LaTeX block
Juan Manuel Macías writes:
>> Ihor Radchenko writes:
>> Would it make sense to make :pdf-process work for png previews as well?
>
> It would be ideal. The expected value for org-latex-pdf-process is a
> command or a list of commands, but org-preview-latex-default-process
> expects a plist of various processes and parameters. Maybe with some
> conditional? If only the png extension is provided (without the
> :imagemagick argument), then the expected value is for
> org-preview-latex-default-process. In all other cases, the value is for
> org-latex-pdf-process. The argument could then be called simply
> :process. E.g.:
>
> Assuming the user has somewhere (add-to-list
> org-preview-latex-process-alist my-process):
>
> :results file :file foo.png :process 'my-process [or :process '(a plist)]
>
> In other cases, like this:
>
> :imagemagick yes :results file :file foo.png :process '("lualatex
> -interaction nonstopmode -output-directory %o %f")
>
> wdyt?
I am attaching a new patch with this idea incorporated. I have also
changed the name from full-to-pdf to standalone.
Best regards,
Juan Manuel
>From a7f72015007722e665338c39b9a02d675c31cd93 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.
* (org-babel-execute:latex): `:process' allows modifying the value of
`org-latex-pdf-process' or `org-preview-latex-default-process' in a
specific block. If only the `png' extension is provided (without the
`:imagemagick' argument), then the expected value is for
`org-preview-latex-default-process'. In all other cases, the value is
for `org-latex-pdf-process'. This argument has no effect if the
conversion is to `HTML'. The `:standalone' argument requires that
the LaTeX block contains all the code necessary to be compiled, as if
it were an autonomous LaTeX document: the expected result will always
be a PDF file.
---
lisp/ob-latex.el | 16
1 file changed, 16 insertions(+)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..8bec0c661 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,14 @@ This function is called by `org-babel-execute-src-block'."
(height (and fit (cdr (assq :pdfheight params
(width (and fit (cdr (assq :pdfwidth params
(headers (cdr (assq :headers params)))
+ (process (cdr (assq :process params)))
+ (org-preview-latex-default-process (if (and process
+ (string-suffix-p ".png" out-file)
+ (not imagemagick))
+ process
+ org-preview-latex-default-process))
+ (org-latex-pdf-process (if process process org-latex-pdf-process))
+ (standalone (cdr (assq :standalone params)))
(in-buffer (not (string= "no" (cdr (assq :buffer params)
(org-latex-packages-alist
(append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +195,14 @@ This function is called by `org-babel-execute-src-block'."
(list org-babel-latex-pdf-svg-process)
extension err-msg log-buf)))
(rename-file img-out out-file t
+ ((and (string= "pdf" extension) standalone)
+ (with-temp-file tex-file
+ (insert body))
+ (when (file-exists-p out-file) (delete-file out-file))
+ (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+ (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+ (err-msg "org babel latex failed"))
+ (rename-file tmp-pdf out-file t
((string-suffix-p ".tikz" out-file)
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
--
2.43.0
Re: [patch] Add two new header args to LaTeX block
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> May you please explain in more detail how these new header arguments fit
>>> into other available LaTeX code block parameters? In particular, when
>>> exporting to .png/.svg/.html or when :imagemagick header argument is
>>> provided.
>>
>> Sure! `:pdf-process' simply applies a local value to
>> org-latex-pdf-process. It does not affect the export to png in its
>> version without imagemagick process, since this option depends on
>> org-create-formula-image, which in turn depends on
>> org-preview-latex-default-process. It also does not affect the export to
>> html, which depends on org-babel-latex-htlatex. It should work in all
>> other cases, including imagemagick, which ultimately depend on
>> org-latex-pdf-process.
>
> Would it make sense to make :pdf-process work for png previews as well?
It would be ideal. The expected value for org-latex-pdf-process is a
command or a list of commands, but org-preview-latex-default-process
expects a plist of various processes and parameters. Maybe with some
conditional? If only the png extension is provided (without the
:imagemagick argument), then the expected value is for
org-preview-latex-default-process. In all other cases, the value is for
org-latex-pdf-process. The argument could then be called simply
:process. E.g.:
Assuming the user has somewhere (add-to-list
org-preview-latex-process-alist my-process):
:results file :file foo.png :process 'my-process [or :process '(a plist)]
In other cases, like this:
:imagemagick yes :results file :file foo.png :process '("lualatex -interaction
nonstopmode -output-directory %o %f")
wdyt?
>> As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
>> better name), the expected result is a pdf file. Therefore it is
>> incompatible with exporting to png, svg or conversion with imagemagick.
>> For it to work, it is enough to provide these 2 args: ":file foo.pdf
>> :full-to-pdf yes."
>
> Maybe just :standalone?
Yes, I totally agree.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [patch] Add two new header args to LaTeX block
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> The attached patch adds two new header args to the LaTeX block:
>>
>> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
>> locally to the block. This can be useful for evaluating a given block
>> with another LaTeX compiler, or even using some custom script.
>> Example:
>> ...
>> - `:full-to-pdf' makes the block like a standalone LaTeX document, which
>> should contain everything needed to be compiled, from \documentclass{}
>> to \end{document}. Example:
>
> Thanks!
> May you please explain in more detail how these new header arguments fit
> into other available LaTeX code block parameters? In particular, when
> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
Sure! `:pdf-process' simply applies a local value to
org-latex-pdf-process. It does not affect the export to png in its
version without imagemagick process, since this option depends on
org-create-formula-image, which in turn depends on
org-preview-latex-default-process. It also does not affect the export to
html, which depends on org-babel-latex-htlatex. It should work in all
other cases, including imagemagick, which ultimately depend on
org-latex-pdf-process.
As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
better name), the expected result is a pdf file. Therefore it is
incompatible with exporting to png, svg or conversion with imagemagick.
For it to work, it is enough to provide these 2 args: ":file foo.pdf
:full-to-pdf yes."
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
[patch] Add two new header args to LaTeX block
The attached patch adds two new header args to the LaTeX block:
- `:pdf-process' allows modifying the value of `org-latex-pdf-process'
locally to the block. This can be useful for evaluating a given block
with another LaTeX compiler, or even using some custom script.
Example:
#+begin_src latex :pdf-process '("lualatex -shell-escape -interaction
nonstopmode -output-directory %o %f")
\textbf{hello world}
#+end_src
- `:full-to-pdf' makes the block like a standalone LaTeX document, which
should contain everything needed to be compiled, from \documentclass{}
to \end{document}. Example:
#+begin_src latex :full-to-pdf yes
\documentclass{article}
\begin{document}
\textbf{hello world}
\end{document}
#+end_src
I think both arguments can have many practical uses. For example, to
compile separately and load multiple subdocuments, with different
preambles:
#+NAME: doc1
#+begin_src org :exports none :results latex
,#+include: some-document.org
#+end_src
#+begin_src latex :noweb yes :results silent file :file file.pdf :full-to-pdf
yes
\documentclass{article}
\usepackage[spanish]{babel}
\usepackage{fontspec}
\setmainfont{Vollkorn}
\begin{document}
<>
\end{document}
#+end_src
#+latex: \includepdf{file.pdf}
Or even to evaluate ConTeXt code within a LaTeX block:
#+begin_src latex :full-to-pdf yes :results raw file :file file.pdf
:pdf-process '("cd %o && context %f")
\starttext
\startsection[title={Testing ConTeXt}]
Lorem ipsum dolor.
\stopsection
\stoptext
#+end_src
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
>From fe1b40e2b22e2c668440bea13feda0ab7923bdd8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.
* (org-babel-execute:latex): `:pdf-process' allows modifying the value
of `org-latex-pdf-process' in a specific block. The `:full-to-pdf'
argument requires that the LaTeX block contains all the code necessary
to be compiled, as if it were an autonomous LaTeX document: the
expected result will always be a PDF file.
---
lisp/ob-latex.el | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..118d81338 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,9 @@ This function is called by `org-babel-execute-src-block'."
(height (and fit (cdr (assq :pdfheight params
(width (and fit (cdr (assq :pdfwidth params
(headers (cdr (assq :headers params)))
+ (pdf-process (cdr (assq :pdf-process params)))
+ (org-latex-pdf-process (if pdf-process pdf-process org-latex-pdf-process))
+ (full-to-pdf (cdr (assq :full-to-pdf params)))
(in-buffer (not (string= "no" (cdr (assq :buffer params)
(org-latex-packages-alist
(append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +190,14 @@ This function is called by `org-babel-execute-src-block'."
(list org-babel-latex-pdf-svg-process)
extension err-msg log-buf)))
(rename-file img-out out-file t
+ ((and (string= "pdf" extension) full-to-pdf)
+ (with-temp-file tex-file
+ (insert body))
+ (when (file-exists-p out-file) (delete-file out-file))
+ (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+ (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+ (err-msg "org babel latex failed"))
+ (rename-file tmp-pdf out-file t
((string-suffix-p ".tikz" out-file)
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
--
2.43.0
Re: Link type for pdf-tools annotations
Irfan S writes: > FYI, there is also > [[https://github.com/fuxialexander/org-pdftools][org-pdftools]] which > provides similar (and additional) functionality, and is on MELPA. > Thanks for sharing your code. Thank you very much, I didn't know that. Best regards, Juan Manuel -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: Link type for pdf-tools annotations
Ihor Radchenko writes: > Juan Manuel Macías writes: > >> Many times I need to "save" an annotation point in the pdf-tools >> annotations buffer. So I defined a new link type and the function to >> store it. The link is stored with the structure: >> >> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. >> page-number)]] >> >> The link opens the PDF and jumps to the specific annotation. > > You may also utilize `org-create-file-search-functions' and > `org-execute-file-search-functions' to make an ordinary file: links > works for the same purpose. Thanks for the pointers. Note that in this use case I don't need to search in the PDF file itself but in the pdf-annot-list-mode buffer that is created via pdf-annot-list-annotations. This buffer is synchronized with the PDF to which it is linked. What this link type does is visit the pdf file (with pdf-tools), create the list of annotations and jump to the specific annotation, by date. pdf-annot-list-display-annotation-from-id highlights the specific list annotation in the linked PDF (if necessary, moves to the corresponding page), and opens the content of the annotation in another window (interactively the function is executed by pressing SPC on the annotation list at point). Storing the annotation date seemed like the safest option to me, since the annotation id can change when adding new annotations, each time the list is created. The typical scenario: when I am consulting a PDF annotated by someone and I want to store the location of some specific annotations. As there can be many annotations per page, adding a simple bookmark to the page would not be enough either. Best regards, Juan Manuel -- Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
Re: Exporting multiple #+AUTHOR keywords
Max Nikulin writes: > On 04/02/2024 22:21, Ihor Radchenko wrote: >> >> Another option is to have a new set of keywords: >> #+LATEX_AUTHOR: >> #+HTML_AUTHOR: ... >> >> For multiple authors, we may introduce something like >> >> #+AUTHOR: John Doe >> #+AUTHOR+: Luke Skywalker > > Another idea: > > #+metadata: > - author :: >- John Doe >- Luke Skywalker > - title :: Some text > > With overrides for specific backends > > #+metadata: :backend latex > - author :: > > Perhaps backends may declare if they support footnotes, etc. by defining > some backend property. I like both ideas. If I had to choose, perhaps I would prefer Ihor's approach since it separates the formatting value and the metadata value using simple keywords. I understand that in the former you could add any direct format (LaTeX, odt, html...), macros and even footnotes. And if the former is not explicitly included in the document, then the latter is used to populate both the formatting value and the metadata value. Anyway, I think your approach would work very well for more complex pdf metadata like xmp. Maybe using the hyperxmp package, which you mentioned in a thread months ago? Maybe something like this: #+latex_xmp ... #+end ? Best regards, Juan Manuel
Re: [DISCUSSION] Add "Recent News" to orgmode.org
Ihor Radchenko writes: > Hi, > > What do you think about an idea to modify Org mode front page > (https://orgmode.org/), adding the most recent blog posts and > discussions about Org mode? > > We might use Org-related records from Sacha's news and/or > https://planet.emacslife.com/ as a source, scrape it regularly (once per > day/week or on every export), and embed the relevant links into the > orgweb/index.html > > This way, visitors can easily see how active Org mode community is and > discover Org-related blogs/forums. +1 Best regards, Juan Manuel
Re: Exporting multiple #+AUTHOR keywords
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Sorry if this is off topic, but something like this:
>>
>> #+AUTHOR: Fred Astaire
>> #+AUTHOR: Ginger Rogers
>>
>> is exported to LaTeX as:
>>
>> \author{Fred Astaire Ginger Rogers}
>>
>> Shouldn't there be some separation? In LaTeX the usual thing is:
>>
>> \author{Fred Astaire \and Ginger Rogers}
>
> You can do
>
> #+AUTHOR: Fred
> #+AUTHOR: Astaire
>
> #+AUTHOR: and Ginger
> #+AUTHOR: Rogers
>
> The values are simply concatenated before passing to the exporter.
>
> Can we concatenate with "\and"? Sure. But not by default or it would be
> a breaking change.
Thanks for the explanation. I've never made documents with more than one
author, so I've never thought about this scenario. For a moment I
thought org supported more than one author (explicitly, I mean).
Anyway, \and is just a formatting command: add a space between two
authors. Some people may prefer to put a line break \\ or anything else.
Of course, \and (and any other format command) will have a negative
effect on the pdfauthor metadata, which only collects text strings. It
is a similar problem to the one with footnotes, which Maxim commented
on. I think the basic problem is that org uses #+author, #+title, etc.
as a single source for both the metadata strings and the exported
format, i.e. the title, the author, the date that is printed somewhere.
Perhaps the ideal would be to distinguish in some way between
author-metadata and author-exported-format. For example something like:
#+AUTHOR[John Doe and Luke Skywalker]: John Doe @@latex:\and@@ Luke
Skywalker
The optional string in square brackets would be the metadata; the rest
would be the direct exported format. If there is no optional string, the
value is used for both metadata and format. Could this be also a
possible solution to the footnote problem?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
Ihor Radchenko writes:
> #+AUTHOR: author1
> #+FN_AUTHOR: footnote for author 1
>
> #+AUTHOR: author2
> #+FN_AUTHOR: footnote for author 2
Sorry if this is off topic, but something like this:
#+AUTHOR: Fred Astaire
#+AUTHOR: Ginger Rogers
is exported to LaTeX as:
\author{Fred Astaire Ginger Rogers}
Shouldn't there be some separation? In LaTeX the usual thing is:
\author{Fred Astaire \and Ginger Rogers}
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages
Ihor Radchenko writes:
> #+LANGUAGE: fa
> #+LaTeX_Header: \usepackage[AUTO]{polyglossia}
>
> #+latex_header: \usepackage[AUTO]{fontspec}
I think Pedro is referring to fontenc not fontspec. fontenc cannot be
used in either lualatex or XelaTeX. fontspec is for advanced selection
of truetype and opentype fonts in XeLatex and LuaLaTeX and setting
opentype properties. fontenc is for 'pre-Unicode' LaTeX font encoding. I
would say that what Pedro proposes is limited only to the output in
pdfTeX.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
Ihor Radchenko writes: > Max Nikulin writes: > >> On 26/01/2024 19:53, Ihor Radchenko wrote: >>> So, I am leaning towards reverting that commit - that will allow things >>> like >>> >>> #+TITLE: This is a test title[fn::This is test] >> >> I hope, document metadata will be generated with stripped footnotes. > > This is a good point. > > For now, [fn::This is test], when passed to exporters, is simply treated > as plain text. > > If we change the parser nesting rules, Org will pass footnote-reference > objects instead. > > Then, in a number of parsers, if something like > (org-export-data (plist-get info :title) info) or > (org-export-data author info) > is used, footnotes may break export because metadata fields often have > special rules about markup that is allowed inside. > > In particular, ox-odt will be broken; ox-latex will be broken. > > Of course, we can adjust built-in backends to take into account the new > parsing rules, but we have no control over the third-party backends. > > On the other hand, when user exports something like > > #+AUTHOR: John Doe[fn::935 Pennsylvania Avenue, NW Washington, D.C. > 20535-0001] > it is probably not exported as expected anyway. How about using dedicated keywords? Something like: #+FN_AUTHOR: footnote text #+FN_TITLE: footnote text I give these two examples because they are the two places where a footnote of this type is expected. I know: it's ugly and corseted (what to do if a title has more than one footnote or an "inner" footnote?). But I suppose it would be safe for a basic case, since it would only be necessary to modify org-latex-template, org-odt-template, etc., without risk of unexpected results. Best regards, Juan Manuel
Re: [BUG] Footnotes in section titles
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> ...
>> \title{Lorem ipsum dolor\thanks{blah blah}}
>> ...
>>
>> Org does not have support for this type of notes in the #+title or
>> #+author keywords. For LaTeX you can use a macro.
>
> Hmm.
> The reason footnotes are not allowed in #+title and other keywords is
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7ebe87e2d5fb6c
>
> Inserting footnote references in parsed keywords (e.g., TITLE or
> CAPTION) can lead to subtle bugs. Indeed, it is impossible to know in
> time if that particular footnote is going to be used in the output,
> and, therefore, if it should count, e.g., in
> `org-export-get-footnote-number'.
>
> However, I am not sure about that line of reasoning - we generally don't
> know if *any* given footnote reference is going to be used in the output
> or not because export backend may skip references or whole parts of the
> original Org file. Same for user filters.
>
> So, I am leaning towards reverting that commit - that will allow things
> like
>
> #+TITLE: This is a test title[fn::This is test]
>
> If we need special handling for footnotes in title (like using \thanks
> instead of \footnote), it is easy.
I completely agree. I think it would be a great improvement, since, as
Colin Baxter says, in academic articles it is a very common practice to
add foot notes to the title of the article or the name of the author.
As for the \thanks{} command, org exports the keyword #+email within a
\thanks{} command as '\author{Name\thanks{email}}0. I don't think two
\thanks macros collide within author (assuming the user adds the email
and puts a footnote in #+author. Anyway, I think the most common thing
is to put the email below the author's name, not as a footnote, but that
is another topic and also depends on the style of each publication,
journal, etc.
>> ... For backends like odt
>> it is trickier. Look at this thread:
>>
>> https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg0.html
>>
>> I think it would be nice if Org had some kind of support for notes in
>> #+title and #+author...
>
> No idea about how to do it in ODT. If someone familiar with OpenDocument
> spec can help, it would be welcome.
I don't have much idea about odt, but I think the problem comes from a
type of nesting that is not allowed in the odt xml. I think org exports
#+author inside the initial-creator tag:
(format "%s\n" author)
And within that tag the code for a footnote produces an error when
opening the document. If the footnote is placed right after
, there would be no problem.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: [BUG] Footnotes in section titles
Colin Baxter writes:
> >> Perhaps it is better to avoid footnotes in titles and to add some
> >> phrase to the body instead.
>
> > That is the ideal scenario. I also believe that footnotes should
> > be avoided in section headings, if possible. Or at least, have
> > another type of numbering (symbols, letters...). The manyfoot and
> > bigfoot packages allow constructions of this type, with various
> > footnote apparatus.
>
> Indeed, but many journals *require* footnotes in titles, especially for
> affiliation, email, etc.
Notes on article titles (and even on the author name) are a slightly
different case from notes on section titles. In LaTeX there is the
"\thanks" command, which inserts footnotes for title and author,
numbered with fnsymbol. For example:
...
\title{Lorem ipsum dolor\thanks{blah blah}}
...
Org does not have support for this type of notes in the #+title or
#+author keywords. For LaTeX you can use a macro. For backends like odt
it is trickier. Look at this thread:
https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg0.html
I think it would be nice if Org had some kind of support for notes in
#+title and #+author...
Best regards,
Juan Manuel
Re: [BUG] Footnotes in section titles
Max Nikulin writes:
> I recall some tricks with \footnotemark and \footnotetext, but I do
> not remember details and whether it may work for section titles.
> Complications may arise if a heading title has several footnotes.
ox-latex has 'org-latex--delayed-footnotes-definitions': "[...] This
function is used within constructs that don't support \footnote{}
command (e.g., an item tag). In that case, \footnotemark is used within
the construct and the function just outside of it."
The \footnotetext/\footnotemark option works well for specific cases,
but in general I don't like to abuse this method.
> Perhaps it is better to avoid footnotes in titles and to add some
> phrase to the body instead.
That is the ideal scenario. I also believe that footnotes should be
avoided in section headings, if possible. Or at least, have another type
of numbering (symbols, letters...). The manyfoot and bigfoot packages
allow constructions of this type, with various footnote apparatus.
Best regards,
Juan Manuel
--
Juan Manuel Macías --
Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> +#+begin_example
>>> +,#+latex_class_options: [greek,spanish,oneside]
>>> +,#+language: es
>>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
>>> +#+end_example
>>
>> I think this example doesn't take advantage of the AUTO facility, which
>> is what the section is about.
> Do you have any suggestions how to improve the patch?
I would give an example that did include the AUTO 'facility', to unify
with the rest of the examples in the section:
#+language: es
#+latex_header: \usepackage[greek,ngerman,AUTO]{babel}
#+latex_header: \usepackage{alphabeta} % to support greek script
It is also said in the patch that this example is for pdfTeX, but it
works equally well for LuaTeX and XeTeX, since Babel and alphabeta
packages support both engines. However, the alphabeta package is not a
specific package for writing texts in Greek. Rather, according to the
package documentation: "The alphabeta package makes the standard macros
for Greek letters in mathematical mode also available in text mode." In
pdfTeX it is useful because you can enter the Greek input directly in
Unicode. But in LuaTeX or XeTeX it would be unnecessary, since Greek can
be written directly, without the help of additional packages.
>> ... Btw, maybe it would be nice to extend ''AUTO'' to
>> latex_class_options and \PassOptionsToPackage? Something like:
>
> It would really be nice to have an ox-latex maintainer who is deeply
> familiar with LaTeX :)
My knowledge of LaTeX (and Elisp) has huge gaps :-). Of course, I am
willing to learn everything I can. And, naturally, I would like to help
in any way I can. But my main problem (currently) is the lack of time to
dedicate myself to it. My presence on this list is intermittent, and
that for a maintainer is horrible. Maybe in a few months (spring
perhaps), when my personal situation stabilizes a little, I could
consider it...
Best regards,
Juan Manuel
Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Ihor Radchenko writes: > Upon looking closer into selective removal, it turned out to be more > tricky than I thought. I'm afraid that using \\[0pt] only in some places > may become a bit of headache to maintain - we may accidentally break > certain regexp replacements in `org-latex-verse-block'. In particular, > when verse contents is not straightforward and uses \\[0pt]. > > Given that `org-latex-line-break-safe' also introduced the problem with > verse blocks, I decided that it is better to remove it at the end. LaTeX code generated without org-latex-line-break-safe is much cleaner. The decision to make this variable obsolete seems correct to me, if there is already a better and more discreet solution. I don't know if it will cause many problems with custom settings and filters written in relation to this variable, as Maxim commented in a previous email... I hope not. I have a couple of filters written already, but I don't think it will take much work for me to readjust them. Best regards, Juan Manuel
Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
Pedro Andres Aranda Gutierrez writes:
> +#+begin_example
> +,#+latex_class_options: [greek,spanish,oneside]
> +,#+language: es
> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> +#+end_example
I think this example doesn't take advantage of the AUTO facility, which
is what the section is about. Btw, maybe it would be nice to extend ''AUTO'' to
latex_class_options and \PassOptionsToPackage? Something like:
#+latex_class_options: [greek,AUTO,oneside]
#+language: es
...
However, I would only find the \PassOptionsToPackage command useful in
classes that already load babel with a main language. From Org, using
just pdfTeX, I think it would be simpler:
#+language: es
#+latex_header: \usepackage[greek,AUTO]{babel}
#+latex_header: \usepackage{alphabeta} % to support greek script
or this variant, using babelprovide and an INI file:
#+language: es
#+latex_header: \usepackage[greek]{babel}
#+latex_header: \babelprovide[import,main]{AUTO}
#+latex_header: \usepackage{alphabeta}
Best regards,
Juan Manuel
Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Ihor Radchenko writes: > I see your point. > Although I am still a bit hesitant to remove > `org-latex-line-break-safe'. > What would be the benefit of removing it? For now, I mostly just see > that it will make the life harder for users in Scenario B. It's a complicated situation, because we now have two solutions to the same problem... It certainly sounds a bit abrupt to remove org-latex-line-break-safe (at least for now). I see no problem in both solutions coexisting. After all, the user can always give an "" value to org-latex-line-break-safe. The other possibility is that org-latex-line-break-safe is selectively deleted, as you mentioned in a previous email. In tables and verse blocks, unless I'm missing something, I think adding [0pt] would be unnecessary, with the new solution. > For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong) >From the tests I have done, the problem of the vertical space being altered after the verse environment only appears when the last line ends in \\[0pt]. If it ends in \\ the problem does not appear. It is not recommended that a verse environment ends in \\, but it does not seem to influence the output. In fact, that was how it was in Org in the days pre org-latex-line-break-safe and there were never any problems. Best regards, Juan Manuel
Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Ihor Radchenko writes: > Juan Manuel Macías writes: > >>> Paragraph\\ >>> @@latex:[foo]@@ >> >> But since in both cases it is literal LaTeX code, the correct thing >> would be for the user to be in charge of adding the curly braces to the >> square brackets. I mean in such scenario it is LaTeX code, not Org. > > Not really. Because we do not give guarantees about the details of LaTeX > export, we should try hard to not break things that users may put into > literal export snippets. > >> Anyway, in both examples it does not make sense for LaTeX to end a >> paragraph with the \\ macro, which is why we commented in previous >> messages in the thread. The \\ macro is only used in horizontal mode; >> this macro does not add a new paragraph but rather a forced line break >> within the paragraph. > > In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph > - it is inside paragraph. What I mean is that literal LaTeX code is LaTeX code, despite the redundancy. IMHO, Org's only duty in that case is to export such literal code as valid LaTeX code, but Org "does not know" what that literal code consists of. The user who enters the literal LaTeX code is the one who has the duty to add the necessary elements to that code so that it is compiled correctly by LaTeX. Let's look at this as a territorial question: Scenario A: @@LaTeX:\libebreak@@ [ipsum] ==> the problem is in Org territory Scenario B: lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory Best regards, Juan Manuel
Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> \begin{itemize}
>>> \item {[}bax]
>>> \item {[}aur]
>>> \end{itemize}
>>
>> Great! Simple and effective. And more surgical than pandoc's global
>> solution. But now a question arises... Your code clearly solves the
>> problem that led to the declaration of org-latex-line-break-safe,
>> without foreseeing any unwanted effects, since it is the solution that
>> is usually recommended from LaTeX. So, if this code is included in Org,
>> what is the future of org-latex-line-break-safe?
>
> It is still useful in situations like
>
> Paragraph\\
>
> #+begin_export latex
> [foo]
> #+end_export
>
> or
>
> Paragraph\\
> @@latex:[foo]@@
But since in both cases it is literal LaTeX code, the correct thing
would be for the user to be in charge of adding the curly braces to the
square brackets. I mean in such scenario it is LaTeX code, not Org.
Anyway, in both examples it does not make sense for LaTeX to end a
paragraph with the \\ macro, which is why we commented in previous
messages in the thread. The \\ macro is only used in horizontal mode;
this macro does not add a new paragraph but rather a forced line break
within the paragraph.
Best regards,
Juan Manuel
Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Max Nikulin writes:
> On 18/01/2024 20:05, Ihor Radchenko wrote:
>> With the patch, I am getting the following:[...]
>> \begin{center}
>> \begin{tabular}{lr}
>> {[}foo] & 2\\[0pt]
>> {[}bar] & 3\\[0pt]
>> \end{tabular}
>> \end{center}
>
> It means that [0pt] is not necessary any more. However users will have
> adjust their filters once more. I have no idea if many of them will
> complain concerning {[} where it is not really required.
> (/[omitted]/).
>
> To have an additional excuse, it is better to add a note that it is
> inspired by pandoc strategy.
I agree with the note. Perhaps both strategies could coexist: by
default, Ihor's code; and org-latex-line-break-safe with value "".
And, after some time, the latter could become obsolete, unless a new
''raison d'etre'' is found for it...
In any case, I would no longer see it necessary to modify
org-latex-verse-block anymore.
Best regards,
Juan Manuel
Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Ihor Radchenko writes:
> This turned out to be a lot easier than I thought.
> See the attached patch.
>
>>> \command
>>> [unrelated text]
>>>
>>> If there are, we may actually want to consider pandoc's approach
>>> seriously.
>>
>> In principle, any environment that takes an optional argument in a
>> "dangerous" position. Just do a simple test. Something like this:
>>
>> #+begin_figure
>> [lorem] ipsum
>> #+end_figure
>>
>> will throw an error like ''LaTeX Error: Unknown float option...''
>>
>> Of course, putting an empty line after #+begin... usually solves it. But
>> the user may not know it.
>>
>> There are also a number of commands with an optional argument. For
>> example \pagebreak. Something like this will give an error:
>>
>> lorem @@latex:\pagebreak@@ [ipsum]
>>
>> \item is another typical example, but in this case org adds \relax.
>
> With the patch, I am getting the following:
>
> * This is test
> lorem @@latex:\pagebreak@@ [ipsum]
>
> #+begin_figure
> [lorem] figure
> #+end_figure
>
> | [foo] | 2 |
> | [bar] | 3 |
>
> - [bax]
> - [aur]
>
> exports to
>
> lorem \pagebreak {[}ipsum]
>
> \begin{figure}
> {[}lorem] figure
> \end{figure}
>
> \begin{center}
> \begin{tabular}{lr}
> {[}foo] & 2\\[0pt]
> {[}bar] & 3\\[0pt]
> \end{tabular}
> \end{center}
>
> \begin{itemize}
> \item {[}bax]
> \item {[}aur]
> \end{itemize}
Great! Simple and effective. And more surgical than pandoc's global
solution. But now a question arises... Your code clearly solves the
problem that led to the declaration of org-latex-line-break-safe,
without foreseeing any unwanted effects, since it is the solution that
is usually recommended from LaTeX. So, if this code is included in Org,
what is the future of org-latex-line-break-safe?
Best regards,
Juan Manuel
Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Ihor Radchenko writes:
> If the idea with custom command does not have obvious downsides, it
> might be a better option. In the previous thread, we only considered
> redefining \\ itself - obviously a non-starter for environments that
> re-define \\ by their own, like here.
I find several drawbacks to adding a new latex command like \nothing.
First, the standardization of the exported LaTeX code is lost. \\[0pt],
at least, always compiles. A new command obviously needs to be defined
first. Let's imagine that someone wants to simply share the LaTeX code
of a table... Then there is the problem of how to name the new command
so that it doesn't 'clash' with some user-defined command. In LaTeX it
is usually good practice to use the at sign character (@) in the name of
a command or macro that is not in user space, since this character can
only be used in a *.sty file. In a *.tex file, if you want to use the at
sign to define or redefine something, you have to enclose the code
between \makeatletter...\makeatother. And, in any case, I think that the
LaTeX code produced by org should be as 'universal' as possible (standard
LaTeX code + packages included in TeX live), and leave the definition of
new commands or environments to the user's discretion.
On the other hand, we are not sure that a command like \nothing does not
have some undesirable effect. I seem to remember that in the
aforementioned thread, adding \relax (the typical command that is used
to tell LaTeX do nothing) was also proposed as a solution, and it was
discarded for some reason.
>> In any case, square brackets are a problematic character in LaTeX
>> (think, e.g., of some environment that takes an optional argument). I
>> think pandoc chooses to always export them as {[}{]}:
>>
>> #+begin_src sh :results latex
>> str="[hello world] [foo] [bar]"
>> pandoc -f org -t latex <<< $str
>> #+end_src
>>
>> #+RESULTS:
>> #+begin_export latex
>> {[}hello world{]} {[}foo{]} {[}bar{]}
>> #+end_export
>>
>> We could do the same, but I'm afraid it's too late if
>> org-latex-line-break-safe already exists... I don't remember if
>> something similar was proposed in that discussion, and it was rejected
>> for some reason.
>
> It is not too late.
>
> AFAIR, we just decided not to dig deeper about pandoc's approach.
>
> As for {[}{]}, it is a bit difficult to implement. Especially when we
> also consider user filters and derived backends. If we have several
> transcoders of consequent elements, there is always a risk that even
> when a given filter/transcoder is generating a valid LaTeX code,
> concatenating them may still cause issues like we have with \\.
I see. I think pandoc's solution is what Leslie Lamport recommends
(naturally, Lamport doesn't say to enclose /all/ brackets in curly
braces).
> I am wondering if there are other examples of commands with optional
> arguments that may cause a similar problem with
>
> \command
> [unrelated text]
>
> If there are, we may actually want to consider pandoc's approach
> seriously.
In principle, any environment that takes an optional argument in a
"dangerous" position. Just do a simple test. Something like this:
#+begin_figure
[lorem] ipsum
#+end_figure
will throw an error like ''LaTeX Error: Unknown float option...''
Of course, putting an empty line after #+begin... usually solves it. But
the user may not know it.
There are also a number of commands with an optional argument. For
example \pagebreak. Something like this will give an error:
lorem @@latex:\pagebreak@@ [ipsum]
\item is another typical example, but in this case org adds \relax.
Best regards,
Juan Manuel
Re: #+LATEX_HEADER: \usepackage[greek,german]{babel} ??
Horst Leps writes:
> % Created 2024-01-16 Tue 20:00
> % Intended LaTeX compiler: pdflatex
> \documentclass{scrartcl}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{grffile}
> \usepackage{longtable}
> \usepackage{wrapfig}
> \usepackage{rotating}
> \usepackage[normalem]{ulem}
> \usepackage{amsmath}
> \usepackage{textcomp}
> \usepackage{amssymb}
> \usepackage{capt-of}
> \usepackage{hyperref}
> \usepackage[germanb]{babel}
> \usepackage[utf8]{inputenc}
> \usepackage[LGR,T1]{fontenc}
> \usepackage[greek,german]{babel}
> \author{HL}
The document loads babel twice:
\usepackage[germanb]{babel} <==
\usepackage[utf8]{inputenc}
\usepackage[LGR,T1]{fontenc}
\usepackage[greek,german]{babel} <==
Hence the 'option class for package babel' error. You have loaded babel
in your org document with the [greek,german] option and (probably, in
the class you are loading) babel is already loaded as well.
Try:
#+LaTeX_Header: \PassOptionsToPackage{greek,german}{babel}
Best regards,
Juan Manuel
Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
Ihor Radchenko writes:
> The very reason we use \\[0pt] is because it supposed to prevent
> interpreting [...] at the new line/transcoded element as argument.
>
> You demonstrated that it is yet not always safe enough.
>
> May it be better to use something like
>
> \newcommand\nothing{}
> \newcommand{\safenewline}{\\\nothing}
>
> And then use \safenewline instead of \\[0pt]
>
> In my tests,
>
> \begin{center}
> \begin{tabular}{ll}
> [t] & s\safenewline
> [I] & A\safenewline
> [m] & kg\safenewline
> \end{tabular}
> \end{center}
>
> Does not suffer from misinterpreting new line as argument.
I remember the thread where these issues were discussed and the long
discussion where many alternatives were proposed. After all, the \\[0pt]
solution still seems the safest to me. It seems that the problem is
located only in the verse environment, probably due to some particular
redefinition of the \\ macro that makes that environment.
In any case, square brackets are a problematic character in LaTeX
(think, e.g., of some environment that takes an optional argument). I
think pandoc chooses to always export them as {[}{]}:
#+begin_src sh :results latex
str="[hello world] [foo] [bar]"
pandoc -f org -t latex <<< $str
#+end_src
#+RESULTS:
#+begin_export latex
{[}hello world{]} {[}foo{]} {[}bar{]}
#+end_export
We could do the same, but I'm afraid it's too late if
org-latex-line-break-safe already exists... I don't remember if
something similar was proposed in that discussion, and it was rejected
for some reason.
> `org-latex-verse-block' already has a giant regexp replacement:
>
> ;; In a verse environment, add a line break to each newline
> ;; character and change each white space at beginning of a line
> ;; 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.
>
> We may as well strip the trailing \\[0pt] there.
I think it would be best to remove the last \\[0pt] in the verse block.
I can prepare a patch, but I'm afraid that org-latex-verse-block is
becoming an homage to replace-regexp-in-string...
Best regards,
Juan Manuel
