all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Eshel Yaron <me@eshelyaron.com>
Cc: 73425@debbugs.gnu.org, philipk@posteo.net
Subject: bug#73425: 31.0.50; Support images in HTML versions of ELPA package manuals
Date: Sun, 22 Sep 2024 20:45:13 +0300	[thread overview]
Message-ID: <86v7ynh9au.fsf@gnu.org> (raw)
In-Reply-To: <m1msjzlll3.fsf@dazzs-mbp.home> (bug-gnu-emacs@gnu.org)

> Cc: Philip Kaludercic <philipk@posteo.net>
> Date: Sun, 22 Sep 2024 18:06:16 +0200
> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I'm opening this feature request following a discussion with Philip
> elsewhere: Texinfo manual can include images, but AFAIK (and please
> correct me if I'm wrong here) there's currently no way for ELPA packages
> to include images in their manuals and have these images appear also in
> the HTML version of the manual that the ELPA server builds and serves.

Why "no way"?  If the image files are present at their filenames as
mentioned by the HTML version of the documentation, they will be shown
by the browser.

> An example is my GNU ELPA package Kubed.  In the development version,
> the manual refers to images which are present on my web server, where I
> provide HTML versions[1][2] of the manual.  There, the images are
> displayed properly.  On the ELPA server[3], OTOH, the images are nowhere
> to be found, and we instead get just the alt text and caption.  That's
> expected, but the alt text is shown with no distinctive styling so the
> result seems quite confusing.

To show images, your HTML version of the manual should reference local
files, not URLs from your some other server.  And, of course, the
image files should be part of the package tarball.

> - Include images in the package repository, somehow indicate in the
>   package specification that the manual refers to these images, and have
>   the ELPA server keep the images around in a predictable location, so I
>   can link to it from the manual.

I don't understand why this would be needed.  Simply include the image
files with the package, and the rest should "just work", AFAIU.

> - Provide a IMAGE_LINK_PREFIX value (e.g. pointing to my web server)
>   that the ELPA server will use while building the HTML manual.

That's definitely not TRT: ELPA packages should be self-contained as
far as their documentation is concerned.

> - Override the creation of the HTML manual entirely, and have the ELPA
>   server redirect or link to the version hosted on my web server.

Likewise: there should be no dependency on any server.

Apologies if I misunderstood the problem.





  reply	other threads:[~2024-09-22 17:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-22 16:06 bug#73425: 31.0.50; Support images in HTML versions of ELPA package manuals Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-22 17:45 ` Eli Zaretskii [this message]
2024-09-22 18:03   ` Philip Kaludercic
2024-09-22 18:13     ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-22 18:16       ` Philip Kaludercic
2024-09-22 18:43         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-22 18:15     ` Eli Zaretskii
2024-09-22 18:23       ` Philip Kaludercic
2024-09-22 19:05         ` Eli Zaretskii
2024-09-23 10:48           ` Philip Kaludercic
2024-09-23 12:03             ` Eli Zaretskii
2024-09-23 12:46               ` Philip Kaludercic
2024-09-23 14:19                 ` Eli Zaretskii
2024-09-26  4:02                 ` Stefan Kangas
2024-09-26 20:10                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-23 14:00             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86v7ynh9au.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=73425@debbugs.gnu.org \
    --cc=me@eshelyaron.com \
    --cc=philipk@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.