[FR] Code preview in opengraph image when linking to file #11098

New Issue

GiteaMirror · 2025-11-02T09:27:30-06:00

GiteaMirror commented

2025-11-02 09:27:30 -06:00

Originally created by @nyxkrage on GitHub (Jun 24, 2023).

Feature Description

Currently, when a link to a file on Gitea is shared, the OpenGraph image is simply the user's or organization's profile picture. I personally don't think this is a very good or informative use of the space.

Instead, I propose that we can, like Sourcegraph, show a preview of the file that is being linked to.
This would provide an instant overview of the code without having to click a link.

I have on my personal fork of Gitea implemented this in a very basic state, using jiro4989/textimg, and alecthomas/chroma, which uses chroma to syntax highlight with ANSI escape codes, and then using the parser from textimg to generate a list of tokens that should be highlighted, and then it creates the actual image with gg. However, my implementation isn't very ideal since the URL being used is ROOT_URL/org/repo/src/og/<branch>/<path>, it currently only uses Catppuccin Mocha for the highlighting, and there is no form of caching.

There are some important differences that there should be from my primitive implementation that should probably be discussed before any work starts on this.

Which URL should be used? I imagine something like ROOT_URL/org/repo/og/branch/<branch>/<path> could make sense, though maybe it should be an API route instead.
Should the images be cached, or should that be up to the services that display the embeds.
Should there be a separate option to control the color scheme used for the preview image, or should it just be controlled by the default theme for the entire instance?

My implementation can be seen here: OpenGraph Changes on my Gitea fork

Screenshots

Current Behaviour

Proposed Behavior

Originally created by @nyxkrage on GitHub (Jun 24, 2023). ### Feature Description Currently, when a link to a file on Gitea is shared, the OpenGraph image is simply the user's or organization's profile picture. I personally don't think this is a very good or informative use of the space. Instead, I propose that we can, like [Sourcegraph](https://sourcegraph.com), show a preview of the file that is being linked to. This would provide an instant overview of the code without having to click a link. I have on my personal fork of Gitea implemented this in a very basic state, using `jiro4989/textimg`, and `alecthomas/chroma`, which uses chroma to syntax highlight with ANSI escape codes, and then using the parser from textimg to generate a list of tokens that should be highlighted, and then it creates the actual image with gg. However, my implementation isn't very ideal since the URL being used is `ROOT_URL/org/repo/src/og/<branch>/<path>`, it currently only uses Catppuccin Mocha for the highlighting, and there is no form of caching. There are some important differences that there should be from my primitive implementation that should probably be discussed before any work starts on this. * Which URL should be used? I imagine something like `ROOT_URL/org/repo/og/branch/<branch>/<path>` could make sense, though maybe it should be an API route instead. * Should the images be cached, or should that be up to the services that display the embeds. * Should there be a separate option to control the color scheme used for the preview image, or should it just be controlled by the default theme for the entire instance? My implementation can be seen here: [OpenGraph Changes on my Gitea fork](https://gitea.pid1.sh/sanctureplicum/gitea/compare/c641a22f2a7f5c404accb67f6aea4a000f7f6e80..develop) ### Screenshots Current Behaviour ![opengraph embed on discord when linking to a file on gitea](https://github.com/go-gitea/gitea/assets/46626618/c428c003-9f02-4ff8-8853-d8fa881c1e62) Proposed Behavior ![opengraph embed on discord when linking to a file on sourcegraph](https://github.com/go-gitea/gitea/assets/46626618/c78f5f78-33f6-46d5-8e8c-0e1d0dbf2ec3) ![opengraph embed on discord when linking to a file on my fork of gitea](https://github.com/go-gitea/gitea/assets/46626618/656886a2-2962-4c8e-8ded-b4bed184ea8d)

GiteaMirror added the type/proposal type/feature labels 2025-11-02 09:27:30 -06:00

GiteaMirror commented

2025-11-02 09:27:31 -06:00

@jolheiser commented on GitHub (Jun 24, 2023):

The changes seems fairly self-contained, which is nice to see.

I think an option to (dis/en)able it would be good, as I'd imagine for smaller instances you'd end up with either more load with caching off, or more storage usage if each image is cached.

In terms of color scheme, perhaps configurable and use the instance default if unset.

The URL route I don't have a strong opinion on, the proposed one sounds okay to me.

@jolheiser commented on GitHub (Jun 24, 2023): The changes seems fairly self-contained, which is nice to see. I think an option to (dis/en)able it would be good, as I'd imagine for smaller instances you'd end up with either more load with caching off, or more storage usage if each image is cached. In terms of color scheme, perhaps configurable and use the instance default if unset. The URL route I don't have a strong opinion on, the proposed one sounds okay to me.

GiteaMirror commented

2025-11-02 09:27:32 -06:00

@lunny commented on GitHub (Jun 25, 2023):

The loading should be on frontend and the markup parser could have a special class name for them.

@lunny commented on GitHub (Jun 25, 2023): The loading should be on frontend and the markup parser could have a special class name for them.

GiteaMirror commented

2025-11-02 09:27:32 -06:00

@nyxkrage commented on GitHub (Jun 25, 2023):

I think an option to (dis/en)able it would be good

Yeah this does seem like a necessity, I'd imagine the extra load would be quite undesirable for most instances.
Keeping it turned off by default, just like LFS, seems like the expected behavior to me.

The loading should be on frontend...

I'm not quite sure whats meant by this. If you mean that the image should be generated on the frontend, then I don't believe that is possible with the way OpenGraph works, as it needs a proper URL to an image file.

@nyxkrage commented on GitHub (Jun 25, 2023): > I think an option to (dis/en)able it would be good Yeah this does seem like a necessity, I'd imagine the extra load would be quite undesirable for most instances. Keeping it turned off by default, just like LFS, seems like the expected behavior to me. > The loading should be on frontend... I'm not quite sure whats meant by this. If you mean that the image should be generated on the frontend, then I don't believe that is possible with the way OpenGraph works, as it needs a proper URL to an image file.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11098