1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
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
|
