Bug 691330 - improve user interface. wish lists, UI complaints and related things go here!
Summary: improve user interface. wish lists, UI complaints and related things go here!
Status: CONFIRMED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: apps (show other bugs)
Version: unspecified
Hardware: All All
: P4 enhancement
Assignee: muPDF bugs
QA Contact: Bug traffic
URL:
Keywords:
: 690544 690760 691027 691110 691144 691214 691351 691594 691947 691962 691964 691965 691966 691967 691968 691973 691974 692044 692045 692207 692407 692452 692467 692575 692635 692932 693309 693425 693635 693648 693649 693650 693707 695158 695161 695174 695177 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-20 23:53 UTC by Tor Andersson
Modified: 2019-04-24 20:26 UTC (History)
48 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Modified pdfapp.c and pdfapp.h to enable external commands. (2.80 KB, patch)
2012-07-03 21:08 UTC, Daniel Wagenaar
Details | Diff
Shift left click to select and copy (616 bytes, patch)
2012-10-07 14:35 UTC, Vincent
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tor Andersson 2010-05-20 23:53:11 UTC
Something like xpdf, with a few buttons and a context menu, smart zooming, search, annotations and form filling.
Comment 1 Tor Andersson 2010-05-20 23:58:00 UTC
*** Bug 691110 has been marked as a duplicate of this bug. ***
Comment 2 Tor Andersson 2010-05-20 23:59:03 UTC
*** Bug 691214 has been marked as a duplicate of this bug. ***
Comment 3 Tor Andersson 2010-05-20 23:59:32 UTC
*** Bug 691027 has been marked as a duplicate of this bug. ***
Comment 4 Tor Andersson 2010-05-21 00:00:53 UTC
*** Bug 691144 has been marked as a duplicate of this bug. ***
Comment 5 Tor Andersson 2010-05-21 00:01:51 UTC
*** Bug 690544 has been marked as a duplicate of this bug. ***
Comment 6 Tor Andersson 2010-05-21 00:03:32 UTC
*** Bug 690760 has been marked as a duplicate of this bug. ***
Comment 7 Tor Andersson 2010-05-23 13:41:45 UTC
*** Bug 691332 has been marked as a duplicate of this bug. ***
Comment 8 Luc 2010-05-29 04:54:37 UTC
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.
Comment 9 vincent.torri 2010-06-19 16:41:32 UTC
7) X11 viewer: plain XCB (instead of Xlib)
Comment 10 Daniel Dutkiewicz 2011-02-14 22:01:37 UTC
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
Comment 11 Tor Andersson 2011-04-10 13:50:41 UTC
*** Bug 691351 has been marked as a duplicate of this bug. ***
Comment 12 Tor Andersson 2011-04-10 13:50:58 UTC
*** Bug 691594 has been marked as a duplicate of this bug. ***
Comment 13 Tor Andersson 2011-04-10 13:53:15 UTC
*** Bug 691947 has been marked as a duplicate of this bug. ***
Comment 14 Tor Andersson 2011-04-10 13:53:50 UTC
*** Bug 691962 has been marked as a duplicate of this bug. ***
Comment 15 Tor Andersson 2011-04-10 13:54:18 UTC
*** Bug 691964 has been marked as a duplicate of this bug. ***
Comment 16 Tor Andersson 2011-04-10 13:54:38 UTC
*** Bug 691967 has been marked as a duplicate of this bug. ***
Comment 17 Tor Andersson 2011-04-10 13:55:00 UTC
*** Bug 691966 has been marked as a duplicate of this bug. ***
Comment 18 Tor Andersson 2011-04-10 13:56:25 UTC
*** Bug 691968 has been marked as a duplicate of this bug. ***
Comment 19 Tor Andersson 2011-04-10 13:57:23 UTC
*** Bug 691973 has been marked as a duplicate of this bug. ***
Comment 20 Tor Andersson 2011-04-10 13:57:56 UTC
*** Bug 691974 has been marked as a duplicate of this bug. ***
Comment 21 Tor Andersson 2011-04-10 14:07:48 UTC
*** Bug 692044 has been marked as a duplicate of this bug. ***
Comment 22 Tor Andersson 2011-04-10 14:08:17 UTC
*** Bug 692045 has been marked as a duplicate of this bug. ***
Comment 23 Tor Andersson 2011-04-10 14:11:23 UTC
*** Bug 691965 has been marked as a duplicate of this bug. ***
Comment 24 Leho Kraav 2011-05-19 11:09:47 UTC
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.
Comment 25 Tor Andersson 2011-05-20 10:35:30 UTC
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.
Comment 26 Leho Kraav 2011-05-20 15:09:04 UTC
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?
Comment 27 Tor Andersson 2011-08-29 19:38:18 UTC
*** Bug 692467 has been marked as a duplicate of this bug. ***
Comment 28 Tor Andersson 2011-08-29 19:58:22 UTC
*** Bug 692407 has been marked as a duplicate of this bug. ***
Comment 29 Tor Andersson 2011-08-29 20:19:15 UTC
*** Bug 692207 has been marked as a duplicate of this bug. ***
Comment 30 Kan-Ru Chen 2011-09-18 05:44:56 UTC
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
Comment 31 jensend 2011-09-28 01:55:42 UTC
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."
Comment 32 lars 2011-10-28 02:23:54 UTC
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!
Comment 33 Ladislav Laska 2012-01-17 01:00:37 UTC
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
Comment 34 OLCC 2012-02-08 15:05:18 UTC
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.
Comment 35 OLCC 2012-03-15 16:54:08 UTC
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"...)
Comment 36 sphakka 2012-07-03 14:15:23 UTC
Hello there!

+1 for all requests in Comment #33. Of course, all that would definitely need a configuration file!

Cheers,

  ^s
Comment 37 Daniel Wagenaar 2012-07-03 21:08:28 UTC
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.
Comment 38 Daniel Wagenaar 2012-07-09 23:29:47 UTC
I opened a new bug report, #693175, for this patch so as to separate it from the catch-all bug report #691330.
Comment 39 Tor Andersson 2012-07-20 12:22:13 UTC
*** Bug 692635 has been marked as a duplicate of this bug. ***
Comment 40 Tor Andersson 2012-07-20 12:22:41 UTC
*** Bug 692452 has been marked as a duplicate of this bug. ***
Comment 41 Jonas 2012-08-13 14:34:46 UTC
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)
Comment 42 konqui 2012-09-01 14:58:08 UTC
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
Comment 43 Vincent 2012-10-07 14:35:50 UTC
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.
Comment 44 Vincent 2012-10-07 14:43:33 UTC
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.
Comment 45 sphakka 2012-12-14 15:52:40 UTC
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.
Comment 46 Oz 2013-09-17 23:23:13 UTC
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
Comment 47 Ryo Furue 2013-09-18 04:14:27 UTC
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
Comment 48 bugzilla 2013-09-30 15:48:59 UTC
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.
Comment 49 Max 2013-11-15 04:46:39 UTC
Would be great to have option current/total page counter with configurable placement on top of the pdf.
Comment 50 Max 2013-11-15 04:49:23 UTC
Support for -v/--version and displaying version if called without parameters would simplify bug reporting and meet expectations of users familiar with GNU tools.
Comment 51 doom3024 2013-12-09 17:03:22 UTC
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
Comment 52 Tor Andersson 2014-05-21 06:13:54 UTC
*** Bug 692932 has been marked as a duplicate of this bug. ***
Comment 53 Tor Andersson 2014-05-21 06:24:14 UTC
*** Bug 693309 has been marked as a duplicate of this bug. ***
Comment 54 Tor Andersson 2014-05-21 06:25:13 UTC
*** Bug 693574 has been marked as a duplicate of this bug. ***
Comment 55 Tor Andersson 2014-05-21 06:25:35 UTC
*** Bug 693635 has been marked as a duplicate of this bug. ***
Comment 56 Tor Andersson 2014-05-21 06:25:51 UTC
*** Bug 693648 has been marked as a duplicate of this bug. ***
Comment 57 Tor Andersson 2014-05-21 06:26:05 UTC
*** Bug 693649 has been marked as a duplicate of this bug. ***
Comment 58 Tor Andersson 2014-05-21 06:26:19 UTC
*** Bug 693650 has been marked as a duplicate of this bug. ***
Comment 59 Tor Andersson 2014-05-21 07:00:48 UTC
*** Bug 695177 has been marked as a duplicate of this bug. ***
Comment 60 Tor Andersson 2014-05-21 07:01:05 UTC
*** Bug 695174 has been marked as a duplicate of this bug. ***
Comment 61 Tor Andersson 2014-05-21 07:01:55 UTC
*** Bug 695161 has been marked as a duplicate of this bug. ***
Comment 62 Tor Andersson 2014-05-21 07:10:56 UTC
*** Bug 695158 has been marked as a duplicate of this bug. ***
Comment 63 Tor Andersson 2014-05-21 07:12:31 UTC
*** Bug 693707 has been marked as a duplicate of this bug. ***
Comment 64 Tor Andersson 2014-05-21 07:14:47 UTC
*** Bug 693425 has been marked as a duplicate of this bug. ***
Comment 65 Tor Andersson 2014-05-21 07:17:24 UTC
*** Bug 692575 has been marked as a duplicate of this bug. ***
Comment 66 emarsk 2014-05-23 00:57:52 UTC
"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! :)
Comment 67 klausgy 2014-07-19 04:18:18 UTC
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.
Comment 68 klausgy 2014-07-19 04:24:29 UTC
Sorry guys, I meant to fill this for MuPDF!  Please delete if possible.
Comment 69 Michai Ramakers 2014-07-25 08:08:24 UTC
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.
Comment 70 Michai Ramakers 2014-07-25 08:10:19 UTC
> ... - 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."
Comment 71 Damjan Chinkole 2014-11-23 19:24:17 UTC
Highlight text + copy/paste operated with mouse would be nice
Comment 72 Geoffrey 2015-03-02 09:15:50 UTC
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?
Comment 73 Martin 2015-03-15 01:50:43 UTC
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.
Comment 74 Max 2015-05-04 10:23:01 UTC
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.
Comment 75 Max 2015-11-14 06:09:04 UTC
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.
Comment 76 Pablo Rodríguez 2015-12-28 10:26:06 UTC
Do you have plans to add printing support to mupdf-gl?
Comment 77 g2408054 2016-08-18 10:41:53 UTC
+1 for printing support
Comment 78 Ben Reaves 2019-04-24 20:24:42 UTC
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.