Interactive table of content -- jumps always 1 page too far
Hello list, Having the problem that if I jump to a chapter or section by clicking on the interactive table of content (while the page numbers presented do match the actual page number where the chapter or section begins) always leads me to jumping one page too far. I've tried to produce a MWE, but failed so far, even if I add all the commands and setups which could affect page numbering, it doesn't reproduce the error. I didn't do setting the userpage number by hand. In fact the page number is off by 2 from the real page number, caused by a makeup title page, which does not do page counting (btw. is there a way to force a custom title page makeup to DO count the page number?) and an extra page coming right after it before the table of contents. Setting the right page number on the table of contents page solves that, but clicking an entry in the table of contents still sends me one page too far. Can anyone guid me on where to look or what to try to solve this nasty problem? Thanks. Greetings, Rob
On 1/31/2015 1:16 AM, Rob Heusdens wrote:
Hello list,
Having the problem that if I jump to a chapter or section by clicking on the interactive table of content (while the page numbers presented do match the actual page number where the chapter or section begins) always leads me to jumping one page too far.
I've tried to produce a MWE, but failed so far, even if I add all the commands and setups which could affect page numbering, it doesn't reproduce the error.
such references don't use user pagenumbers (often automated references use internal numbers or real page numbers or a symbolic name) so, either something is really wrong or your browser is bad Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
such references don't use user pagenumbers (often automated references use internal numbers or real page numbers or a symbolic name)
so, either something is really wrong or your browser is bad
Hans
Hans, No, it can't be a browser thing (I think). In the code I sent, using the same setups and document structure as the actual document, the browser jumpt to the correct page. So it is not the browser which is in error, supposedly. I will try to make a minimal example that exposes the same behaviour, but so far I could not reproduce it (and working on some other glitches that needs repair, so it may take some time). Greetings, Rob
On 01/31/2015 01:16 AM, Rob Heusdens wrote:
Hello list,
Having the problem that if I jump to a chapter or section by clicking on the interactive table of content (while the page numbers presented do match the actual page number where the chapter or section begins) always leads me to jumping one page too far.
I've tried to produce a MWE, but failed so far, even if I add all the commands and setups which could affect page numbering, it doesn't reproduce the error.
I didn't do setting the userpage number by hand. In fact the page number is off by 2 from the real page number, caused by a makeup title page, which does not do page counting (btw. is there a way to force a custom title page makeup to DO count the page number?) and an extra page coming right after it before the table of contents. Setting the right page number on the table of contents page solves that, but clicking an entry in the table of contents still sends me one page too far.
Hi Rob, there is a minimal sample: \setupcolors[state=start] \setupinteraction[state=start, focus=standard] \setupinteractionscreen[width=fit] \definecombinedlist[content][all] \setuphead[part][placehead=yes] \starttext \completecontent \dorecurse{5} {\part{Part} \input zapf \chapter{Chapter} \input zapf \section{Section} \input zapf \subsection{Subsection} \input zapf} \stoptext It doesn’t show what you meant, the link destination is not on the heading itself, but on the next paragraph. I think this should be improved. And I guess it goes unnoticed, because after clicking on a link, the browser fits view to page.
Can anyone guid me on where to look or what to try to solve this nasty problem?
All you can do is to copy your file to a temporary version and start commenting commands from the preamble in that temporary version. This is trial and error. Remove individual commands from preamble, compile the document and check the error. When the error dissapeared, you have probably found its cause. If you report it to the mailing list, people will tell whether it is a bug or your code needs improvements. Don’t do any other changes to that temporary file. After the bug hunting, you should delete that file. Sorry, but (I’m afraid) this is the best way I know to hunt undefined bugs. I hope it helps, Pablo -- http://www.ousia.tk
On 1/31/2015 1:12 PM, Pablo Rodriguez wrote:
On 01/31/2015 01:16 AM, Rob Heusdens wrote:
Hello list,
Having the problem that if I jump to a chapter or section by clicking on the interactive table of content (while the page numbers presented do match the actual page number where the chapter or section begins) always leads me to jumping one page too far.
I've tried to produce a MWE, but failed so far, even if I add all the commands and setups which could affect page numbering, it doesn't reproduce the error.
I didn't do setting the userpage number by hand. In fact the page number is off by 2 from the real page number, caused by a makeup title page, which does not do page counting (btw. is there a way to force a custom title page makeup to DO count the page number?) and an extra page coming right after it before the table of contents. Setting the right page number on the table of contents page solves that, but clicking an entry in the table of contents still sends me one page too far.
Hi Rob,
there is a minimal sample:
\setupcolors[state=start] \setupinteraction[state=start, focus=standard] \setupinteractionscreen[width=fit] \definecombinedlist[content][all] \setuphead[part][placehead=yes] \starttext \completecontent \dorecurse{5} {\part{Part} \input zapf \chapter{Chapter} \input zapf \section{Section} \input zapf \subsection{Subsection} \input zapf} \stoptext
It doesn’t show what you meant, the link destination is not on the heading itself, but on the next paragraph.
\enabletrackers[*references*] \enabletrackers[*destinations*]
I think this should be improved. And I guess it goes unnoticed, because after clicking on a link, the browser fits view to page.
this is also a bit browser dependent i think
Can anyone guid me on where to look or what to try to solve this nasty problem?
All you can do is to copy your file to a temporary version and start commenting commands from the preamble in that temporary version.
This is trial and error. Remove individual commands from preamble, compile the document and check the error.
When the error dissapeared, you have probably found its cause. If you report it to the mailing list, people will tell whether it is a bug or your code needs improvements.
Don’t do any other changes to that temporary file. After the bug hunting, you should delete that file.
Sorry, but (I’m afraid) this is the best way I know to hunt undefined bugs.
I hope it helps,
Pablo
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 01/31/2015 01:36 PM, Hans Hagen wrote:
On 1/31/2015 1:12 PM, Pablo Rodriguez wrote:
[...] It doesn’t show what you meant, the link destination is not on the heading itself, but on the next paragraph.
\enabletrackers[*references*] \enabletrackers[*destinations*]
Hi Hans, many thanks for your reply. I’m afraid there might be something wrong with this. I have been using poppler-glib-demo to check it (and this is the first time I use it, so I might be wrong as well). The minimal sample: \enabletrackers[*destinations*] \setupinteraction[state=start, focus=standard] \setupinteractionscreen[width=fit] \starttext \completecontent \chapter{Chapter} \stoptext Link destination for “Chapter” seems to be: << /D [27 0 R /XYZ 70.867 689.409 null]>> But both chapter headings are placed at x,y (70.87, 122.22), according to poppler-glib-demo. Anyway, there is a proof that something might be rotten, because the link itself has a higher box (an it is lower in the page): << /Subtype /Link /Dest (#2) /F 4 /Rect [70.867 652.344 496.06 666.772] /Border [0 0 0]>> I cannot give a more accurate description (the PDF spec is all Greek to me), but I think there is something wrong with link destinations (they seem to be lower than they should be). BTW, does the sample above work right with Adobe? (I’m don’t have it installed.) It doesn’t work with either evince-3.10.3 or mupdf-1.6.
I think this should be improved. And I guess it goes unnoticed, because after clicking on a link, the browser fits view to page.
this is also a bit browser dependent i think
I guess this is caused by the link destination syntax (section 12.3.2.2 of the PDF specification). Withouth specifying "focus=standard" in the sample above, the link is: << /Subtype /Link /Dest [13 0 R /Fit] /F 4 /Rect [70.867 652.344 496.06 666.772] /Border [0 0 0]>> /Fit specifies that the page should be so that its entire width and height are magnified enough so that they fit in the window. Having said that, I cannot see why it makes sense that ConTeXt generates documents with this default. I mean, the default paper size is A4, if the default behavior after cliciking on a link is to fit page height (or width in landscape), one needs a huge screen not to render the text unreadable. Sorry, but I cannot see the gain in this default. Would it be possible that the default would be the behaviour set by "focus=standard"? Could you consider both suggestions? Many thanks for your help, Pablo -- http://www.ousia.tk
On 01/31/2015 01:36 PM, Hans Hagen wrote:
On 1/31/2015 1:12 PM, Pablo Rodriguez wrote:
[...] It doesnât show what you meant, the link destination is not on the heading itself, but on the next paragraph.
\enabletrackers[*references*] \enabletrackers[*destinations*]
Hi Hans,
many thanks for your reply.
Iâm afraid there might be something wrong with this. I have been using poppler-glib-demo to check it (and this is the first time I use it, so I might be wrong as well).
The minimal sample:
\enabletrackers[*destinations*] \setupinteraction[state=start, focus=standard] \setupinteractionscreen[width=fit] \starttext \completecontent \chapter{Chapter} \stoptext
Link destination for âChapterâ seems to be:
<< /D [27 0 R /XYZ 70.867 689.409 null]>>
But both chapter headings are placed at x,y (70.87, 122.22), according to poppler-glib-demo.
Anyway, there is a proof that something might be rotten, because the link itself has a higher box (an it is lower in the page):
<< /Subtype /Link /Dest (#2) /F 4 /Rect [70.867 652.344 496.06 666.772] /Border [0 0 0]>>
I cannot give a more accurate description (the PDF spec is all Greek to me), but I think there is something wrong with link destinations (they seem to be lower than they should be).
BTW, does the sample above work right with Adobe? (Iâm donât have it installed.) It doesnât work with either evince-3.10.3 or mupdf-1.6.
I think this should be improved. And I guess it goes unnoticed, because after clicking on a link, the browser fits view to page.
this is also a bit browser dependent i think
I guess this is caused by the link destination syntax (section 12.3.2.2 of the PDF specification).
Withouth specifying "focus=standard" in the sample above, the link is:
<< /Subtype /Link /Dest [13 0 R /Fit] /F 4 /Rect [70.867 652.344 496.06 666.772] /Border [0 0 0]>>
/Fit specifies that the page should be so that its entire width and height are magnified enough so that they fit in the window.
Having said that, I cannot see why it makes sense that ConTeXt generates documents with this default.
I mean, the default paper size is A4, if the default behavior after cliciking on a link is to fit page height (or width in landscape), one needs a huge screen not to render the text unreadable.
Sorry, but I cannot see the gain in this default. Would it be possible that the default would be the behaviour set by "focus=standard"?
Could you consider both suggestions?
Many thanks for your help,
Pablo -- http://www.ousia.tk
What I forgot to include in the code ex, was this settings: \setupinteraction [state=start, title={Leerboek politieke economie}, subtitle={politieke economie}, author={Academie der Wetenschappen van de Sovjet-Unie}, keyword={economie, politieke economie, marxisme, marxisme-leninisme}, openaction=FitWidth, focus=width, date={31 januari 2015}] I will replace this with: \setupinteraction[state=start] and see if that makes a difference... Greetings, Rob
On 1/31/2015 3:50 PM, Pablo Rodriguez wrote:
On 01/31/2015 01:36 PM, Hans Hagen wrote:
On 1/31/2015 1:12 PM, Pablo Rodriguez wrote:
[...] It doesn’t show what you meant, the link destination is not on the heading itself, but on the next paragraph.
\enabletrackers[*references*] \enabletrackers[*destinations*]
Hi Hans,
many thanks for your reply.
I’m afraid there might be something wrong with this. I have been using poppler-glib-demo to check it (and this is the first time I use it, so I might be wrong as well).
Well, guess why I never use these fancy zoom features ... not only is the standard fuzzy, viewers have behaved differently over more than a decade depending on versions and checking again is a waste of energy (a similar fuzzyness is with widgets where the inheritance model depends on the viewer version). Even with width or height preferences one needs to compensate for lack of proper offset control in viewers. I get the impression that there is also some gambling involved related to the height of characters. Acrobat is not perfect with this and most public viewers are bugged. The default pdf code is something << /D [ 13 0 R /Fit ] /S /GoTo >> which is about as safe as it can be (in fact, last time I looked into it I even noticed a difference between named and page destinations). The logic is there in context but it's unclear how to flush the right stuff that suits all viewers.
The minimal sample:
\enabletrackers[*destinations*] \setupinteraction[state=start, focus=standard] \setupinteractionscreen[width=fit] \starttext \completecontent \chapter{Chapter} \stoptext
Link destination for “Chapter” seems to be:
<< /D [27 0 R /XYZ 70.867 689.409 null]>>
But both chapter headings are placed at x,y (70.87, 122.22), according to poppler-glib-demo.
these things also depend on where one starts counting (lower left corner is the reference point so the headers have a large y position)
Anyway, there is a proof that something might be rotten, because the link itself has a higher box (an it is lower in the page):
<< /Subtype /Link /Dest (#2) /F 4 /Rect [70.867 652.344 496.06 666.772] /Border [0 0 0]>>
I cannot give a more accurate description (the PDF spec is all Greek to me), but I think there is something wrong with link destinations (they seem to be lower than they should be).
BTW, does the sample above work right with Adobe? (I’m don’t have it installed.) It doesn’t work with either evince-3.10.3 or mupdf-1.6.
I think this should be improved. And I guess it goes unnoticed, because after clicking on a link, the browser fits view to page.
this is also a bit browser dependent i think
I guess this is caused by the link destination syntax (section 12.3.2.2 of the PDF specification).
Withouth specifying "focus=standard" in the sample above, the link is:
<< /Subtype /Link /Dest [13 0 R /Fit] /F 4 /Rect [70.867 652.344 496.06 666.772] /Border [0 0 0]>>
/Fit specifies that the page should be so that its entire width and height are magnified enough so that they fit in the window.
Having said that, I cannot see why it makes sense that ConTeXt generates documents with this default.
I mean, the default paper size is A4, if the default behavior after cliciking on a link is to fit page height (or width in landscape), one needs a huge screen not to render the text unreadable.
Sorry, but I cannot see the gain in this default. Would it be possible that the default would be the behaviour set by "focus=standard"?
Could you consider both suggestions?
Many thanks for your help,
Pablo
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hi Rob,
there is a minimal sample:
\setupcolors[state=start] \setupinteraction[state=start, focus=standard] \setupinteractionscreen[width=fit] \definecombinedlist[content][all] \setuphead[part][placehead=yes] \starttext \completecontent \dorecurse{5} {\part{Part} \input zapf \chapter{Chapter} \input zapf \section{Section} \input zapf \subsection{Subsection} \input zapf} \stoptext
It doesnât show what you meant, the link destination is not on the heading itself, but on the next paragraph.
I think this should be improved. And I guess it goes unnoticed, because after clicking on a link, the browser fits view to page.
Can anyone guid me on where to look or what to try to solve this nasty problem?
All you can do is to copy your file to a temporary version and start commenting commands from the preamble in that temporary version.
This is trial and error. Remove individual commands from preamble, compile the document and check the error.
When the error dissapeared, you have probably found its cause. If you report it to the mailing list, people will tell whether it is a bug or your code needs improvements.
Donât do any other changes to that temporary file. After the bug hunting, you should delete that file.
Sorry, but (Iâm afraid) this is the best way I know to hunt undefined bugs.
I hope it helps,
Pablo -- http://www.ousia.tk ____
The code looks likes this, but this examples does not exhibit the same faulty off-by-1-page interactive page jump behaviour. In the chapters in the body matter, always directly after a new chapter a section begins (in this example omitted). \setupinteraction[state=start] \setuppagenumbering[location=,alternative=doublesided] \definemakeup [titlepage] [align=middle,style=\bf] \starttext \startfrontmatter Small title \page \phantom{x}\vfill Colofon \page \starttitlepagemakeup BIG TITLE \stoptitlepagemakeup % <- empty page inserted after here, so page number becomes 5 \setcounter[userpage][5] % <- without this, the page number = 3 \setuppagenumbering[location={footer,middle}] \completecontent \chapter{Introduction} \dorecurse{4}{\input zapf} \stopfrontmatter \startbodymatter \setuppagenumbering[location={header,middle}] \dorecurse{21}{\chapter{Knuth} \dorecurse{10}{\input knuth}} \stopbodymatter \startappendices \chapter{Appendix} \dorecurse{4}{\input zapf} \stopappendices \startbackmatter \chapter{Notes} \dorecurse{4}{\input zapf} \stopbackmatter \stoptext I'ĺl start trying \enabletrackers...
Am 31.01.2015 um 17:42 schrieb Rob Heusdens
: \starttitlepagemakeup BIG TITLE \stoptitlepagemakeup % <- empty page inserted after here, so page number becomes 5 \setcounter[userpage][5] % <- without this, the page number = 3
You don’t need this manual setting for the pagenumber when you set „pagestate=start” for the markup environment. Below you can see that the second makeup environment increments the page number. \starttext \startmakeup[standard] Standardmakeup page \stopmakeup \input knuth \startmakeup[standard][pagestate=start] Standardmakeup page \stopmakeup \input knuth \stoptext Wolfgang
Am 31.01.2015 um 17:42 schrieb Rob Heusdens
: \starttitlepagemakeup BIG TITLE \stoptitlepagemakeup % <- empty page inserted after here, so page number becomes 5 \setcounter[userpage][5] % <- without this, the page number = 3
You donât need this manual setting for the pagenumber when you set âpagestate=startâ for the markup environment. Below you can see that the second makeup environment increments the page number.
\starttext
\startmakeup[standard] Standardmakeup page \stopmakeup
\input knuth
\startmakeup[standard][pagestate=start] Standardmakeup page \stopmakeup
\input knuth
\stoptext
Wolfgang
Wolfgang Thank you. But the real issue is still that page jumps from the interactive table of contents (at least, only those I have tried and noticed their misbehaviour) are always off by 1 page too far. I will try to make a MWE for this (the other code I sent, did not expose the error), and will try to see if \enabletrackers can point me to where the problem might be located (but first I have some other glitches I need to repair). greetings, Rob
On 01/31/2015 05:42 PM, Rob Heusdens wrote:
[...] The code looks likes this, but this examples does not exhibit the same faulty off-by-1-page interactive page jump behaviour. In the chapters in the body matter, always directly after a new chapter a section begins (in this example omitted).
Hi Rob, include in your preamble the following command to avoid makeups not being numbered as pages: \setupmakeup[pagestate=start] So you don’t have to worry about setting counters for userpage. I don’t see any special problem here. You could define a colophon makeup for the colophon: \definemakeup[colophon][bottom=] (BTW, I thought colophons were at the end of the book.) I wonder what makes your links point to the next page from their destinations. BTW, which OS and PDF interpreter are you using? Pablo
\setupinteraction[state=start] \setuppagenumbering[location=,alternative=doublesided] \definemakeup [titlepage] [align=middle,style=\bf] \starttext \startfrontmatter Small title \page \phantom{x}\vfill Colofon \page \starttitlepagemakeup BIG TITLE \stoptitlepagemakeup % <- empty page inserted after here, so page number becomes 5 \setcounter[userpage][5] % <- without this, the page number = 3 \setuppagenumbering[location={footer,middle}] \completecontent \chapter{Introduction} \dorecurse{4}{\input zapf} \stopfrontmatter \startbodymatter \setuppagenumbering[location={header,middle}] \dorecurse{21}{\chapter{Knuth} \dorecurse{10}{\input knuth}} \stopbodymatter \startappendices \chapter{Appendix} \dorecurse{4}{\input zapf} \stopappendices \startbackmatter \chapter{Notes} \dorecurse{4}{\input zapf} \stopbackmatter \stoptext
On 01/31/2015 05:42 PM, Rob Heusdens wrote:
[...] The code looks likes this, but this examples does not exhibit the same faulty off-by-1-page interactive page jump behaviour. In the chapters in the body matter, always directly after a new chapter a section begins (in this example omitted).
Hi Rob,
include in your preamble the following command to avoid makeups not being numbered as pages:
\setupmakeup[pagestate=start]
So you donât have to worry about setting counters for userpage.
I donât see any special problem here.
You could define a colophon makeup for the colophon:
\definemakeup[colophon][bottom=]
(BTW, I thought colophons were at the end of the book.)
I wonder what makes your links point to the next page from their destinations.
BTW, which OS and PDF interpreter are you using?
Pablo
Hello Pablo, The problem is NOT that the pagenumber as displayed on the page and the page counter in the viewer ar not in sync (because that is repairable by either setting the pagestate=start in the makeup, or by setting the page counter directly, as I did as temoporary workaround). The problem is that the viewer sends me to the wrong page (always off by 1 page too far) in the interactive table of contents. So far I have not figured out where to look for, or make a MWE that exposes the same problem. The code I sent, resembling the setups I use and document structure I use, did NOT expose that error, so I conclude that the problem is (most likely) not viewer related. I use an Evince Document Viewer 3.10.3 on Ubuntu. If I have time I will use the \enabletrackers to see if that can direct me to where the problem may be located. Greetings & thanks, Rob
On 01/31/2015 07:28 PM, Rob Heusdens wrote:
[...] If I have time I will use the \enabletrackers to see if that can direct me to where the problem may be located.
Hi Rob, \enabletrackers[*destinations*] will visually display (adding a grey background to) the destination where the link points to. I’m afraid that I won’t be surprised that the trackers display the areas where destinations are supposed to be, but actual destinations are different. (I would be happy to be proven wrong.) Checking it is really simple. At first, I thought I had to dive into the log file, but the PDF document itself shows the results. Just in case it helps, Pablo -- http://www.ousia.tk
On 01/31/2015 07:28 PM, Rob Heusdens wrote:
[...] If I have time I will use the \enabletrackers to see if that can direct me to where the problem may be located.
Hi Rob,
\enabletrackers[*destinations*] will visually display (adding a grey background to) the destination where the link points to.
Iâm afraid that I wonât be surprised that the trackers display the areas where destinations are supposed to be, but actual destinations are different. (I would be happy to be proven wrong.)
Checking it is really simple. At first, I thought I had to dive into the log file, but the PDF document itself shows the results.
Just in case it helps,
Pablo -- http://www.ousia.tk
Hello Pablo, I am sorry, I had not yet tried the \enabletrackers... Anyway, the problem resides in the settings for \setupinteraction which I use to set the page in the viewer to fit the width. Unfortunately is also leads to the "off by one page too far" error. If I omit those settings, it jumps to the right page, but then unfortunately does not do fit width but fit height (which is not what I want...). Greetings, Rob
On 01/31/2015 08:11 PM, Rob Heusdens wrote:
[...] Hello Pablo,
I am sorry, I had not yet tried the \enabletrackers...
Hi Rob, don’t worry, \enabletrackers don’t work here.
Anyway, the problem resides in the settings for \setupinteraction which I use to set the page in the viewer to fit the width. Unfortunately is also leads to the "off by one page too far" error.
If I omit those settings, it jumps to the right page, but then unfortunately does not do fit width but fit height (which is not what I want...).
"focus=width" is the problematic part. Replace it with "focus=standard" and it will work better (it isn’t perfect either [there is a bug reported before]). \enabletrackers[*destinations*] \setupinteraction[state=start, focus=standard] \starttext \completecontent \chapter{Chapter} \dorecurse{5}{\input knuth} \stoptext It took me a while to realized the problem, because I didn’t have continious view enabled in evince. I hope it is solved now. Best, Pablo -- http://www.ousia.tk
"focus=width" is the problematic part. Replace it with "focus=standard" and it will work better (it isnât perfect either [there is a bug reported before]).
\enabletrackers[*destinations*] \setupinteraction[state=start, focus=standard] \starttext \completecontent \chapter{Chapter} \dorecurse{5}{\input knuth} \stoptext
It took me a while to realized the problem, because I didnât have continious view enabled in evince.
I hope it is solved now.
Best,
Pablo -- http://www.ousia.tk
In other words the "focus=width" option causes the bug, and the workaround is to set it to "focus=standard", so at least you go to the right page.... Well that is at least a solution for publicing my material. But I hope one day someone finds time to repair the bug. Thanks, Rob
"focus=width" is the problematic part. Replace it with "focus=standard" and it will work better (it isnâÂÂt perfect either [there is a bug reported before]).
\enabletrackers[*destinations*] \setupinteraction[state=start, focus=standard] \starttext \completecontent \chapter{Chapter} \dorecurse{5}{\input knuth} \stoptext
It took me a while to realized the problem, because I didnâÂÂt have continious view enabled in evince.
I hope it is solved now.
Best,
Pablo -- http://www.ousia.tk
In other words the "focus=width" option causes the bug, and the workaround is to set it to "focus=standard", so at least you go to the right page....
Well that is at least a solution for publicing my material.
But I hope one day someone finds time to repair the bug.
Thanks,
Rob
One last word on this... Actually the "focus=standard" is fine, it keeps the viewer in the same status (fit width or fit height) as you had when clicking on the link. So this works fine. Greetings, Rob
On 01/31/2015 08:51 PM, Rob Heusdens wrote:
[...] In other words the "focus=width" option causes the bug, and the workaround is to set it to "focus=standard", so at least you go to the right page....
Hi Rob, I’m afraid that the issue with "focus=width" is a bug in evince or poppler. I’m afraid that link destination is miscalculated by ConTeXt. But in the previous sample, evince should behave the same either with "focus=width" or "focus=standard". Links have internally the same top value: << /D [25 0 R /XYZ 70.867 689.409 null]>> << /D [27 0 R /FitH 70.867]>> I will ask to the evince developers about it. mupdf-1.6 doesn’t have this issue (and it’s way faster than evince). Just in case it helps, Pablo -- http://www.ousia.tk
participants (4)
-
Hans Hagen
-
Pablo Rodriguez
-
Rob Heusdens
-
Wolfgang Schuster