Document viewer

[blakerosenthal]

• Add API endpoints for document content
• Add source content viewer to UI

Closes https://github.com/Quansight/ragna/issues/466

[blakerosenthal]

@pmeier I have two outstanding questions before being ready for a full review:

1. Are we only supporting PDFs right now, or do we want to include all supported types? It doesn't seem too difficult to just send any blob to the browser and let the browser decide whether to display it or offer it as a download.
2. I'm currently just calling the Document.read() method and sending the entire blob to the browser wrapped in a fastapi.Response. I'd be interested in your thoughts on how this should be chunked and streamed properly.

Here's a video of how it looks so far.

https://github.com/user-attachments/assets/9d299775-60c8-48fb-89d7-f90f7d4b2c4a

[pmeier]

1. Are we only supporting PDFs right now, or do we want to include all supported types? It doesn't seem too difficult to just send any blob to the browser and let the browser decide whether to display it or offer it as a download.

Does the browser handle this automatically? Meaning, we just pass it a blob and the browser figures out whether it can show it (.pdf, .md, .txt) or offer it as download (.pptx, .docx)? If yes, that would be awesome and we should really have this feature for everything.

2. I'm currently just calling the Document.read() method and sending the entire blob to the browser wrapped in a fastapi.Response. I'd be interested in your thoughts on how this should be chunked and streamed properly.

FastAPI has a FileResponse that handles this properly. Downside is that this requires a file on disk to work. Short-term I'd be ok to just read the data and write it to a temporary file that we remove in a background task after the response has gone out. Long-term we need to build our own response type that does the same, but starts from bytes or an iterable thereof.

Here's a video of how it looks so far.

Looks good. #466 also states that

Ideally the new pane would scroll to and highlight the exact source content in the file.

Is that possible / planned?

[blakerosenthal]

Does the browser handle this automatically? Meaning, we just pass it a blob and the browser figures out whether it can show it (.pdf, .md, .txt) or offer it as download (.pptx, .docx)? If yes, that would be awesome and we should really have this feature for everything.

I thiiink so as long as the right mimetype is specified in the response header. I will confirm and let you know what I find out.

FastAPI has a FileResponse that handles this properly. Downside is that this requires a file on disk to work. Short-term I'd be ok to just read the data and write it to a temporary file that we remove in a background task after the response has gone out. Long-term we need to build our own response type that does the same, but starts from bytes or an iterable thereof.

Okay, I'd be interested in seeing the level of effort on building our own. It seems like FileResponse is mostly just a wrapper around StreamingResponse that sets the right headers.

Ideally the new pane would scroll to and highlight the exact source content in the file.

Is that possible / planned?

I need to think a bit more about how this could work. Might be best suited for a followup PR.

[blakerosenthal]

@pmeier This is ready for another look! This is was the source viewer looks like now after putting the accordion widget back and adding a new button. And I added some MIME types to our supported documents so the browser knows what to do with them when it receives the blob. On my browser PDFs open in a new tab, text is displayed as HTML, and Word and Powerpoints are downloaded. For sources with page numbers there's also now an anchor that scrolls the view to the right page for in-browser sources.

[blakerosenthal]

This looks great, thanks Blake! One question though: in case the browser downloads the file, I get something like "{uuid.UUID}.docx". Why isn't this the proper file name?

That's a typo, thanks for catching!