On a related note - what to do about the html_view demo in the test folder, and about fluid?
Both attempt to load the html version of the fltk docs, but on many platforms now with 1.3, these html files will not exist at all. Albrecht's suggestion of offering a docs tarball would go some way to alleviating that, of course. Or, can fluid be made to (optionally) load the PDF if it can't find the html version of the docs, is that even feasible? That might "fix" fluid but will not help with the html-view demo. >> Do we need to provide three different compression methods, or can we limit >> this to a single one? I think that by now, every platform supports .zip, >> even for the hard-core open source addicts. > Or, running at this the other way, should we not just push bzip2, since it will be smaller? It appears to be handled correctly by Winzip and 7-zip, so that pretty much covers the WinXX platforms (and is a "native" compression format on *nix and OSX). Anybody who can't figure out how to open a bzip2 compressed tarball probably isn't able to use fltk anyway! ;-) > I often see that the zip files have Windows (CR/LF) line endings, > whereas the others have Unix (LF) line endings, but this would only > matter for the html files. Or is this a feature of the unpacking > program... ? I think "that depends" is the answer - I know that several zip de-compressors have an option to expand automatically the line endings to match what they think the local host is. I also know I have had to suppress this behaviour at times as it can *really* mess things up if the utility incorrectly guesses that a file is a text file when it is actually something else... _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
