On Tue, Oct 28, 2008 at 4:15 PM, Marco van de Voort <[EMAIL PROTECTED]> 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/ _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal