We plan to implement both, when it becomes clear how they should be rendered (this is especially important for small screens). support of style sheets included in the book (e.g.There are two non-implemented features that many formats required: In the foreseen future we plan to make format support pluggable - this will help to separate the application from the actual format support. However if a particular file is rendered incorrectly from your point of view, please contact us and if possible include the offensive file and we will try to fix the situation. In many cases that would require a significant effort that would not result in visible effect for the end user. those that would unlikely to be used in real life. We do not aim to make support for a particular format as complete as possible so it would cover all options listed in the format description, e.g. if a book is just a collection of TIFF-images within a container of some sort (archive or other), then it's most likely that implementation of this format will be prioritized rather low) the format is text based, and not image based (e.g.the format is expected to be used for books and, first of all, fiction books (we do not have any short-term plans to add support for any spreadsheet format).popularity of the format (usually this means that there are at least several books in this format :)).Secondly, since FBReader's authors have limited resources, formats that have the following properties are considered first: However this requires desire not only of FBReader developers, but also that of owners of the corresponding format.
Theoretically, FBReader's engine could be used as a part of a closed-source application that would be supporting books in some DRM-ed/non-open format. Firstly, FBReader is an open source application, and as result all formats FBReader currently supports are open formats.
0 kommentar(er)
