[gs-bugs] [Bug 691330] write new fancy gui. wish lists go here!

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Mon Feb 14 22:01:39 UTC 2011


Daniel Dutkiewicz <dsdutkiewicz at msn.com> changed:

           What    |Removed                     |Added
                 CC|                            |dsdutkiewicz at msn.com

--- Comment #10 from Daniel Dutkiewicz <dsdutkiewicz at msn.com> 2011-02-14 22:01:37 UTC ---
here is my opinion of the options presented so far above

- 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

6. where is the code for that?

7. great you might as well have a Wayland port too

Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the gs-bugs mailing list