You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
95 lines
3.7 KiB
95 lines
3.7 KiB
API
|
|
===
|
|
|
|
If we want developers of other applications to move over to
|
|
kviewshell, we definitvely need a stable and mature API. Here are some
|
|
things that I feel need to be implemented, at least in API (it is
|
|
probably ok if we don't implement all of them right now).
|
|
|
|
* documentRenderer. This class needs documentation. We need to specify
|
|
what the documentRenderer actually does at what time, and what signals
|
|
it emits at what time and what they mean. Things that come to my mind:
|
|
|
|
- specify what drawPage actually does. In kdvi, drawPage is a highly
|
|
asynchronous method, that either does nothing (e.g. if font are still
|
|
being generated), or really draws a page. The behaviour must be
|
|
specified, and I believe that for printing (see below) we would also
|
|
need to provide for a synchronous way of rendering pages.
|
|
|
|
- some document formats include ready-made thumbnails. We should have
|
|
have a virtual function that makes thumbnails out of fully rendered
|
|
pages, which can be overloaden if the author of a specific file format
|
|
supports 'embedded thumbnails'
|
|
|
|
- in the future we probably want to use threading to render pages in
|
|
memory to improve the perceived speed of applications. Thus, we will
|
|
have to specify what methods need to be implemented in a reentrant or
|
|
thread-save manner. Probably we should provide infrastructure for
|
|
that.
|
|
|
|
- support for reading and writing hirachical bookmarks for document
|
|
that support that
|
|
|
|
- some document formats, such as dvi, allow to READ the position of
|
|
characters, which allows for full-text search, copying of text,
|
|
etc. Other formats, such djvu allow also WRITING of such
|
|
information. The idea is that you produce a djvu file by scanning a
|
|
certain document, and than later add the position and
|
|
character-information by using e.g. OCR software. We should at least
|
|
have support for that in the API, even if we don't implement an OCR
|
|
interface right now.
|
|
|
|
- dvi has the special feature that it supports source information and
|
|
uses that to implement inverse and forward search functionality. We
|
|
must somehow make sure that even these unusual features fit well into
|
|
our framework without too much of an effort.
|
|
|
|
* kmultipage
|
|
|
|
- kviewshell should provide a print dialog (with the extra option that
|
|
certain document formats can insert their own configuration pages). I
|
|
find the print dialog of Acroread 6.0 in OSX very well done. Then we
|
|
should have a default printing implementation that uses KPrinter, etc,
|
|
to print the pages (this will be used e.g. by kfax), and we would need
|
|
infrastructure for implementation which have their own way of
|
|
producing PS file (such as dvi, where dvips is the preferred method to
|
|
print).
|
|
|
|
This may rise some important questions in documentRenderer API. For
|
|
printing we would need a SYNCHRONOUS way of rendering pages to a
|
|
qpainter object.
|
|
|
|
|
|
|
|
DOCUMENTATION
|
|
=============
|
|
|
|
If we want developers of other applications to move over to
|
|
kviewshell, we definitvely need a well-documented API, and some
|
|
applications that demonstrate how everything works. In particular, we
|
|
should have
|
|
|
|
* lots of documentation, including API documentation and a tutorial on
|
|
"How to implement a kmultipage"
|
|
|
|
* an exteremely well-defined reference implementation for a trivial
|
|
file format, either one that is actually useful (kfax, perhaps), or
|
|
one that serves only demonstration purposes and that goes into the
|
|
tdesdk module
|
|
|
|
|
|
|
|
|
|
|
|
KVIEWSHELL APPLICATION
|
|
======================
|
|
|
|
* improve command line interface. The somewhat antique method of
|
|
giving the library name in the command line should be replaced by a
|
|
more modern method where kviewshell uses some kde wizardy
|
|
(e.g. 'services') so that installed kmultipage implementations can
|
|
announce what mime type they are supposed to handle, and kvieshell
|
|
then loads them automatically
|
|
|
|
|