brailleapps / dotify Goto Github PK

A unified interface for translator and hyphenator should be created. This would 
allow complex hyphenation of braille, for example.

If there is a TOC, the volume splitting might not complete due to oscillation 
issues where the TOC never matches the actual content of a volume.

RunParameters in the system package does not belong there, since it implies a 
specific usage of the task system. This should be modified. Preferably by 
adding parameter requirements to the task system and task interfaces. The 
parameters sent to a task system should be a generic key-value map, e.g. 
properties.

Folder tests should be renamed to test as this is the convention.

The old volume cover implementation is redundant as this functionality has been 
added to OBFL. The layout should be migrated into the xslt in the task system 
where it is used, and the implementation deleted.

Add styles to translator interface. Currently, adding braille markers requires 
a pre-processing step. Adding styles to the translator interface would create a 
more complete translator interface, with no braille knowledge required outside 
of the translator.

Nesting of styles may be necessary.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Verify that the page number resolver (PageImpl) includes page number offset.

Span elements are ignored in pre-/post-volume content (BlockEvent processing in 
OBFL-parser). This can for example result in incorrect hyphenation of spans 
with language markup.

Move CLI to separate package, so that dotify.jar can be placed in lib along 
with dotify-translator.jar. This makes sense for dotify.jar classpath when used 
in another context

Whitespace normalization needs improvement

Implementation specific parameters exist in framwork code (RunParameters). 
These should be moved.

What steps will reproduce the problem?
1. add the following to a TOC in the OBFL input:
<toc-sequence [...] range="volume" [...]>
    [...]
    <on-toc-end>
        <block>Test</block>
    </on-toc-end>
</toc-sequence>
2. run file

What is the expected output? 
Volume toc finishes with paragraph "Test".

What do you see instead?
Nothing

Use java factories and separate jars for input interpreters.

The reason for this is that these have a tendency to change while the system 
remains the same, and it can generate a lot of new versions.

If separated, those interested in a package of input interpreters can update 
only these, and the system does not have to change version.

What steps will reproduce the problem?
1. run dotify with sv-SE and obfl output

What is the expected output? What do you see instead?
Expected: The input file converted to obfl
Actual: The input file

Re-evaluate libraries for a possibly smaller list of dependencies. 
Specifically, is there anything that isn't maintained anymore and needs 
improvement?

BlockEventHandler was created to solve the problem that the original formatter 
did not support reformatting. Now that it does, the BlockEventHandler may be 
redundant, and should then be removed to minimize work when extending the 
functionality of the formatter.

BlockEventHander does not support all ContentTypes, for example MARKER.

When used with Daisy Pipeline there are compatibility issues between Braille 
Utils 1.1.0 and Braille Utils 1.2b, which inhibits Dotify from benefiting from 
recent development in Braille Utils. If this is solved, additional 
functionality could easily be implemented, for example by adding post 
processing of PEF-files into braille text.

Output path must be absolute, this should be changed.

The translator interface can only answer if it supports a given specification, 
it cannot tell what the available combinations are. This can pose a problem in 
a UI context, where the user might want to choose from a list of available 
combinations rather than guessing.

Investigate if XProc can and should be used instead of TaskSystem.

The context language is currently supplied as a parameter to the LayoutEngine, 
however it should be specified in the OBFL input.

What steps will reproduce the problem?

In a new block, insert a leader with position=100% and align=right, follow that 
with <br/> and some text:
<block>
<leader position="100%" align="right"/><br/>some text
</block>

What is the expected output?
[EMPTY LINE]
some text

What do you see instead?
                                  some text

(aligned to the right on the same row as leader)

Add the hyphenator from Daisy Pipeline to the project

Adding caches to factories could improve performance.

BlockEventHander does not support all ContentTypes, for example MARKER.

An empty page is inserted when the last page in the input is filled to the last 
row.

The hyphenator should be integrated in the dotify run. This would require 
xml:lang on obfl elements and an extended interface for the braille translator 
(supply node language).

The paginator interface is not really useful, since it requires much of the 
internal data structure. The output of the formatter could be finished volumes 
instead.

A keep property for volumes would be useful, indicating that a specific number 
of pages following a block must be in the same volume.

Some interfaces use a URL to communicate parameters. However, this implies a 
specific format for the URL, which is inferior to a map from a design 
standpoint.

In the Swedish implementation, there is a dependency between the input format 
and the output format (meta finalizer and cover adder). This should be 
resolved, as OBFL is the canonical format for Dotify.

Harmonize design with brailleutils.

Output format is the top selector in the input system. This was done because 
braille is inserted in preprocessing for braille output, but should not be 
applied when converting to text. However, when introducing additional output 
formats, code duplication grows out of control and the result of the system 
will appear unpredictable. Therefor, the processing mode should be 
parameterized instead, for example: processingMode=braille/text

The resulting output is not validated. When using Daisy Pipeline, validation is 
done as a post process. When running standalone, validation has to be done 
within Dotify.

Temp files are handled by FileJuggler (in org.daisy.util). However, when temp 
files are kept in Dotify, files are copied from the current temp file. This is 
somewhat ineffective. It would be better this was handled by FileJuggler. The 
current reuse of temp files would then be replaced with moving the file to a 
temp file directory if the files should be kept.

Adding the following constructor to FileJuggler:
FileJuggler(File pathToTemp, boolean keepFilesOnClose)

void writeTempFiles(boolean value)
boolean isWritingTempFiles()

Adding this to FileJuggler may be somewhat confusing as the "juggling" part is 
no longer used and swap() might have to be renamed. Therefore, creating another 
class building on this might be a better solution.

Support Java 1.5 JVM

The formatter could be separated, so could the input system.

InputManagerFactory should be allowed to peek at input file in order to 
determine if it supports the format or not, as not to block another 
implementation that might support it

Input an OBFL-file containing a float-item. It will validate, but the item will 
not be in the output.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

TextBorder is a text type class that the translator needs to know about, as it 
may return different values depending on if braille translation is on or not. 
I.e., it's a braille aware component, and as such it should be in the 
translator.

Some characters are converted to braille after the output is written to file. 
This is not desired and should be solved internally before writing the output 
file.

Migrate existing code from Daisy Pipeline

Component jars (such as dotify-translator) should not contain version numbers 
in the file name. These may be released more frequently than the entire Dotify 
installation and it would be useful to be able to "hot swap" jars in an 
existing installation which is difficult if you have to modify the class path 
etc. For those interested in the version number, this information is included 
in the MANIFEST.MF. Another bonus of excluding the version number is that it 
will be completely painless to change it, making it more likely that each 
update gets its own number.

Note that the release zip should still contain version numbers.

The organization of the formatter packages have been lost. Some reorganization 
is needed.

What steps will reproduce the problem?
1. Run a file that violates a schematron test in the Daisy Pipeline GUI

What is the expected output?
An error message that indicates what the problem is. 

What do you see instead?
An error message that simply reads: "InternalTaskException".

Input format conversions should deal with layout specification, not braille 
conversion. This issue depends on issue #51 and issue #35.

There is an option to keep temp files. However, files are kept even when the 
process is successful, which may not be suitable in some cases. An option to 
keep the temp files only if the process fails could be added.