[fpc-pascal] helpsystem, some numbers

[Graeme Geldenhuys]

On Tue, Oct 28, 2008 at 4:15 PM, Marco van de Voort <marcov at stack.nl> wrote:
>
> CHM has all that, and working code is in the tree now, so why bother?  The
> indexes and toc are several MB each too. (for CHM, they are XML, though you
> could cook something up binary that is tighter. OTOH it will also compress
> worse)

Like I said, I'll investigate all the options available to me when we
start the help files and help system in Q2 2009. I just quoted what we
had it mind and decided some 1.5 years ago. At the time, not much was
available.

> Well that is the fun of the CHM stuff. It does all that, but at the same
> time Windows, Gnome and KDE have viewers, and you can even extract them on
> cmdline linux (package chmlib comes with the appopriate cmdline tools).

And for Linux (Gnome and KDE) you are relying on 3rd party packages
that as far as I have found doesn't come standard with any Linux
distro I tried. Plus the Gnome and KDE ones differ in performance and
features. Also the whole point of fpGUI is to give the end-user a
consistent UI even if they switch between Linux and Windows. Our
franchisees are such a case in point. They have centres that have
mixed OS's next to each other. Learners come for lessons and grab the
first available PC. One day they can be on Linux the next on Windows.

> Moreover you can get heaps of authoring tools for it, and the fpdoc process
> is validated for it. And FPC comes with native encoders and decoders units

True, that is one benefit of CHM. Though fpdoc already creates a nice
structure and some index files. So it should be much trouble working
with what fpdoc already does with HTML output. TOC and improved
Indexing can always be added to fpdoc in required.

>> So if some better algorithm comes out in the future, the help system is
>> ready for it.
>
> Probably with any own invention is that you are your own island again.
> Usually I'm the one argueing that, but a few percent compression is not
> worth the trouble for me.

Well considering that the RTL CHM size example has been reduced by
more than half with 7-zip, that's a nice push for supporting
alternative compression. We ship updates of our product on a single CD
every six months (500+ centres). We are already pressed for space, so
every little bit helps. Plus having to ship 2 CD's to every centre
will hugely impact on printing and postage costs.

> If you have more data about what they have working that would be nice.

tiOPF has abstract classes for Compression and Encryption in the
'Core' directory.
Actual implementations are in the 'Options' directory.

Core/
  tiCompress.pas
  tiEncrypt.pas

The following implementations are available in Options/:

Compression:
   tiCompressNone.pas  // <-- very handy for testing
   tiCompressZLib.pas

Encription:
  tiEncryptNone.pas  // <-- again very handy for testing
  tiEncryptSimple.pas
  tiEncryptDES.pas
  tiEncryptBlowfish.pas

All code has been extensively unit tested and example projects are
available.  All code is available on SourceForge.
http://tiopf.sourceforge.net


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/