How does Plucker (free) compare to iSilo (commercial)?

[Alexander Turcic]

Some of you may ask why to pay money for an offline browser if there is a free solution available. Indeed, Plucker is a candidate to be taken serious in the Palm world. But how does it compare to iSilo, which is in the eyes of many, including myself, the currently best available offline browser & reader for the Palm?

Instead of just giving a subjective account I've tried to spend a little bit more time with both programs and to analyze their strengths and weaknesses.

So here we go...

Feel free to post your comments

PS: This is my first review. If you find anything wrong with it, please contact me. We all make mistakes, right?

[Alexander Turcic]

Testing Environment:

Software:
Plucker Desktop V1.2.0.4 Build Feb 12 2003 -- Install Size: 23,210 Kb (includes Python parser)
Plucker Viewer Hi-Res V1.1.3 Feb 22 2003 -- Install Size: 179 Kb + 73 Kb (SysZLib V1.1.4-1)
iSiloX V3.3 Final --Install Size: 2,323 Kb
iSilo iSilo V3.3 Final --Install Size: 350 Kb
Windows XP

Hardware:
Sony Clie PEG-N760C OS 4.1 33MHz overclocked to 45MHz
Toshiba S5100-201 Notebook, 1.6GHz, 512Mb Ram, 256kBit DSL Internet

Not tested: Hires+ (320x480), Silkscreen Support, OS 5 Support

[Alexander Turcic]

Test 1: Small Channel, Low Graphics

CNN: http://wireless.cnn.com/avantgo/cnn/index.html

Plucker:

• Link-Depth: 3
• Image Settings: Include Image (1000s of colors), thumbnail for images > 320x320
• Other Settings: ZLIB
• Target: PALM\PROGRAMS\Plucker
• Conversion Time: insignificant
• File Size: 84,994 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/CNN Pluck.pdb">here</a>)

iSiloX:

• Link-Depth: 2
• Image Settings: Include Image (16-bit 64K colors), Compress
• Other Settings: Process table formatting
• Target: PALM\PROGRAMS\iSilo
• Conversion Time: insignificant
• File Size: 47,382 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/CNN iSilo.pdb">here</a>)

Observations:
There is a bug in the current Plucker Desktop Parser. As apparent from the Log (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/CNN Pluck.log">here</a>), Plucker downloaded and saved each page twice here. This explains why the resulting file is almost twice as big as the converted iSiloX file. If I reduce the Link-Depth for Plucker to 2, it would not download the pages twice anymore, but the “<< Main” link in the header of each CNN article would link to an unresolved URL.

Note that for Plucker Link-Depth always starts at 1 (=retrieve starting page only), whereas for iSiloX Link-Depth starts at 0.

In both cases, conversion time was below 10 seconds.

Screenshots:
CNN Home iSilo:


CNN Home Plucker:


CNN Article iSilo:


CNN Article Plucker:

[Alexander Turcic]

Test 2: Big Channel, Low Graphics

Ananova News: http://pda.ananova.com/

Plucker:

• Link-Depth: 4
• Image Settings: Include Image (1000s of colors), thumbnail for images > 320x320
• Other Settings: ZLIB
• Target: PALM\PROGRAMS\Plucker
• Conversion Time: 11:52 mins
• File Size: 1,079,628 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/Ananova Pluck.pdb">here</a>)

iSiloX:

• Link-Depth: 3
• Image Settings: Include Image (16-bit 64K colors), Compress
• Other Settings: Process table formatting
• Target: PALM\PROGRAMS\iSilo
• Conversion Time: 6:20 mins
• File Size: 921,997 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/CNN iSilo.pdb">here</a>)

Observations:
Hyperlinks = Killer. The more links it has to parse, the slower Plucker Desktop becomes.

In this test, about 900 links were parsed. Plucker Desktop needed almost twice as long as iSiloX to finish the conversion. Plucker’s resulting file size is ~17% bigger than iSiloX’s.

Screenshots:
Ananova Home iSilo:


Ananova Home Plucker:


Ananova Article iSilo:


Ananova Article Plucker:


Ananova Sport Results iSilo:


Ananova Sport Results Plucker:

[Alexander Turcic]

Test 3: Big Channel, Medium Graphics

Slate: http://slate.msn.com/Apps/MySlate/ac...n=read&ids=toc

Plucker:

• Link-Depth: 1
• Image Settings: Include Image (1000s of colors), thumbnail for images > 240x240
• Other Settings: ZLIB
• Target: PALM\PROGRAMS\Plucker
• Conversion Time: 1:41 mins
• File Size: 985,994 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/Slate Pluck.pdb">here</a>)

iSiloX:

• Link-Depth: 3
• Image Settings: Include Image (16-bit 64K colors), Resize 240x240, Compress
• Other Settings: Process table formatting
• Target: PALM\PROGRAMS\iSilo
• Conversion Time: 1:03 mins
• File Size: 1,522,466 Bytes (get file <a href="http://www.turcic.com/forums/supplements/isilo-plucker/Slate iSilo.pdb">here</a>)

Observation:
Misleading compression results.
At the first look it appears that in Test 3, Plucker’s compression is superior to iSiloX. But this is not the case. What happens underneath the surface is that Plucker reduces the quality of the images, which makes them look dithered after the conversion.

See <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen00.png" target="_blank">here</a> and compare <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen01.png" target="_blank">here</a> to iSiloX. If I reduce the image quality in iSiloX accordingly (256 colors), the converted iSiloX file size is actually reduced to 721,078 Bytes; ~26% smaller than Plucker!

Note that there is unfortunately no apparent switch available in Plucker Desktop to disable it from reducing image quality. See next paragraph why that is so.

60Kb Image Limit.
Plucker limits the size of an uncompressed image to less than 60Kb (to be more precise: 60,000Bytes). The major problem in Plucker therefore is that the resolution is severely limited for 8bpp (256 colors) and 16bpp (65536 colors) images.

You can calculate the max image resolution for a given color depth with the following formula:

imageWidth * imageHeight = 60000 / pixelDepth

According to this formula,

• for 2bpp (4 shades of gray), the size is limited to 489x489 pixels
• for 4bpp (16 shades of gray), the size is limited to 346x346 pixels
• for 8bpp (256 colors), the size is limited to 244x244 pixels
• for 16bpp (65536 colors), the size is limited to 173x173 pixels

Click <a href="http://www.turcic.com/forums/supplements/isilo-plucker/screen04.png" target="_blank">here</a> for a visual representation.

In other words, with the current implementation (Plucker developers are still trying to find a new way to display images), Plucker is not able to display a single colored (be it 256 or 65536 colors) image that fills the entire screen on a regular hi-res Sony Clie (like when you want to read comics/cartoons). What Plucker does instead is try to reduce the image size (either by reducing resolution or by reducing color depth).

Document Fragmentation:
Plucker automatically breaks a document into 32Kb parts.

This is due to Palm OS’s memory handling and how Plucker deals with it. In the current Palm OS (4.x) implementation, a record or resource can be no larger than the largest memory chunk, which is 64Kb (or slightly less). Furthermore, there can be no more than 64Kb records in a record database. And as if this limit is not enough, Plucker uses API calls that reference records and resources by index, a method that further reduces the number of accessible records or resources to 32,768.

Implication: Documents larger than 32Kb are broken into 32Kb chunks. What you get is a not-so-nice "click here for the next part" link at the bottom of each document chunk.

Some people may disagree with me and argue that the jump from the bottom of one 32Kb page to the top of the next 32Kb page is not a big deal. However, there is another drawback arising from this limitation: it makes the percentage figure meaningless. Of what interest is it to me that I am at 70% percent of the *current* 32Kb segment, if I don’t know how much that is in terms of the *total* document!

Like magic, iSilo “seems” to break these limits, and I have no clue how (maybe by rewriting some Palm OS structures?). Neither does iSilo split a document into segments, nor does it have any apparent limitation on the document size (e.g., I have a 17Mb tutorial and iSilo reads it just like any other document).

Slow Search:
Plucker’s search algorithm doesn't win a prize for speed. Probably part of the reason for its slowness is the document segmentation mentioned earlier.

I ran the following test: From the top (home) of the Slate document, I searched for the keyword “salmonella” (wonderful, isn’t it?) which appears only once at the very end of the document. And here are my findings:

Plucker:

• (setting: unchecked case-sensitive, find in all pages) 82 secs + 13 secs (for refreshing the page and marking the found keyword)
• (setting: checked case-sensitive, find in all pages) 51 secs + 13 secs (for refreshing the page and marking the found keyword)

iSilo:

• (setting: unchecked case-sensitive, entire document) 21 secs
• (setting: checked case-sensitive, entire document) 12 secs

iSilo’s search algorithm is about 4x faster than the one used by Plucker.

Scrolling
"Drag" scrolling is not anywhere near as smooth as that found on iSilo.

Ever since using iSilo, I’ve found the following the most convenient region options:

• [1] 15% Screen Up
• [2] 35% Drag
• [3] 35% Drag
• [4] 15% Screen Down

Plucker also allows for a 4-part region setting. However, neither is it possible to define the size of each region, nor is it possible to use the 4-part region setting together with the dragging mode.

Scrolling is slow in Plucker. You can “see” how Plucker refreshes the screen each time you scroll to a new page, whereas iSilo seems smooth and instantaneous.

Related to scrolling is the auto-scrolling feature that both programs offer. With Plucker, auto-scrolling cannot keep up with normal reading speed unless scroll speed is set to more pixels. But at that point, the text becomes too jumpy to be read without getting a headache. iSilo’s auto-scrolling is pleasantly smooth, and scroll speed can easily be configured with the jog dial (adjustable in 20 increments).

Refresh Time
The Plucker version of Slate is 985,994 Bytes. That means the Plucker View splits it up into 31 pages or sections (32Kb each). Every time you "click here for the next part", there is a load time of 10-15 seconds until you can actually begin to read and scroll down on that one 32Kb part of Slate. If you take this x 31, you get a total waiting time of 5-8 minutes for the entire Slate document.

Compare this to iSilo, where the Slate document is presented in one single part without any refresh times.

Note: Slate uses Unicode, specifically UTF-8 encoding. Neither iSilo nor Plucker support it.

Screenshots:
Slate Home iSilo:


Slate Home Plucker:


Slate "click here for the next part" Plucker:


Slate Image iSilo:


Slate Image Plucker:

[Alexander Turcic]

Test 4: Medium Channel, Low Graphics, Table Formatting

Bloomberg ToGo: **Removed** (on request by Bloomberg)

Plucker:

• Link-Depth: 5
• Image Settings: Include Image (1000s of colors), thumbnail for images > 320x320
• Other Settings: ZLIB
• Target: PALM\PROGRAMS\Plucker
• Conversion Time: 2:15 mins
• File Size: 180,013 Bytes

iSiloX:

• Link-Depth: 4
• Image Settings: Include Image (16-bit 64K colors), Resize 240x240, Compress
• Other Settings: Process table formatting
• Target: PALM\PROGRAMS\iSilo
• Conversion Time: 0:52 mins
• File Size: 186,540 Bytes

Observations:
No Table Support.
Plucker doesn’t support tables yet. The Plucker developer team is working on it.

Some people argue not only that tables (multi-column) are unnecessary, but also that tables make reading web pages on the PDA more difficult and inconvenient (in case the table is too big to be displayed in 320x320 and would thus need left-right scrolling).

Personally I consider this a weak argument.

First, many tables are *not* too big to be displayed nicely on the full 320x320 screen. One example is the Bloomberg Channel.

Second, tables are not only used to display wide charts or schedules. They are also used for layout purposes. Plucker breaks that layout by not supporting tables.

Btw: iSilo has the option to disable tables (display options->tables->single-column). Because iSilo still interprets the html attributes inside the table tags, the resulting output is closer to the source than with Plucker.

[Alexander Turcic]

Test Results

iSilo

positive:

• ability to copy&paste text (word, screen, page, document)
• global search in all documents and channels
• instantaneous display and scrolling
• perl regex for defining include/exclude pattern
• community available (shameless self-advertisement)
• theoretically unlimited document size
• support for any image size with any color depth
• very stable

negative:

• commercial ($17.95)
• database format undocumented
• only available in English
• doesn't handle forms
• doesn't handle java-scripts
• doesn't support non-html yet common tags like pods://avantgo/back
• no build-in scheduler (implemented since 3.35b1)
• no Internet Explorer integration (implemented since 3.35b1)
• no Unicode (specifically UTF-8 encoding) support
• no multi-threaded download of webpages

Plucker

positive:

• free
• open-source (GPL)
• database format open and documented
• multi-language available
• ability to select line/paragraph spacing (You will see the importance of line spacing for easy reading.)
• ability to copy text (but only export to memopad)
• build-in scheduler
• perl regex for defining include/exclude pattern
• bugs discussion available (http://bugs.plkr.org)
• mailing list available (http://lists.rubberchicken.org/pipermail/plucker-list/)
• date column in document list
• includes ad websites exclusion list
• strike-through feature: shows which links have already been visited

negative:

• documents > 32Kb are fragmented into 32Kb parts (where you get the "click for next page" link at the bottom of each part)
• uncompressed images can only be <60Kb
• no table support (in latest CVS: table support, rudimentary due to limited 60Kb space)
• auto-scrolling cannot keep up with normal reading speed unless scroll speed is set to more pixels, at which point the text becomes too jumpy
• slow screen updates
• slow scroll bar response time
• search text algorithm slow
• change in font causes page to reparse and restart from the top again
• applications lose focus when Plucker updates channels (also in scheduling mode)
• only single URL include pattern
• high ram memory consumption while downloading (Plucker Desktop)
• font support is incomplete for OS5 machines such as Sony NX, NZ, TG, Tungsten
• doesn't do double-density fonts (someone with OS 5 confirm please)
• doesn't handle cookies (allowing, disabling, manual setting)
• doesn't handle forms
• doesn't handle java-scripts
• doesn't support non-html yet common tags like pods://avantgo/back
• no Pocket PC version available
• indentation for bulleted/numbered lists is wrong, the text is not properly aligned
• no Internet Explorer integration
• no Unicode (specifically UTF-8 encoding) support
• no multi-threaded download of webpages

[Alexander Turcic]

empty space for possible add-ons

Please check:

http://jpluck.sourceforge.net/

and update all your parsing tests to include it. This Java parser uses the Plucker viewer.

JPluck, which is an alternative to the Plucker parser, offers some important features that iSiloX does not have:

- Multi-threaded downloading
- XSLT transformation of web pages
- Dedicated HotSync conduit (Windows-only)

With XSLT transformation pages can be reformatted on-the-fly to make them more suitable for PDA display. A particularly good example is The Register, which you can find in the Showcase.

The conduit converts sites during HotSync, providing near AvantGo-like functionality. With iSiloX you have to convert the sites first then run HotSync to get the PDBs on the device. This is a lengthier process, especially on a serial or IR connection.

http://jpluck.sourceforge.net/

[Alexander Turcic]

The reason I did not include JPluck in this first review (notice, it is my first - and I am willing to write addons!), is because of David's comment here.

Alex

[BasilC]

Wow, an impressive bit of work, Alexander, and not much doubt about which app wins the prize at the moment. My transition has been first HandStory, then Plucker, and only recently iSilo, which I now use most of all. I think both Plucker and iSilo outstrip HandStory for the sort of uses you've been discussing here, but HandStory also has various other tricks up its sleeve (eg images as single files, but also various things that I haven't tried but are described in the HandStory online manual.

What's good is that we have a three-way competition (four ways if you count MobiPocket, which I probably wouldn't count) which seems to be spurring on improvements. And JPlucker looks promising.

[radleyp]

I just installed JPluck, to see what it was like. I didn't find out, since the conduit does not work. It does not work, as I saw, because the path it uses to find the conversion profile is incorrect. I have no idea how to correct this, and I am not prepared to start playing with dos command lines. Has anyone else had this problem? RadleyP

Originally posted by radleyp
I just installed JPluck, to see what it was like. I didn't find out, since the conduit does not work. It does not work, as I saw, because the path it uses to find the conversion profile is incorrect. I have no idea how to correct this, and I am not prepared to start playing with dos command lines. Has anyone else had this problem? RadleyP

Make sure you create a conversion profile in JPluck X first. Then select the profile in the conduit configuration dialog.

[radleyp]

I set a profile. Where is the conduit configuration file? In HotSync? If so, I can't open it, because it is looking for the data in the wrong place. For the moment, I am going to forget about it. I don't need more unnecessary things to do. This is something the conduit should do by itself. RadleyP