Re: two issues with interactive hyperlinks (please comment)

[Pablo Rodriguez <oinos@gmx.es>]

On 02/23/2016 09:33 AM, Hans Hagen wrote:
> On 2/23/2016 12:21 AM, Pablo Rodriguez wrote:
> 
>> Well, Sumatra works fine with this concrete feature (at least, this is
>> my experience). And mupdf is the only exception in this regard.
> 
> hm, sumatra uses the mupdf engine

Well, this is more complex than it seems. Right now, SumatraPDF cannot
simply merge the latest version of fitz
(https://github.com/sumatrapdfreader/sumatrapdf/issues/344#issuecomment-156269119).

And SumatraPDF has this particular feature implemented.

>> Besides that, all other links use named destinations, so why are they so
>> problematic (not from the coding perspective) when it somes to
>> footnotes, references and indices? Sorry, but I don’t understand the
>> difference.
> 
> because using named destinations has no advantage when ther eis no view 
> and not all hyperlinked constructs have views (either because it's 
> impossible due to lack of structure i.e. where does something begin/end, 
> or because it's not yet implemented there)

Not sure I understand your explanation (totally my fault, of course).

I think your implementation of \setupinteraction[focus=standard] as:

    ["<< /D [ %i 0 R /XYZ %0.3F %0.3F null ] >>"]

is really great. Because you don’t chenge zooming or page view at all.
This is extremely wise (as ConTeXt itself). It is only a pity that it
doesn’t work for footnotes, endnotes and index entries.

> the hyperlink mechanism currently has the options page,name,auto (auto 
> being default) so you can try name but still not get what you want; the 
> page variant is needed for documents with 100K or more hyperlinks (and 
> in fact the ability to choose between name/page is also there because in 
> principle we can have backends that only support page linking ... i 
> forgot the details but when pdf came out and acrobat / dvipsone was 
> supported one had named only and the other page only destinations; if i 
> kick out that kind of flexibility we're locked into pdf completely)

These options are totally new (and previously unknown to me). I’m afraid
I wasn’t able to find them in the ConTeXt command list
(http://www.pragma-ade.com/general/qrcs/setup-en.pdf).

Grepping in the source, I see \showsetup{interaction} in scrn-ini.mkiv.
I don’t know how to get the options from showsetup (I get a MISSING
SETUP message [probably I’m missing to load a module]). I don’t know how
to get the name (which command and which option?).

lpdf-ano.lua contains variables.names (and v_names). I’m afraid I don’t
know how to use that. I know it may be stupid, but Lua code (as coding
in general) is Greek to me.

Sorry, but I’m only an average computer user. With a very basic sense
for typography (awakened by ConTeXt).

>> I think that (futhermore not being a default) ConTeXt should implemente
>> what is an ISO standard nowadays. If viewers don’t follow the standard,
>> users may complain, But if documents don’t follow any standard in this
>> point, no viewer will be able to handle these documents properly.
> 
> well, i have been quite active in implementing what pdf provided and 
> constantly had to adapt to what acrobat finally implemented (often the 
> standard was ahead) and

Sorry, you are right and I was rude from me. I didn’t mean that. You
implemented standard features at my request in days and I’m happy and
extremely helpful for that.

I wrote “nowadays” because you have more experience than myself (I’m not
a professional) and I agree: PDF viewers suck.

The point I was trying to make was the following: if PDF viewers fail to
comply with the standard, it is their problem. And for the open source
viewers, I will report to them the issue (well, for the most imporant
ones ;-).

For example, you implemented printing options (such as duplex printing)
in ConTeXt (I’m extremely happy with this feature, it’s extraorinarily
useful in copyshops). Well, I know I have to use Acrobat (and a recent
[or decent] version). This doesn’t prevent that I report the issue at
poppler (https://bugs.freedesktop.org/show_bug.cgi?id=92779). It will
take a while to get this implemented, I know. And I have to report it at
mupdf when they enable printing suppport in mupdf-gl.

>> And sorry for saying this (I have no other experience), but I had never
>> an issue with that using LaTeX. I love ConTeXt and it’s a pity that this
>> isn’t implemented yet.
> 
> i don't know about latex but i do know that depending on the engine to 
> do it is quite fragile ... i don't know about today but inconsistent 
> margins, no nesting or overlaying, tricky page dimensions ... the 
> engine's built in mechanisms are heuristics and can fail in some cases 
> ... as you don't make screen docs you probably never ran into that but 
> if we hadn't done it in alternative ways in context i'd probably already 
> had quit working on context a decade ago simply because some docs could 
> not be produced

Sorry, the comparision was probably unfair. It isn’t something specific
to ConTeXt or LuaTeX. It is jsut that footnotes (and other link)
destionations just don’t have named ones with null zooming.

> anyway, it's no problem to implement things, given time and motivation, 
> but anything implemented in context has to be predictable ok and above 
> all consistent and the thing that annoys me the most is zooming that one 
> moment gives you a effective 20 pt size and another time 17.5 pt 
> depending on where / how you click and view so one handicap for me is 
> that i won't make test docs for it

I totally agree with that. This is the reason why I consider setting
named destinations to null zooming an extremely wise decision from your
side.

Otherwise, readers get sick after clicking in links.

> for example: when one clicks, goto and the viewer zooms in to some piece 
> of text on ehas to assume that the pdf generator guessed right about 
> reasonable margins on top / bottom / left / right as one expect 
> consistency ... it might be convenient on a 768x1024 screen (which imo 
> is unuseable for reading anyway) but on a proper high res screen lack of 
> quality starts dominating

I try to prevent reading. But my ConTeXt manual in Spanish
(http://www.aprender-context.tk, to be released in a couple of decades
:-)) has to be proofread also on screen. Of course, this is the basic
proofreading.

And I cannot afford (mainly space at the desk I use to work) a higher
resolution screen. My 10yo Dell Inspiron 6400 running Fedora 23 (and the
latest beta from the ConTeXt Suite) works fine.

>> Well, A4 pages aren’t readable on a 15-inch screen (that is very common
>> in laptops). I would say, no matter which resolution it has.
>>
>> And sorry, not being the default, why is wrong reading pages in fit to
>> width mode?
> 
> that one still has to make sure that there is a reasonable view area (so 
> that one sees what went and comes) ... i'm not sure how you handle it 
> but esp jumping from page to page in a fit width mode is quite annoying; 
> fit width actually makes sense when one makes each chapter (or section) 
> into one long page and i actually played with it but i found no viewer 
> capable to keep the same scale each page

With null zooming (as implemented for named destinations), the user has
to set a confortable view.

In most of the cases only the top value will be used And the top left
anchors for note reference (or index reference) are fine. I’m only
guessing, but I think this is the way to do it.

> btw, the upcoming zoom fashion is not the ones we have now but zoom to 
> some tagged location (can be mid line)

But in that case, the reader is responsible for that. The named
destination doesn’t change zooming.

>> Is there anything that I can do to help? I’m especially interested in
>> this feature.
> 
> small few page examples with predictable positioning and predictable 
> spacing (btw, footnotes will always be sort of a pain as they are 
> rendered in special ways, but footnotes should be forbidden anyway; if a 
> doc is also for screen endnotes are way better)

I use endnotes for my documents. And the problem is exactly the same:
page view and zooming changes.

With named destinations, zoom is set to null (please, don’t change that
ever) and you get where you need to.

BTW, this is what already happens with headings.

I hope my explanation is more accurate now. Please, let me know if there
are some unaccurate points.

Many thanks for your help,


Pablo
-- 
http://www.ousia.tk
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________