Asciidoctor-pdf: Reference to moved source block jumps to wrong page

[andswitch]

If a source block doesn't fit on the current page, it is automatically moved to the next page. However, if you click on a reference to the block, you still jump to the old page.

[andswitch]

Is it perhaps because the add_dest_for_block call here

https://github.com/asciidoctor/asciidoctor-pdf/blob/28be6e3f5112bf474722452568b509caf3d7ecb8/lib/asciidoctor/pdf/converter.rb#L1744

is not inside the keep_together block?

https://github.com/asciidoctor/asciidoctor-pdf/blob/28be6e3f5112bf474722452568b509caf3d7ecb8/lib/asciidoctor/pdf/converter.rb#L1877-L1889

[mojavelinux]

Thanks for raising this issue. This is actually true for most blocks that have keep together semantics. But the solution is more complex than just moving the call to add_dest_for_block, as the test failure on the PR reveal.

Fortunately, we have a reference for how to solve it. We already handle this situation for block images. The solution is to use a proc that can be invoked at the appropriate time, once we determine where the top of the block will be. I'll see if we can reuse that solution in this case, and perhaps other cases as well.

[mojavelinux]

...it turns out the test failures were unrelated. I thought we verified the location of the anchor, but apparently we don't. I'm still working on the foundation we need to make this work, though.

[mojavelinux]

So here's the question. Should the anchor be located above the top margin of the block, or should it be located where the visible content begins? We now have the ability to do both.

If the answer is a), here's how it would be implemented:

top_margin = theme_margin :block, :top
keep_together do |box_height = nil|
  add_dest_for_block node, y: @y + top_margin if node.id

If the answer is b), here's how it would be implemented:

keep_together do |box_height = nil|
  add_dest_for_block node if node.id

I'm not sure which one the user expects.

NOTE: At the moment, the default theme does not use a top margin. So the behavior would be the same either way right now. But we plan to switch the default margin from the bottom of blocks to the top in the near future, so this decision would then have an impact.

[andswitch]

If I had to vote, I would go for option a because I personally don't like it when things are touching the window border. On the other hand, it also doesn't matter that much to me. So, if the implementation of option a turns out to be much more complicated than the implementation of option b, then I'd just go for option b.

[mojavelinux]

I'm partial to option a) too. The functions have been prepared such that neither option is more complicated than the other.

I'm happy to prepare a PR for this since writing a test for this is a bit tricky and hard to explain. Easier to show.

[mojavelinux]

See #1901.