gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] Re: Is xupdf reasonable?!


From: Tuomas Lukka
Subject: Re: [Gzz] Re: Is xupdf reasonable?!
Date: Mon, 27 Jan 2003 18:21:12 +0200
User-agent: Mutt/1.4i

On Mon, Jan 27, 2003 at 05:40:16PM +0200, Asko Soukka wrote:
> My point is that there are dozens of different link types and if we start 
> marking them somehow in xupdf we have to make big compromises: choosing 
> what link types are enough to include, and what kind of graphical elements 
> we add to present them. We have already used the "color coding" for 
> papers' uniqueness. (should also remember 7+-2)

7+-2 is more about immediate grasping, not about remembering
different types, right?

> > Asko's second idea was that this is only talking about different views.
> 
> I couldn't get xupdf compiled, so I don't know how it have changed during 
> last month. 

Please report any errors here!  Immediately!

> Anyway I would like to see it only as an applitude among many 
> others and would like to keep it as simple and tidy as possible. If we 
> can't show something like link-types in xupdf without making it visually 
> bloated, we should make a new view/applitude for them.

Showing link types is not the problem - forcing the user to mark them is IMHO.

> IMHO it's better to have several easy-to-use views/applitudes which 
> performs their job well (and changing between them is easy, because they 
> use the same structure), than adding so many features that we have to 
> make compromises for usability.  

There are some downsides here as well: one of the main faults of the normal
raster views of the zz structure is that most dimensions are hidden and that
the dimensions are sparse.

You cannot know if there are connection "hidden" without rotating around.

In this way, the separate views/applitudes thing needs more thinking; something
like hinting to the user that there's something in the other applitude here.

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]