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, 28.08.2008, 17:46

> > (Are you sure? Afaik HTTP2 allows for GZ compression, but .gz on HTML
> > sounds like an Unix extension, not something a standard would describe,
> > since .gz is meaning less on a standard windows install. Do you have a
> > reference?)
>
> Such files are found on Unix servers, and get used in the usual two ways:
> They can be read online like any other .HTML file, or downloaded. A
> compliant browser decompresses for reading. Opera does it for sure, using
> zlib.
You didn't answer my real question. Is it really a standard, or do some browsers simply do this (since they have zlib support internal for http2 anyway)?

> > Well, the crucial part is the combination of archive functionality with
> > compression, and an preexisting viewer (This because the slack space of
> > tens of thousands of little html files is as important as the
> > compression).
>
> By preexisting viewer, do you mean one that the user already has? Or one
> that you don't have to write, but that you can just throw into the
> download package?

No, more that there are several basic embeddable html viewers, while finding e.g. a RTF widget is hard (for winhelp .hlp). E.g. IPRO.

> Either way, I don't see any problem, when you put it in
> those terms. HTML files can be separately gzipped, or tarred first in the
> normal way. Images can remain as separate files from the original HTML.
> Viewer should be no problem - doesn't everybody have a browser?
Yes. But we are not viewing one simple page here, but an hyperlinked archive that must be available on a simple keypress, and with an index to multiple entrypoints, and with minimal memory use.

And an external program leads to installation/detection and instrumentation problems. E.g. for browsers to force them to change pages, to trap hyperlinks so you can lead them to the next page in the ZIP, etc is _NOT_ standarized.

So I can extract an html file from the ZIP and start it up via some OS feature (e.g. shellexecute) in the browser, but what happens if the user clicks on a link in the shown file? How do I redirect that to the next page in the zip?

Also, the automated helpsystem saves space, since the basic controls don't need to be coded on each page.

> The slack space problem goes away if raw HTML files are tarred before
> gzipping (or bzipping).
Yes. IF YOU LEAVE THEM ZIPPED AFTER INSTALL. But then I can't browse them. The zip or tarring itself is no problem, the (de)compressor is in the installer already. It is kind of slow though with tens of thousands of files. (and with 4k clustersize this quickly turns into tens of MBs, while it is is a 6MB chm)

> My point is, there are purely mechanical solutions that do not require
> programming other than revising scripts for packing files and uploading to
> servers.
I afraid I totally don't get what point you want to make here. Either you are reacting out of reflex against .chm (Microsoft paranoia?), or you totally lost me.

Sure, I can zip html files. But is that equal to a indexed helpfile system? Can I use a mainstream browser to browse such zip as hypertext? NO.

Is there a standard helpfile system on *nix ? :no.

> > Also .chm has the ability to embed internal files, which are important
> for
> > additional tables for e.g. context sensitive help etc.
>
> Perhaps .ps or .pdf, with batch files to run Ghostscript or other free
> reader?
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.

> > All browsers will be internal anyway, since starting up and fully
> > instrumenting the many commonly used browsers is next to impossible.
>
> Yes, browsers are annoying, with so many variations and degrees of
> compliance with the HTML specs. But I see that as another reason to go
> with .ps or .pdf, and perhaps supply a reader on the FP servers.
Any external solution is a maintenance nightmare. I want to display an help text, not debug why the new version of viewer package X version B breaks on OS Y version Z. Specially since I have no interest in package X itself in the first place, except displaying the bloody helptext.

Also using external tools (for the final install, not in crafting the binaries of the install) precludes alternate functionality based on the helpfiles like displaying help in tooltips.

Free Pascal goes pretty far in eliminating external tools, for maintenance and control reasons btw. E.g. on Windows we have elmininated GNU AS and LD, and on the more common (x86,x86_64) ELF targets also AS. Just to avoid the horrible maintenance nightmare, and Unix centric thinking that haunts Free Software on non Unix targets. Unfortunately, there is no substitute for GDB.

Post reply
 

Complete thread:

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