Okular moving

[Kurt Pfeifle]

On Thursday 16 November 2006 23:49, Tobias Koenig wrote:
> On Thu, Nov 16, 2006 at 11:52:23PM +0100, Wilfried Huss wrote:
> > Am Donnerstag, 16. November 2006 20:47 schrieb Thomas Zander:
> Hi Wilfried,
> 
> > > A huge portion of the features you listed in your email seem out of place for 
> > > either app. As Tobias also pointed out.
> > 
> > Why? Would you like to have an image viewer were you cannot crop the image,
> > or rotate it?
> You crop and rotate the image to view it, that's something different
> from modifying it.
> 
> > Deleting pages from a PDF file, mergin two PDF files, or rearranging
> > the pages in a PDF file, are functions that I do expect of a good PDF viewer.
> No, not of a PDF viewer but a PDF tool like Acrobat.

You can't necessarily compare Acrobat/Reader on Windows with KDE's
way of organizing its applications.

Adobe made the Reader free as in beer in order to push their file
format to universal usage; and at the same time it is the bait to
lure users with more professional requirements into buying (the
pretty expensive) Acrobat software.

KDE does not have a business "requirement" for such an artifical
separation. *If* we think of splitting between viewer ("read-only")
and editor ("read-write") functions, it may be because...

 ...a) viewer more lightweight, and hence does faster startups,
       has less UI elements (so easier to learn), less memory
       footprint,...
 ...b) editor is of course more powerful, needed by less users --
       and necessarily is more "heavy" and more of what "a)"
       outlines.

"Viewer" and "Editor" of course should share the maximum amount of
code; ideally, a running "viewer" would transform itself into an
editor by loading the additional functionality at run-time as needed.

Linux printing is moving towards PDF as its central spooling file
format. Automatically, this will also lead to more demand for an
ability to be able to "edit" PDF documents. Inserting and removing
pages are the most simple ones -- imposition/reordering of pages 
for booklet printing and creation of "book signatures" are not much
more difficult. Editing page content (with comments, markups) or 
even inline editing is the icing on the cake.

My main point is: we shouldn't erect an artificial Berlin Wall 
between viewing and editing functions, just because we see the same
thing in Adobe's PDF tools (where mostly business considerations
made them to be what they are today).

Cheers,
Kurt