itsjunetime / tdf

A tui-based PDF viewer
Mozilla Public License 2.0
713 stars 12 forks source link

Feature request. Add a "raw" mode #22

Open vvatikiotis opened 1 month ago

vvatikiotis commented 1 month ago

Hello,

for lack of a better introduction, I'll just write "tdf without the TUI, just render the pdf in the terminal".

Why? To allow tdf to integrate with other command line tools. Like, for instance, fzf or less and lesspipe, which are my use cases. Using fzf and configuring it to preview the selected file enables a seamless and very efficient file exploration workflow. Setting up lesspipe with less and enabling tab completion with fzf and previewing seems to me like the ultimate file exploration experience. I consider exploration and file management as different workflows, so as much as I like tuis like yazi, for file management, I think that a less/lesspipe/fzf/previewing with previewers combo is much better.

(There maybe additional workflows and experiences, like grepping into searchable files/pdf, but I won't go there).

So I envision a tdf working seamlessly with other cli tools. In order for this to be possible, tdf (or any other tool) has to let go, or even better, have a "raw" mode, where there is no tui. Something like tdf --raw <file> would just render the pdf file in the terminal, ideally respecting a pager.

I know of one tool,yazi, which accomplishes this out of the box. But, as I said before, yazi is an excellent TUI file manager, whereas something even closer to the shell prompt would be, in my mind, better for just file exploration.

Please pardon my long winded post, tdf is a valuable tool in my cli toolbelt!

itsjunetime commented 1 month ago

I think this is a good idea, but would require some more design/explanation before I would be able to work on it. I'm just not quite certain how pages would be rendered, more specifically:

  1. Would we render all pages at once, or just a specified range of pages, or just render them on-demand (if on-demand, how?)
  2. How do we determine how large to render the images so that they aren't pixelated but also don't take too long to render? It would probably be best to just keep the same measurements/computations we currently keep, I just don't know exactly what your vision is so I don't know what this would look like.
  3. If you're envisioning being able to 'scroll through' the pages on a PDF, I think it would be smart to check out issue #7 to be aware of the limitations there.

Also, making pdfs 'greppable' would definitely be possible. tdf already supports searching through pdfs and highlighting relevant text, we'd just need to figure out how that would work with the other tools you'd like to use it with.

If you would like to try to implement this desired functionality yourself, feel free to file a PR. Otherwise, I think a specific use-case or mockup of what it would look like or what the ideal command flow would be could help a lot here.

Also, based on this issue, #15, and #12, it would probably make sense to start adding argument parsing into this, so I can start working on at least building out the structure for this sort of thing soon.

vvatikiotis commented 1 month ago

I think we should go for easy wins/implementation, to begin with. I'm saying this cause, unfortunately I don't have the slightest idea about Rust programming, so I shouldn't "dictate" anything, on your or any other ppl willing to spend their time on it. With this in mind, I'd think the following:

  1. I'd draw inspiration from https://github.com/sxyazi/yazi. The preview pane of yazi shows pdfs page by page and the user is able to view next/previous page.
  2. I think that tdf already performs these kind of calculations as it respects the terminal size. It also respects tmux window/pane size (I use tmux and pdfs page size handling is perfect).
  3. For the "scrolling through", I'd go with the "easy wins", especially after reading the https://github.com/itsjunetime/tdf/issues/7 issue. It seems to me this would be a major, or at least a substantial undertaking, which, touches on other use cases as well. Up to you.

The first part of the video shows how yazi handles pdf previewing, which is per page. The second part, shows fzf with previewing pdfs, which are converted to text on the fly (using pdftotext). The full idea is to have yazi style pdf previewing within fzf previewing pane.

https://github.com/user-attachments/assets/f37796ae-2d65-4948-be16-ec5b7549a072

About "grepping" pdfs: I also have an fzf-previewing use case, which looks similar to the video above. I'll upload another video (can't do it in this post cause of github's 10MB upload limit).

Again, tackling this is well beyond my time constraint, so I don't expect anything from you or anyone else. However, imho, something like this would be a great addition and general design direction of tdf since it opens all kinds of integrations as it allows tdf to be used by other cli programs.

Thank you for your time and efforts!

Kreijstal commented 1 week ago

@vvatikiotis how did you configure yazi to do page up or pagw down on pdfs? when I do ctrl_u it scrolls up or down but not the page

vvatikiotis commented 1 week ago

In keymap.toml I added:

[[manager.prepend_keymap]]
on = ["<C-d>"]
run = "seek 5"
desc = "Preview, down 5 lines"

[[manager.prepend_keymap]]
on = ["<C-u>"]
run = 'seek -5'
desc = "Preview, up 5 lines"

My yazi config doesn't have anything else about pdfs...... Vanilla yazi 0.3.3

MilitaoLucas commented 1 week ago

A simple mode, with the keybinds, but without anything but the PDF would also be appreciated. I closed an issue on this because I didn't know if it counted as a duplicate.