[Skim-app-users] synctex forward search, Skim centering and focus

[Patrik Jonsson]

Hi all,

I'm trying to set up skim and aquamacs to work with synctex. What I am
mostly interested in is forward search , i.e. that the pdf view
updates itself to the point in aquamacs. I have it working to the
point that C-c C-v in aquamacs displays the red arrow highlight in
skim. It's not quite working the way I want, though, so I thought
someone might be able to help out.

First, the highlighted line with the red dot on it is often off by a
line up or down, but sometimes by a large fraction of the paragraph.
Is this a deficiency in the synctex accuracy or a bug in Skim?

Second, if the center point isn't visible in the current skim display,
it is often shifted in such a way that the highlighted line in skim is
the very top line at the edge of the display. This makes it hard to
see where you are in the document because you don't have any preceding
context. I think it would be better if the line was *centered* in the
display. Is there any way to adjust how Skim centers the view?

Third, when issuing the tex-view command (C-c C-v) i Aquamacs to
update the pdf display, Skim grabs focus. This is not what I want. I'm
working in emacs and I want to continue to do that, I just want Skim
to update the view. I don't know whether this is controlled by emacs
or skim, but is there a way to not have this happen? (Like when you
run the latex command with C-c C-c and the pdf is updated, in which
case skim just updates the view but focus remains with Aquamacs.)

Any hints would be appreciated.

Thanks,

/Patrik

[Christiaan Hofman]

Post by Patrik Jonsson
Hi all,
I'm trying to set up skim and aquamacs to work with synctex. What I am
mostly interested in is forward search , i.e. that the pdf view
updates itself to the point in aquamacs. I have it working to the
point that C-c C-v in aquamacs displays the red arrow highlight in
skim. It's not quite working the way I want, though, so I thought
someone might be able to help out.
First, the highlighted line with the red dot on it is often off by a
line up or down, but sometimes by a large fraction of the paragraph.
Is this a deficiency in the synctex accuracy or a bug in Skim?

It's in SyncTeX, the red dot is always exactly on the point returned by it. Generally, it is not possible to be accurate in general, as latex is not necessarily 'local', stuff can end up generating code at a different place from where it appears in the source.

Post by Patrik Jonsson
Second, if the center point isn't visible in the current skim display,
it is often shifted in such a way that the highlighted line in skim is
the very top line at the edge of the display. This makes it hard to
see where you are in the document because you don't have any preceding
context. I think it would be better if the line was *centered* in the
display. Is there any way to adjust how Skim centers the view?

We go through the system frameworks to do that. In general, this is the best way to do, and it should be up to Apple to improve that if needed. Only when there is a very good reason could we consider to forgo the system code, but usually it gives more pain than relieve, trust me.

It would have negative side effects, like scrolling when this is not necessary. It's better in general to err on the side of doing too little than doing too much. So I am not inclined to change that behavior.

Post by Patrik Jonsson
Third, when issuing the tex-view command (C-c C-v) i Aquamacs to
update the pdf display, Skim grabs focus. This is not what I want. I'm
working in emacs and I want to continue to do that, I just want Skim
to update the view. I don't know whether this is controlled by emacs
or skim, but is there a way to not have this happen? (Like when you
run the latex command with C-c C-c and the pdf is updated, in which
case skim just updates the view but focus remains with Aquamacs.)
Any hints would be appreciated.
Thanks,
/Patrik

Skim does not itself activate on forward search, sot this is controlled by Aquamacs. That is, assuming you are using their viewer command(s), otherwise it's your choice. As you may know, emacs (including Aquamacs) allows you to basically redefine about any command, that's certainly true for these, but I cannot help you with that. The Wiki has some information on how to call Skim. I can say that the displayline script provided by Skim does put the focus on Skim, but it's not necessary to use it, and it seems Aquamacs doesn't by default.

Christiaan

[Patrik Jonsson]

Hi Christiaan,

Thanks for responding. As I mentioned in the other thread, the focus
issue was easy to solve. The update location bothers me though. I just
realized it might also be related to this other issue that I've been
meaning to bring up:

When using the mouseover feature for figure references in the text so
you get a little popup with the location that's being referenced, the
start of the caption is, similarly to the synctex issue, in the very
upper left corner of the popup. In all my journals, the caption is
below the figure, so this means that you see not a single pixel of the
figure that's being referenced. When using it on equation references,
it works better since they are generally on one line, but even here
the center point is so far up to the left that for tall equations
(with fractions, integrals, etc) the top is cut off.

These glitches unfortunately make this popup feature, which is great
in principle, mostly useless. Am I right that this is another symptom
of the same deficiency in the system framework functionality?

Does the framework really take no hints as to how this centering
should be done, no size of the region that should be visible, or
anything like that? (Maybe you could point me to where in the code
this is done so I can play with it myself? Even fudging it to ask for
one or two lines further up than the target might be a net improvement
for me.)

Thanks,

/Patrik

Post by Christiaan Hofman

Post by Patrik Jonsson
Hi all,
I'm trying to set up skim and aquamacs to work with synctex. What I am
mostly interested in is forward search , i.e. that the pdf view
updates itself to the point in aquamacs. I have it working to the
point that C-c C-v in aquamacs displays the red arrow highlight in
skim. It's not quite working the way I want, though, so I thought
someone might be able to help out.
First, the highlighted line with the red dot on it is often off by a
line up or down, but sometimes by a large fraction of the paragraph.
Is this a deficiency in the synctex accuracy or a bug in Skim?

It's in SyncTeX, the red dot is always exactly on the point returned by it. Generally, it is not possible to be accurate in general, as latex is not necessarily 'local', stuff can end up generating code at a different place from where it appears in the source.

Post by Patrik Jonsson
Second, if the center point isn't visible in the current skim display,
it is often shifted in such a way that the highlighted line in skim is
the very top line at the edge of the display. This makes it hard to
see where you are in the document because you don't have any preceding
context. I think it would be better if the line was *centered* in the
display. Is there any way to adjust how Skim centers the view?

We go through the system frameworks to do that. In general, this is the best way to do, and it should be up to Apple to improve that if needed. Only when there is a very good reason could we consider to forgo the system code, but usually it gives more pain than relieve, trust me.
It would have negative side effects, like scrolling when this is not necessary. It's better in general to err on the side of doing too little than doing too much. So I am not inclined to change that behavior.

Post by Patrik Jonsson
Third, when issuing the tex-view command (C-c C-v) i Aquamacs to
update the pdf display, Skim grabs focus. This is not what I want. I'm
working in emacs and I want to continue to do that, I just want Skim
to update the view. I don't know whether this is controlled by emacs
or skim, but is there a way to not have this happen? (Like when you
run the latex command with C-c C-c and the pdf is updated, in which
case skim just updates the view but focus remains with Aquamacs.)
Any hints would be appreciated.
Thanks,
/Patrik

Skim does not itself activate on forward search, sot this is controlled by Aquamacs. That is, assuming you are using their viewer command(s), otherwise it's your choice. As you may know, emacs (including Aquamacs) allows you to basically redefine about any command, that's certainly true for these, but I cannot help you with that. The Wiki has some information on how to call Skim. I can say that the displayline script provided by Skim does put the focus on Skim, but it's not necessary to use it, and it seems Aquamacs doesn't by default.
Christiaan
------------------------------------------------------------------------------
Accelerate I/O Performance of HDD-Based Arrays
Configure SSDs as a secondary tier of high performance
cache to maximize transactional I/O performance while
minimizing investments in SSD technology.
http://p.sf.net/sfu/infohub-sdnews
_______________________________________________
Skim-app-users mailing list
https://lists.sourceforge.net/lists/listinfo/skim-app-users

[Christiaan Hofman]

Post by Patrik Jonsson
Hi Christiaan,
Thanks for responding. As I mentioned in the other thread, the focus
issue was easy to solve. The update location bothers me though. I just
realized it might also be related to this other issue that I've been
When using the mouseover feature for figure references in the text so
you get a little popup with the location that's being referenced, the
start of the caption is, similarly to the synctex issue, in the very
upper left corner of the popup. In all my journals, the caption is
below the figure, so this means that you see not a single pixel of the
figure that's being referenced. When using it on equation references,
it works better since they are generally on one line, but even here
the center point is so far up to the left that for tall equations
(with fractions, integrals, etc) the top is cut off.
These glitches unfortunately make this popup feature, which is great
in principle, mostly useless.

I am a bit allergic to such unwarranted generalizing remarks.

Post by Patrik Jonsson
Am I right that this is another symptom
of the same deficiency in the system framework functionality?
Does the framework really take no hints as to how this centering
should be done, no size of the region that should be visible, or
anything like that? (Maybe you could point me to where in the code
this is done so I can play with it myself? Even fudging it to ask for
one or two lines further up than the target might be a net improvement
for me.)
Thanks,
/Patrik

No, there's no scrolling involved, so it's a totally different thing. Moreover, it's also really not a question about whether things could be done differently. Of course they could, but that does not mean it should be done. Links should point to the start of relevant content. So if the link does not do that, this is a problem of the link, not of the way it's interpreted. Trying to "fix" that only will result in doing it wrong in the generic case where the link is correct, that's most definitely not an improvement. And in fact, we DO shift the preview tooltips up a bit.

Christiaan

Post by Patrik Jonsson

Post by Christiaan Hofman

Post by Patrik Jonsson
Hi all,
I'm trying to set up skim and aquamacs to work with synctex. What I am
mostly interested in is forward search , i.e. that the pdf view
updates itself to the point in aquamacs. I have it working to the
point that C-c C-v in aquamacs displays the red arrow highlight in
skim. It's not quite working the way I want, though, so I thought
someone might be able to help out.
First, the highlighted line with the red dot on it is often off by a
line up or down, but sometimes by a large fraction of the paragraph.
Is this a deficiency in the synctex accuracy or a bug in Skim?

It's in SyncTeX, the red dot is always exactly on the point returned by it. Generally, it is not possible to be accurate in general, as latex is not necessarily 'local', stuff can end up generating code at a different place from where it appears in the source.

Post by Patrik Jonsson
Second, if the center point isn't visible in the current skim display,
it is often shifted in such a way that the highlighted line in skim is
the very top line at the edge of the display. This makes it hard to
see where you are in the document because you don't have any preceding
context. I think it would be better if the line was *centered* in the
display. Is there any way to adjust how Skim centers the view?

We go through the system frameworks to do that. In general, this is the best way to do, and it should be up to Apple to improve that if needed. Only when there is a very good reason could we consider to forgo the system code, but usually it gives more pain than relieve, trust me.
It would have negative side effects, like scrolling when this is not necessary. It's better in general to err on the side of doing too little than doing too much. So I am not inclined to change that behavior.

Post by Patrik Jonsson
Third, when issuing the tex-view command (C-c C-v) i Aquamacs to
update the pdf display, Skim grabs focus. This is not what I want. I'm
working in emacs and I want to continue to do that, I just want Skim
to update the view. I don't know whether this is controlled by emacs
or skim, but is there a way to not have this happen? (Like when you
run the latex command with C-c C-c and the pdf is updated, in which
case skim just updates the view but focus remains with Aquamacs.)
Any hints would be appreciated.
Thanks,
/Patrik

Skim does not itself activate on forward search, sot this is controlled by Aquamacs. That is, assuming you are using their viewer command(s), otherwise it's your choice. As you may know, emacs (including Aquamacs) allows you to basically redefine about any command, that's certainly true for these, but I cannot help you with that. The Wiki has some information on how to call Skim. I can say that the displayline script provided by Skim does put the focus on Skim, but it's not necessary to use it, and it seems Aquamacs doesn't by default.
Christiaan
------------------------------------------------------------------------------
Accelerate I/O Performance of HDD-Based Arrays
Configure SSDs as a secondary tier of high performance
cache to maximize transactional I/O performance while
minimizing investments in SSD technology.
http://p.sf.net/sfu/infohub-sdnews
_______________________________________________
Skim-app-users mailing list
https://lists.sourceforge.net/lists/listinfo/skim-app-users

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Skim-app-users mailing list
https://lists.sourceforge.net/lists/listinfo/skim-app-users

[Patrik Jonsson]

Post by Christiaan Hofman

Post by Patrik Jonsson
These glitches unfortunately make this popup feature, which is great
in principle, mostly useless.

I am a bit allergic to such unwarranted generalizing remarks.

I'm sorry, I hope people realize that there is an implied "TO ME"
qualifier attached to any such statements, since I'm obviously only
expressing my opinion. Nevertheless, in MY experience, it really is
mostly useless to ME. Other people may think it's great, and that's
good for them. That, however, does not make me any happier.

Post by Christiaan Hofman
No, there's no scrolling involved, so it's a totally different thing. Moreover, it's also really not a question about whether things could be done differently. Of course they could, but that does not mean it should be done. Links should point to the start of relevant content. So if the link does not do that, this is a problem of the link, not of the way it's interpreted. Trying to "fix" that only will result in doing it wrong in the generic case where the link is correct, that's most definitely not an improvement. And in fact, we DO shift the preview tooltips up a bit.

Ok, I understand your point. However, to me it seems like a perfectly
valid, alternative strategy would be to *center* the link. It depends
on whether ones idea of reading a pdf is either that a link means the
reader will go to the target and then only read *down* on from there
or if a link points to a "region of interest" and the reader may well
want to look at the text immediately preceding the target as well.
There is no fundamental axiom saying that putting the link in the
upper left corner is the correct way. The purpose of a pdf viewer is
to help the user read pdfs, and there is no "proven correct" way of
doing that. Saying that LaTeX should change seems like tilting at
windmills, so I believe my life would be net improved if I could tweak
the behavior of Skim. So, I ask you again to please point out the
relevant part in the code so I can fiddle with it myself. I don't
think that is too much to ask for.

Regards,

/Patrik

[Christiaan Hofman]

Post by Patrik Jonsson

Post by Christiaan Hofman

Post by Patrik Jonsson
These glitches unfortunately make this popup feature, which is great
in principle, mostly useless.

I am a bit allergic to such unwarranted generalizing remarks.

I'm sorry, I hope people realize that there is an implied "TO ME"
qualifier attached to any such statements, since I'm obviously only
expressing my opinion. Nevertheless, in MY experience, it really is
mostly useless to ME. Other people may think it's great, and that's
good for them. That, however, does not make me any happier.

Post by Christiaan Hofman
No, there's no scrolling involved, so it's a totally different thing. Moreover, it's also really not a question about whether things could be done differently. Of course they could, but that does not mean it should be done. Links should point to the start of relevant content. So if the link does not do that, this is a problem of the link, not of the way it's interpreted. Trying to "fix" that only will result in doing it wrong in the generic case where the link is correct, that's most definitely not an improvement. And in fact, we DO shift the preview tooltips up a bit.

Ok, I understand your point. However, to me it seems like a perfectly
valid, alternative strategy would be to *center* the link.

If generically the target is NOT the center, assuming that it IS the center will GENERICALLY do it wrong.

Post by Patrik Jonsson
It depends
on whether ones idea of reading a pdf is either that a link means the
reader will go to the target and then only read *down* on from there
or if a link points to a "region of interest" and the reader may well
want to look at the text immediately preceding the target as well.
There is no fundamental axiom saying that putting the link in the
upper left corner is the correct way.

Uhm, yes, there is. A (PDF) link targets a point, not a region. That should be the beginning of whatever it refers to. A link to a section should point to the beginning of that section, not some arbitrary point in the middle. Every viewer assumes this. And this is, BTW also true for e.g. HTML links and web viewers.

Post by Patrik Jonsson
The purpose of a pdf viewer is
to help the user read pdfs, and there is no "proven correct" way of
doing that.

There is a general correct way, and that's what we assume, and should assume.

Post by Patrik Jonsson
Saying that LaTeX should change seems like tilting at
windmills,

Quite the opposite. LaTeX should generate its PDF as the PDF format expects, otherwise it's LaTeX trying to tilt windmills (last I checked PDF is far more ubiquitous than latex).

Post by Patrik Jonsson
so I believe my life would be net improved if I could tweak
the behavior of Skim. So, I ask you again to please point out the
relevant part in the code so I can fiddle with it myself. I don't
think that is too much to ask for.
Regards,
/Patrik

The behavior for the tooltip preview is in SKImageToolTipContext.m, and for synctex in SKPDFView.m

Christiaan

[Maxwell, Adam R]

Post by Christiaan Hofman

Post by Patrik Jonsson
Saying that LaTeX should change seems like tilting at
windmills,

Quite the opposite. LaTeX should generate its PDF as the PDF format expects, otherwise it's LaTeX trying to tilt windmills (last I checked PDF is far more ubiquitous than latex).

Additionally, not all PDF is generated with LaTeX, so there's no point in even bringing it up (links are created by hyperref, anyway, not LaTeX). Some citation links in Acrobat Distiller-generated PDFs will point to the top of a page, which is even less useful, but there's no way to know this. I think we tried some different heuristics in developing that feature, but there's no general solution.