I missed the support in context, to define exact destination (page 553 [533], PDF Reference 1.5 PD) in interactive documents. The defined types lack the support for destinations, that don't lie on the top of a page. An example to make it clear... You have made a PDF document with bookmarks, the focus is set to width for good readability. Now you press a bookmark for a section and Acroreader opens the correct page. But hey, where is the section? If it starts at the lower quarter of the page, it isn't visible at all. So I tried to change this behaviour, playing around with bookmarks (as one fuction using destinations). As I'm no TeX wizzard, the result is very limited. But I hope it's enough to show that there are more or less good reasons for an extension of destinations in context. Regards, Peter
Thursday, June 12, 2003 Peter Rolf wrote: PR> An example to make it clear... PR> You have made a PDF document with bookmarks, the focus is set to width PR> for good readability. Now you press a bookmark for a section and Acroreader PR> opens the correct page. But hey, where is the section? If it starts at the PR> lower quarter of the page, it isn't visible at all. Welcome to the world of PDF vs TeX :) The reason of the problem: TeX puts the reference mark for the current line on the baseline; when a PDF reference is set that refers to a particular point of the page (e.g. a Rectangle reference, or an XYZ one), this means that the current *baseline* will end up on the top of the screen, therefore hiding the actual line. One would therefore have to put the reference mark not where TeX wants to put it, but at <TeX placement> + <appropriate height> (where the height added would be "enough to show the text we *really* want to refer to.) The problem is: how to determine the appropriate height? For normal text, this would be the current lineheight, for example (plus a baseline skip so that the line does not coincide *precisely* with the monitor border, and there's some extra margin). For section heads, it would be the whole sectionhead height. For floats, it would be the float height. In general, for all ConTeXt objects we would need a "put reference mark here" command; if the object is then made into a reference, it should be put there. (When no such mark is defined, it should default to <TeX placement> + <lineheight>) Hans, this is a core thing, isn't it? Oh, and yes we need to add "rectangle" references :) -- Giuseppe "Oblomov" Bilotta
At 12:34 12/06/2003 +0200, you wrote:
In general, for all ConTeXt objects we would need a "put reference mark here" command; if the object is then made into a reference, it should be put there. (When no such mark is defined, it should default to <TeX placement> + <lineheight>)
even then you would run into problems with 'virtual content'
Hans, this is a core thing, isn't it?
a proper bodyfontsize offset would be enough;
Oh, and yes we need to add "rectangle" references :)
well, anything is possible, but as a starter: - the pdftex xyz should work ok - acrobat viewers should behave consistently (or in a controlled way) we did play with the xyz thing didn't we? if there are problems, its time to repair pdftex (we can discuss this with thanh during tug 2003 in hawaii) if there was an efficient extra hash mechanism (i don't want to to run out of tex mem/hash) we could do a lot more interesting things ... (like this) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
participants (3)
-
Giuseppe Bilotta -
Hans Hagen -
Peter Rolf