> This is a weak argument, I'm sorry to say. A real book has pages, too, so
> you can judge its length and decide whether to read some more or go to
> sleep. Likewise, an e-book should have a scrollbar or percentage
> indicator.
"Should have" is a feature request. The viewer works fine in its
current incarnation without it. Many of us have been using it for quite a
few years (I think Mike and I the longest now) and have never had a problem
with a "missing" percentage across the whole ebook.
> 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.
..and to use your analogy, a paper book has no scrollbar, does it?
> 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've already indicated that you have no inclination to address this
> issue.
He's indicated that he doesn't believe it to be an issue, and that
there are many other real issues that take a higher priority right now. It
doesn't mean it won't get added, or fixed, by someone else with other
motivations, but again, Mike decides what code goes in and what code stays
out.. of his part. If you want it fixed, and REALLY want to continue using
Plucker in the same way, you can easily priorities of the developers
concerned by compensating them for their time on the parts you need. You can
also pay someone to write a patch for you. You can also take the code, add
your features, and create your OWN version of Plucker, and distribute that
as well (with the code of course). It may be "Free Software", but it's
certainly not free in terms of time, resources, and testing to design and
build these features in for users like yourself.
> Still, many people do find this problem annoying because it's a limitation
> that greatly affects usage.
Greatly affects usage... for you.
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.
> 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.
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.
d.
_______________________________________________
plucker-list mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-list
