From: Hans Hagen <pragma@wxs.nl>
To: ntg-context@ntg.nl
Subject: Re: two issues with interactive hyperlinks (please comment)
Date: Tue, 23 Feb 2016 09:33:16 +0100 [thread overview]
Message-ID: <56CC194C.5080400@wxs.nl> (raw)
In-Reply-To: <56CB97DE.1070201@gmx.es>
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
> 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)
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)
> 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
> 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
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
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
>>> 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?
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
btw, the upcoming zoom fashion is not the ones we have now but zoom to
some tagged location (can be mid line)
>>> 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.
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 think this is a basic feature that will benefit many ConTeXt users.
>
> Many thanks for your help,
>
> Pablo
>
--
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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
___________________________________________________________________________________
next prev parent reply other threads:[~2016-02-23 8:33 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
2016-02-23 8:33 ` Hans Hagen [this message]
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=56CC194C.5080400@wxs.nl \
--to=pragma@wxs.nl \
--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).