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