Wesley Mason: > What if it was a compile time option to include support for direct > web/file access to the viewer. If you're going to make a parser, why > make it seperate.
So that it can be maintained. A parser that handled only valid well-formed documents and very simple stylesheets (or a single default stylesheet) might not be much harder than the current parser - but it would be different. If you want to add support for docbook, or html-not-tidied-up, these are different again. There is no reason that someone writing a docbook handler should have to rewrite the uncompression code or the screen rotation code - nor should they stomp on the standard code by accident. There has been talk about plugins already, but it hasn't been coded yet. > allow for retrieving missing links dynamicly as the user clicks on > them. There has been some concern about modifying a pdb, particularly on the device. Even deleting a page causes some nervousness. Figuring out where to insert one seems reasonable to me, but ... I dont' speak for everyone. A task on my todo list for next year (unless someone beats me to it - and they might) is to automatically fetch any urls exported to memopad. This would probably work like AvantGos form manager, which is not optimal, but does work. > Also I mentioned 'file access'. This would only make sense > as you will already be teaching the program how to parse > html/jpg/gif directly, why not allow people to save html/jpg/gif > to a directory on the card This would also be nice, particular for palms with a camera - I suspect plucker would display photos better (or at least faster) than some of the builtin tools. -jJ _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
