From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id aB1uB2k/62N4SwEAbAwnHQ (envelope-from ) for ; Tue, 14 Feb 2023 08:59:37 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id qBNmBmk/62OQNAEAG6o9tA (envelope-from ) for ; Tue, 14 Feb 2023 08:59:37 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C0CB72E8A2 for ; Tue, 14 Feb 2023 08:59:36 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRqDN-0005gd-Mb; Tue, 14 Feb 2023 02:59:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRqDJ-0005cL-7E for emacs-orgmode@gnu.org; Tue, 14 Feb 2023 02:58:57 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRqDG-0002gR-Vg for emacs-orgmode@gnu.org; Tue, 14 Feb 2023 02:58:56 -0500 Received: from localhost ([::ffff:102.85.204.48]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000055DB5.0000000063EB3F40.000070FF; Tue, 14 Feb 2023 00:58:56 -0700 Date: Tue, 14 Feb 2023 10:58:17 +0300 From: Jean Louis To: Ihor Radchenko Cc: Gustaf Waldemarson , 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)]) Message-ID: Mail-Followup-To: Ihor Radchenko , Gustaf Waldemarson , emacs-orgmode@gnu.org References: <87cz6dipt1.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87cz6dipt1.fsf@localhost> User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Seal: i=1; s=key1; d=yhetil.org; t=1676361576; a=rsa-sha256; cv=none; b=LS4QlQE2P32FBQCK49E5owxjkshiefJmrl45qk4ELBpqb4Gy7ZN9V3eIT8UqIYu5YXfWbI 7lYyy7SHlkuY+/I+u/iUyKPRAS/nghLSTG0Dz35fCwcsEBhaENjSRgbDRC3zHhkC7sk/lR if/C32fD2Zyv4Fvez7veV9Ok97hVWh4+f6rrKoKqBMLc9pv6dmafpclXLmaA0A4stC+9Kk 2e9c9OK9/bnhBC1RhHdpJq5Vwl/lOUbXHK4huZBB0fg/+8jYxjR0La6Uq/EQLPwKNOmONs bEYomU8vtzS/VHctFk3LfrL4Oh5oQdoHDyLWR2IrFJ/IFEm5Vhxy5t2UPK/jRQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1676361576; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=zJQRyrdwsKAYnTknGDFXjtAhqQA4C/ek3Ex2i3tvmvM=; b=mFM+a8IznuvmtfQVNgnTf7knP5bw2Nrgyg9agIIEUQDzX+xApSf+3jJ9q8NURdn1E4MhS2 TvZc6Vk8RjGKtgK7Ud2owMLE3TlHf1ctg+m+FcujS5UGd6If5/RsKATkMJznfxyU2zf+mz LdbpFWkNjR0/EMLt0raf7y7t4slLgWFhEAZ9tpMAMO3JIb71dPx4cAIAG5AlGX8O6VCHTj BZJApmNyF6bfY+6Vh/Ra1sqwqA/ckayFRpwktp/EbqUviPTGZ6RtlDgd2NqEkOQ3FkwdJ5 kKDlyvEGfvecquCT+PukNQhYv5HTbhi4s2tUcT53mpmUhj+aVF9WHubzHfCvKg== Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -2.92 X-Spam-Score: -2.92 X-Migadu-Queue-Id: C0CB72E8A2 X-TUID: fW69nda4M6Ud * Ihor Radchenko [2023-02-13 17:50]: > Gustaf Waldemarson 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: https://www.dougengelbart.org/content/view/110/460/#2a1a So anything can be elementary object, no matter in what kind of a system. 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: [width="80%",options="header"] |==== | My left| My right | left| right |==== Then this here: | [[./img/a.jpg]] | [[./img/b.jpg]] | Get correctly exported as: [width="80%"] |==== | 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 [width="80%"] |==== | image:./img/a.jpg[]| image:./img/b.jpg[] |==== #+END_SRC 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"))) text)) (rcd-asciidoc-snippet-no-header-footer-to-latex " [width=\"80%\"] |==== | 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}}@{}} \\toprule\\noalign{} \\endhead \\bottomrule\\noalign{} \\endlastfoot \\includegraphics{./img/a.jpg} & \\includegraphics{./img/b.jpg} \\\\ \\end{longtable} " 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]] | #+END_SRC 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. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/