wishlist.txt

A list of random ideas, big and small. In no particular order. Those that are
marked "risky" are likely to cause disturbance to existing code, so should be
done at the beginning of the dev cycle. I also estimate the complexity (time to
implement) as low/med/high

-- fullscreen (low)

See if https://stackoverflow.com/questions/2382464/win32-full-screen-and-hiding-taskbar
has better way of switching to fullscreen

-- text viewer (high)

Important thing: make it work even with gigantic files by limiting how much of
the file we load in memory (1-10 MB?). We would only build and index for each
line, consisting of:
* position in the file
* length in bytes
* encoding (to support various encodings; but we would start by only supporting
ascii/utf8)
* measured size of this line

We would build that index for the whole file in the background thread, then
only load the needed part as the user scrolls through the document.

-- hex viewer (high)

-- search for eBook UI (med)

-- thumbnails (med)

Many viewers have an option to navigate document via thumbnails.

For perf, we could cache thumbnails as a single, WebP-encoded image + info
about where a thumbnail for a given page is within the image (similar to
sprite technique in web dev)

-- toolbar improvements (med, risky)

Ditch using toolbar control for the toolbar and use more mui-like approach.
That would allow us to have overlaid toolbar (shown semi-transparent over the
content). Also we could add an option to make it vertical. Also an option to
have it user-configurable (via advanced settings, allow specifying the order
of controls in the toolbar).

This would also help in unifying full-screen modes (overlaid, auto-hidden
toolbar is a better match for full-screen mode than the current one).

-- better looking notifications (med)

Visual style of notifications is dated. Use more modern look e.g. inspired by
Chrome or Android.

-- loading errors are not always reported (low)

In some cases we don't show document loading errors (e.g. drag&drop a file that
fails to load). We need to show them as notifications

-- more detail when page doesn't render

I think we sometimes get bug reports when PDF page doesn't render because of
running out of memory. It would be good to show the exact cause of page
rendering failure instead of generic "failed to render" message.

-- faster re-layout for eBooks (med, risky)

Layout time is dominated by measuring strings.

Split layout into 2 or 3 phases:
* generate instructions (text fragments, images, font/style changes etc.)
* measure strings, images etc.
* calculating positions of the elements given page dx/dy and break them into pages

When users resizes the window, we would only need to redo phase 3. A small
complication: when a string doesn't fit in a single line, we need to split
it into to string instructions. We would need to be able to do it e.g. by
adding a "compound" instruction, that just contains one or more other instructions.
That way the instruction stream would be almost-immutable, and we could turn
a e.g. a long string into 2 smaller strings by replacing string instruction with
"compound" instructions that points to the original string instructions (so that we
can undo that in the next layout) and 2 or more substrings.

Changing default font would require redoing phase 2 and 3.

-- eBook: re-introduce preserving top of page after re-layout (risky, med)

The code to preserve current top of page after re-layout was so complicated
that I had to remove it in order to implement dual pages in eBook mode.
It would be nice to bring it back in a saner way and without the problem
of breaking the styling.
It would be easier if we implement faster re-layout as described above and
have every element remember its reparse point (instead of having it on a
per-page basis).

That way we would generate instructions just once. A page would just be:
(index of first instruction, number of instructions).

We could avoid breaking styling because now we have access to the whole instruction
stream and we could quickly scan back instructions from any point to find
formatting instructions and recover current styling.

-- manual cropping of margins for PDFs (med, risky)

Screen space is always at premium and most PDFs have very wasteful
margins. Good Reader has a really nice feature for manual cropping of margins
(https://www.goodiware.com/gr-man-view-pdf.html#crop). They have a mode for
manually selecting visible part of the PDF, similar to how many graphics
program implement cropping. Cropping can be set for all pages or separately
for odd/even pages. Cropping can also be reset. After cropping, the program
only shows the non-cropped part. This would be especially valuable for small
screens (netbooks/small laptops).

Note: Automatic cropping is currently implemented as "Fit Content" View mode.
Note to note: it's similar but not really the same. One big difference is that
with this style of cropping, for the purpose of layout and display the cropped
part doesn't exist. Fit Content positions the page so that it's out of the view,
but change zoom and it's really there.
Plus, automatic cropping has limitations. There are many cases where a PDF has
lots of white-space but cannot be cropped because has some small thing there,
like a page number.

-- Editing/saving of PDF forms (high)

-- Integration with web-based backup/viewer system (high)

The idea is that users could easily backup their PDFs on the server. They would
have a convenient access to those PDFs from Sumatra as well as being able to
view them on the web. Basically it would be private Scribd for PDFs only. The
web service would have to be paid (since on-line storage is rather expensive)
but there would be free accounts (with quota, similar to how Dropbox works).

-- Document library management (high)

Similar to how e.g. Picasa manages photos or iTunes manages mp3 files.

User would tell us which directories contain PDF and other supported files
(or, on Win 7, we could use windows search or scan the whole hard-drive to
automatically find all files). We would index the files (their filenames, metadata,
maybe extract text for full-text search), build thumbnails and allow efficient
browsing/searching those files.

This would be a good feature for those who have large collections of PDFs
(compared to using file explorer or open file dialog for locating the file).

-- use pdfium (high)

Google released https://pdfium.googlesource.com/pdfium/ which is Foxit codebase
under BSD license.

It would probably be a bunch of work to integrate this (although at first it
could be done alongside mupdf, since we have necessary abstractions to plug
another engine). So that's the downside.

I've briefly looked at the code and it might have some benefits over mupdf:
* they have hooks for form editing (which should make implementing this much
  easier)
* their printing code looks more efficient
* they probably support some of the more advanced PDF features
* they are probably faster and (thanks to Google) more secure