| Summary: | improve user interface. wish lists, UI complaints and related things go here! | ||
|---|---|---|---|
| Product: | MuPDF | Reporter: | Tor Andersson <tor.andersson> |
| Component: | apps | Assignee: | MuPDF bugs <mupdf-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | 1130134041, b.reaves, bahusdrive, br4nd0n-paert, bugzilla, christinedelight.top85, damjan.cinkole, daw, ddascalescu+ghostscript, dev, doom3024, dsdutkiewicz, egk10, g2408054, ghostscript, hc36123, jamesfengcao, klausgy, klizet, konqui, koster, l.parrington, laska, leho, lemaire.adrien, lichray, lililjlj, m.ramakers, mandar.mitra, marcoep, martin+bugsghostscriptcom, maxim.suraev, nahumoz, nathanael.schaeffer, oc-spam65, ominfowave.developers, palmem, panov, ryofurue, seth_yan, shuge.lee, soul.warrior, talljohan, vext01, vincent.laporte, vincent.torri, xivman, zeniko |
| Priority: | P4 | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: |
Modified pdfapp.c and pdfapp.h to enable external commands.
Shift left click to select and copy |
||
|
Description
Tor Andersson
2010-05-20 23:53:11 UTC
*** Bug 691110 has been marked as a duplicate of this bug. *** *** Bug 691214 has been marked as a duplicate of this bug. *** *** Bug 691027 has been marked as a duplicate of this bug. *** *** Bug 691144 has been marked as a duplicate of this bug. *** *** Bug 690544 has been marked as a duplicate of this bug. *** *** Bug 690760 has been marked as a duplicate of this bug. *** *** Bug 691332 has been marked as a duplicate of this bug. *** Sorry for my delayed response to bug 690544. All mails from ghostscript.com is blocked in my mail box and I failed to notice that. And, this bug still exists in the newest source code. Here is my wish lists: 1. Customizable keyboard and mouse binding for navigation in the new GUI. And when scrolling down to the bottom of current page, it should be aware and jump to next page automatically, either in mouse navigation or keyboard. 2. Cache search results: Every search result should be cached in memory, until search keyword is changed. Start a new search for previous keyword is not necessary, IMHO. 3. Cache the most time-consuming pages in memory. This make sense in the case one page contains complex vector arts, and re-render the page have noticeable lag. Perhaps this should considered carefully on memory-limited system, as mobile devices. ;) 4. Customizable background color in rendering. 5. (Optional) Grep-like search: I wish it will provide an function on search and show all results in some way, thus I can get an overview on every result with its context. It is a bit like the Acrobat's behavior on searching on indexed items. Um, Mendeley's embedded PDF reader also highlight all search results in current page and current search result with different color. 6. Months ago, I tried to add a XFT-based sub-window showing the outline, one title per line without any folding as some other PDF reader. Fortunately, they works fine without any performance loss (about 2k outline entries, nearly as fast as original build). Different font size and color are used on different entry levels. I think maybe a new consideration on displaying outline other than conventional collapsed text will be interesting, but customs maybe also be respected. 7) X11 viewer: plain XCB (instead of Xlib) here is my opinion of the options presented so far above
tor.
- why xpdf, why not compare with gv or deckview or uplib's readup or the numerous other pdf or pdf like document viewer
- buttons are nice but i don't mind not having them; is it going to have a clone and a cite button; clone makes a new window appear on the screen with the same contents as the old one; cite puts a citation to this pdf on the clipboard (sorry if you don't get this i've been working on what would seem like a thesis project without an advisor nor an editor so i really don't understand how to do what i need to so don't get troubled i really do see the need to collate my mupdf related writing i'll have to get back to you on that)
- a context menu maybe but what would be on it
- smart zooming what is that
- search ok but i'd like modeless Leaping
- annotations eww mutate me pdfs are you mad well, if mupdf could use a collaboration store like acrobat and would put the annotation there and not in the pdf files i wouldn't mind that
- form filling great with that we could do taxes and submit them just using mupdf and no other pdf viewer but i don't do taxes and don't fill out forms so i think it might be a better thing for Sumatrapdf to do
1. best option is to use dconf to store the options but as this needs to be available on all platforms an abstracted interface that would fallback to a text file -- the rest describes that: all this would require is a text file that contains key action pairs the default key action pairs would be in a table in the code when the program launches it would read ~/.config/mupdf/keyactions or such and use those or use
2. i have a way to do this without making the program need to cache anything and it can be simply extended to support caching
you have a array: char * match_hit = malloc(sizeof(char)*pageno)
you set 'match_hit' to all 1 i.e. memset(match_hit, 1, sizeof(char)*pageno)
you have a vector of 1s the length of the number of pages
when you start a new search you reset it to all 1s
when looking for the next hit
- if match_hit[current page] == 0: you skip it (i.e. no need to check its text for possible hits because there are none)
- if you look at a page and don't find a hit: you set match_hit[pageno] = 0
to cache this for more than one search you just put match_hit in a cache keyed by the term and when you start a search you put the current term:vector in the cache and get the one that matches this search from the cache in this way you could have a limited cache of say 8 or so without the need for any data structure than one of your existing
if you do a search in a pdf like for 'fish', it should remember for each page if there was a hit on it or not this requires only pageno amount of storage. when you start a new search this memory gets transfered into a cache of {term:<vector pdf's pageno = length>} -- so when searching you look at the vector if the if it's true the page matches and is loaded and scanned for the next hit (i think i might try to code this as it doesn't seem that hard)
3. cost based caching is would be nice but it's really not useful
4. i like the gray
5. the first part about a grep like display of hits is hard but the second part about highlighting all the possible hits on the page rather than the current one is like chrome's and gedit's incremental search although as your mainly copying less's / and its n and N the idea here would mean you'd need one more way other than inverse video to color the search hits which might be the blocker
6. where is the code for that?
7. great you might as well have a Wayland port too
*** Bug 691351 has been marked as a duplicate of this bug. *** *** Bug 691594 has been marked as a duplicate of this bug. *** *** Bug 691947 has been marked as a duplicate of this bug. *** *** Bug 691962 has been marked as a duplicate of this bug. *** *** Bug 691964 has been marked as a duplicate of this bug. *** *** Bug 691967 has been marked as a duplicate of this bug. *** *** Bug 691966 has been marked as a duplicate of this bug. *** *** Bug 691968 has been marked as a duplicate of this bug. *** *** Bug 691973 has been marked as a duplicate of this bug. *** *** Bug 691974 has been marked as a duplicate of this bug. *** *** Bug 692044 has been marked as a duplicate of this bug. *** *** Bug 692045 has been marked as a duplicate of this bug. *** *** Bug 691965 has been marked as a duplicate of this bug. *** loving the minimalism. the only thing for me is i would like some sort of position information. it's sort of disorienting otherwise, esp. in large multipage documents. "1 / 10" somewhere in the corner would be just fine. You already have position information in the title bar, which is only a problem if you use evilwm or a similar window manager that doesn't display title bars. Oh, right. I'm indeed on awesome wm, and if the page information is at the end of window title sting then I am indeed not seeing it. Maybe optionally or .mupdfrc let me put it in front? *** Bug 692467 has been marked as a duplicate of this bug. *** *** Bug 692407 has been marked as a duplicate of this bug. *** *** Bug 692207 has been marked as a duplicate of this bug. *** Please consider to add support for continuous showing: Evince supports continuous showing of PDF files with more than one page. You see the end of page 1 and the beginning of page 2 at the same time. MuPDF can only show one page at the same time. It would be nice to see this feature in MuPDF, too. http://bugs.debian.org/641746 Seems a little strange that UI bugs are resolved as being duplicates of this. The normal way to have a general "feature tracking" bug like this would be to have all those issues block this rather than resolving them as duplicates of this. Once something is resolved as a duplicate it of course won't get any attention on its own anymore. So marking all these as duplicates seems to be a way of saying "we don't want to work on any UI bugs right now" or "we'll be doing a total rewrite of the UI, so bugs in the current UI are only relevant as reasons why we need to get around to doing that rewrite." Is that the intention? If so, you may want to give people different directions about bug reporting (such as "don't bother reporting UI bugs" or "if you see a UI bug just comment 69133." i am requesting more intelligent handling of the maximum window height. right now it is just set as 90% of the monitor resolution. it seems like the right way to do it would be to subtract the height of the top and bottom window borders as well as any panels from the monitor resolution. however, even something as simple as a command line option to tweak this would be awesome. fyi, i am running openbox window manager on a 1920x1080 screen, and 98% seems to be ideal the ideal value for me. mupdf is awesome. thanks! Hello, I love mupdf. There are three things I would appreciate most: 1) Key to print document -- possibly one to just print it, and second to display prompt with prefilled "lp $", where $ would be substituded for the file. 2) Key to save document somewhere else -- I usually open a pdf from browser, review it and sometimes want to save it. Unfortunately, to do this, I have to get back to the browser and save it, or find it in temporary files, where is way too many files. 3) That 'j' and 'k' keys behave like Pg Down/Up in case I'm on the end/beginning of a page (so if there is nothing more to show, that is currently when 'j' and 'k' does nothing, flip pages istead) It would be even better if the keys are configurable, or at least documented (I've just searched the code a little and couldn't find a place to define keys in code -- they seem to be scattered all around the code). Thanks! Regards Ladislav Laska I love MuPDF because it's very fast! I suggest the following improvements: - I suggest adding keys "space"/"backspace" for "block scrolling", like in xpdf or djview. This is important because currently, it's not possible to go from the bottom of a page to the top of the next page with just one key (or the reverse). - Zooming should be centered on the mouse cursor when using CTRL + mouse scroll. In other words, the character under the mouse cursor should still be under the mouse cursor after the zoom (it's not the case currently with version 0.9). This is important for zooming on a detail in a document because many successive zooms are often needed and re-centering the page after every zoom is painful. - Page number should be at the beginning of the window title. This is important because ebook names are often very long and the page number is then too far and thus invisible. May I add another request? The window name should display the "file name" instead of the "pdf title" (like 'xpdf' does). The reason is that 1) It's easier to retrieve the file in a directory when the "file name" is known 2) Many programs give useless "pdf title" (like "1/8" or "Microsoft Word"...) Hello there! +1 for all requests in Comment #33. Of course, all that would definitely need a configuration file! Cheers, ^s Created attachment 8728 [details] Modified pdfapp.c and pdfapp.h to enable external commands. The attached patch partially implements the suggestions in Comment #33: Added new keypress, "!", which runs external commands on the current pdf file. The external command is defined in a new environment variable "MUPDF_EXTERNAL". For instance, you could add "export MUPDF_EXTERNAL=lpr" to your shell setup. Additional external commands may be defined in "MUPDF_EXTERNAL1", "MUPDF_EXTERNAL2", etc. Those are executed if the "!" key is prefixed by the corresponding number. I opened a new bug report, #693175, for this patch so as to separate it from the catch-all bug report #691330. *** Bug 692635 has been marked as a duplicate of this bug. *** *** Bug 692452 has been marked as a duplicate of this bug. *** Forward a start command to show a specific page on startup in Android.
Adobe Reader have this #page=n command to open a specific page on start up. But it is not implanted in the Android version.
I would find this function very useful.
Exemple in B4A
Dim i As Intent
i.Initialize(i.ACTION_VIEW, "file:///sdcard/file.pdf#page=3")
i.SetType("application/pdf")
i.WrapAsIntentChooser("Choose PDF Viewer")
StartActivity(i)
First of all many thanks to all developers of this great piece of software! Here's my wishlist to make MuPDF perfect for me: - Please add a command-line switch (or make it otherwise configurable) that a document is automatically zoomed to fit the window height if opened. - Please add an option to keep already rendered pages in memory. Currently every page is newly rendered if you go back and forward. If you have a large/complex PDF (e.g. some lecture slides) this can take some time. If previously rendered pages were cached, this could speed up navigating through a document dramatically. - It would also be great if there would be an option to always prerender the next (e.g. 10) pages in advance to speed up navigation. - A key bind to display the document properties (the metadata, e.g. simply the output of pdfinfo) in a popup window would be nice. - Support for reading PDF bookmarks - Printing support Created attachment 8986 [details]
Shift left click to select and copy
This patch enables selecting by means of shift + left click in addition to the existing right-click.
Hi, MuPDF is a great peace of software. I miss the ability to select and copy text from viewed documents since the hardware I use does not enable me to “right-click and select”. Hence I suggest shift + left click as an other means to select and copy. I have attached a brief patch. Best regards. On Linux, when using the find function AND a document page doesn't wholly fit into the window (zoom beyond the window size), looking for the next match ('n' key) doesn't bring the portion containing the highlighted text into visibility. This is annoying as it makes the user think that no other match is found, and forces him/her to scroll down manually to check.
In other words, I'd like to have an auto-scroll feature to allow following every next match on the same page.
Android Feature request: When using MuPDF for android only horizontal scrolling is possible. Sometimes it is much easier and natural to scroll vertically. Other applications that MuPDF do that already (http://code.google.com/p/apv/ for example). It would be nice to have the same capability in MuPDF (mainly because the others don't support all the features (like comments etc.). Thanks you for MuPDF so far. Oz Hi folks, I'd like to warn you :-) Adding nice features would be fine as long as they don't make mupdf slower. It's wonderful primarily because it's light. xpdf and mupdf are the only PDF viewers I can use over X on SSH (Run mupdf on a remote server and its window is displayed on your local PC screen). All the other PDF viewers I've tried are ultra slow over the Internet. In my view, a PDF viewer can be useful only in one of the two ways: 1) To be more capable (feature-rich) than Adobe Reader; 2) To be much lighter than Adobe Reader. Is (1) achievable? If not, (2) is the way to go. I for one would have to stop using mupdf if it becomes significantly heavier. Cheers, Ryo I have no wishes, other than a presentation mode, i.e., a black background in full screen mode. I am using the MuPDF 1.3 for Windows binaries. Although the manual in fact reports a "presentation mode", pressing the mentioned button (p) has no effect. Would be great to have option current/total page counter with configurable placement on top of the pdf. Support for -v/--version and displaying version if called without parameters would simplify bug reporting and meet expectations of users familiar with GNU tools. Hi, I just love muPDF. Please keep it as minimalistic as possible with least amount of UI clutter. For reading or studying, I find many readers distract me but muPDF does not because it does not have any UI noise. Please keep it that as much as possible. If you intend to make any UI menus then please make it possible for people like us to hide them with something. Additionally, it would be good if we could have night mode https://blogs.adobe.com/readermobile/2013/01/18/feature-preview-night-mode/. This is best implemented by apple ibooks or evernote clearly. I am actually interested in working on this feature if somebody could provide me few pointers to start with. I believe this should be that hard as we already have support for gray color mode (keyboard option c). --Amey *** Bug 692932 has been marked as a duplicate of this bug. *** *** Bug 693309 has been marked as a duplicate of this bug. *** *** Bug 693574 has been marked as a duplicate of this bug. *** *** Bug 693635 has been marked as a duplicate of this bug. *** *** Bug 693648 has been marked as a duplicate of this bug. *** *** Bug 693649 has been marked as a duplicate of this bug. *** *** Bug 693650 has been marked as a duplicate of this bug. *** *** Bug 695177 has been marked as a duplicate of this bug. *** *** Bug 695174 has been marked as a duplicate of this bug. *** *** Bug 695161 has been marked as a duplicate of this bug. *** *** Bug 695158 has been marked as a duplicate of this bug. *** *** Bug 693707 has been marked as a duplicate of this bug. *** *** Bug 693425 has been marked as a duplicate of this bug. *** *** Bug 692575 has been marked as a duplicate of this bug. *** "Block scrolling", as someone here called it, has been requested multiple times here (#1 of comment 8, #3 of comment 33, comment 34, comment 36) and here: http://bugs.ghostscript.com/show_bug.cgi?id=693574 and here: http://bugs.ghostscript.com/show_bug.cgi?id=694518. In the second link there's a working patch already, it's less than 20 lines of code and it works. Also, I concord with comment 31, and since this "bug" is open since 2010, I fear none of this will ever get implemented and this is just a "forget it" drawer. Please, prove me wrong! :) Hi, I never filled a bug report before so hopefully Iom doing this right. Just some thoughts on the search feature. First of all it annoys me that mupdf searches for the empty string, for example if I accidentally hit 'n' before specifying any search string, it works for some while before outputting 'Warning: String '' not found', I think it should just ignore 'n' when no search string is specified. Also, when searching for a string which appears only one time in the document, the first press of 'n' brings me to the first occurrence but a second press again outputs 'Warning: String [string] not found' which I find a bit counterintuitive since it has already been found! To get rid of the 'Warning: String [string] not found' banner you have to press '/' and then ESC, at least that's the way I do it, would prefer the banner to disappear if you use any navigation command or even better just by pressing ESC. Last thing, I would find it intuitive to get rid of the highlighted strings by just hitting ESC, now you have to go to the next page and then return or something similar. Sorry guys, I meant to fill this for MuPDF! Please delete if possible. I noticed when going from MuPDF 1.1 -> 1.5: scroll down (key 'j') and up (key 'k') now automatically go to the next page. This is IMHO not always useful: when zoomed in a lot, and reading text at the bottom of the page (and scrolling down to continue reading text at the bottom), and in case end-of-page is not clearly shown on the page, and 'j' automatically goes to the next page (so, if all of the above 'and' are true), then new text on the new page appears at the top of the page. It is not always clear that a page-flip has occurred - the user expects new page to be at the bottom of the page, not top. IMHO regardless whether auto-increment/-decrement page when scrolling is good or bad, perhaps it can be disabled, or perhaps a visual indication of 'page flipped' can be given, to give the user a clue. Personally I liked the 1.1 behaviour much more. Besides, 'page flip' is a matter of noticing 'nothing happens when I try to scroll up/down', and pressing 'b' or <space> - wasn't such a big deal. > ... - the user expects new page
> to be at the bottom of the page, not top.
should be: "the user expects new _text_ to be at the bottom of the page, not top."
Highlight text + copy/paste operated with mouse would be nice MuPDF seems to support oxps files as well as xps, but the Windows executable (.exe version) doesn't have the .oxps file extension registered so that such files can easily be opened from the open file dialogue box. (The Windows 8 Modern app version *does* recognize this file extension.) Could it be added to the executable version? On larger Displays, showing only 1 page is kind of ineffective. I often find myself wishing for a option that displays 2 pages site by site. Finally, the sane scrolling behavior when reaching end of one page will lead to the beginning of next one - great bugfix! I'd like to second the request for printing support - that's the only feature I miss to drop my old pdf reader. The zoom behavior on mouse wheel scrolling seems inverted: at least my browser treat it exactly the opposite way. This should be configurable - it's unlikely that any default in here would please everybody. Do you have plans to add printing support to mupdf-gl? +1 for printing support On Windows10, when I open a file with mupdf (explorer, rightclick the file, open with, mupdf.exe), the mupdf window opens in the background. This causes confusion among users, thinking that it simply did not open. They expect it to open in front (on top, in the foreground) instead of in the back. Please, make "backspace" work again in mupdf viewer (opposite to "space"). (In reply to Damjan Chinkole from comment #71) > Highlight text + copy/paste operated with mouse would be nice It already works: use the right mouse button. Please, make keys ">" and "<" work again! Why were all the useful shortkeys dismissed in the new version??? Apologies if I'm missing something, but it seems that MuPDF doesn't remember the zoom factor, or window size. I open the same PDF often, on a widescreen monitor, and every time I need to zoom in and resize the window. Would it be possible to remember the window size, position and zoom level per document? Feature request for mupdf-gl: like 'o' opens an outline pane, and 'a' opens the annotation menu, would it be possible to add a key for listing all annotations/comments in the entire file, organised by page? Feature request for mupdf-gl: like 'o' opens an outline pane, and 'a' opens the annotation menu, would it be possible to add a key for listing all annotations/comments in the entire file, organised by page? Feature request for mupdf-gl: like 'o' opens an outline pane, and 'a' opens the annotation menu, would it be possible to add a key for listing all annotations/comments in the entire file, organised by page? Feature request for mupdf-gl: like 'o' opens an outline pane, and 'a' opens the annotation menu, would it be possible to add a key for listing all annotations/comments in the entire file, organised by page? |