Re: Initial comments

[Nikolai Weibull <mailing-lists evince rawuncut elitemail org>]

* Justin Ross (Jan 28, 2005 13:40):
> Well, if the doc were sufficiently hypertexty, I'd switch to using my
> imaginary pdf-enabled browser.  "Browser for reading hypertexty stuff,
> evince for reading structured stuff" is the idea, I guess.

The only problem with this reasoning being that your imaginary
pdf-enabled browser is just that: imaginary.

> Taking it from the other direction: There exist both html viewers (web
> browsers) and html editors.  They happen to deal with the same file
> type, but in quite different modes.  Since the modes are distinct
> enough, we have separate apps for each.

You are comparing viewing versus viewing with viewing versus editing?

> So, I'm saying that to my way of thinking, the pdf-ness is incidental.
> What's essential is something more like "structured, standalone"
> documents vs. "hypertexty, often network-dependent" ones.

Network-dependent?

> Now, this will come down to priorities.  There are, as you point out,
> intra-document links in many pdf files.  But is it worth it to
> introduce navigation history if it will find only infrequent use?  And
> wouldn't it be better to tell the user to point his browser at it if
> he *really* wants the navigation history?

I'm talking about inter-document links mostly.  Either way, both are
easier to deal with, if there is a navigation history.

You're assuming that all viewers are of the male sex?

The whole bonobo-embedding-hype-type-thing is dead.  There isn't going
to be an Epiphany that displays PDFs using evince and have their history
linked.  Not as I've understood it anyhow.

> I'm not claiming this is the obviously right approach, but it might be
> a step in the right direction.  My work patterns, at least, reflect
> this distinction, and it's an opportunity to make evince simpler.

Removing "vital" features doesn't make evince simpler (to use anyway).

Look, I'm not saying that the history feature is vital, but there's no
reason to simply dismiss it as flawed either.  One has to face the fact
that there are two types of PDF documents: those with links, and those
without.  Why design software that only works well with either one?
Simply add detection for the two cases and act accordingly.

I don't know the PDF specification very well, but I'm guessing that
there is a way to tell, quite simply, whether a document uses links or
not.

More and more documents rely on these features of PDF.  It'd be sad if
evince would be out-of-date in a couple of years, simply for this
reason.
	nikolai

-- 
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}