After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 303365 - increase zooming level
increase zooming level
Status: RESOLVED OBSOLETE
Product: evince
Classification: Core
Component: general
git master
Other Linux
: High critical
: ---
Assigned To: Evince Maintainers
Evince Maintainers
: 313176 321138 343328 499810 507650 632857 724252 752885 788909 (view as bug list)
Depends on: 629322
Blocks:
 
 
Reported: 2005-05-07 13:14 UTC by Pablo Rodríguez
Modified: 2018-05-22 12:58 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Pablo Rodríguez 2005-05-07 13:14:20 UTC
Wouldn't it be possible to improve the top zooming level to at least 800% (when
not 1600%)?

Acroread 7 supports a 6400% zooming level.
Comment 1 Nickolay V. Shmyrev 2005-05-07 13:34:43 UTC
This is hard-fix bug, but actually it's important. The problem is that evince 
backend should render a whole page, not only visible part of it. That requires 
a lot of memory, especially for big zooming level.
Comment 2 Troy Henderson 2005-07-23 11:27:20 UTC
I would very much like to increase the zoom level.  I often do things with
*very* high precision, and the way that Evince reloads the document and keeps
the same zoom level and page position is *AWESOME*.  However, I would really
like to see this zoom level increased as high as possible withough "killing" the
computer ;)
Comment 3 Jonathan Blandford 2005-07-30 02:08:10 UTC
Not going to happen for 2.12.  Too much of a feature.
Comment 4 Nickolay V. Shmyrev 2005-08-11 04:27:56 UTC
*** Bug 313176 has been marked as a duplicate of this bug. ***
Comment 5 Pablo Rodríguez 2005-08-12 10:48:19 UTC
I don't understand why evince (splash backend) requires so much memory.

GPDF renders documents antialiased faster and its 800% zooming is reasonably fast.

I like evince a lot, but I wonder why evince is slower than gpdf and it doesn't
render graphics antialiased.

With the cairo backend I'm afraid that evince's performance is even slower.

Sorry guys, I really appreciate your work (and no doubt evince rocks), but I
guess that AMD Athlon XP-M 2400+ and 512MB RAM should be enough to run evince
(as they are to run gpdf).
Comment 6 Martin Kretzschmar 2005-08-12 13:23:18 UTC
GPdf doesn't render the whole page to a pixbuf like evince. It uses gnome-canvas
(indirectly). That makes zooming very fast and allows almost arbitrary zoom
levels. One of the very few advantages of GPdf's codebase.
Comment 7 Pablo Rodríguez 2005-08-14 11:43:30 UTC
Thanks, Martin, for you reply.

My question is now: wouldn't it be possible that evince rendered the page the
same way that GPdf does?
Comment 8 Pablo Rodríguez 2005-08-28 09:46:32 UTC
One of the new features of xpdf-3.01 is the following:

At high zoom levels, don't rasterize the entire page - this avoids
  problems running out of memory.

Couldn't this be added to evince so that zooming will be faster?

(If this should be reported to poppler developers, please tell me.)
Comment 9 Nickolay V. Shmyrev 2005-11-10 15:29:26 UTC
*** Bug 321138 has been marked as a duplicate of this bug. ***
Comment 10 Nickolay V. Shmyrev 2005-11-10 15:30:28 UTC
Raising priority due to:

This bug has been opened here: http://bugzilla.ubuntu.com/show_bug.cgi?id=18496

"Evince starts with wild swapping and finally crashed on my machine when Zooming
the attached PDF-File to 400%.

http://bugzilla.ubuntu.com/attachment.cgi?id=4787
A sample PDF-File
...
> Thanks for your bug. Does it crash or is ejected because it uses too much
ressources? Do you get a bug-buddy dialog when that happens?
...
I did not get a bug-buddy report. So it probably consumed to many resources. The
computer has 512 MByte Ram + the same SWAP Ram. So such a resource consumption
seems to be more or less a bug and not a feature ;-)

Furthermore, XPDF has no problems with presenting the file at 400%."
Comment 11 Pablo Rodríguez 2005-11-21 16:51:06 UTC
I read somewhere (and I wrote in a poppler bug, but I don't remember which one),
that the lastest release of xpdf 3.01 includes:

At high zoom levels, don't rasterize the entire page - this avoids
  problems running out of memory.

Poopler developers are merging the xpdf-3.01 code into poppler, but I'm not sure
they will include this particular feature.
Comment 12 Pablo Rodríguez 2005-11-29 09:23:59 UTC
poppler does support only partial rendering of the page (I was told on poppler
mailing list).

I guess that it would be very useful to improve partial page rendering for the
actual part of the page that evince displays.

This would make evince faster and this is important.
Comment 13 Nickolay V. Shmyrev 2006-06-01 01:14:20 UTC
*** Bug 343328 has been marked as a duplicate of this bug. ***
Comment 14 Pablo Rodríguez 2006-06-03 12:28:16 UTC
Since poppler does support partial rendering of a page (on both splash and cairo backends, I guess) and the main problem with the zooming feature in evince is that its backend has to render the whole page, why doesn't evince implement the partial rendering that poppler offers?
Comment 15 Nickolay V. Shmyrev 2006-06-03 12:34:43 UTC
Just because nobody is working on it :( It's possible to render page partially, but you should take into account EvPixbufCache, it allows quite fast drawing and can't be dropped as well. Currenly EvPixbufCache is page-oriented and that is the main problem in using partial-page rendering. 
Comment 16 Reinout van Schouwen 2007-03-18 20:02:16 UTC
Updating version fields.
Comment 17 Mike Fedyk 2007-06-26 18:59:58 UTC
http://metro.net/riding_metro/riders_guide/system_map.pdf

Another PDF that kills my 768MB + 1GB swap system.

Zooming to 400% immediately fills up swap and then churns on my system.  I didn't leave it running long enough to finish.

Another bad thing is that once you set evince to 400%, it will always open that file at that zoom level, effectively making evince unusable with that file.
Comment 18 Nickolay V. Shmyrev 2007-11-26 20:53:28 UTC
*** Bug 499810 has been marked as a duplicate of this bug. ***
Comment 19 steff 2007-11-26 21:02:31 UTC
Apologies for logging a dupe of this bug - I did have a nose around but failed to find this one. Just to add my very small voice, I'd be perfectly happy to have higher zoom levels available with a naive implementation at the risk of the program dying. As it is, certain documents are of no use to me at all in evince.

Perhaps for ease of implementation a simple(ish) hack would be to add higher zoom levels to the menu with a warning dialog on selecting them and a test on the preference-saving part to ensure that nothing higher than 400% is saved for a doc? I realise that this suggestion is hideous :-)
Comment 20 Nickolay V. Shmyrev 2008-01-08 21:55:24 UTC
*** Bug 507650 has been marked as a duplicate of this bug. ***
Comment 21 Troy Henderson 2008-01-08 22:17:04 UTC
I've been following this "bug" for a while.  Does anyone know the status of the request?  Is there any chance of getting a > 400% zoom level?
Comment 22 Wouter Bolsterlee (uws) 2008-01-08 22:32:24 UTC
This bug depends on a refactoring of the Evince rendering code to render only parts of pages (poppler couldn't do this before, but can now, afaik). It's quite hard to fix, but the OLPC people have recently shown some interest in this issue as well, so there's hope ;)
Comment 23 Troy Henderson 2008-01-08 22:42:08 UTC
Well this feature is the ONLY reason I keep acroread around ;)
Comment 24 Wouter Bolsterlee (uws) 2008-01-08 22:58:41 UTC
(In reply to comment #23)
> Well this feature is the ONLY reason I keep acroread around ;)

You forget the annotations :)
Comment 25 Oleksij Rempel 2008-03-09 10:33:16 UTC
Iget same issue with big djvu files.

For example:
"Pennsylvania County Type 10 Maps in DJVU Format"

http://www.dot.state.pa.us/Internet/Bureaus/pdPlanRes.nsf/infoBPRCountyType10MapsDJVU?OpenForm&AutoFramed

djvudump franklin_GHSN.djvu 
  FORM:DJVU [720740] 
    INFO [10]         DjVu 13200x18600, v25, 300 dpi, gamma=2,2
    CIDa [36] 
    Sjbz [621454]     JB2 bilevel data
    FGbz [6340]       JB2 colors data
    BG44 [23602]      IW4 data #1, 72 slices, v1.2 (color), 4400x6200
    BG44 [11380]      IW4 data #2, 11 slices
    BG44 [19832]      IW4 data #3, 10 slices
    BG44 [38018]      IW4 data #4, 10 slices

This file will crash with zoom 200 % on my system with 2GB RAM and 2GB SWAP
Comment 26 Gonz 2008-03-18 01:37:42 UTC
Here's another file that kills my system:
http://www.cmap.polytechnique.fr/~mallat/papiers/MallatTheory89.pdf

Evince uses more than 600MB for this 2.8MB file after paging through it.
This is one of three bugs in my Ubuntu system that makes the system (nearly) unusable.
Comment 27 Patricio Espinoza 2008-11-06 17:48:07 UTC
Yes, it would be nice to be able to zoom more than 400% for conference posters.
Thanks!
Comment 28 Greg Grossmeier 2009-01-29 22:18:12 UTC
It isn't just an issue of being able to increase precision when reading pdfs, it also is an issue of being able to read the pdf in the first place.  Not everyone believes that pdfs should be analogous to printed paper, eg: http://olex.openlogic.com/wazi/2008/license-comparison-matrix-pdf_screenshots/

Hopefully some intrepid soul will help with the refactoring.
Comment 29 Daniel Brewer 2009-02-19 10:28:52 UTC
I would really love to have greater zoom levels too.  Even if when rendering the full page it is a problem, surely there should be some option to set the maximum zoom so that people who have more powerful machines can take advantage of them.

Additionally,  I have a situation where a priority program by default renders their pdfs 1 in by 1 in and you need to zoom in by more than 400% to get a good look.  I am sure in this situation that zooming to more than 400% would place much burden on the system.  So maybe maximum level should be pdf page size (and complexity??) dependent.
Comment 30 Peter Bašista 2010-05-10 20:27:46 UTC
Hello there,

I am sorry to say that, but ... Hey! Evince developers! Wake up! This issue has not been solved for five years! Come on, guys! Everyone wants to zoooooom :)

No kidding! This has to be resolved now!
Comment 31 Carlos Garcia Campos 2010-05-11 07:48:15 UTC
Yeah, we know, but there are good reasons why this hasen't been fixed yet. 

The best way to fix this would be implementing tile based rendering, but poppler is designed to parse and render, so that rendering every slice takes almost the same time than render the whole page. We would need to change poppler to parse to intermediate format and then render which is not trivial.
Comment 32 Benjamín Valero Espinosa 2010-05-11 10:44:36 UTC
(In reply to comment #31)
> The best way to fix this would be implementing tile based rendering, but
> poppler is designed to parse and render, so that rendering every slice takes
> almost the same time than render the whole page. We would need to change
> poppler to parse to intermediate format and then render which is not trivial.

So this bug should be reported to Poppler?
Comment 33 Peter Bašista 2010-05-11 20:26:55 UTC
(In reply to comment #32)
> So this bug should be reported to Poppler?

Yes. As soon as Evince developers are not able to work it out, I do not see any other possibility. But guys, this should be done five years ago!
Comment 34 Pander 2010-05-12 21:10:52 UTC
see https://bugs.launchpad.net/evince/+bug/241604 for example patch
Comment 35 Pablo Rodríguez 2010-05-13 17:56:04 UTC
@Peter: many thanks for your interest and enthusiasm with this issue.

@Benjamín: this is not a poppler issue, but it affects evince, more accurately, the way that evince uses poppler to display PDF files.

@Pander: this is actually not a patch, but it doesn't solve the underlying problem.

This issue is one of the main issues to solve for the next release (http://live.gnome.org/Evince/Roadmap), I mean, last time I checked the roadmap it was. On May, 5th, it had been delayed for a later release.

AFAIK, the issue is related to the way evince renders the page. Right now, due to the implementation, evince has to render the whole page, no matter how much of it is displayed. Evince needs a new drawing model that allows partial rendering. This is required for higher zooming levels. And it doesn't seem to be an easy task (I don't code myself).

About the issue itself and to the Evince developers: many thanks for your excellent work on Evince. The issue is important for both general speed improvements and needed higher zooming levels.

This issue was planned for versions 2.32, 2.30, 2.28, 2.26, 2.24 and it was delayed for later releases.

So that users know what is to be expected from this issue, an statement from developers would be extremely helpful.

I wonder whether the issue has been assigned already (it is not clear to me whether a primary contact is an assigned developer). Considering that this issue has been marked as critical with high priority, I don't understand why it has been delayed again. I don't really understand why new features are implemented (which is great, no doubt) while this basic functionality is still waiting for a fix.

I don't want to start a flame at all. I have some questions on this issue that is already 5 years old (as Peter noticed). An explanation would help to understand things. The interrogation that comes to my mind is the following: do you really think that adding multimedia capabilities to a document reader is more important than enabling partial rendering?

Again, I don't want to start any flame, not even a discussion. I'd really appreciate a kind of “official” statement that addresses these questions.

Congratulations for your excellent work and many thanks for your help,


Pablo
Comment 36 Carlos Garcia Campos 2010-05-13 18:53:26 UTC
(In reply to comment #35)
> @Benjamín: this is not a poppler issue, but it affects evince, more accurately,
> the way that evince uses poppler to display PDF files.

actually both, it could be fixed in evince, but due to poppler design it would make evince very very slow. 

> @Pander: this is actually not a patch, but it doesn't solve the underlying
> problem.

indeed.

> This issue is one of the main issues to solve for the next release
> (http://live.gnome.org/Evince/Roadmap), I mean, last time I checked the roadmap
> it was. On May, 5th, it had been delayed for a later release.

I removed it from the Reoadmap for 3.0 when I realized that with current poppler tile rendering would make evince very slow. 

> AFAIK, the issue is related to the way evince renders the page.

Not exactly, all rendering is done by poppler, not by evince. 

>  Right now, due
> to the implementation, evince has to render the whole page, no matter how much
> of it is displayed. Evince needs a new drawing model that allows partial
> rendering. This is required for higher zooming levels. And it doesn't seem to
> be an easy task (I don't code myself).

Exactly, the idea was to implement tile based rendering, so that instead of asking poppler to render the whole page, we ask to render slices of the page depending on the current view area. That requires to re-work the current pixbuf-cache, since it's based on pages rather than slices (or tiles)

> I wonder whether the issue has been assigned already (it is not clear to me
> whether a primary contact is an assigned developer).

Yes, José Aliste is/was working on it. 

>  Considering that this
> issue has been marked as critical with high priority, I don't understand why it
> has been delayed again. I don't really understand why new features are
> implemented (which is great, no doubt) while this basic functionality is still
> waiting for a fix.

Because we need to fix poppler first, and it's not an easy task since it's actually a design issue. Current poppler API allows to render a random slice of page, but due to poppler design, rendering a slice takes mostly the same time than render the whole page, only if we need two slices, rendering the page would be 2x slower. Every time you ask poppler to render a slice, it needs to parse the whole page and then the slice is drawn. Most of the time when rendering is spent parsing the page, not drawing. We need to change poppler to use an intermediate format that can be used to render the page.

> I don't want to start a flame at all. I have some questions on this issue that
> is already 5 years old (as Peter noticed). An explanation would help to
> understand things. The interrogation that comes to my mind is the following: do
> you really think that adding multimedia capabilities to a document reader is
> more important than enabling partial rendering?

No, it's not more important, just more realistic. 

> Again, I don't want to start any flame, not even a discussion. I'd really
> appreciate a kind of “official” statement that addresses these questions.

I know, you feedback is very appreciated.
Comment 37 Pander 2010-05-13 22:28:57 UTC
Thanks to all for the feedback. My notes indeed do not fix the underlying problem. However, I'm able to zoom as I please even though it costs me lots of CPU power and I can live with that for now. I hope this initiates fixing of poppler.

Meanwhile, allowing for zooming up to e.g. 1600% (a scaling of 8) would please many users without getting into too much CPU load. Would evince maintainers like to consider this for now?
Comment 38 Pablo Rodríguez 2010-05-14 16:37:51 UTC
(In reply to comment #36)
> (In reply to comment #35)
> > [...]
> > Right now, due to the implementation, evince has to render the whole page,
> > no matter how much of it is displayed. Evince needs a new drawing model
> > that  allows partial rendering. This is required for higher zooming levels.
> > And it doesn't seem to be an easy task (I don't code myself).
> 
> Exactly, the idea was to implement tile based rendering, so that instead of
> asking poppler to render the whole page, we ask to render slices of the page
> depending on the current view area. That requires to re-work the current
> pixbuf-cache, since it's based on pages rather than slices (or tiles)

Thanks for your reply, Carlos.

Would it take long to rewrite the pixbuf-cache?

> > I wonder whether the issue has been assigned already (it is not clear to me
> > whether a primary contact is an assigned developer).
> 
> Yes, José Aliste is/was working on it. 

On evince, poppler or both?

> > [..]
> > I don't really understand why new features are implemented (which is great,
> > no doubt) while this basic functionality is still waiting for a fix.
> 
> Because we need to fix poppler first, and it's not an easy task since it's
> actually a design issue. Current poppler API allows to render a random slice
> of page, but due to poppler design, rendering a slice takes mostly the same
> time than render the whole page, only if we need two slices, rendering the
> page would be 2x slower. Every time you ask poppler to render a slice, it 
> needs to parse the whole page and then the slice is drawn. Most of the time
> when rendering is spent parsing the page, not drawing. We need to change
> poppler to use an intermediate format that can be used to render the page.

Thanks for your explanation.

I guess this improvement won't be planned for the next 0.14 release, but for version 0.16, which could be release six months from the 0.14 release (early 2011).

Is there any poppler bug report where those ones interested could follow the issue? (If such report exists, I wonder whether it would be possible to mark that this issue depends on that poppler bug.)

> > [...]
> > The interrogation that comes to my mind is the following: do you really
> > think that adding multimedia capabilities to a document reader is more
> > important than enabling partial rendering?
> 
> No, it's not more important, just more realistic.

I agree. Having some info from the poppler side would be extremely useful.

Thanks for your help,


Pablo
Comment 39 Carlos Garcia Campos 2010-05-15 14:42:04 UTC
(In reply to comment #38)
> Would it take long to rewrite the pixbuf-cache?

Well, I think it could be done in a release cycle. 
 
> > Yes, José Aliste is/was working on it. 
> 
> On evince, poppler or both?

on evince
 
> I guess this improvement won't be planned for the next 0.14 release, but for
> version 0.16, which could be release six months from the 0.14 release (early
> 2011).

I has been never planned actually. 
 
> Is there any poppler bug report where those ones interested could follow the
> issue? (If such report exists, I wonder whether it would be possible to mark
> that this issue depends on that poppler bug.)

No, there isn't any bug report.
Comment 40 Carlos Garcia Campos 2010-05-31 17:12:16 UTC
I've just pushed a patch to git master to use a dynamic cache size to increase the zooming level. See 

http://git.gnome.org/browse/evince/commit/?id=d375c36972ff3a01b7979984b5a1043eb4c807b0

please, try it out and let me know whether it works for you.

Thanks.
Comment 41 Pablo Rodríguez 2010-05-31 21:20:08 UTC
(In reply to comment #40)
> I've just pushed a patch to git master to use a dynamic cache size to increase
> the zooming level. See 
> 
> http://git.gnome.org/browse/evince/commit/?id=d375c36972ff3a01b7979984b5a1043eb4c807b0
> 
> please, try it out and let me know whether it works for you.

Many thanks, Carlos.

May I ask whether this is a workaround for a faster partial rendering from poppler?

Thanks again,


Pablo
Comment 42 Carlos Garcia Campos 2010-06-01 07:57:20 UTC
No, it's not a workaround, this just changes the way the pixbuf cache works, but it still renders the whole page. Pixbuf cache cached always 2 pages before and after the current page range, no matter what the zoom level was. However, for lower zoom levels the memory required for every page is less, so we can cache more pages in this case without increasing the memory required. In the same way, when the zoom level is high we can just save memory by not caching any pages at all and use that memory to be able to render pages at a higher zoom level. This means there's still a limit, but it depends on the memory used rather than a static number of pages. With tile based rendering we could zoom in/out limitlessly
Comment 43 Pablo Rodríguez 2010-09-07 17:44:24 UTC
Carlos,

I wonder whether the release of cairo-1.10 might help to tile based rendering.

Thanks for your help,


Pablo
Comment 44 José Aliste 2010-09-07 17:58:26 UTC
Pablo, the new child surfaces in cairo-1.10 coul help to make the refactoring of the pixbuf cache a lot simpler, although I need to investigate about memory usage when only some sub-surfaces of a bigger surface have data. However, we will still need the poppler refactoring to avoid reparsing everytime a render is made.
Comment 45 Carlos Garcia Campos 2010-09-08 07:46:19 UTC
(In reply to comment #43)
> Carlos,
> 
> I wonder whether the release of cairo-1.10 might help to tile based rendering.

It might help, but main problem is still the poppler parsing and rendering model. 

> Thanks for your help,
> 
> 
> Pablo
Comment 46 Pablo Rodríguez 2010-09-09 05:00:35 UTC
(In reply to comment #44)
> Pablo, the new child surfaces in cairo-1.10 could help to make the refactoring
> of the pixbuf cache a lot simpler, although I need to investigate about memory
> usage when only some sub-surfaces of a bigger surface have data. However, we
> will still need the poppler refactoring to avoid reparsing everytime a render
> is made.

Thanks for your replies, José and Carlos.

I guest that both evince and poppler should be improved, so rendering would be as fast as it is possible.

BTW, José, do you plan to work on parsing and rendering in poppler?

Thanks for your help,


Pablo
Comment 47 Christian Persch 2010-10-22 10:56:21 UTC
*** Bug 632857 has been marked as a duplicate of this bug. ***
Comment 48 Paul Sladen 2011-02-18 11:59:02 UTC
I've ended up filing a related bug:

  "Evince restricts maximum zoom to 70% on large (area) documents"
  http://launchpad.net/bugs/721217

Should I move that upstream as a new bug-report, or as the intended fix for this bug (maximum zoom arbitrarily limited to 400%) been the cause of this one?
Comment 49 José Aliste 2011-02-18 13:56:26 UTC
Paul, this is intentional, we restrict the amount of memory that evince will use, so for big documents you don't get many options on the zoom level. The current limit is around 100 MB I think and it is hardcoded in the code. Of course we could make it configurable by a gsetting key, but the real thing is to fix the cache code to only cache visible regions instead of the hole page...
Comment 50 Pander 2011-02-18 14:01:41 UTC
Why not do both? GIMP also allows users changing limits for maximum memory usage.
Comment 51 Paul Sladen 2011-02-18 15:20:43 UTC
José: thanks for the answer, filed separately as:

  "Hardcoded cache size limit restricts maximum zoom to 70% on large (area) documents"
  https://bugzilla.gnome.org/show_bug.cgi?id=642683
Comment 55 Dmitry K 2013-01-21 12:09:25 UTC
Still waiting impatiently for this bug to be fixed.
Comment 56 José Aliste 2013-01-21 17:53:19 UTC
weird. I don't know why I haven't commented on this. I am working on a solution... I have a working solution for non-dual-mode that allows tile rendering, and thus, allow evince to use less memory on higher zoom. Unfortunately, I am on leave until march, and in march I have three courses to teach, so it is safer to assume that I might finish this around the 3.8 release, which means that it won't be merged before the 3.10 release.
Comment 57 Pablo Rodríguez 2013-06-27 20:31:47 UTC
I have just read that there is GSOC project by Aakash Goenka (mentored by José) on this bug.

I wonder whether the project also includes fixing the poppler side of the issue (according to comment 31 by Carlos).
Comment 58 José Aliste 2013-06-27 20:50:52 UTC
Pablo, the poppler side is much more difficult to solve and I don't think we will have time to taclke it within this SoC. Otherwise, the slowness should not affect how things work in evince because we'll use tiles that are big enough so we don't need many tiles each time...In fact, most probably we 'll use tiles only for large zoom modes where a page would make several screens wide.
Comment 59 Germán Poo-Caamaño 2014-02-12 22:12:13 UTC
*** Bug 724252 has been marked as a duplicate of this bug. ***
Comment 60 David Gumberg 2014-04-10 15:18:42 UTC
Is this going to be merged soon?
Comment 61 André Klapper 2014-04-10 16:41:59 UTC
David: Doesn't merging require a patch first?
Comment 62 David Gumberg 2014-04-10 17:01:26 UTC
Andre sorry I thought a patch had already been submitted, I remember the GSOC user having a local git branch last time I checked on this bug
Comment 63 José Aliste 2015-11-02 16:47:46 UTC
*** Bug 752885 has been marked as a duplicate of this bug. ***
Comment 64 joel.forums 2016-05-22 01:39:45 UTC
Thanks for working on a patch for this @Jose!
Together with the great recently added annotation features, increased max zoom level would make me able to completely move away from wine and PDF-XChange.

Especially when reading scientific papers and similar articles where there are many figures in total, I find myself not being able to go further than ~ 250% which is not enough to see the small details in the figures.
Comment 65 c.buhtz 2016-08-20 07:15:26 UTC
What is the current status about that bug?

I read about a merge. But in Debian unstable the limit is still at 400%.
Comment 66 André Klapper 2016-12-26 17:49:10 UTC
(In reply to c.buhtz from comment #65)
> I read about a merge.

Then please provide links to the place where you read that.

> But in Debian unstable the limit is still at 400%.

Then please provide info which Evince version is in "Debian unstable".
Comment 67 c.buhtz 2016-12-26 20:03:34 UTC
https://tracker.debian.org/pkg/evince
Comment 68 André Klapper 2016-12-27 07:29:04 UTC
@c.buhtz: And that link shows "a merge" where exactly?
Comment 69 c.buhtz 2017-07-22 22:01:27 UTC
Currently it is 3.22.1-4.
You can check here https://packages.debian.org/source/unstable/evince
Comment 70 André Klapper 2017-07-23 20:54:39 UTC
@c.buhtz: Would you please answer my first question in comment 66 by providing an exact link and a quote so I know which phrase to search for? Thanks!
Comment 71 c.buhtz 2017-07-23 21:12:13 UTC
I don't have a link or source. When I would I had reported it here. Sorry.
Comment 72 André Klapper 2017-07-31 15:22:27 UTC
So the last six comments cover discussing random unsourced rumors. Alright...
Comment 73 Germán Poo-Caamaño 2018-05-14 21:22:56 UTC
*** Bug 788909 has been marked as a duplicate of this bug. ***
Comment 74 GNOME Infrastructure Team 2018-05-22 12:58:24 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/6.