Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include images in rustdoc output #32104

Open
emoon opened this issue Mar 7, 2016 · 43 comments · May be fixed by #107640
Open

Include images in rustdoc output #32104

emoon opened this issue Mar 7, 2016 · 43 comments · May be fixed by #107640
Assignees
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@emoon
Copy link
Contributor

emoon commented Mar 7, 2016

As written by Luthaf over here

https://users.rust-lang.org/t/include-images-in-rustdoc-output/3487

"Hi rustaceans!

Images in documentation can be really useful to provide some insight on algorithms or modules organisation.

It is already possible to insert a link to an image in documentation comment

/// ![Alt version](url://for/this/image.png)

But using this method, we only get to include images already available in some place of Internet.

Is it a way to make rustdoc copy some files to the target/doc folder, so that it is easy to include specific images in the documentation? The same could go for other static files, like specific CSS or JS.

Is it possible yet? If not, do you think it is worth it?"

I this this would be awesome to include as sometimes using images is much easier when explain something than showing text.

@bluss
Copy link
Member

bluss commented Mar 7, 2016

I second this, images can greatly help explaining (geometrical split_at example).

@sanxiyn sanxiyn added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Mar 11, 2016
@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 24, 2017
@jimblandy
Copy link
Contributor

Since the focus is on doxidize now, rustdoc is in maintenance-only mode. Should this be closed?

cc: @steveklabnik

@steveklabnik
Copy link
Member

I'd say "maintenance-only" mode is a bit strong; rustdoc has its own team and they're still working on new stuff. It's entirely possible that this will get added to rustdoc.

@TotalKrill
Copy link

TotalKrill commented Jul 30, 2018

Would love this as well! Has there been any updates?

@ZhangHanDong
Copy link

It‘s work

//! <div>
//! <img src="../../../images/rustbook.jpg" height="300" width="220" />
//! </div>
//! <hr/>

@crepererum
Copy link
Contributor

crepererum commented Nov 22, 2018

That only works locally if you're building the docs for your own crate. Does not work on docs.rs or if the crate is a dependency of something else.

Background:
The referred image is not copied / tracked.

@ZhangHanDong
Copy link

@crepererum you're right. One solution is to separate the doc file and manually modify it.

@crepererum
Copy link
Contributor

Or you host the image somewhere, like on GitHub pages (that's what ndarray is doing here https://github.com/rust-ndarray/ndarray/blob/master/src/impl_views.rs )

@TotalKrill
Copy link

I think what would be most optimal is if there could be a folder where images for the doc could be stored in the crate folder structure.

There is one huge painpoint here though, and that is a lot of people just love to generate extremely large pictures to include in the crates. For no reason: ClickBait article with example

So if this should be in the code, the file size should be limited.

@donbright
Copy link

donbright commented Apr 15, 2019

There is a workaround.

You can insert the image data, base64 encoded, directly into your rust source code comments,
and rust-doc will pass this to the html, where it will become an inline image in the html code.
This is based on rfc2397 aka the data URI.

http://www.bigfastblog.com/embed-base64-encoded-images-inline-in-html
https://tools.ietf.org/html/rfc2397

$ base64 ../images/mypicture.png  | awk ' { print "/// " $1 } ' > myfile.b64
myfile.rs:

/// my function does blah blah blah. here is a picture:
/// <div>
/// <img src="data:image/png;base64,
/// iVBORw0KGgetcetcetc                       <-- copy/paste myfile.b64 here
/// ....                                      <-- several dozen lines of myfile.b64
/// JDIOIDondio00778==                        <-- last line of myfile.b64
/// ">
/// </div>
fn myfunction(x:u64)->bool { x<5 }
$ cargo doc

Now the html file under target/whatever will have the png image baked inside of it as base64 code.

I think this might be possible with svg but havent tested.


I think it might be nice to consider if rustdoc could do this on it's own, automatically, taking a <img src=../../image.png file, encoding it as base64, and inline it into the html file itself, without the user having to insert base64 directly into their rust comments.

@GuillaumeGomez
Copy link
Member

I don't think this is a good idea: it'd force rustdoc to download the content to know if it's an image or a video or anything else. Also, from a security perspective, I think this wouldd be an issue as well (cc @pietroalbini ).

@pietroalbini
Copy link
Member

From my point of view it'd be fine if rustdoc included images present in the crate's source tarball into the generated docs. It definitely should not download images from the Internet.

@GuillaumeGomez
Copy link
Member

I don't see the difference between local image and one from the internet. In both case, it can't be trusted.

@TotalKrill
Copy link

Well then, I am guessing the current way to input it into a comment as base64 isnt much different.

The end result should still be an image shown online, wherever it is a link to an image, or an image generated from base64.

Nothing can be trusted anywhere, but still we do it.

@pietroalbini
Copy link
Member

I don't see the difference between local image and one from the internet. In both case, it can't be trusted.

You can do the same thing with workarounds today, and you'll still be able to do it with workarounds in the future. Besides, it's a legit feature request.

@GuillaumeGomez
Copy link
Member

Indeed, I don't know why but I was kinda confusing the URL thing... Then yes, it'll require to move the file content to a given target and be sure to not have conflicts. Urg... Headache ahead! I'll try to do it in not too long from now.

@GuillaumeGomez GuillaumeGomez self-assigned this Jan 31, 2020
@Luthaf
Copy link

Luthaf commented Jan 31, 2020

Then yes, it'll require to move the file content to a given target and be sure to not have conflicts.

A possible solution for this would be to hash the image content, move them to target/doc/{crate}/static-img/{hash}.{ext}, and rewrite the links in the generated HTML accordingly. (static-img not being a valid module name should not clash with other files)

@GuillaumeGomez
Copy link
Member

If I hash the path, it might be easier, indeed. I didn't want to create another folder but that would fix the naming conflict so I think I'll do that. Thanks for the tips!

@Luthaf
Copy link

Luthaf commented Feb 1, 2020

I would rather hash the file content than the path, since the same file might be referred to by different .rs files, using different paths.

@tspiteri
Copy link
Contributor

With this feature, would it also be possible to link to a file included in the crate inside the doc(html_root_url) attribute?

@dherman
Copy link
Contributor

dherman commented May 16, 2021

I ran into this today and would love to see it happen. @GuillaumeGomez is this something I could help with? I've never contributed to rustdoc before but if you'd be interested in mentoring me maybe I could help implement it?

@TotalKrill
Copy link

We should encourage usage of SVG as format in documentation output, it is a well working format for block-diagrams, flowcharts and similar things that are actually useful for documentation purposes.

Nice tip though!

@Andlon
Copy link

Andlon commented Feb 16, 2022

If you can rely on Rust >= 1.54, then using embed-doc-image is also similarly simple:

/// A diagram of something
///
/// ![Diagram](diagram_label)
/// 
/// The rest of the docs.
#![doc = embed_image!("diagram_label", "images/diagram.png")]

This should work with all major file formats supported on the web, and works both locally and on docs.rs. The example code in the docs is much more complex because they explain how to have a graceful fallback to Rust < 1.54. If you don't need this then it's simple to use. I should probably update the docs with the simpler case first.

Admittedly the crate could still need some improvements in terms of conditionally enabling the feature (so that, for example, for non-doc builds you can easily skip the embed macro compilation). I'm too pressed on time for doing that myself atm, but it wouldn't take too much effort to improve further - though there should probably be a brief discussion about design first.

@GuillaumeGomez
Copy link
Member

You can make it generate cfg(doc) and it'll only be generated when rustdoc is running.

@Andlon
Copy link

Andlon commented Feb 16, 2022

@GuillaumeGomez: that sounds perfect. Seems like cfg(doc) has not been stabilized yet, is this correct? According to https://doc.rust-lang.org/beta/unstable-book/language-features/doc-cfg.html.

@GuillaumeGomez
Copy link
Member

doc(cfg()) != cfg(doc). 😉 It's been stable for a while now. There is also cfg(doctest) (which is when you run rustdoc --test).

@GuillaumeGomez
Copy link
Member

GuillaumeGomez commented Feb 16, 2022

The documentation is here.

@Andlon
Copy link

Andlon commented Feb 16, 2022

@GuillaumeGomez: that's very interesting! I was led to believe otherwise by the following sentence in the unstable book (see link above):

image

I couldn't find out when cfg(doc) was stabilized. This would be useful info for documenting a fallback solution. Do you know where to find this info?

While this cfg directive seems very useful in the context of embedding images, it doesn't directly solve the issue of embed-doc-image, which is that you'll end up including syn and some other dependencies in your non-doc builds. I believe it's not possible to conditionally enable a Cargo feature only for doc builds somehow, is it?

EDIT: It would however lead to an improvement in the sense that no doc-related code is generated for non-doc builds, other than having to build the dependencies.

@GuillaumeGomez
Copy link
Member

No even though there is an open issue about that on cargo. But it hasn't received much attention unfortunately.

As for cfg(doc), it's stable since 1.40.

@GuillaumeGomez
Copy link
Member

And here is the cargo issue.

@GuillaumeGomez
Copy link
Member

I opened an RFC for this feature: rust-lang/rfcs#3397

blp added a commit to feldera/feldera that referenced this issue May 14, 2023
Our architecture diagram is broken if you run `cargo doc`.  I looked
into it.  It seems that it's hard to put images into Rustdoc (see
[rust-lang/rust#32104]).  You can do it with
absolute URLs that point to some fixed HTTPS location, you can hack
things up with helpers so that images get recoded into data: URLs, and a
few other strategies.

But our architecture diagram can work OK in ascii art, and that doesn't
require any extra hacks, so here's what I've got.

Signed-off-by: Ben Pfaff <blp@feldera.com>
blp added a commit to feldera/feldera that referenced this issue May 17, 2023
Our architecture diagram is broken if you run `cargo doc`.  I looked
into it.  It seems that it's hard to put images into Rustdoc (see
[rust-lang/rust#32104]).  You can do it with
absolute URLs that point to some fixed HTTPS location, you can hack
things up with helpers so that images get recoded into data: URLs, and a
few other strategies.

But our architecture diagram can work OK in ascii art, and that doesn't
require any extra hacks, so here's what I've got.

Signed-off-by: Ben Pfaff <blp@feldera.com>
blp added a commit to feldera/feldera that referenced this issue May 17, 2023
Our architecture diagram is broken if you run `cargo doc`.  I looked
into it.  It seems that it's hard to put images into Rustdoc (see
[rust-lang/rust#32104]).  You can do it with
absolute URLs that point to some fixed HTTPS location, you can hack
things up with helpers so that images get recoded into data: URLs, and a
few other strategies.

But our architecture diagram can work OK in ascii art, and that doesn't
require any extra hacks, so here's what I've got.

Signed-off-by: Ben Pfaff <blp@feldera.com>
github-merge-queue bot pushed a commit to bevyengine/bevy that referenced this issue Jul 31, 2023
# Objective

This PR continues #8885

It aims to improve the `Mesh` documentation in the following ways:
- Put everything at the "top level" instead of the "impl".
- Explain better what is a Mesh, how it can be created, and that it can
be edited.
- Explain it can be used with a `Material`, and mention
`StandardMaterial`, `PbrBundle`, `ColorMaterial`, and
`ColorMesh2dBundle` since those cover most cases
- Mention the glTF/Bevy vocabulary discrepancy for "Mesh"
- Add an image for the example
- Various nitpicky modifications

## Note

- The image I added is 90.3ko which I think is small enough?
- Since rustdoc doesn't allow cross-reference not in dependencies of a
subcrate [yet](rust-lang/rust#74481), I have a
lot of backtick references that are not links :(
- Since rustdoc doesn't allow linking to code in the crate (?) I put
link to github directly.
- Since rustdoc doesn't allow embed images in doc
[yet](rust-lang/rust#32104), maybe
[soon](rust-lang/rfcs#3397), I had to put only a
link to the image. I don't think it's worth adding
[embed_doc_image](https://docs.rs/embed-doc-image/latest/embed_doc_image/)
as a dependency for this.
cart pushed a commit to bevyengine/bevy that referenced this issue Aug 10, 2023
# Objective

This PR continues #8885

It aims to improve the `Mesh` documentation in the following ways:
- Put everything at the "top level" instead of the "impl".
- Explain better what is a Mesh, how it can be created, and that it can
be edited.
- Explain it can be used with a `Material`, and mention
`StandardMaterial`, `PbrBundle`, `ColorMaterial`, and
`ColorMesh2dBundle` since those cover most cases
- Mention the glTF/Bevy vocabulary discrepancy for "Mesh"
- Add an image for the example
- Various nitpicky modifications

## Note

- The image I added is 90.3ko which I think is small enough?
- Since rustdoc doesn't allow cross-reference not in dependencies of a
subcrate [yet](rust-lang/rust#74481), I have a
lot of backtick references that are not links :(
- Since rustdoc doesn't allow linking to code in the crate (?) I put
link to github directly.
- Since rustdoc doesn't allow embed images in doc
[yet](rust-lang/rust#32104), maybe
[soon](rust-lang/rfcs#3397), I had to put only a
link to the image. I don't think it's worth adding
[embed_doc_image](https://docs.rs/embed-doc-image/latest/embed_doc_image/)
as a dependency for this.
@ryanpeach
Copy link

This is how I did it in Github Actions, not complicated, might not be worth a full RFC. However, it would be nice if rustdoc could do this natively so it could check if the image link is valid. ryanpeach/OrbitingSandRust#102

@GuillaumeGomez
Copy link
Member

Sure, it works in your CI, but how does it work for crates depending on yours? Are your images included into your crate package? If so you're doing something very wrong.

@ryanpeach
Copy link

Just including my PR so that others looking for a more immediate solution who find this on google can see an example.

@frewsxcv
Copy link
Member

Sure, it works in your CI, but how does it work for crates depending on yours? Are your images included into your crate package? If so you're doing something very wrong.

Is there a particular issue with including images in a crate package besides size?

@GuillaumeGomez
Copy link
Member

Not that I can think of. The RFC is currently on hold until the potential cargo archive format becomes a reality (as mentioned here).

@frewsxcv
Copy link
Member

If so you're doing something very wrong.

@GuillaumeGomez So if this is the only way to do it, then why is it "very wrong"?

@GuillaumeGomez
Copy link
Member

I answered (too aggressively) to:

This is how I did it in Github Actions, not complicated, might not be worth a full RFC. However, it would be nice if rustdoc could do this natively so it could check if the image link is valid. ryanpeach/OrbitingSandRust#102

In particular this part:

might not be worth a full RFC

The fact that we might includes megabytes (if not more) of data by default only for documentation sounds like something that should be very carefully considered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet