2016-05-13 This VimodPub project is now maintained on Github - https://github.com/SILAsiaPub/vimod-pub
2016-05-13 This 'sfmDictionary2web' project is now on Github - https://github.com/SILAsiaPub/sfm-dict2web
It is no longer developed. Vimod-Pub scripting (also moved to Github) is used instead.
2016-05-13 This "DFM build environment" project has been migrated to Github - https://github.com/indiamcq/dfm-build-env
This project sprang up from being unable to process an already published USFM project through another program that generates HTML output. It turns out that there were out of order verses. Bibles for years have been print published with out of order verses. One of the problems of Digital publishing is that many apps require the verses to be in order and no verse 1a and 1b. This rigidity takes no account of what is good translation. The question remains, why is digital publishing different. Many processes are data centric, which usually also means verse centric. While USFM appears verse centric it is not fully verse centric. USX an XML representation of USFM is clearly not verse centric but is document centric.
Simplehtmlscr is used to generate the HTML in the same efficient form as Prophero and Haiola. It has a simple menu bar with no wording only a next and previous arrow and a menu icon. This app builder allows any order of verses. It does require that each book does have one \id line and one \h line.
So far this has been used to generate over 20 Bible language apps. It is just a simple reader with no search.The Simplehtmlscr process is just two XSLT transformation.
- Combine all the USX files into one file, orders them, and adds grouping within the files for chapters and introduction matter.
- Output a file for each chapter in HTML, as well as book chapter indexes and book index and any other pages.
Once the parameters are entered into the VimodPub script,
Cordova/PhoneGap is used to generate a project
Simplehtmlscr is used to generate the HTML within the project
An Android output is setup
A debug version is created for checking
Modifications are made to the Cordova files to add icon and other changes.
The final signed output is generated
You need Java JDK 1.7. and the Android ADT installed on your computer. The ADT is quite large.
A demo project can be found in the Files secion [[http://projects.palaso.org/projects/vimod-pub/files]]
XML today is one of the standards in the publishing industry. Some publishers start and end in XML, while others end there and some use it in the middle. This project aims to bring together a set of generalized XSLT transformations for processing XML. The input could be various structured input SFM or XML or ???. Many outputs would be XHTML based but not all.
The tool chain is run by a batch file that is modifiable to add new input types, processing features or output types. At a minimum you set an input file and a list of tasks to be done. Each task takes the previous output as its input by default. It also numbers and names the output file so changes can be compared. Many generalized XSLTs require parameters. XSLTs that take parameters are preferred for recyclability. The dream is to have scripts that non-XSLT writers can use, by just adding parameters.
As I work on various Digital publishing projects, I find that one source in XML can be quickly output in different output formats. Once say one format is achieved, the next takes less time to achieve and so on.
DITA is a fix form of digital publishing that requires Schema compliance. VimodPud does not use schema but does demand valid XML.
To help one of developers I made this simple php script that shows a lift file as an interactive dictionary. See the demo here
The Homograph merger has been updated:
- Multiples senses are now considered as candidates for merging.
- 'option list' type properties can now be merged in, rather than causing entries to remain separate.
- Fixed a bug whereby multiple homographs were not considered as candidates for merging.
The CAWL tool can be used to strip unwanted language forms in lift for glosses and definitions. Such forms may have been introduced through the use of the CAWL task for example in WeSay. After removing unwanted forms, you can then use the Writing Systems tool to remove the now redundant writing systems definitions.
There are two main issues with the use of Writing Systems in Lift that this tool addresses:
- Writing Systems that are essentially duplicates of each other, but have been used in the lift data independently.
- Unused writing systems that have a definition and thus show up in the UI.
- Reports on Writing Systems in use in the Lift file.
- Provides a function to rename one Writing System (or regular expression) to another Writing System.
- Deletes (now) unused Writing Systems from the Writing Systems folder.
Some recent issues in some dictionary software applications have caused audio files to become detached from the lift file. This is because either the file is inadvertently renamed, or the link inside the lift file is deleted. The 'Audio Files' tool attempts to reconnect audio files to lift by:
- Attempting to rename the audio file if it is incorrectly named.
- Attempting to find an entry in the lift file that matches part of the audio file name.
Also available in: Atom