Closed jvgaultney closed 6 years ago
Mind you, this does not fix the problem for .exe. For this we do unix2dos conversion in the installer, copying the file to a temporary file and dosifying it into place during the installer running on the target machine.
Fixed? in 3e576a8
Not fixed, because none of the OS type zip extractors obey the text flag field for handling line endings. So I propose we store text files with CRLF line endings, but set the creator to be Windows, so that if per chance an extractor does obey the flag, it might do the right thing. Users can then get sensible line endings using unzip -a, if they ever use a command line to extract such things. Sigh, what a shame :(
Fixed in f9d6c5f
zip seems to work correctly as far as line-endings.
The exe is problematic. After installing the EXE, the installed text files are all zero length. Also, there is only one item (the uninstaller) on the start menu (which should include documentation). Also the FONTLOG, OFL_FAQ, and Readme are not installed:
Finally, the OFL text is present but essentially unreadable due to formatting:
My guess that the zero length files are either due to the unix2dos function in the installer messing up, or, more likely, the file expansion from the installer to a temporary file either failed or unix2dos couldn't read or find it. Needs to be tested within the installer. The bad OFL.txt is due to it not being passed through unix2dos. Easy to fix once unix2dos is working.
Almost fixed. The text files from the .exe are fine, but the text files from the .zip have the last newline ( \r\n ) removed.
Fixed in 49406a0
The problem at the moment is that documentation in the .zip files often has linux line endings, due to the zip having been made on a linux machine. One approach to this is to change the line endings to Windows, but that doesn't help if someone expands the .zip on a Mac or Linux box. But zip does allow files to be marked as text files and to take native line endings of the producing operating system (another flag in the zip file). So I propose we use that mechanism in preference.
This raises the tricky question of what is a text file?
For documentation directories, we can presume that for an unknown file format, the file is a text file. So 'all' we need is a list of binary file extensions (or fnmatch patterns) and allow the user to extend that list. I propose the wscript control be
BINARYTYPES=["*.bz*", "*gz"]
for example. The default list would start out as:["*.doc*", "*.jp*", "*.mp*", "*.od*", "*.pdf", "*.png", "*.pp*", "*.ttf", "*.woff"]