emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Gustaf Waldemarson <gustaf.waldemarson@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [FR] Side-by-side images during export (was: [BUG] Org-mode Side-by-Side Images [9.5.3 (release_9.5.3-3-gd54104)])
Date: Tue, 14 Feb 2023 10:58:17 +0300	[thread overview]
Message-ID: <Y+s/GaKA6yYEwRe7@protected.localdomain> (raw)
In-Reply-To: <87cz6dipt1.fsf@localhost>

* Ihor Radchenko <yantar92@posteo.net> [2023-02-13 17:50]:
> Gustaf Waldemarson <gustaf.waldemarson@gmail.com> writes:
> >   Does something like that already exist in org-mode? Alternatively,
> >   what is the recommended and most portable approach to placing images
> >   side-by-side?
> No, AFAIK.

Org is already a text structure that has elementary objects defined,
as you said, not everything is granular, but there is no limit what
users can define in Org.

Elementary Objects:

So anything can be elementary object, no matter in what kind of a

By having that in mind, I think other objects could be used to get
what user wants.

In Asciidoctor I can make table with invisible lines, and position
pictures inside of cells, or place some text on sides. There exists
Asciidoc export for Org. What you read is now my thoughts about it,
development towards possible solution:

| My left | My right |
| left    | right    |

Giving this with Asciidoc Org export:

| My left| My right

| left| right

Then this here:

| [[./img/a.jpg]] | [[./img/b.jpg]] |

Get correctly exported as:

| image:./img/a.jpg[]| image:./img/b.jpg[]

in Asciidoctor.

One can use that as fundamental point. Instead of using Asciidoctor
export, one could use source blocks to generate LaTeX export by using
Asciidoctor markup.

Here is only the idea:

#+BEGIN_SRC asciidoctor-to-latex
| image:./img/a.jpg[]| image:./img/b.jpg[]

Then based on following function, one can conevert that above:

(defun rcd-asciidoc-snippet-no-header-footer-to-latex (text)
  "Return LaTeX for Asciidoc snippet TEXT without header and footer."
  (let* ((text (rcd-asciidoctor text "-s" "-b" "docbook5"))
	 (text (rcd-pandoc-convert-string text "docbook" "latex")))

(rcd-asciidoc-snippet-no-header-footer-to-latex "
| image:./img/a.jpg[]| image:./img/b.jpg[]
") ➜ "\\begin{longtable}[]{@{}
  >{\\raggedright\\arraybackslash}p{(\\columnwidth - 2\\tabcolsep) * \\real{0.4000}}
  >{\\raggedright\\arraybackslash}p{(\\columnwidth - 2\\tabcolsep) * \\real{0.4000}}@{}}
\\includegraphics{./img/a.jpg} & \\includegraphics{./img/b.jpg} \\\\

and by using the above think process, it is possible to make
following, by using the Org snippet:

#+BEGIN_SRC org-to-asciidoc-to-latex
| [[./img/a.jpg]] | [[./img/b.jpg]] |

then such Org snippet can be converted to Asciidoc, then to docbook5,
then to LaTeX or to HTML. 

Solution is right there by using pandoc, asciidoctor and "elementary
objects" as Org Babel source blocks.

And this may not be the only solution.

> There are two problems:
> 1. We currently lack object-granular control over export attributes.
>    Attributes for images are set for the whole paragraph and Org uses a
>    paragraph starting with image as a special case, assigning paragraph
>    to the image.

By using above method, that is solved for each individual user how
they wish and want. It does not need much adaptation IMHO.

> 2. There is no easy universal way to create side-by-side images for all
>    possible backends.

As if you do not control those backends, there is also no need for that.

However, by using the above method, it is possible to solve it for all
backends straight from Org, by only adding conversion function.

> The best thing we might provide is merging multiple images into one
> using, for example, a LaTeX minipage export to create merged image
> to be included into the exported document.

Merging multiple images sounds to me as hard coding. 

Providing small conversion functions for various exports like HTML,
Org would just make it work.

I did not provide final example in this e-mail, but now you could, I
gave you the thought process and functionality.


Take action in Free Software Foundation campaigns:

In support of Richard M. Stallman

      reply	other threads:[~2023-02-14  7:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 12:24 [BUG] Org-mode Side-by-Side Images [9.5.3 (release_9.5.3-3-gd54104)] Gustaf Waldemarson
2023-02-13 14:48 ` [FR] Side-by-side images during export (was: [BUG] Org-mode Side-by-Side Images [9.5.3 (release_9.5.3-3-gd54104)]) Ihor Radchenko
2023-02-14  7:58   ` Jean Louis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+s/GaKA6yYEwRe7@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --cc=gustaf.waldemarson@gmail.com \
    --cc=yantar92@posteo.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).