Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

CHM (Developers)

posted by marcov, 30.08.2008, 14:29

> In use, html.gz files are as readable as any
> other html files.
I just tried with IE6, and it doesn't open them.

> I was focusing on download package size, because I think reducing download
> time is more important than disk space after download. Really, what's the
> big deal about a few MB on today's disks?. And maybe I'm MS-paranoid, so
> what? :-P

Well, try to enter a file with 100000 files and you know it is more than just size.

> > There already is PS/PDF. Beautifully typeset using LaTeX. Even
> published
> > as a book (though in German). If you have a decent way to turn it into
> an
> > helpsystem, let me know.
>
> PDF can have hyperlinks and indexes, right?
Yes. And they have those, even since before hyperref and pdf(la)tex were parts of the standard distro's (think 1997). Actually the PDF docs are considered authorative, and the HTML ones just a derivative.

That makes it an hyperrefed document though, not an helpsystem. PDF is even worse, since acroread is cumbersome to install (must download it separately, on *nix need to include non-free repositories etc)

> > Free Pascal goes pretty far in eliminating external tools, for
> maintenance
> > and control reasons btw.
>
> Understood. So here is yet another option: Rather than a tightly
> integrated CHM system, still separate the data files from the viewer.

Maybe I should take a step back and describe some of the requirements:

- The main point is that we want to have an helpsystem. Not just a bunch of hapazardly packaged files on disk.
- Also we prefer to use something that at least at some systems is native. That limits it to OS X help and Windows .HLP and .CHM. OS X is an unknown factor, for .hlp and .chm heaps of third party helpcompilers, decryptors, converts etc exist.
- The amount of additional work must be minimal. While the number of free helper utils was bigger for .hlp than for .chm a few years back, CHM was chosen because the html format is simply better known and there is a chance of recycling free third party html viewer widgets as core of the helpviewer on e.g. non Windows systems).
- Format must allow embedding third party streams, which is important for indexes of context-sensitive help systems. Both .hlp and .chm are essentially filesystems-in-a-file.
- Preferably system that uses one file per library, but allows inter-file links. The experience with loose HTML files has been sobering, and there as a "never that again" attitude. Renaming heaps of helpfiles to 8.3 syntax while keeping links intact is cumbersome.
- It must be usable in some form from the textmode IDE preferably even under Dos(what was this forum about again? :-) . IOW, there must be native access to the format. You can't simply start an external helper there. Native access also allows limited reformatting to fit the textmode screen.

> You> keep control, need to maintain only your own code, and can issue data > or viewer updates in small packages.

Ah, but keep in mind that the .chms are not manmade. They are machine generated, and considered throwaway! Editing is not required, since both the master documentation files, as the tools to generate the .chms are multi-platform and open.

> Also, the user can customize data files
> (add personal notes, change colors for ergonomic reasons...). It's a
> tradeoff - some loss of speed (how much really?)
The problem is more in the installation, distribution size, and keeping 8.3 and case sensitivity problems from ruining releases. Help popup speed is less of a problem, except for building indexes and so.

Also moving or compressing an existing FPC installation (for backup or moving purposes) gets cumbersome since the filemanager/compressor spends ages in the huge directories searching for little files.

> and some increase in disk
> space, but with the gain of greater overall flexibility (my preference).
I rather spend that space in providing the help(de)compiler in the pkg, for the e.g. occasional teacher that wants to annotate/fix some minor issue directly in the help, and not wait for a new release.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 282 users online (0 registered, 282 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum