silnrsi / smith

font development, testing and release
Other
14 stars 5 forks source link

Have Smith change line endings for .txt files to DOS in main .zip and .exe targets #25

Closed jvgaultney closed 6 years ago

mhosken commented 7 years ago

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"]

mhosken commented 7 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

mhosken commented 7 years ago

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 :(

mhosken commented 7 years ago

Fixed in f9d6c5f

bobh0303 commented 7 years ago

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:

image

Finally, the OFL text is present but essentially unreadable due to formatting: image

mhosken commented 7 years ago

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.

devosb commented 7 years ago

Almost fixed. The text files from the .exe are fine, but the text files from the .zip have the last newline ( \r\n ) removed.

mhosken commented 7 years ago

Fixed in 49406a0