David A. Desrosiers wrote: >> Splitting the page also breaks reading flow, which is another >> problem. A workaround for this is to place a page indicator at the >> top of the page with links to jump between pages, as suggested by >> someone earlier. > > This is not a viewer problem either, this is an ebook design > problem. If you have one huge long text file, and import that, it > will get chunked into separate records, clickable to the next in > series; just like flipping the pages of a paper book.
This is a fair argument. However, rendering the page takes quite a bit longer than flipping a paper page. > > ..and to use your analogy, a paper book has no scrollbar, does it? My point was that you cannot judge a page's length. That is the problem. (A paper book has pages to judge its length.) A compounding problem is that the links only occur at the bottom of the page so you cannot easily go to another page. (Yes, this is a parser issue and I'm looking to add a page navigator in JPluck.) Another problem is that you cannot easily search a long page. In fact, long pages are prime candidates for searching, but the split records make this too hard. >> Another workaround would be to decide on a URL naming scheme for >> split pages and let the viewer display a page indicator based on >> those URLs. (This means you must include URL info.) > > We can't decide on a url naming scheme, because we don't control the > content. Besides, an ebook doesn't have a URL, does it? It's a text > file. You could append the page number to the URL and scan that. The viewer does not validate URLs and uses record IDs internally anyway. In fact, you can use any piece of text as the URL. Example: http://www.server.com/index.html (original URL, page 1) http://www.server.com/index.html-page-2 (page 2) http://www.server.com/index.html-page-3 (page 2) etc. You could scan the URL data records when processing the page (in the viewer) to see how many subpages are ahead. This way you can add an indicator or menu command to jump to the last page without coding navigation in the page itself. Just an idea. I suspect it's easier to implement than >> Still, many people do find this problem annoying because it's a >> limitation that greatly affects usage. > > Greatly affects usage... for you. And others as well. I know I'm not the only one. > > How many people have complained about this so far? Have you taken a > poll to determine if it's 1%? 20%? 90%? Seriously, the app works, and > sure, can be better in a lot of ways, depending on how you use it, > but the app doesn't "suffer" because the scrollbar doesn't compensate > for all pages linked within your document. Many people do not take or have the time to give feedback about software, If they don't like a particular application, they simply don't use it. Some of the people I know don't want to use Plucker because of the split record issue. Why would they bother filing a bug report? I wanted to check if bug voting was supported since all bugs I'm clicking on seem to have only 1 vote, but I lost my password and I see no way of retrieving it. (I tried signing on with a different ID but haven't received a password yet.) > >> Dismissing their "demands" as "bitching" makes you come off as >> unwilling to listen to user requests, which is not the best way to >> promote your software. > > If nobody at all were to use the software except Mike, or myself, or > any of the other Plucker developers, it would still be a successful > package. It's successful because it does what *WE* want, and *WE* > made it work this way. We don't have to promote it, it does that well > enough on its own, and the thousands of happy users (and companies) > using Plucker do all of the marketing for us. I understand the free software philisophy. What I meant with that remark is that Mike was scaring off users. There are better ways of dealing with user queries than respond in such an abrasive manner by telling a user (not a developer) to fix it himself or stop bitching about it. If my remark came off as a flame, I apologize. I was only reflecting what Mike said. > He may not want to fix it, but that doesn't mean it doesn't get > fixed. Try to motivate someone to provide a patch, and I'm sure Mike > would have no problem reviewing it, assuming it doesn't break any > existing code or divert the project in some direction that it wasn't > initially intended to go. I would take a shot at it if I could, but I don't know the Palm API. Learning that will take some time I suspect. I know C/C++, though. Regards -Laurens _______________________________________________ plucker-list mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-list
