emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: orgmode <emacs-orgmode@gnu.org>
Subject: Re: Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX?
Date: Mon, 02 Oct 2023 14:55:24 +0000	[thread overview]
Message-ID: <87leclnkf7.fsf@posteo.net> (raw)
In-Reply-To: <87il7pw4oc.fsf@localhost> (Ihor Radchenko's message of "Mon, 02 Oct 2023 13:10:43 +0000")

Ihor Radchenko writes:

>> ┌────
>> │ #+caption: Main caption
>> │ #+begin_figure
>> │ #+CAPTION: subcaption 1
>> │ #+ATTR_LaTeX: :float subfigure :placement {\textwidth} :center nil :width \textwidth
>> │ [[file:/usr/share/texmf-dist/tex/latex/mwe/example-image-a.jpg]]
>> ...
>> I think this is a case where certain elements of Org have evolved
>> (consciously or unconsciously) ahead of the names, and these names have
>> become somewhat outdated. There is not only the case of :placement. Even
>> :float seems imprecise, since can be used to create a minipage, and the
>> minipage environment is not a float environment. Would it be worth
>> making those names obsolete (with backward compatibility, of course) and
>> replacing them with slightly more precise ones? I think that new names
>> would give the user an idea of more variety of uses, like the examples I
>> have put here.
>
> I am not sure about obsolete - I see not reason to obsolete the intended
> use case. Your example is rather an abuse.

Why abuse? First, it works like a charm. Second, if :float can support
any string as an environment name, why not minipage or subfigure? As for
:placement, the term would seem more precise to me if it were really
"placement" (as :align in tables is actually "align"), not LaTeX code
passed directly after the \begin{...}. That a user can put things like
this (I do it often, and I think I'm not the only one):

:placement [htbp]\SomeExtraLaTeXCode...

it is a consequence of the above. It is not an "orthodox" use (I mean,
it's not described in the manual), but it works without problems. Again,
I don't want to seem too picky about the names, but a user who doesn't
understand the source code might think that :placement only supports
things like [htbp]. My idea here is: instead of implementing new
features, recycle and take advantage of those that arise unexpectedly
:-). Although :placement was created thinking about putting code related
to placement figures, as it is implemented I would have called it
:latex-code or something similar.


> What we might do it to introduce something like a new :wrap attribute:
>
> #+attr_latex: :wrap subfigure,{\textwidht}

That would be nice if with a single latex_attr line you could export a
single figure environment for several images, since every subfigure
environment must be inside a figure environment. And putting a single
subfigure inside a figure environment doesn't make much sense. Other
than that, the idea of :wrap is good. I find it very useful, especially
on tables.

> I think we have discussed something similar in the past, but more
> generic - allow wrapping arbitrary Org elements (headings, drawers,
> paragraphs, etc) on export.

I remember that thread. In fact, I think I created a TODO to study that,
but due to lack of time I haven't been able to take a look at it.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com


  reply	other threads:[~2023-10-02 14:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-01 15:08 Are 'placement' and 'float' "obsolete terms" in inline images exported to LaTeX? Juan Manuel Macías
2023-10-01 18:07 ` Juan Manuel Macías
2023-10-02 13:10 ` Ihor Radchenko
2023-10-02 14:55   ` Juan Manuel Macías [this message]
2023-10-04  9:12     ` Ihor Radchenko
2023-10-04 14:34       ` Juan Manuel Macías
2023-10-06 16:29         ` Ihor Radchenko
2023-10-06 18:35           ` Juan Manuel Macías
2023-10-06 19:49             ` Ihor Radchenko

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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=87leclnkf7.fsf@posteo.net \
    --to=maciaschain@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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