emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix regex for determining image width from attribute


From: Matt Huszagh
Subject: Re: [PATCH] Fix regex for determining image width from attribute
Date: Sun, 21 Nov 2021 11:51:57 -0800

Timothy <tecosaur@gmail.com> writes:

> Once again, thank you for the patch. The fact that the current regexp matches
> `#+attr_latex' and `#+attr_html' is in fact by design though*. This is 
> because I
> consider it safe to assume that a `#+attr_*' which gives non-integer width 
> between
> 0 and 2 can be safely assumed to be that proportion of the page width. e.g.
> `#+attr_latex: :width 0.7\linewidth' or `#+attr_html: :width 70%'.
> This way, a good guess can be made without having do have both an
> `#+attr_latex/html' /and/ an `#+attr_org' line for the width. Should this 
> assumption
> be incorrect, a subsequent `#+attr_org' line will override the other 
> `#+attr_*'.
>
> Should there be edge-cases where this assumption doesn’t hold, I’d be 
> interested
> in patches that improves the logic here. As long as this holds more often than
> not though, this should be a net positive for user experience as I see it.
>
> Do please let me know if there are any good examples of unintended /
> counter-intuitive behaviour you’re aware of.

Thanks for explaining the logic behind the current implementation.

Unfortunately, I think this makes a valid use case
impossible. Specifically, I like to be able to set an image width
explicitly with #+attr_org (or some other attr_ for the corresponding
export) and fall back to the actual image width when this isn't
specified. This includes the ability to use the actual image width in an
org buffer, but an explicitly-set image width for export. For example,
for my blog I often have attr_html set, but I want the image to use its
actual width when displayed in org. I don't see how this is possible
with the current implementation. But, it works naturally with the
implementation I have in mind (IIRC this is how it previously worked,
but I could be mistaken).

I do understand the desire to avoid specifying a whole bunch of
redundant attr_ settings, but I don't think it should make fine-tuned
use cases like the one above impossible. I also find the current
implementation a bit counterintuitive, if less verbose. Maybe a solution
to accomplish all goals would be to add an #+attr_fallback (or
attr_default, attr_any, attr_all, etc.) that is used for any backend
unless a specific setting is made for that backend.

Matt




reply via email to

[Prev in Thread] Current Thread [Next in Thread]