-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Feature Request: Source code highlight and math formula rendering #10758
Comments
The proposal seems good. You can add a PR for it if you like |
Your implementation is working fully offline? |
Yes, as far as I tested. It can work offline. @mirek190 |
The katex library is too big for this a nice-to-have feature like this (takes > 1MB from bundled size). We should find other alternatives. |
Why is the bundle size a concern here? |
On my build (macos metal), the server without webui is just 1.8MB. So including a 2MB+ frontend doesn't seem right to me. Also katex is quite a nice-to-have feature. Having a 1.5MB library for the only purpose of rendering latex is quite wasteful. To put it into perspective, all the other part of the UI (daisyui + tailwindcss + vuejs + highlight) combined is just less than 600KB. |
Just to be clear, adding syntax highlighting is quite trivial and only cost 100KB to the bundle, so it will be added. We only have the problem with katex, which has too much JS code and at the same time, also use custom embedded fonts |
I understand, but if that's what it takes to render latex, I think we should consider it. I don't think that proper rendering of the model responses is just a nice-to-have feature, I think it is borderline mandatory for an usable UI. Realistically, it may not be possible to find a smaller library, since all latex rendering is going to require custom fonts. Maybe it could be optionally loaded from cdn? |
Yes I was thinking about that too. We can add an option under settings to enable latex rendering, and explicitly state that it will use katex from CDN (not from local) Another option could be to use gzip compression at it can reduce up the storage size to only 30%. But that requires linking against |
I suspect it should be possible to avoid needing to link to |
Hmm yes that's a good idea. It's possible to pre-compress the file and set appropriate HTTP header as you said. It will break if the client don't have support for gzip deflate, but I think we're fine because no one gonna use internet explorer |
Note that Brotli is also supported on all browsers except IE, and usually gives about 20% better compression than gzip. |
hmm yeah I do acknowledge brotli, but I also remember some users use this behind a reverse proxy, which may not have support for brotli (i.e. some user may try to decompress the data and encode it back in gzip) For now gzip is already good enough, we can switch to brotli in the future if we really need. |
Which reverse proxies don't support Brotli? Brotli is more than 10 years old, and e.g. nginx has supported it since 2016. |
nginx don't have it built-in, need to be installed as a module |
Ah, I didn't know that. Makes sense to stick to gzip then! |
Prerequisites
Feature Description
Motivation
The following are missing in the default webui:
Possible Implementation
This can be down by using highlight.js and markdown-it-katex-gpt in the llama-server webui.
I've implemented this by the following steps.
main.js
likeThe text was updated successfully, but these errors were encountered: