From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id sPaADyjaGmX8fgAAauVa8A:P1 (envelope-from ) for ; Mon, 02 Oct 2023 16:56:40 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id sPaADyjaGmX8fgAAauVa8A (envelope-from ) for ; Mon, 02 Oct 2023 16:56:40 +0200 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 EE85D410C9 for ; Mon, 2 Oct 2023 16:56:39 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="mPYZ/Tr8"; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1696258600; 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:dkim-signature; bh=j8pp04tYHt68CuM5HnC8Qafyxz/bT6x+MuStdsfpbCI=; b=qg7JjNmTZbvMeMfb4tSkyaMbsEkSaZLSfwn7Pedl9ARJlK9bJTUq5U5Z79kk317QUMBj+e NZ5kzPBJ+cMQ4ub1hx/wdWTnbCJi3ZzDNlIZ4VcmEACGt7U7IkwOqXg949xopQNcoa/X3L o7HPbhhy0mYOo0Ja9eFrJXwzZQp/fRfW9+bfCASy1Ua47z2ayKmgUWI3/SpGY1MSPxksyG kVHfCFJtdi4VYJqli66K8Qpv8bsDi2WA345m9dDYBj/fiXcQt/vI8DiAdnnZwbYjF5sIc3 CW3eOM0StdO+e1Q2wm6TopeYsdbHTs6x3B+1nv1atsgrn8eEibLQV5qwFiQa0g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="mPYZ/Tr8"; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1696258600; a=rsa-sha256; cv=none; b=TIPUmuGm6GYJVzo3Gl+FGPvrMj3u60yBJ6CLUOA0jFfwFFP2JU6vtd8pK4gUa3yLv8ssyq hLBwXHJVqQJncjUDLmdEy7Dmw2A/JKm/VuBjREO6I+EHRZR4wc+uP+5EK1ZIFQIPyVwb12 vRYLDWKbgDRTdQi4F/aDaqhqiIclvVI4qCAzi7UAzy23/z1AzdLhajVS1AFRZe5XowedSu tlNn8+3vlLzkM5jog8XNvfwbMEGhviPbmCnA423m/8d1dsbtIMlcwXgwIcVnWdXPHeCvZu iCrEM92H3+NJgbfFpXbbMetKX5H2k/sQ6e4FI8Z1APgFQuSuJaY4Emm+4Nn1yg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qnKKq-00071s-O3; Mon, 02 Oct 2023 10:55:48 -0400 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 1qnKKo-00071W-BK for emacs-orgmode@gnu.org; Mon, 02 Oct 2023 10:55:46 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnKKZ-0003La-GF for emacs-orgmode@gnu.org; Mon, 02 Oct 2023 10:55:46 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 6C971240027 for ; Mon, 2 Oct 2023 16:55:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1696258527; bh=j8pp04tYHt68CuM5HnC8Qafyxz/bT6x+MuStdsfpbCI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=mPYZ/Tr8st/OQz5mg2YDvXSzW4a3YAGgpkT2x5zkmMMcQ06bhnOVDjfK3dZ78U4ah 1JyXe7grSmrimhhlOl0YUXg9Q1JS+JwRxS2XGQW1nnA/XVNAmYzvgmK9EBzNOnl4Wc 029F6t7uSpM2RyfYM/z3znGQakpBxUu+mZB9UPDRYRyS9yyOpmpY98dTtmB3Xi9CZC +6TMTpiHTXsUdvJn7n0LCF70nHIqsfJY3kwpnTHceos9lLFDZQJud6fQ+7y0ovhZnL 1RM2PH+/qLK1JknGUwvYZ8cAUNiV39vCp+tU0aO/DfPFb34p3gkR9pxU2o37odnGHp yCvYuLVQfAiVA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RzkXG6qKgz6ty8; Mon, 2 Oct 2023 16:55:26 +0200 (CEST) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Ihor Radchenko Cc: orgmode Subject: Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? In-Reply-To: <87il7pw4oc.fsf@localhost> (Ihor Radchenko's message of "Mon, 02 Oct 2023 13:10:43 +0000") References: <874jjatm6c.fsf@posteo.net> <87il7pw4oc.fsf@localhost> Date: Mon, 02 Oct 2023 14:55:24 +0000 Message-ID: <87leclnkf7.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=maciaschain@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 X-Migadu-Spam-Score: -8.89 X-Migadu-Scanner: mx2.migadu.com X-Migadu-Queue-Id: EE85D410C9 X-Spam-Score: -8.89 X-TUID: omuvJ7eHJMqm Ihor Radchenko writes: >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 >> =E2=94=82 #+caption: Main caption >> =E2=94=82 #+begin_figure >> =E2=94=82 #+CAPTION: subcaption 1 >> =E2=94=82 #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center= nil :width \textwidth >> =E2=94=82 [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg= ]] >> ... >> I think this is a case where certain elements of Org have evolved >> (consciously or unconsciously) ahead of the names, and these names have >> become somewhat outdated. There is not only the case of :placement. Even >> :float seems imprecise, since can be used to create a minipage, and the >> minipage environment is not a float environment. Would it be worth >> making those names obsolete (with backward compatibility, of course) and >> replacing them with slightly more precise ones? I think that new names >> would give the user an idea of more variety of uses, like the examples I >> have put here. > > I am not sure about obsolete - I see not reason to obsolete the intended > use case. Your example is rather an abuse. Why abuse? First, it works like a charm. Second, if :float can support any string as an environment name, why not minipage or subfigure? As for :placement, the term would seem more precise to me if it were really "placement" (as :align in tables is actually "align"), not LaTeX code passed directly after the \begin{...}. That a user can put things like this (I do it often, and I think I'm not the only one): :placement [htbp]\SomeExtraLaTeXCode... it is a consequence of the above. It is not an "orthodox" use (I mean, it's not described in the manual), but it works without problems. Again, I don't want to seem too picky about the names, but a user who doesn't understand the source code might think that :placement only supports things like [htbp]. My idea here is: instead of implementing new features, recycle and take advantage of those that arise unexpectedly :-). Although :placement was created thinking about putting code related to placement figures, as it is implemented I would have called it :latex-code or something similar. > What we might do it to introduce something like a new :wrap attribute: > > #+attr_latex: :wrap subfigure,{\textwidht} That would be nice if with a single latex_attr line you could export a single figure environment for several images, since every subfigure environment must be inside a figure environment. And putting a single subfigure inside a figure environment doesn't make much sense. Other than that, the idea of :wrap is good. I find it very useful, especially on tables. > I think we have discussed something similar in the past, but more > generic - allow wrapping arbitrary Org elements (headings, drawers, > paragraphs, etc) on export. I remember that thread. In fact, I think I created a TODO to study that, but due to lack of time I haven't been able to take a look at it. --=20 Juan Manuel Mac=C3=ADas https://juanmanuelmacias.com https://lunotipia.juanmanuelmacias.com https://gnutas.juanmanuelmacias.com