This HACKING file describes the development environment.
Copyright (C) 2012 Swiss Library for the Blind, Visually Impaired and Print Disabled
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved.
The prep tool is used as an aid to enrich DTBook XML with markup needed to render Braille. It is implemented as a plugin to the oXygen XML editor.
The current implementation of the plugin does the markup enrichment directly in the text and does not parse the XML. This has some problems in that we have to deal with gruesome regular expressions which try to match across the XML tags (see the whole business with the skipper and the interval tree, trying to hide the XML tags). So on the one hand this is a drawback. On the other hand it keeps us from having to synchronize the document tree with the text, as while we are manipulating the document tree the user might at the same time modify the text.
Deals with initializing the (Swing) Menu bars, tool bar, etc. It also makes sure that some menu items which are implicitly resetting the state of a document are wrapped, so that the prep tool can be notified of these events. These are the “Revert” and the “Save as” menus. Similarly when switching to another prep tool while the current one is still active we need to make sure that the user is warned and the state of the prep tool is reset.
Group a bunch of edits so that they can be undone with one undo
Store info such as current active prep tool, state of each prep tool or current cursor position. This is needed to reflect it in the tool bar but also for example to check if the user changed the cursor position behind the prep tools back.
Not needed in favor of the MenuPlugger
- https://github.com/bwagner/interval-tree as forked from https://github.com/dyoo/interval-tree
- https://github.com/bwagner/wordhierarchy
Short description of individual preptools. Included is discussion of feasibility in xslt. The idea is to replace the preptools written in Java by one generic preptool that knows how to treat specially marked-up dtbook files. pros:
- xslt operates on xml instead of raw text
cons:
- the process becomes more clunky, as we have a call to the pipeline in the edit->preptool->check-cycle. particularly: Parens-PrepTool
Searches for a collection of vforms and allows user to verify (accept/reject). Offers two different patterns of matching vforms selectable via a checkbox. Implementation in XSLT should be possible. Challenge: how to handle user’s choice of pattern. -> generic plugin should allow flags specific to process, i.e. for vforms the choice of pattern.
Finds orphaned parens and wrongly oriented quotation marks. Implementation in XSLT possible, but more awkward than current implementation (see introduction).
Finds potential ordinal numbers and allows user to verify (accept/reject). Implementation in XSLT should be possible.
Finds potential roman numbers and allows user to verify (accept/reject). Implementation in XSLT should be possible.
Finds potential measure numbers and allows user to verify (accept/reject). Implementation in XSLT should be possible.
Finds potential abbreviations and allows user to verify (accept/reject). Implementation in XSLT should be possible.
Finds potential urls/emails and allows user to verify (accept/reject). Implementation in XSLT should be possible.
Finds page breaks and allows user to verify (accept/reject) or to add a <precedingemptyline> element. Implementation in XSLT should be possible, however, it’s a process that allows not only two choices, but three.
Finds accents and allows user to verify (accept/reject). The difference to other preptools: once a word has been marked with a certain choice, the same choice is applied globally to all occurrences of the word in the text. This functionality would need to be implemented in the generic preptool.
There is an effort underway within the DAISY pipeline 2 project to create a set of what they call pre-processing steps which have a similar goal: To enrich XML with additional markup to make it ready for Braille generation. These steps will probably be based on XML technologies, i.e. XSLT and XProc and will also interact with the user, e.g. to confirm an enrichment. How this interaction will be and if it could be integrated in an oXygen editor plugin remains to be seen.