ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Pablo Rodriguez <oinos@gmx.es>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: two issues with interactive hyperlinks (please comment)
Date: Tue, 23 Feb 2016 00:21:02 +0100	[thread overview]
Message-ID: <56CB97DE.1070201@gmx.es> (raw)
In-Reply-To: <56CB5CC2.1030300@wxs.nl>

On 02/22/2016 08:08 PM, Hans Hagen wrote:
> On 2/21/2016 8:54 PM, Pablo Rodriguez wrote:
>> [...]
>> The regression is that \setupinteraction[focus=standard] doesn’t work
>> with hyperlink in table of contents for chapter in betas from 2016.02.15
>> 10:26.
> 
> a bit too complex example

Many thanks for your reply, Hans.

Sorry, I mixed both issues. And it was easy to provide two samples (and
even two messages to the list).

>> Beta from 2016.02.08 15:35 adds a link with named destination (/XYZ).
>> Next beta from 2016.02.15 10:26 adds a link pointing only to the page
>> (/Fit).
>>
>> This is the regression.
> 
> i checked the changes and uploaded beta (split the methods a bit) .. 
> hopefully i didn't break the patches that taco needed (option=name)

Many thanks for the new beta, it seems to have fixed the issue (sorry,
but I haven’t checked with all my files).

>> And I think it is time to discuss an issue with textual links. I know
>> you don’t like it. I’m sorry, but I think it is an essential feature for
>> hyperlinks.
> 
> well, in general i only read full screen, or print a document, or don't 
> read a pdf at all as i just loose track when views keep changing (so for 
> me a viewing device is only useful when it can show a page, which the 
> surface (or even a nexus) can do quite ok)

I avoid to read PDF documents on screen as much as I can. But I’m an
amateur. I don’t even have a printer at home. I totally depend on
copyshops (there isn’t none especially close where I live).

Sometimes we amateurs have to proofread on screens (on the 15-inch
screen in the 10-year-old laptop I have). There is no other way. After
the text is composed in full, we print in a copyshop. And proofreading
on screen only works, if text can be displayed in fit to width form.

I also loose track when view changes. Sorry, but it is really annoying
This is exactly what happens when I click on a link for a footnote (or
index reference). From fit to width, it goes to /Fit.

>> And if \setupinteraction[focus=standard] is used, all link destinations
>> should be named ones (/XYZ). Of course, I’m not talking about widgets
>> for presentations. But footnotes, references, linenotes and other
>> similar links that may appear in a text should behave the same way in
>> the same document.
> 
> this also depends on if that xyz info is available in a consistent way 
> which is not always the case (even then one needs take margins and other 
> things into account so whatever gets added in the core will always be 
> suboptimal and imo kind of crappy, so never default)

I’m not asking for a default. I’m asking for named destinations in all
kinds of links (that is, also for footnotes, references and indices)
behave the same way. Otherwise, it generates an highly inconsistent user
experience (it’s dizzy).

>> Sorry, but some users complained to me about this behavior. I know that
>> some PDF readers don’t follow this (only mupdf that I’m aware of
>> [and I opened an issue:
>> http://bugs.ghostscript.com/show_bug.cgi?id=696442]). SumatraPDF,
>> Adobe, evince and xpdf implement named destinations.
> 
> well, that is the problem: for 15 years there has been no real 
> consistent viewer behaviour ... for long i tested using acrobat, but the 
> interface kept changing and got worse so now i test with sumatrapdf 
> which lacks some features or has issues) and i find it real hard to test 
> this kind of stuff (i simply lack the mindset for it) so when something 
> is needed i need real simple and small examples and/or know what kind of 
> pdf code is needed that works in most viewers

Well, Sumatra works fine with this concrete feature (at least, this is
my experience). And mupdf is the only exception in this regard.

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.

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.

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.

>> It is an extremely useful feature and it isn’t reasonable to expect
>> from users that they have huge screens to read PDF documents generated
>> with ConTeXt. And in many scenarios, having a screen version (different
>> from the print version) is not an option. And as explained in the
>> sample code above, I have only a 15-inch screen.
> 
> actually i wonder if screens need to be huge ... small high res screens 
> are quite readable (i consider reading pdf on a small phone a no-go 
> whatever scaling gets applied and i expect epub like devices eventually 
> to get the same quality as paper)

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?

>> Would it be possible that the destinations with links in a text all
>> honored \setupinteraction[focus=standard]?
> 
> this can only be implemented stepwise (given that i can motivate myself 
> so it also depends on the weather, music, reasonable background movie or 
> talkshow, lack of other tasks, etc) .. and of course a reasonable viewer 
> (i wasted too much time already on bypassing fuzzy features that i don't 
> need myself)

Is there anything that I can do to help? I’m especially interested in
this feature.

I think this is a basic feature that will benefit many ConTeXt users.

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
___________________________________________________________________________________

  reply	other threads:[~2016-02-22 23:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-21 19:54 Pablo Rodriguez
2016-02-22 19:08 ` Hans Hagen
2016-02-22 23:21   ` Pablo Rodriguez [this message]
2016-02-23  8:33     ` Hans Hagen
2016-02-24  9:01       ` Pablo Rodriguez
2016-02-24  9:50         ` Wolfgang Schuster
2016-02-25  6:55           ` Pablo Rodriguez
2016-02-25 18:19         ` Hans Hagen
2016-02-25  6:51       ` Pablo Rodriguez
2016-02-25 10:20         ` Hans Hagen
2016-02-22 19:13 ` Hans Hagen
2016-02-22 20:40   ` Alan BRASLAU
2016-02-22 22:54     ` Martin Schröder
2016-02-23 22:07       ` Alan BRASLAU
2016-02-24  9:25         ` Pablo Rodriguez
2016-02-22 23:32   ` Pablo Rodriguez
     [not found] <mailman.1.1456225201.14598.ntg-context@ntg.nl>
2016-02-23 14:30 ` Christoph Reller
2016-02-23 22:24   ` Alan BRASLAU

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56CB97DE.1070201@gmx.es \
    --to=oinos@gmx.es \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).