GNU bug report logs -
#73425
31.0.50; Support images in HTML versions of ELPA package manuals
Previous Next
To reply to this bug, email your comments to 73425 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
philipk <at> posteo.net, bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 16:07:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eshel Yaron <me <at> eshelyaron.com>:
New bug report received and forwarded. Copy sent to
philipk <at> posteo.net, bug-gnu-emacs <at> gnu.org.
(Sun, 22 Sep 2024 16:07:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
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.
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.
Ideally, I would like a way to be able to do one of the following:
- 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.
- Provide a IMAGE_LINK_PREFIX value (e.g. pointing to my web server)
that the ELPA server will use while building the HTML manual.
- Override the creation of the HTML manual entirely, and have the ELPA
server redirect or link to the version hosted on my web server.
Thanks,
Eshel
[1] https://eshelyaron.com/kubed.html
[2] https://eshelyaron.com/man/kubed/
[3] https://elpa.gnu.org/devel/doc/kubed.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 17:47:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> Cc: Philip Kaludercic <philipk <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 18:04:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: Philip Kaludercic <philipk <at> 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 <at> 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.
The issue is that when generating the HTML documentation for
elpa.gnu.org, we don't copy out any files, but just generate the HTML
version of the manual.
What we need is some kind of an indication in the package specification,
what files should be copied out for the manual to access, as otherwise
the images would only be hidden in the package tarball, that a web
browser cannot access (AFAIK).
>> 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.
Unrelated to this issue, have you considered rendering screenshots as
SVG files using `x-export-frames'?
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.
Do you know if TeXinfo has an option to inline images? If the
"makeinfo" command could somehow generate data: urls when exporting
images, then this could be very easily solved.
[0] https://developer.mozilla.org/en-US/docs/Web/URI/Schemes/data
>> - 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.
I agree.
> Apologies if I misunderstood the problem.
--
Philip Kaludercic on siskin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 18:15:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> posteo.net> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Cc: Philip Kaludercic <philipk <at> 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 <at> 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.
>
> The issue is that when generating the HTML documentation for
> elpa.gnu.org, we don't copy out any files, but just generate the HTML
> version of the manual.
>
> What we need is some kind of an indication in the package specification,
> what files should be copied out for the manual to access, as otherwise
> the images would only be hidden in the package tarball, that a web
> browser cannot access (AFAIK).
Yes.
>>> 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.
>
> Unrelated to this issue, have you considered rendering screenshots as
> SVG files using `x-export-frames'?
I haven't, but I'll be sure to check it out. Thanks for the tip :)
>>> 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.
>
> Do you know if TeXinfo has an option to inline images? If the
> "makeinfo" command could somehow generate data: urls when exporting
> images, then this could be very easily solved.
I'm not aware of such an option. BTW, which version of Texinfo does the
ELPA server run?
Thanks,
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 18:17:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: Eshel Yaron <me <at> eshelyaron.com>, 73425 <at> debbugs.gnu.org
> Date: Sun, 22 Sep 2024 18:03:26 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Cc: Philip Kaludercic <philipk <at> 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 <at> 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.
>
> The issue is that when generating the HTML documentation for
> elpa.gnu.org, we don't copy out any files, but just generate the HTML
> version of the manual.
>
> What we need is some kind of an indication in the package specification,
> what files should be copied out for the manual to access, as otherwise
> the images would only be hidden in the package tarball, that a web
> browser cannot access (AFAIK).
"Copied" where and why? Aren't the HTML docs generated in the
package's tree, like the Info docs?
> >> - 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.
>
> Do you know if TeXinfo has an option to inline images? If the
> "makeinfo" command could somehow generate data: urls when exporting
> images, then this could be very easily solved.
This is already supported, for a long time, both in Info and HTML
formats (and in other formats as well; see the node "Image Syntax" in
the Texinfo manual.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 18:18:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Eshel Yaron <me <at> eshelyaron.com> writes:
> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> Cc: Philip Kaludercic <philipk <at> 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 <at> 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.
>>
>> The issue is that when generating the HTML documentation for
>> elpa.gnu.org, we don't copy out any files, but just generate the HTML
>> version of the manual.
>>
>> What we need is some kind of an indication in the package specification,
>> what files should be copied out for the manual to access, as otherwise
>> the images would only be hidden in the package tarball, that a web
>> browser cannot access (AFAIK).
>
> Yes.
>
>>>> 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.
>>
>> Unrelated to this issue, have you considered rendering screenshots as
>> SVG files using `x-export-frames'?
>
> I haven't, but I'll be sure to check it out. Thanks for the tip :)
>
>>>> 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.
>>
>> Do you know if TeXinfo has an option to inline images? If the
>> "makeinfo" command could somehow generate data: urls when exporting
>> images, then this could be very easily solved.
>
> I'm not aware of such an option. BTW, which version of Texinfo does the
> ELPA server run?
--8<---------------cut here---------------start------------->8---
$ ssh elpa makeinfo --version
texi2any (GNU texinfo) 6.8
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
--8<---------------cut here---------------end--------------->8---
I.e. the version distributed by Debian stable.
>
>
> Thanks,
>
> Eshel
--
Philip Kaludercic on siskin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 18:25:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: Eshel Yaron <me <at> eshelyaron.com>, 73425 <at> debbugs.gnu.org
>> Date: Sun, 22 Sep 2024 18:03:26 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Cc: Philip Kaludercic <philipk <at> 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 <at> 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.
>>
>> The issue is that when generating the HTML documentation for
>> elpa.gnu.org, we don't copy out any files, but just generate the HTML
>> version of the manual.
>>
>> What we need is some kind of an indication in the package specification,
>> what files should be copied out for the manual to access, as otherwise
>> the images would only be hidden in the package tarball, that a web
>> browser cannot access (AFAIK).
>
> "Copied" where and why? Aren't the HTML docs generated in the
> package's tree, like the Info docs?
No, these are the files we generate for a package under
https://elpa.gnu.org/packages:
-rw-r--r-- 1 phi phi 368640 Mar 22 2024 compat-29.1.4.5.tar
-rw-r--r-- 1 phi phi 11183 Mar 22 2024 compat.html
-rw-r--r-- 1 phi phi 997 Mar 22 2024 compat-readme.txt
-rw-r--r-- 1 phi phi 1230 Mar 22 2024 compat.svg
lrwxrwxrwx 1 phi phi 19 Mar 22 2024 compat.tar -> compat-29.1.4.5.tar
-rw-r--r-- 1 phi phi 1016 Mar 22 2024 compat.xml
plus the manual under https://elpa.gnu.org/packages/doc/[package name]
-rw-r--r-- 1 phi phi 46640 Mar 21 2024 corfu.html
(there is another symlink to this file but that is not important now).
Other than that, no files are copied out.
>> >> - 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.
>>
>> Do you know if TeXinfo has an option to inline images? If the
>> "makeinfo" command could somehow generate data: urls when exporting
>> images, then this could be very easily solved.
>
> This is already supported, for a long time, both in Info and HTML
> formats (and in other formats as well; see the node "Image Syntax" in
> the Texinfo manual.
I did take a look at that node, but I couldn't find anything that would
help me.
--
Philip Kaludercic on siskin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 18:45:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> posteo.net> writes:
> Eshel Yaron <me <at> eshelyaron.com> writes:
>
>> Philip Kaludercic <philipk <at> posteo.net> writes:
>>
>>> Do you know if TeXinfo has an option to inline images? If the
>>> "makeinfo" command could somehow generate data: urls when exporting
>>> images, then this could be very easily solved.
>>
>> I'm not aware of such an option. BTW, which version of Texinfo does the
>> ELPA server run?
>
> $ ssh elpa makeinfo --version
> texi2any (GNU texinfo) 6.8
>
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> I.e. the version distributed by Debian stable.
Good to know, thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 22 Sep 2024 19:07:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: me <at> eshelyaron.com, 73425 <at> debbugs.gnu.org
> Date: Sun, 22 Sep 2024 18:23:38 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> What we need is some kind of an indication in the package specification,
> >> what files should be copied out for the manual to access, as otherwise
> >> the images would only be hidden in the package tarball, that a web
> >> browser cannot access (AFAIK).
> >
> > "Copied" where and why? Aren't the HTML docs generated in the
> > package's tree, like the Info docs?
>
> No, these are the files we generate for a package under
> https://elpa.gnu.org/packages:
>
> -rw-r--r-- 1 phi phi 368640 Mar 22 2024 compat-29.1.4.5.tar
> -rw-r--r-- 1 phi phi 11183 Mar 22 2024 compat.html
> -rw-r--r-- 1 phi phi 997 Mar 22 2024 compat-readme.txt
> -rw-r--r-- 1 phi phi 1230 Mar 22 2024 compat.svg
> lrwxrwxrwx 1 phi phi 19 Mar 22 2024 compat.tar -> compat-29.1.4.5.tar
> -rw-r--r-- 1 phi phi 1016 Mar 22 2024 compat.xml
Then the image files should be in the same directory (or in its
images/ subdirectory, but that would need to be coordinated with the
package developers).
How do we generate these HTML files from the Texinfo sources?
> plus the manual under https://elpa.gnu.org/packages/doc/[package name]
So we have the HTML docs in two places? Why two? And why do I see
both https://elpa.gnu.org/packages/doc/compat.html and
https://elpa.gnu.org/packages/doc/compat/compat.html?
In any case, what I propose is to have the image files right near the
HTML files which reference them.
> >> Do you know if TeXinfo has an option to inline images? If the
> >> "makeinfo" command could somehow generate data: urls when exporting
> >> images, then this could be very easily solved.
> >
> > This is already supported, for a long time, both in Info and HTML
> > formats (and in other formats as well; see the node "Image Syntax" in
> > the Texinfo manual.
>
> I did take a look at that node, but I couldn't find anything that would
> help me.
??? What are you looking for that is not there?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Mon, 23 Sep 2024 10:50:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: me <at> eshelyaron.com, 73425 <at> debbugs.gnu.org
>> Date: Sun, 22 Sep 2024 18:23:38 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> What we need is some kind of an indication in the package specification,
>> >> what files should be copied out for the manual to access, as otherwise
>> >> the images would only be hidden in the package tarball, that a web
>> >> browser cannot access (AFAIK).
>> >
>> > "Copied" where and why? Aren't the HTML docs generated in the
>> > package's tree, like the Info docs?
>>
>> No, these are the files we generate for a package under
>> https://elpa.gnu.org/packages:
>>
>> -rw-r--r-- 1 phi phi 368640 Mar 22 2024 compat-29.1.4.5.tar
>> -rw-r--r-- 1 phi phi 11183 Mar 22 2024 compat.html
>> -rw-r--r-- 1 phi phi 997 Mar 22 2024 compat-readme.txt
>> -rw-r--r-- 1 phi phi 1230 Mar 22 2024 compat.svg
>> lrwxrwxrwx 1 phi phi 19 Mar 22 2024 compat.tar -> compat-29.1.4.5.tar
>> -rw-r--r-- 1 phi phi 1016 Mar 22 2024 compat.xml
>
> Then the image files should be in the same directory (or in its
> images/ subdirectory, but that would need to be coordinated with the
> package developers).
Right, and we can facilitate this by allowing package specifications to
annotate where images are found.
> How do we generate these HTML files from the Texinfo sources?
Basically by executing,
--8<---------------cut here---------------start------------->8---
makeinfo --no-split [input-name] -o [output-name] --html --css-ref=[css-url]
--8<---------------cut here---------------end--------------->8---
>> plus the manual under https://elpa.gnu.org/packages/doc/[package name]
>
> So we have the HTML docs in two places? Why two? And why do I see
> both https://elpa.gnu.org/packages/doc/compat.html and
> https://elpa.gnu.org/packages/doc/compat/compat.html?
I am not sure, my suspicion is some kind of historical backwards
compatibility. I have CC'ed Stefan who might know more.
> In any case, what I propose is to have the image files right near the
> HTML files which reference them.
That would make sense.
>> >> Do you know if TeXinfo has an option to inline images? If the
>> >> "makeinfo" command could somehow generate data: urls when exporting
>> >> images, then this could be very easily solved.
>> >
>> > This is already supported, for a long time, both in Info and HTML
>> > formats (and in other formats as well; see the node "Image Syntax" in
>> > the Texinfo manual.
>>
>> I did take a look at that node, but I couldn't find anything that would
>> help me.
>
> ??? What are you looking for that is not there?
Some kind of --embed flag, that would inline images. So instead of
generating
<img src="/path/to/image.png" />
makeinfo could produce
<img src="data:image/png;base64,iVBORw0KGgoAAAANS..."
--
Philip Kaludercic on siskin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Mon, 23 Sep 2024 12:05:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: me <at> eshelyaron.com, 73425 <at> debbugs.gnu.org, "Stefan Monnier"
> <monnier <at> iro.umontreal.ca>
> Date: Mon, 23 Sep 2024 10:48:41 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Then the image files should be in the same directory (or in its
> > images/ subdirectory, but that would need to be coordinated with the
> > package developers).
>
> Right, and we can facilitate this by allowing package specifications to
> annotate where images are found.
>
> > How do we generate these HTML files from the Texinfo sources?
>
> Basically by executing,
>
> --8<---------------cut here---------------start------------->8---
> makeinfo --no-split [input-name] -o [output-name] --html --css-ref=[css-url]
> --8<---------------cut here---------------end--------------->8---
>
> >> plus the manual under https://elpa.gnu.org/packages/doc/[package name]
> >
> > So we have the HTML docs in two places? Why two? And why do I see
> > both https://elpa.gnu.org/packages/doc/compat.html and
> > https://elpa.gnu.org/packages/doc/compat/compat.html?
>
> I am not sure, my suspicion is some kind of historical backwards
> compatibility. I have CC'ed Stefan who might know more.
>
> > In any case, what I propose is to have the image files right near the
> > HTML files which reference them.
>
> That would make sense.
OK, so we agree. I guess what's left is to somehow make sure this all
does indeed happen?
> >> >> Do you know if TeXinfo has an option to inline images? If the
> >> >> "makeinfo" command could somehow generate data: urls when exporting
> >> >> images, then this could be very easily solved.
> >> >
> >> > This is already supported, for a long time, both in Info and HTML
> >> > formats (and in other formats as well; see the node "Image Syntax" in
> >> > the Texinfo manual.
> >>
> >> I did take a look at that node, but I couldn't find anything that would
> >> help me.
> >
> > ??? What are you looking for that is not there?
>
> Some kind of --embed flag, that would inline images. So instead of
> generating
>
> <img src="/path/to/image.png" />
>
> makeinfo could produce
>
> <img src="data:image/png;base64,iVBORw0KGgoAAAANS..."
Ah, apologies for my misunderstanding. No, such inlining is not
supported by Texinfo for HTML, AFAIK, they only support external image
files for HTML. (DVI and PDF outputs do embed the image, I believe.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Mon, 23 Sep 2024 12:47:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: me <at> eshelyaron.com, 73425 <at> debbugs.gnu.org, "Stefan Monnier"
>> <monnier <at> iro.umontreal.ca>
>> Date: Mon, 23 Sep 2024 10:48:41 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Then the image files should be in the same directory (or in its
>> > images/ subdirectory, but that would need to be coordinated with the
>> > package developers).
>>
>> Right, and we can facilitate this by allowing package specifications to
>> annotate where images are found.
>>
>> > How do we generate these HTML files from the Texinfo sources?
>>
>> Basically by executing,
>>
>> --8<---------------cut here---------------start------------->8---
>> makeinfo --no-split [input-name] -o [output-name] --html --css-ref=[css-url]
>> --8<---------------cut here---------------end--------------->8---
>>
>> >> plus the manual under https://elpa.gnu.org/packages/doc/[package name]
>> >
>> > So we have the HTML docs in two places? Why two? And why do I see
>> > both https://elpa.gnu.org/packages/doc/compat.html and
>> > https://elpa.gnu.org/packages/doc/compat/compat.html?
>>
>> I am not sure, my suspicion is some kind of historical backwards
>> compatibility. I have CC'ed Stefan who might know more.
>>
>> > In any case, what I propose is to have the image files right near the
>> > HTML files which reference them.
>>
>> That would make sense.
>
> OK, so we agree. I guess what's left is to somehow make sure this all
> does indeed happen?
Yes. My suggestion is to allow listing additional non-.texi/.org files
under :doc that would be copied out to the web server. So in Eshel's
case, we could update the specification to be
(kubed :url "https://git.sr.ht/~eshel/kubed"
:doc ("kubed.texi" "images/"))
and the HTTP server could host all files under images/.
>> >> >> Do you know if TeXinfo has an option to inline images? If the
>> >> >> "makeinfo" command could somehow generate data: urls when exporting
>> >> >> images, then this could be very easily solved.
>> >> >
>> >> > This is already supported, for a long time, both in Info and HTML
>> >> > formats (and in other formats as well; see the node "Image Syntax" in
>> >> > the Texinfo manual.
>> >>
>> >> I did take a look at that node, but I couldn't find anything that would
>> >> help me.
>> >
>> > ??? What are you looking for that is not there?
>>
>> Some kind of --embed flag, that would inline images. So instead of
>> generating
>>
>> <img src="/path/to/image.png" />
>>
>> makeinfo could produce
>>
>> <img src="data:image/png;base64,iVBORw0KGgoAAAANS..."
>
> Ah, apologies for my misunderstanding. No, such inlining is not
> supported by Texinfo for HTML, AFAIK, they only support external image
> files for HTML. (DVI and PDF outputs do embed the image, I believe.)
What about the Info viewer in Emacs?
--
Philip Kaludercic on siskin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Mon, 23 Sep 2024 14:01:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 73425 <at> debbugs.gnu.org (full text, mbox):
>> How do we generate these HTML files from the Texinfo sources?
>
> Basically by executing,
>
> --8<---------------cut here---------------start------------->8---
> makeinfo --no-split [input-name] -o [output-name] --html --css-ref=[css-url]
> --8<---------------cut here---------------end--------------->8---
>
>>> plus the manual under https://elpa.gnu.org/packages/doc/[package name]
>>
>> So we have the HTML docs in two places? Why two? And why do I see
>> both https://elpa.gnu.org/packages/doc/compat.html and
>> https://elpa.gnu.org/packages/doc/compat/compat.html?
>
> I am not sure, my suspicion is some kind of historical backwards
> compatibility. I have CC'ed Stefan who might know more.
On disk, this is only one place: the `doc/compat.html` is a symlink to
`doc/compat/compat.html`. The only URL we want to expose is
the `doc/compat.html`, OTOH (which is why `doc/compat.html` is a symlink
rather than an HTTP redirect).
The reason is the following:
- We put all the generated files into the `doc/PKG/` subdir so we know
which files belong to which package when we need to "garbage collect"
old files when updating a package.
- We need to the URL to be `doc/compat.html` (i.e. include only the
manual name but not the package name) so that links from one
manual to the other work correctly regardless if the other manual
belongs to the same package or not.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Mon, 23 Sep 2024 14:21:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: me <at> eshelyaron.com, 73425 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Mon, 23 Sep 2024 12:46:25 +0000
>
> >> Some kind of --embed flag, that would inline images. So instead of
> >> generating
> >>
> >> <img src="/path/to/image.png" />
> >>
> >> makeinfo could produce
> >>
> >> <img src="data:image/png;base64,iVBORw0KGgoAAAANS..."
> >
> > Ah, apologies for my misunderstanding. No, such inlining is not
> > supported by Texinfo for HTML, AFAIK, they only support external image
> > files for HTML. (DVI and PDF outputs do embed the image, I believe.)
>
> What about the Info viewer in Emacs?
Same: it displays external image files, given a special control
sequence which refers to it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Thu, 26 Sep 2024 04:05:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> posteo.net> writes:
> Yes. My suggestion is to allow listing additional non-.texi/.org files
> under :doc that would be copied out to the web server. So in Eshel's
> case, we could update the specification to be
>
> (kubed :url "https://git.sr.ht/~eshel/kubed"
> :doc ("kubed.texi" "images/"))
>
> and the HTTP server could host all files under images/.
That has a significant drawback: when package maintainers want to add a
new image, they have to patch the (Non-)GNU ELPA package listing.
It would be better to keep that information it in the package itself
somehow, like we do with .elpaignore. Or we could just copy all image
files automatically.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Thu, 26 Sep 2024 20:12:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 73425 <at> debbugs.gnu.org (full text, mbox):
>> Yes. My suggestion is to allow listing additional non-.texi/.org files
>> under :doc that would be copied out to the web server. So in Eshel's
>> case, we could update the specification to be
>>
>> (kubed :url "https://git.sr.ht/~eshel/kubed"
>> :doc ("kubed.texi" "images/"))
>>
>> and the HTTP server could host all files under images/.
>
> That has a significant drawback: when package maintainers want to add a
> new image, they have to patch the (Non-)GNU ELPA package listing.
Agreed.
> It would be better to keep that information it in the package itself
> somehow, like we do with .elpaignore. Or we could just copy all image
> files automatically.
I think we should provide a "generic" way to provide some of the
`elpa-packages` contents directly from the package's own files.
I was thinking of something like a
;; ELPA-spec: (:readme "README.md" :doc "clear.texi" ...)
there's a security implication, so we'd need to "sanitize" this info
before using it, but other than that it should not be too hard
to implement.
But to get back to the "real" problem of images: in order for manual
`foo` to be able to have (working) cross-links to manual `bar`, it's
important that they are both exposed as `.../doc/foo.html` and
`.../doc/bar.html`, so they can't both use an image with a relative
URL of `snapshot1.png`.
Stefan
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 30 Sep 2024 01:38:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Thu, 10 Apr 2025 19:18:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> Yes. My suggestion is to allow listing additional non-.texi/.org files
> under :doc that would be copied out to the web server. So in Eshel's
> case, we could update the specification to be
>
> (kubed :url "https://git.sr.ht/~eshel/kubed"
> :doc ("kubed.texi" "images/"))
That'd be kind of a problem because `:doc` already supports a list of
strings where each string is expected to be the source file of a manual,
so the above is currently treated as a package with two manuals: one
produced from `kubed.texi` and the other from `images/`.
IOW we'd need to tweak the format a bit to avoid the ambiguity.
Maybe we can get away with just a `:doc-files` instead?
Other than that I agree.
AFAICT, the plan is as follows:
- Add support in package specs for "associated files" for each of the
manuals (ideally also for the `:readme`, BTW).
- Arrange to copy those "associated files" to the `doc/<PACKAGE>/`
subdirectory of the `archive(-devel)/` area.
- Massage the HTML files so that `href="snapshot.png"` becomes
`href="<PACKAGE>/snapshot.png"`. For the `:readme` case, we should
instead redirect them to `doc/<PACKAGE>/snapshot.png`.
This should make the HTML links to images work in the web versions of
the manuals. Complements:
- Offer a way to specify part of the package specs directly in the
package itself (presumably within the pseudo-headers of the main
file). Would be useful in general rather than just for "associated
files".
- Maybe also offer some support to generate the list of associated files
dynamically/automatically by scrubbing the generated HTML files?
There is apparently a related issue with the Info version of the manual
when the Texinfo doc is not in the root of the package dir, in which
case when the Info file is moved to the root of the package directory
(which is necessary for the code in `package.el` which adds the
package's dir in `Info-directory-list`), the links to the image
files break. So another related change would be:
- Make sure the links to associated files work also for the Info
versions of the manuals, even when they're moved to the
root directory.
Beside `kubed` there's also `hyperbole` which can be used
for experiments (`hyperbole` suffers from the problem both in the web
version and in the Info version of their manual).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Fri, 18 Apr 2025 18:05:05 GMT)
Full text and
rfc822 format available.
Message #58 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> AFAICT, the plan is as follows:
>
> - Add support in package specs for "associated files" for each of the
> manuals (ideally also for the `:readme`, BTW).
OK, I added a `:doc-files` thingy.
Currently it can be a list of file or dir names, and if it's a dir we
copy all the files in it (but not recursively).
> - Arrange to copy those "associated files" to the `doc/<PACKAGE>/`
> subdirectory of the `archive(-devel)/` area.
Done.
> - Massage the HTML files so that `href="snapshot.png"` becomes
> `href="<PACKAGE>/snapshot.png"`. For the `:readme` case, we should
> instead redirect them to `doc/<PACKAGE>/snapshot.png`.
Done to some extent but I'm not completely sure what to do with the
Kubed manual (and I haven't looked at the `:readme` case at all).
Eshel: could you explain to me the "/assets" thingy in the references
to images in the Texi (and resulting HTML)?
> This should make the HTML links to images work in the web versions of
> the manuals.
And indeed it seems to work for Hyerpbole.
Mats&Robert: please check http://elpa.gnu.org/devel/doc/hyperbole.html
> - Offer a way to specify part of the package specs directly in the
> package itself (presumably within the pseudo-headers of the main
> file). Would be useful in general rather than just for "associated
> files".
Not there yet.
> - Maybe also offer some support to generate the list of associated files
> dynamically/automatically by scrubbing the generated HTML files?
Even less there yet.
> - Make sure the links to associated files work also for the Info
> versions of the manuals, even when they're moved to the
> root directory.
Not there yet either.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Fri, 18 Apr 2025 21:36:03 GMT)
Full text and
rfc822 format available.
Message #61 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> Stefan Monnier writes:
> And indeed it seems to work for Hyerpbole.
> Mats&Robert: please check http://elpa.gnu.org/devel/doc/hyperbole.html
It looks OK, sort of. Two comments:
- We use another css which is stored on the same level as the texi-file, in
the man-folder. The css is missed and a "standard" css is used instead. So
the formatting is not the expected but it is not bad.
I guess having different css for each package will add some extra
complexity, it has to be passed to the texinfo command line I think, but
might be possible to support? WDYT?
Not to mention that our css is for texinfo 7 so not sure how that would
look with texinfo 6.8 that is currently used on ELPA.
- I got the impression that the images would be copied to a flat
structure. Looking in the generated html it looks like the file structure
is kept. Was that the intention?
Example: <img name="Hyperbole Screenshot" src="hyperbole/man/im/hyperbole-cv.png">
That src works so it is fine. Just want to check that there is no
unintended magic going on here.
>> - Make sure the links to associated files work also for the Info
>> versions of the manuals, even when they're moved to the
>> root directory.
> Not there yet either.
For hyperbole it should work to lift the "man/im" folder one level up. No need
to manipulate the texi nor info files for that. Just keep the relative
distance and install them one level up. Is that what you are planning to do?
%% Mats
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Fri, 18 Apr 2025 22:59:04 GMT)
Full text and
rfc822 format available.
Message #64 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> - We use another css which is stored on the same level as the texi-file, in
> the man-folder. The css is missed and a "standard" css is used instead. So
> the formatting is not the expected but it is not bad.
We use our own CSS for all the Texinfo manuals, indeed.
[ Well, it's not exactly "our own", it's stolen from
www.gnu.org/software, IIRC. ]
> I guess having different css for each package will add some extra
> complexity, it has to be passed to the texinfo command line I think, but
> might be possible to support? WDYT?
I think it heavily depends on the purpose. If your CSS has something
specific to Hyperbole, then it would be nice to support that in some
way, but otherwise it seems better to use the same CSS for all the
(Non)GNU ELPA manuals.
> - I got the impression that the images would be copied to a flat
> structure. Looking in the generated html it looks like the file structure
> is kept. Was that the intention?
>
> Example: <img name="Hyperbole Screenshot" src="hyperbole/man/im/hyperbole-cv.png">
>
> That src works so it is fine. Just want to check that there is no
> unintended magic going on here.
I wrote the code under the assumption that the HTML would use file names
relative that "work in place", i.e. that are relative to the location of
the source file. For that reason, the files are copied in a way that
tries to preserve the directory structure. This hopefully also avoids
name conflicts.
>>> - Make sure the links to associated files work also for the Info
>>> versions of the manuals, even when they're moved to the
>>> root directory.
>> Not there yet either.
> For hyperbole it should work to lift the "man/im" folder one level up. No need
> to manipulate the texi nor info files for that. Just keep the relative
> distance and install them one level up. Is that what you are planning to do?
I haven't looked closely, but it's one of the options I'd consider, yes.
Currently for the HTML, I do a search&replace directly on the HTML (in
a naive way, sadly), but it's not so easy to do on the Info file because
it contains "inner pointers" which would need to be adjusted.
Moving the image files like you propose would avoid that problem, but it
comes with another downside: it would break the references to those same
image files contained in the HTML and Texinfo manual bundled in the
tarball. To get both to work correctly, we'd need to *copy* (rather
than move) those files, which would bloat the tarball a bit more.
Another option is to modify the Texinfo before we generate the Info.
This seems more cumbersome to do with the current code but would avoid
both of those problems.
The overall cleaner option might be not to move the Info file.
It's currently not supported by the ELPA protocol, so we'd have to "do
it by hand". This means adding code in the `<PKG>-autoloads.el` file to
tweak `Info-directory-list`, but since we don't get to generate the
`<PKG>-autoloads.el` ourselves, we'd have instead to tweak some *other*
file so as to cause the end-user's Emacs to generate a `<PKG>-autoloads.el`
with the appropriate tweak to `Info-directory-list`. 🙁
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sat, 19 Apr 2025 03:06:07 GMT)
Full text and
rfc822 format available.
Message #67 received at 73425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Stefan:
For Hyperbole with regard to use of our hyperbole.css file, if you prefer
that all the Elpa manuals use the same css, then that is fine with us. The
main reason for our new css file was to add a decent style for reading the
manual on mobile phone-sized devices, but the Elpa css seems to work fine
there now, so no issue there.
Cheers,
Bob
On Fri, Apr 18, 2025 at 6:57 PM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
> > - We use another css which is stored on the same level as the
> texi-file, in
> > the man-folder. The css is missed and a "standard" css is used
> instead. So
> > the formatting is not the expected but it is not bad.
>
> We use our own CSS for all the Texinfo manuals, indeed.
> [ Well, it's not exactly "our own", it's stolen from
> www.gnu.org/software, IIRC. ]
>
> > I guess having different css for each package will add some extra
> > complexity, it has to be passed to the texinfo command line I think,
> but
> > might be possible to support? WDYT?
>
> I think it heavily depends on the purpose. If your CSS has something
> specific to Hyperbole, then it would be nice to support that in some
> way, but otherwise it seems better to use the same CSS for all the
> (Non)GNU ELPA manuals.
>
> > - I got the impression that the images would be copied to a flat
> > structure. Looking in the generated html it looks like the file
> structure
> > is kept. Was that the intention?
> >
> > Example: <img name="Hyperbole Screenshot"
> src="hyperbole/man/im/hyperbole-cv.png">
> >
> > That src works so it is fine. Just want to check that there is no
> > unintended magic going on here.
>
> I wrote the code under the assumption that the HTML would use file names
> relative that "work in place", i.e. that are relative to the location of
> the source file. For that reason, the files are copied in a way that
> tries to preserve the directory structure. This hopefully also avoids
> name conflicts.
>
> >>> - Make sure the links to associated files work also for the Info
> >>> versions of the manuals, even when they're moved to the
> >>> root directory.
> >> Not there yet either.
> > For hyperbole it should work to lift the "man/im" folder one level up.
> No need
> > to manipulate the texi nor info files for that. Just keep the relative
> > distance and install them one level up. Is that what you are planning to
> do?
>
> I haven't looked closely, but it's one of the options I'd consider, yes.
> Currently for the HTML, I do a search&replace directly on the HTML (in
> a naive way, sadly), but it's not so easy to do on the Info file because
> it contains "inner pointers" which would need to be adjusted.
>
> Moving the image files like you propose would avoid that problem, but it
> comes with another downside: it would break the references to those same
> image files contained in the HTML and Texinfo manual bundled in the
> tarball. To get both to work correctly, we'd need to *copy* (rather
> than move) those files, which would bloat the tarball a bit more.
>
> Another option is to modify the Texinfo before we generate the Info.
> This seems more cumbersome to do with the current code but would avoid
> both of those problems.
>
> The overall cleaner option might be not to move the Info file.
> It's currently not supported by the ELPA protocol, so we'd have to "do
> it by hand". This means adding code in the `<PKG>-autoloads.el` file to
> tweak `Info-directory-list`, but since we don't get to generate the
> `<PKG>-autoloads.el` ourselves, we'd have instead to tweak some *other*
> file so as to cause the end-user's Emacs to generate a `<PKG>-autoloads.el`
> with the appropriate tweak to `Info-directory-list`. 🙁
>
>
> Stefan
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sat, 19 Apr 2025 06:41:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> AFAICT, the plan is as follows:
>>
>> - Add support in package specs for "associated files" for each of the
>> manuals (ideally also for the `:readme`, BTW).
>
> OK, I added a `:doc-files` thingy.
> Currently it can be a list of file or dir names, and if it's a dir we
> copy all the files in it (but not recursively).
Just to be sure I didn't miss something, this only relates to the
generation of HTML docs for elpa.{,non}gnu.org, right? So we don't need
any special handling for package-vc?
>> - Arrange to copy those "associated files" to the `doc/<PACKAGE>/`
>> subdirectory of the `archive(-devel)/` area.
>
> Done.
>
>> - Massage the HTML files so that `href="snapshot.png"` becomes
>> `href="<PACKAGE>/snapshot.png"`. For the `:readme` case, we should
>> instead redirect them to `doc/<PACKAGE>/snapshot.png`.
>
> Done to some extent but I'm not completely sure what to do with the
> Kubed manual (and I haven't looked at the `:readme` case at all).
>
> Eshel: could you explain to me the "/assets" thingy in the references
> to images in the Texi (and resulting HTML)?
>
>> This should make the HTML links to images work in the web versions of
>> the manuals.
>
> And indeed it seems to work for Hyerpbole.
> Mats&Robert: please check http://elpa.gnu.org/devel/doc/hyperbole.html
>
>> - Offer a way to specify part of the package specs directly in the
>> package itself (presumably within the pseudo-headers of the main
>> file). Would be useful in general rather than just for "associated
>> files".
>
> Not there yet.
>
>> - Maybe also offer some support to generate the list of associated files
>> dynamically/automatically by scrubbing the generated HTML files?
>
> Even less there yet.
>
>> - Make sure the links to associated files work also for the Info
>> versions of the manuals, even when they're moved to the
>> root directory.
>
> Not there yet either.
>
>
> Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sat, 19 Apr 2025 07:12:05 GMT)
Full text and
rfc822 format available.
Message #73 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Hi Stefan,
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> AFAICT, the plan is as follows:
>>
>> - Add support in package specs for "associated files" for each of the
>> manuals (ideally also for the `:readme`, BTW).
>
> OK, I added a `:doc-files` thingy.
> Currently it can be a list of file or dir names, and if it's a dir we
> copy all the files in it (but not recursively).
>
>> - Arrange to copy those "associated files" to the `doc/<PACKAGE>/`
>> subdirectory of the `archive(-devel)/` area.
>
> Done.
>
>> - Massage the HTML files so that `href="snapshot.png"` becomes
>> `href="<PACKAGE>/snapshot.png"`. For the `:readme` case, we should
>> instead redirect them to `doc/<PACKAGE>/snapshot.png`.
>
> Done to some extent but I'm not completely sure what to do with the
> Kubed manual (and I haven't looked at the `:readme` case at all).
>
> Eshel: could you explain to me the "/assets" thingy in the references
> to images in the Texi (and resulting HTML)?
So currently the way we include images in kubed.texi is as follows:
--8<---------------cut here---------------start------------->8---
@ifhtml
@float
@image{/assets/kubed-overview,,,Image: Four different kinds of Kubed buffers in Emacs,.png}
@caption{Pods, logs, shells, YAMLs, all in one integrated interface}
@end float
@end ifhtml
--8<---------------cut here---------------end--------------->8---
This refers to https://eshelyaron.com/assets/kubed-overview.png
I'd love to change these references to relative paths so they also work
on the ELPA server, but I'm still not sure how to do that: we provide
the manual at https://eshelyaron.com/kubed.html (all nodes in one page)
and at https://eshelyaron.com/man/kubed/ (each node in a separate page).
The image references need to work from these two different locations.
That's easy to do with absolute references. With relative references,
not so much... It would be nice if Texinfo allowed us to use different
references depending on whether or not "--no-split" is in effect, but I
couldn't find such an option.
Any ideas/suggestions?
>> This should make the HTML links to images work in the web versions of
>> the manuals.
>
> And indeed it seems to work for Hyerpbole.
> Mats&Robert: please check http://elpa.gnu.org/devel/doc/hyperbole.html
Cool!
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sat, 19 Apr 2025 07:17:04 GMT)
Full text and
rfc822 format available.
Message #76 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> From: Mats Lidell <matsl <at> gnu.org>
> Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
> 73425 <at> debbugs.gnu.org, me <at> eshelyaron.com, Robert Weiner
> <rswgnu <at> gmail.com>
> Date: Fri, 18 Apr 2025 23:35:38 +0200
>
> - We use another css which is stored on the same level as the texi-file, in
> the man-folder. The css is missed and a "standard" css is used instead. So
> the formatting is not the expected but it is not bad.
>
> I guess having different css for each package will add some extra
> complexity, it has to be passed to the texinfo command line I think, but
> might be possible to support? WDYT?
>
> Not to mention that our css is for texinfo 7 so not sure how that would
> look with texinfo 6.8 that is currently used on ELPA.
Texinfo supports use of non-default CSS, see the node "HTML CSS" in
the Texinfo manual.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sat, 19 Apr 2025 08:28:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
> 73425 <at> debbugs.gnu.org, Mats Lidell <matsl <at> gnu.org>, Robert Weiner
> <rswgnu <at> gmail.com>
> Date: Sat, 19 Apr 2025 09:10:58 +0200
>
> I'd love to change these references to relative paths so they also work
> on the ELPA server, but I'm still not sure how to do that: we provide
> the manual at https://eshelyaron.com/kubed.html (all nodes in one page)
> and at https://eshelyaron.com/man/kubed/ (each node in a separate page).
> The image references need to work from these two different locations.
> That's easy to do with absolute references. With relative references,
> not so much... It would be nice if Texinfo allowed us to use different
> references depending on whether or not "--no-split" is in effect, but I
> couldn't find such an option.
>
> Any ideas/suggestions?
Use "@ifset foo" and "@ifclear foo", and build the docs with -Dfoo
when you need it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sat, 19 Apr 2025 14:07:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 73425 <at> debbugs.gnu.org (full text, mbox):
>>> AFAICT, the plan is as follows:
>>>
>>> - Add support in package specs for "associated files" for each of the
>>> manuals (ideally also for the `:readme`, BTW).
>>
>> OK, I added a `:doc-files` thingy.
>> Currently it can be a list of file or dir names, and if it's a dir we
>> copy all the files in it (but not recursively).
>
> Just to be sure I didn't miss something, this only relates to the
> generation of HTML docs for elpa.{,non}gnu.org, right? So we don't need
> any special handling for package-vc?
That's right (and this option is tentative: it may change or even
disappear altogether).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sat, 19 Apr 2025 14:13:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> So currently the way we include images in kubed.texi is as follows:
>
> --8<---------------cut here---------------start------------->8---
> @ifhtml
> @float
> @image{/assets/kubed-overview,,,Image: Four different kinds of Kubed buffers in Emacs,.png}
> @caption{Pods, logs, shells, YAMLs, all in one integrated interface}
> @end float
> @end ifhtml
> --8<---------------cut here---------------end--------------->8---
>
> This refers to https://eshelyaron.com/assets/kubed-overview.png
Ah, so it's something "personal", nice, thanks. I thought it could be
some "standard convention" used on some system somewhere.
> I'd love to change these references to relative paths so they also work
> on the ELPA server,
I guess our scripts could be told to strip away the "/assets/" part.
I'll think about it.
> but I'm still not sure how to do that: we provide
> the manual at https://eshelyaron.com/kubed.html (all nodes in one page)
> and at https://eshelyaron.com/man/kubed/ (each node in a separate page).
> The image references need to work from these two different locations.
If you change those to
https://eshelyaron.com/man/kubed/
and
https://eshelyaron.com/kubed/singlepage.html
then relative file names should work fine, right?
[ Obviously, it comes with its own problems. ]
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Sun, 20 Apr 2025 09:21:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> Eli Zaretskii writes:
> > From: Mats Lidell <matsl <at> gnu.org>
> > Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
> > 73425 <at> debbugs.gnu.org, me <at> eshelyaron.com, Robert Weiner
> > <rswgnu <at> gmail.com>
> > Date: Fri, 18 Apr 2025 23:35:38 +0200
> >
> > - We use another css which is stored on the same level as the texi-file, in
> > the man-folder. The css is missed and a "standard" css is used instead. So
> > the formatting is not the expected but it is not bad.
> >
> > I guess having different css for each package will add some extra
> > complexity, it has to be passed to the texinfo command line I think, but
> > might be possible to support? WDYT?
> >
> > Not to mention that our css is for texinfo 7 so not sure how that would
> > look with texinfo 6.8 that is currently used on ELPA.
>
> Texinfo supports use of non-default CSS, see the node "HTML CSS" in
> the Texinfo manual.
Yes. We use that for the HTML we generate and bundle with Hyperbole. But that
is "missed" when ELPA generates the HTML since it does not use the CSS we
supply.
However, I understand that having the same CSS for all manuals is a good idea
and, as Bob pointed out in separate reply, the issues we had in the past seems
to have been solved in that CSS. So we are good without my suggestion.
%% Mats
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Tue, 22 Apr 2025 10:25:03 GMT)
Full text and
rfc822 format available.
Message #91 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Hi,
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> So currently the way we include images in kubed.texi is as follows:
>>
>> --8<---------------cut here---------------start------------->8---
>> @ifhtml
>> @float
>> @image{/assets/kubed-overview,,,Image: Four different kinds of Kubed buffers in Emacs,.png}
>> @caption{Pods, logs, shells, YAMLs, all in one integrated interface}
>> @end float
>> @end ifhtml
>> --8<---------------cut here---------------end--------------->8---
>>
>> This refers to https://eshelyaron.com/assets/kubed-overview.png
>
> Ah, so it's something "personal", nice, thanks. I thought it could be
> some "standard convention" used on some system somewhere.
>
>> I'd love to change these references to relative paths so they also work
>> on the ELPA server,
>
> I guess our scripts could be told to strip away the "/assets/" part.
> I'll think about it.
Actually, Eli's suggestion to use @ifset and -Dfoo works pretty well :)
So I don't think any special handling is required, as I can just change
the image references to use relative paths and leverage @ifset to pick
another relative path for the node-per-page case.
After I'll make these changes in Kubed, we'll just need to update
elpa-packages with something like:
diff --git a/elpa-packages b/elpa-packages
index e4ae18a4be..711d8ff986 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -477,7 +477,8 @@
;; :readme "README")
(kmb :url nil)
(kubed :url "https://git.sr.ht/~eshel/kubed"
- :doc "kubed.texi")
+ :doc "kubed.texi"
+ :doc-files ("assets/"))
(landmark :url nil)
(latex-table-wizard :url "https://github.com/enricoflor/latex-table-wizard"
:doc "latex-table-wizard.texi")
Thanks,
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Tue, 22 Apr 2025 13:20:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> (kubed :url "https://git.sr.ht/~eshel/kubed"
> - :doc "kubed.texi")
> + :doc "kubed.texi"
> + :doc-files ("assets/"))
Actually, `:doc-files` disappeared yesterday. Now it should "just work".
That is: as long as the file names in the src="..." are relative to the
place where the doc's source file is located. I can't see any `assets/`
directory currently in the Kubed source code, so I can't judge whether
that would work.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Tue, 22 Apr 2025 13:59:02 GMT)
Full text and
rfc822 format available.
Message #97 received at submit <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier writes:
>> (kubed :url "https://git.sr.ht/~eshel/kubed"
>> - :doc "kubed.texi")
>> + :doc "kubed.texi"
>> + :doc-files ("assets/"))
>
> Actually, `:doc-files` disappeared yesterday. Now it should "just work".
>
> That is: as long as the file names in the src="..." are relative to the
> place where the doc's source file is located.
Nice!
> I can't see any `assets/` directory currently in the Kubed source
> code, so I can't judge whether that would work.
Now there is :) Let's see how this works on elpa-devel.
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Tue, 22 Apr 2025 13:59:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Tue, 22 Apr 2025 22:25:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 73425 <at> debbugs.gnu.org (full text, mbox):
> Now there is :) Let's see how this works on elpa-devel.
So, how do you like the result?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Wed, 23 Apr 2025 07:08:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Now there is :) Let's see how this works on elpa-devel.
>
> So, how do you like the result?
Pretty neat! It's great that it Just Works like that.
The images appear somewhat bigger than I'd like them to, but that's a
secondary concern, and probably something I can tweak on my end.
Thank you!
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Wed, 23 Apr 2025 14:30:08 GMT)
Full text and
rfc822 format available.
Message #109 received at 73425 <at> debbugs.gnu.org (full text, mbox):
>> So, how do you like the result?
> Pretty neat! It's great that it Just Works like that.
> The images appear somewhat bigger than I'd like them to, but that's a
> secondary concern, and probably something I can tweak on my end.
Sizing images is definitely above my pay grade, 🙂
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Wed, 23 Apr 2025 15:41:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> So, how do you like the result?
>> Pretty neat! It's great that it Just Works like that.
>> The images appear somewhat bigger than I'd like them to, but that's a
>> secondary concern, and probably something I can tweak on my end.
What images are you referring to?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Wed, 23 Apr 2025 17:07:04 GMT)
Full text and
rfc822 format available.
Message #115 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Hi Philip,
Philip Kaludercic <philipk <at> posteo.net> writes:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>>> So, how do you like the result?
>>> Pretty neat! It's great that it Just Works like that.
>>> The images appear somewhat bigger than I'd like them to, but that's a
>>> secondary concern, and probably something I can tweak on my end.
>
> What images are you referring to?
Those that now appear in the HTML Kubed manual that ELPA generates.
See https://elpa.gnu.org/devel/doc/kubed.html#Overview for example.
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Wed, 23 Apr 2025 17:12:04 GMT)
Full text and
rfc822 format available.
Message #118 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Eshel Yaron <me <at> eshelyaron.com> writes:
> Hi Philip,
>
> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>
>>>>> So, how do you like the result?
>>>> Pretty neat! It's great that it Just Works like that.
>>>> The images appear somewhat bigger than I'd like them to, but that's a
>>>> secondary concern, and probably something I can tweak on my end.
>>
>> What images are you referring to?
>
> Those that now appear in the HTML Kubed manual that ELPA generates.
> See https://elpa.gnu.org/devel/doc/kubed.html#Overview for example.
On my end it appears as "max-width: 100%;", which appears fine to me.
Were you expecting wider margins? Something like
max-width: 90%;
margin: auto;
display: block;
?
>
>
> Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73425; Package
emacs.
(Wed, 23 Apr 2025 18:54:03 GMT)
Full text and
rfc822 format available.
Message #121 received at 73425 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> posteo.net> writes:
> Eshel Yaron <me <at> eshelyaron.com> writes:
>
>> Hi Philip,
>>
>> Philip Kaludercic <philipk <at> posteo.net> writes:
>>
>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>
>>>>>> So, how do you like the result?
>>>>> Pretty neat! It's great that it Just Works like that.
>>>>> The images appear somewhat bigger than I'd like them to, but that's a
>>>>> secondary concern, and probably something I can tweak on my end.
>>>
>>> What images are you referring to?
>>
>> Those that now appear in the HTML Kubed manual that ELPA generates.
>> See https://elpa.gnu.org/devel/doc/kubed.html#Overview for example.
>
> On my end it appears as "max-width: 100%;", which appears fine to me.
> Were you expecting wider margins? Something like
>
> max-width: 90%;
> margin: auto;
> display: block;
>
> ?
Yes, with those it's looks a little better IMO. Even max-width: 75%
seems wide enough to me. On mobile it looks great as it is, BTW.
Eshel
This bug report was last modified 108 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.