making links work in rotated text
Hi! if i typeset e.g. a table in LaTeX's landscape environment, and there are some links in the table, they become not clickable because of rotation. it is a known problem, as far as i can tell (searching in google shows that; the reason seems to be that the clickable areas links remain where they were before the rotation, i.e. they are not affected by the rotation, unlike the text)... is there any hope that this problem is going to be solved in not too distant future? :) Best, v.
Hi Vladimir,
if i typeset e.g. a table in LaTeX's landscape environment, and there are some links in the table, they become not clickable because of rotation.
it is a known problem, as far as i can tell (searching in google shows that; the reason seems to be that the clickable areas links remain where they were before the rotation, i.e. they are not affected by the rotation, unlike the text)...
Annotations position is absolute. pdfman says that is for sake of speed and don't think anybody will touch it in 'not too distant future' -) You can make any geometrical transformations on boxes, and once the box is tranformed in the way you want, put it into the link. BR, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
On Thu, Mar 02, 2006 at 08:03:16AM +0100, Pawe?? Jackowski wrote:
Hi Vladimir,
if i typeset e.g. a table in LaTeX's landscape environment, and there are some links in the table, they become not clickable because of rotation.
it is a known problem, as far as i can tell (searching in google shows that; the reason seems to be that the clickable areas links remain where they were before the rotation, i.e. they are not affected by the rotation, unlike the text)...
Annotations position is absolute. pdfman says that is for sake of speed and don't think anybody will touch it in 'not too distant future' -) You can make any geometrical transformations on boxes, and once the box is tranformed in the way you want, put it into the link.
The problem is not a transformation of stuff inside a link,
but of transformations of stuff that contain the link.
Transformations (scaling, rotating) is done by \pdfliteral.
pdfTeX doesn't interpret the contents of \pdfliteral, thus it
misses the transformations.
Probably transformations should be performed by a new primititive
to pdfTeX that changes the current transfer matrix. And pdfTeX is
notified about the transformation and can use correct link and
anchor rectangles then.
The problem is known *many* years. But appearently nobody wants
to implement a solution. :-(
Yours sincerely
Heiko
Heiko:
The problem is not a transformation of stuff inside a link, but of transformations of stuff that contain the link. Transformations (scaling, rotating) is done by \pdfliteral. pdfTeX doesn't interpret the contents of \pdfliteral, thus it misses the transformations[...]
Yes, and this is one of pdfTeX liitations. The only workaround is to make links after geometry transformation... That could be not trivial, if one need to have rotated and still linked list of contents or something -) Regards, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
On Thu, Mar 02, 2006 at 12:54:57PM +0100, Pawe?? Jackowski wrote:
Heiko:
The problem is not a transformation of stuff inside a link, but of transformations of stuff that contain the link. Transformations (scaling, rotating) is done by \pdfliteral. pdfTeX doesn't interpret the contents of \pdfliteral, thus it misses the transformations[...]
Yes, and this is one of pdfTeX liitations. The only workaround is to make links after geometry transformation... That could be not trivial, if one need to have rotated and still linked list of contents or something -)
In my option the time is better invested in fixing pdfTeX
than trying difficult incomplete workarounds at TeX macro level.
Yours sincerely
Heiko
On 2006-03-02 14:15:47 +0100, Pawel Jackowski wrote:
Ye, but how do you imageine such fix? New primitives for transformations?
Seems to be the way. pdfTeX has to know of these transformations. Best Martin -- http://www.tm.oneiros.de
On Thu, Mar 02, 2006 at 02:15:47PM +0100, Pawe?? Jackowski wrote:
In my option the time is better invested in fixing pdfTeX than trying difficult incomplete workarounds at TeX macro level.
Ye, but how do you imageine such fix? New primitives for transformations?
Yes, for changing the CTM, perhaps similar to \pdfliteral,
but with a syntax that saves parsing of code in \pdfliteral.
With the CTM the rotate and scale transformations can be
expressed (would go to pdftex.def).
Probably we also need something for the save and restore
operators, because these operators can have affect the CTM
also. This is more work to implement, because a stack is
necessary.
Yours sincerely
Heiko
Hi Paweł, "PJ" == Paweł Jackowski writes: PJ> Annotations position is absolute. pdfman says that is for sake of PJ> speed and don't think anybody will touch it in 'not too distant PJ> future' -) sad. currect situation is simply *broken*. PJ> You can make any geometrical transformations on boxes, and once PJ> the box is tranformed in the way you want, put it into the link. could you give an example on how to do that? Best, v.
Vladimir Volovich wrote:
Hi Pawe�,
"PJ" == Pawe� Jackowski writes:
PJ> Annotations position is absolute. pdfman says that is for sake of PJ> speed and don't think anybody will touch it in 'not too distant PJ> future' -)
sad. currect situation is simply *broken*.
not broken, it's just not supported and this is a known limitation; annotations have their own layer in pdf and one could as well consider it a limitation of the pdf format that it has annotations not as part of the text stream in order to support this properly we need something \pdfcm set|reset|push|pop num num num num num num the tricky thing is that - pdftex needs to apply the values to the annots dimensions directly (not delayed to shipout) - because sometimes we need to add info to objects (resources, annot dicts) we also need \pdfcmdimen <dimen> which returns the dimen with the applied current cm so that we can do things like [0 0 \the\pdfcmdimen\wd0 \space \the\pdfcmdimen\ht0] and alike and this should cooperate nicely with the already present cm stuff in pdftex (recently cleaned up by hartmut, so maybe he can foresee where things may fail one should be careful with annotation anyway, annotation based multimedia features sometimes fail to scale/rotate, but that's a biewer problem; nowadays one can at least specify that annotation follow the page rotation (in the viewer; NoZoom NoRotate flags) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Thu, Mar 02, 2006 at 04:43:17PM +0100, Hans Hagen wrote:
in order to support this properly we need something
\pdfcm set|reset|push|pop num num num num num num
the tricky thing is that
- pdftex needs to apply the values to the annots dimensions directly (not delayed to shipout) - because sometimes we need to add info to objects (resources, annot dicts) we also need
Quite impossible, because the final location of the boxes is not known before shipout time.
\pdfcmdimen <dimen> which returns the dimen with the applied current cm
But why not using the same method that is used for the current position? \pdfsavepos, \pdflast(x,y)pos?
so that we can do things like [0 0 \the\pdfcmdimen\wd0 \space \the\pdfcmdimen\ht0] and alike
In the second run this would be correct then.
Yours sincerely
Heiko
On Thu, 2 Mar 2006, Heiko Oberdiek wrote:
On Thu, Mar 02, 2006 at 04:43:17PM +0100, Hans Hagen wrote:
in order to support this properly we need something
\pdfcm set|reset|push|pop num num num num num num
the tricky thing is that
- pdftex needs to apply the values to the annots dimensions directly (not delayed to shipout) - because sometimes we need to add info to objects (resources, annot dicts) we also need
Quite impossible, because the final location of the boxes is not known before shipout time.
\pdfcmdimen <dimen> which returns the dimen with the applied current cm
But why not using the same method that is used for the current position? \pdfsavepos, \pdflast(x,y)pos?
in principle similar to letting TeX make nested x/y position transforms for \pdfsavepos through boxes, one step later xpdf should be able to resolve nested cm transforms, as it can display ready pages. So if one somehow feeds the positions of the rectangle corners from TeX into the page stream, maybe as 4 characters in some special font, perhaps there is some way that one can get the final transformed rectangle coordinates from the xpdf display engine? Derek knows for sure... Regards, Hartmut
Heiko Oberdiek wrote:
On Thu, Mar 02, 2006 at 04:43:17PM +0100, Hans Hagen wrote:
in order to support this properly we need something
\pdfcm set|reset|push|pop num num num num num num
the tricky thing is that
- pdftex needs to apply the values to the annots dimensions directly (not delayed to shipout) - because sometimes we need to add info to objects (resources, annot dicts) we also need
Quite impossible, because the final location of the boxes is not known before shipout time.
sure, but there could be information stored (the accumulated cm) with the annotation node that is resolved later (just before the shipout); of course a problem is that such thingies can be out in boxes and moved around
\pdfcmdimen <dimen> which returns the dimen with the applied current cm
But why not using the same method that is used for the current position? \pdfsavepos, \pdflast(x,y)pos?
something like that indeed
so that we can do things like [0 0 \the\pdfcmdimen\wd0 \space \the\pdfcmdimen\ht0] and alike
In the second run this would be correct then.
hm, for this to work, we need a one-pass solution, since there can be many annotations (btw, positions already can put a big burden on a second pass). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Fri, Mar 03, 2006 at 12:14:40AM +0100, Hans Hagen wrote:
Heiko Oberdiek wrote:
But why not using the same method that is used for the current position? \pdfsavepos, \pdflast(x,y)pos?
something like that indeed
so that we can do things like [0 0 \the\pdfcmdimen\wd0 \space \the\pdfcmdimen\ht0] and alike
In the second run this would be correct then.
hm, for this to work, we need a one-pass solution, since there can be many annotations (btw, positions already can put a big burden on a second pass).
The automatically added rectangles are available in one-pass.
Only if interaction is needed with TeX macro level, then there
is a need for a second pass. Or have I misunderstood something?
Yours sincerely
Heiko
participants (6)
-
Hans Hagen -
Hartmut Henkel -
Heiko Oberdiek -
Martin Schröder -
Paweł Jackowski -
Vladimir Volovich