Open alerque opened 2 months ago
Yes, I'd be happy to support this.
At the moment, tdf has no arg-parsing or config-file-handling code, and I'd like to keep it simple like that where possible, mostly for binary size and compilation speed reasons. With that in mind, is there a way that we could pull this information (about how the pdf should be displayed) from the pdf itself? Do you know if they have any sort of metadata that we could pull from to detect and adjust for this?
If most other pdf viewers that you know of rely on users to explicitly configure the spread like this, I'm guessing it's not the sort of information that you could just pull from the PDF itself, so I understand if we have to start adding configuration options to make this work nicely.
PDFs do not have information for this baked in in any way that can be reliably used to configure viewer behavior.
Most people won't care how long it took to compile tdf, only that it does or doesn't do what they want. Just use clap
and don't worry about it. The runtime performance will my fine even if compile time takes a hit.
I work primarily with books, not just multi-page PDFs. Book layout is very specific such that facing pages are spreads and often have design elements that are designed to be on on or the other of the sides of a spread. They also (for LTR languages) always start with an odd page that is the right side of a spread, usually with no matching left side, thereafter consecutive even/odd pages are matching spreads.
The current display scrambles up book views because it is off by 1:
Most good PDF readers have an option to support this. The best is probably
zathura
that has:set first-page-column 2
that can also handle spreads of more than 2 pages. That's a feature request for another time, but for now a way to set the first page offset would be quite useful.Also as noted in #12 the "first", "second", etc. column counting should be reversed for documents in primarily RTL languages.