From: Matt Huszagh <huszaghmatt@gmail.com>
To: Timothy <tecosaur@gmail.com>
Cc: , emacs-orgmode@gnu.org
Subject: Re: [PATCH] Fix regex for determining image width from attribute
Date: Mon, 22 Nov 2021 23:46:07 -0800 [thread overview]
Message-ID: <87k0gzpb5s.fsf@gmail.com> (raw)
In-Reply-To: <871r37l96a.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
Here are two patches that prioritize attr_org over other attr_
keywords. I believe this is what you had in mind Timothy. But let me
know if not.
The second patch (intended to be applied after the first) improves the
documentation. It describes behavior that wasn't previously documented
and removes redundant documentation between org-image-actual-width and
org-display-inline-image--width (now only in
org-image-actual-width). Please double check I got everything correct,
as I haven't used all this behavior myself.
Thanks
Matt
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 1st patch --]
[-- Type: text/x-patch, Size: 1870 bytes --]
From 22bbe7d651e1f27398597297c7c35ae4f3253773 Mon Sep 17 00:00:00 2001
From: Matt Huszagh <huszaghmatt@gmail.com>
Date: Mon, 22 Nov 2021 23:28:48 -0800
Subject: [PATCH 1/2] org.el: Prioritize attr_org when computing image width
* lisp/org.el (org-display-inline-image--width): First look
for attr_org: :width and then look for another attr_.* :width
when that isn't specified.
---
lisp/org.el | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 308bb7d51..bf5d08e09 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16853,13 +16853,20 @@ buffer boundaries with possible narrowing."
((listp org-image-actual-width)
(let* ((case-fold-search t)
(par (org-element-lineage link '(paragraph)))
- (attr-re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)")
+ (attr-re (lambda (backend)
+ (concat "^[ \t]*#\\+attr_"
+ backend
+ ": +.*?:width +\\(\\S-+\\)")))
(par-end (org-element-property :post-affiliated par))
- ;; Try to find an attribute providing a :width.
+ ;; If an attr_org provides a :width, use that. Otherwise,
+ ;; use the first attribute that provides it, if any.
(attr-width
(when (and par (org-with-point-at
(org-element-property :begin par)
- (re-search-forward attr-re par-end t)))
+ (or (re-search-forward (funcall attr-re "org")
+ par-end t)
+ (re-search-forward (funcall attr-re ".*?")
+ par-end t))))
(match-string 1)))
(width
(cond
--
2.31.1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 2nd patch --]
[-- Type: text/x-patch, Size: 3260 bytes --]
From aff581922e8d8bf10f813cdb9bc8adf9c8632683 Mon Sep 17 00:00:00 2001
From: Matt Huszagh <huszaghmatt@gmail.com>
Date: Mon, 22 Nov 2021 23:30:11 -0800
Subject: [PATCH] org.el: Clarify documentation for computing image width
* lisp/org.el (org-display-inline-image--width)
(org-image-actual-width): Specify documentation for computing
an inline image width in org-image-actual-width and remove the
redundant documentation from org-display-inline-image--width.
---
lisp/org.el | 38 ++++++++++++++++++++++++--------------
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index bf5d08e09..c8dc1815f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15529,10 +15529,29 @@ When set to a number in a list, try to get the width from any
and fall back on that number if none is found.
-When set to nil, try to get the width from an #+ATTR.* keyword
-and fall back on the original width if none is found.
-
-When set to any other non-nil value, always use the image width.
+When set to nil, first try to get the width from #+ATTR_ORG. If
+that is not found, use the first #+ATTR_.*:width specification.
+If that is also not found, fall back on the original image width.
+
+Finally, org is quite flexible in the width specifications it
+supports and intelligently interprets width specifications for
+other backends when rendering an image in an org buffer. This
+behavior is described presently.
+
+1. A floating point value is interpreted as the percentage of the text
+ area that should be taken up by the image.
+2. A number followed by a percent sign is divided by 100 and then
+ interpreted as a floating point value.
+3. If a number is followed by other text, extract the number and
+ discard the remaining text. That number is then interpreted as a
+ floating-point value. For example,
+
+ #+ATTR_LATEX: :width 0.7\\linewidth
+
+ would be interpreted as 70% of the text width.
+4. If t is provided the original image width is used. This is useful
+ when you want to specify a width for a backend, but still want to
+ use the original image width in the org buffer.
This requires Emacs >= 24.1, built with imagemagick support."
:group 'org-appearance
@@ -16838,16 +16857,7 @@ buffer boundaries with possible narrowing."
(defvar visual-fill-column-width) ; Silence compiler warning
(defun org-display-inline-image--width (link)
"Determine the display width of the image LINK, in pixels.
-- When `org-image-actual-width' is t, the image's pixel width is used.
-- When `org-image-actual-width' is a number, that value will is used.
-- When `org-image-actual-width' is nil or a list, the first :width attribute
- set (if it exists) is used to set the image width. A width of X% is
- divided by 100.
- If no :width attribute is given and `org-image-actual-width' is a list with
- a number as the car, then that number is used as the default value.
- If the value is a float between 0 and 2, it interpreted as that proportion
- of the text width in the buffer."
- ;; Apply `org-image-actual-width' specifications.
+See `org-image-actual-width' for how the image width is computed."
(cond
((eq org-image-actual-width t) nil)
((listp org-image-actual-width)
--
2.31.1
next prev parent reply other threads:[~2021-11-23 7:46 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-21 19:08 [PATCH] Fix regex for determining image width from attribute Matt Huszagh
2021-11-21 19:20 ` Timothy
2021-11-21 19:51 ` Matt Huszagh
2021-11-22 8:29 ` Timothy
2021-11-22 16:11 ` Matt Huszagh
2021-11-22 17:54 ` Timothy
2021-11-22 20:53 ` Matt Huszagh
2021-11-23 4:59 ` Kyle Meyer
2021-11-23 5:14 ` Timothy
2021-11-23 5:38 ` Matt Huszagh
2021-11-23 5:39 ` Timothy
2021-11-23 7:46 ` Matt Huszagh [this message]
2021-11-23 16:44 ` Max Nikulin
2021-11-24 1:57 ` Matt Huszagh
2021-11-24 14:48 ` Max Nikulin
2021-11-24 15:59 ` Matt Huszagh
2021-11-24 17:00 ` Max Nikulin
2021-11-25 16:43 ` Max Nikulin
2021-11-29 0:23 ` Matt Huszagh
2021-11-29 5:13 ` Timothy
2021-12-01 3:24 ` Matt Huszagh
2021-12-01 4:54 ` Timothy
2021-12-03 2:06 ` Matt Huszagh
2024-05-02 16:28 ` Ihor Radchenko
2024-05-07 4:59 ` Karthik Chikmagalur
2024-05-08 10:36 ` Max Nikulin
2024-05-08 10:54 ` Ihor Radchenko
2024-05-09 10:47 ` Max Nikulin
2024-05-13 12:42 ` Ihor Radchenko
2024-05-13 12:42 ` Ihor Radchenko
2021-11-29 12:15 ` Max Nikulin
2021-11-22 14:30 ` Max Nikulin
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=87k0gzpb5s.fsf@gmail.com \
--to=huszaghmatt@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=tecosaur@gmail.com \
/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).