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 -----------------------------------------------------------------