Add the ability to handle zip and directory input

[ssb22]

Hi, thanks for all your hard work on brf2ebrl. This merge request adds the ability for the convert() function and the brf2ebrl command to take input from one or more zip files or directory (folder) names as well as individual .brf / .brl files.

• If a directory name is given, the code recursively scans it for all files inside it (so we assume it contains only .brf / .brl files),
• If a zip file is given, it is unpacked to a temporary directory, which is then scanned and deleted after use.

[mwhapples]

I need to look at this closely and also plan to raise it as a discussion tomorrow at the project meeting. However from a technical point of view I have some initial thoughts. This project is primarily a library for use in other project UI frontends and any scripts contained in this project were really added mainly to aid development and serve as an example to anyone looking to implement a UI frontend tool which uses this library. How to handle files feels more like a frontend UI matter and to hard code functionality like processing ZIP files in this library does not sit well with me. You may want to look at https://github.com/aphtech/Convert2EBRL which is the APH primary user interface for converting BRF into eBraille.

[ssb22]

Thanks. It's useful to have a non-GUI command-line tool for those of us who don't get on very well with GUIs.

[mwhapples]

This pull request was discussed yesterday at the project meeting and it raised a more general question of how we would like to handle pull requests, especially when adding features. The feeling is that issues should be created first so that the full detail of how things should work can be discussed before implementation. As an example here are some questions specific to this which should have been dealt with in a discussion pre-implementation:

• Does each BRF create a separate eBraille bundle or do all inputs get bundled into a single eBraille file?
• What order do files get detected when scanning directories?
• Do we want to use BRL files, these are not formatted Braille and a significant part of this library is detecting formatting and relies upon there being Braille pages. BRL probably needs a different parser chain to be created.
• How is file type determined, extension, mimetype, etc?
• How should unknown file types be handled or should they be ignored.
  We feel these questions may be answered differently by different people and so it probably is best left for the frontend apps (eg. https://github.com/aphtech/Convert2EBRL) to control this sort of stuff instead of putting it in the library and removing the control from frontends. If this functionality were to be added to the brf2ebrl CLI script, this then should be constrained to only change files in the brf2ebrl.scripts package, thus assuring us of no breakage for frontend apps depending on this library.
  Finally, other than the ZIP file example, it is unclear whether this adds anything which cannot already be done with the brf2ebrl script. Are you aware that brf2ebrl allows multiple files to be specified on the command line and these get bundled into a single eBraille file? You then can rely upon wildcards and shell expansion to gather files from multiple directories? Where shell wildcards are not enough, it probably makes sense to create a custom script which will form a list of files in the order you want, either stores it in an environment variable or file and you use shell commands to pass the list to the brf2ebrl script.

[ssb22]

Thanks, raised as aphtech/Convert2EBRL#1 for discussion there.