> 1. Plucker currently takes too long to render the next or previous page
> when scrolling (at least, too long compared to iSilo). I suppose that
> this speed problem could be taken care of if Plucker pre-rendered the
> next and previous pages while the current page is being viewed.
> Displaying would then be much faster.
We all realize this is a problem, and there are some different ways of
addressing it. There have been some users asking about making one long
continuous page as well, instead of the 64k page breaks used now (a Palm
limitation, not Plucker, which can be worked around). I'm not sure where
this particular issue stands.
> 2. The ability to select text into the clipboard would be very nice.
This has been talked about before several times. You might want to look
at ClipString. Two references here:
http://www.plkr.org/list/plucker-list/0352.html
http://lthaler.free.fr/clipstring.htm
> 3. Ability to export to other formats, particularly Doc or WordSmith
> would also be nice. This is probably better implemented as a plugin that
> understands the Plucker format than as an inbuilt feature, so that those
> who don't need it can do away with the bloat. (Maybe reorganise plucker
> into a PluckerLib, PluckerViewer and PluckerConverter?)
This is probably better handled by something like Sitescooper, which
can handle iSilo, Plucker, and other formats natively. Another option
would be to have a desktop conversion application, but then it would
have to be written in both Windows and POSIX (Unix, Linux, etc.)
formats. It's definately not something Plucker (viewer and parser)
should be handling at this time.
> 4. Printing support, for the entire page or selected area, using an
> external print tool like PrintBoy.
Outside of the scope of Plucker. Plucker is not a web browser, it's an
offline HTML viewing application. It tries it's best to make sense of
web content, but printing? That's a little outside the box. Besides,
does the built-in Palm Addressbook supporting printing? How about
Calendar? Unless I misunderstand what you mean by "Printing support".
You can easily get around this by using ClipString, clip to a memo, then
use PrintBoy from there. The less confusing elements in Plucker, the
smaller (and faster) it remains.
> 5. Tables support, like iSilo has. Tables are very essential at times
> like when I'm trying to pluckerize a conference schedule with multiple
> parallel tracks. In this case, the table format is more important than
> the hassle of sidescrolling.
EEK! Tables present a whole bunch of problems for devices of this size.
Remember, Plucker is not Netscape-for-the-Palm. It allows you to view
HTML/text/etc. content on your Palm device. It doesn't print. It doesn't
edit. You can't 'view source'. It's not a browser. It's a reader of
previously-prepared HTML content. That being said, here's some of the
issues with supporting tables in the way you are requesting:
1.) Tables are computationally expensive. On a device with 16Mhz to
33Mhz of power, rendering a large or complicated table would be very
slow, as would scrolling it. Remember, tables aren't just 'grids'. Many
people (myself included, embarassingly) have used tables in the past to
align images, center form elements, and move columns around on the
screen.
2.) Tables are almost always missing elements. It is one of the least
understood of the HTML elements. Many people use the
<tr><td><table></table></td></tr> tags out of order, or forget to close
them entirely. In a desktop browser, the browser can compensate for
missing tags. On a desktop parser, this become a bit more difficult (not
impossible, just more difficult), when you have to compensate for an
infinite number of possible ways a table can be rendered.
3.) What about tables which contain form elements in some cells, and
contain normal data in other cells? How do you render the form elements,
when Plucker doesn't (yet) support forms? Do we just remove everything
between <form> and </form> and replace with to keep the cell
properly aligned?
4.) Given your previous request for cut-n-paste of content, how do you
cut-n-paste a table?
5.) What about images inside the table cells, or images with alt tags?
And now the uly part -- the horizontal scrollbar. Adding this presents
a nice handful of gotchas that Plucker is not engineered to handle.
Adding the scrollbar now decreases the size of the document displayed by
5px or so. Relocating it from bottom to top (assuming it is always
opposite the toolbar) changes the way the pages are rendered, though
only slightly. What if the table was 10,000 pixels wide?
Now we introduce issues with horizontal scrolling of a
computationally-expensive operation of rendering a table (with
potentially missing/misused tags) in Plucker, and making sure that
images, text above/below the table, and other elements appear "normal".
What about a situation where you have a table 600px wide at the top of
a page, you scroll to the far right of the table, then drop down to 90%
down in the document. Would you like to see blank whitespace? or would
you expect it to put you where text is? Here's an example (pardon my bad
ascii art here)
<---- 600 pixel wide table ---------------------------->
.------------------------------------------------------.
| | | | | | | | | | | | | | |
|------------------------------------------------------|
| | | | | | | | | | | | | | |
`------------------------------------------------------'
<- 160 wide region ->
blah blah blah blah
blah blah blah blah
blah blah blah blah
blah blah blah blah
blah blah blah blah
blah blah blah blah
blah blah blah blah
[...]
blah blah blah blah
Whenn you scroll all the way to the right, then scroll down, you're
scrolling through whitespace. Try it on a real webpage that does this,
you'll see what I mean. It may me confusing to the user, unless they
realize that they're all the way to the right, and that text exists if
they grab and move the scrollbar back to the left.
So, it's not as easy as adding <td></td> to the parser and Plucker will
just jump onboard, it's going to take a bit of thinking and engineering
to get working, if at all. I'm not even sure tables should be supported.
I'm all for just converting the table to a gif, runtime (with gd
perhaps?) and inserting the gif as a tappable image you can pan and
scroll, vs. having to render tables, adding a horizontal scrollbar, and
engineer the scrolling/document display/parser accordingly to
compensate.
> Hoping to see Plucker have these features soon. Thanks for the great
> app!
Thanks for the feedback. Remember, this is only my take on the issue,
and I'm only one member of the Plucker team. It's everyone's decision
what they want to implement.
/d
