brailleapps / dotify.formatter.impl Goto Github PK

With fallback I mean renaming collections:

<fallback>
   <rename collection="..." to="..."/>
</fallback>

NLB would like to have this feature because they want to make information available in the title pages about where notes can be found, at the bottom of pages or at the end of volumes. See nlbdev/pipeline-mod-nlb#32.

For example, because it has too many columns.

In order to fully support row-by-row/page- by-page/sheet-by-sheet/volume-by-volume processing,
scenario selection should occur separately from the main processing. Once the desired scenario is selected, it should be processed in the main processing flow.

Each translator has the ability to handle markers, however this isn't used, because FormatterCoreImpl always uses a single instance of the marker processor (the default locale and translation mode).

I will have a look at this myself.

The table processing is inferior to the regular block processing in terms of page breaking, this could perhaps be improved now.

When I have a left page margin of 2 and I create a block with a border:

<margin-region align="left" width="2">
  <indicators/>
</margin-region>

...

<block border-top-style="solid" border-top-align="outer">
  ⠿⠿⠿
</block>

that border extends into the left margin:

⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉
⠀⠀⠿⠿⠿

Is this expected behavior?

After separating this into its own project, the publishing of obfl examples has been lost.

which Joel did intentionally but I relied on the old behavior. We should have another look at it and think about what is the desired behavior, then document that properly in the OBFL spec, then possibly fix.

See brailleapps/dotify#149 (comment)

ScenarioProcessor evaluates different scenarios for efficiency and chooses the most efficient one for further processing (the following interations). However, the way it's implemented is perhaps not optimal, because it is quite complicated and difficult to follow. An easier way of doing this would be to simply copy the results and evaluate a scenario on that copy, and then compare that to the baseline efficiency. Then use the best copy for the rest of the processing.

Currently table cell borders are only rendered where either horizontal or vertical borders exist, if both exist, nothing is rendered.
Currently it looks like this (using ascii characters to illustrate, not braille):

A | B
-- --

It could look something like this:

A | B
--+--

so that

<template use-when="(= (% $page 2) 1)">
  ...
</template>

which does not work anymore when a initial-page-number has been set with an even value, could be replaced with:

<template use-when="$is-right-hand-page">
  ...
</template>

See brailleapps/dotify#134 (comment).

The implemenations of tables and xml-data have not been optimized for performance and could potentially pose a problem when used extensively.

OBFL output cannot be viewed easily. This could be solved by attaching a 
display transform.

Original issue reported on code.google.com by [email protected] on 17 Mar 2014 at 8:34

Incorporate this: https://github.com/daisy/pipeline-mod-braille/blob/f9bb8a9be075703282088d616b549654aa36723d/pipeline-braille-utils/dotify-utils/dotify-formatter/src/main/resources/xml/obfl-normalize-space.xsl

stax2-api contains two interfaces that can be used with OSGi:

• Stax2InputFactoryProvider
• Stax2OutputFactoryProvider

In the dtbook conversion, margin markers are sometimes rendered on the wrong row, if the inline marker are first on the row. For example:

⠀⠀⠿⠧⠁⠗⠊⠑⠗⠁⠗⠀⠎⠞⠕⠗⠞⠀⠃⠡⠙⠑⠀⠍⠑⠇⠇⠁⠝⠀⠀⠀
⠀⠀⠀⠌⠌⠀⠕⠉⠓⠀⠊⠝⠕⠍⠀⠇⠜⠝⠙⠑⠗⠂⠀⠕⠉⠓⠀⠀⠀⠀⠀⠀

It is in the parser, but not in the xsd

Original issue reported on code.google.com by [email protected] on 1 Aug 2013 at 7:01

The OBFLParser now has an interface in the api, this should be supported by the implementation.

Disclaimer: I'm not saying the behavior is wrong, I created this issue to explain my problem.

The way I have implemented the CSS keyword spread-start currently is like this (a bit inspired by the way Joel does it in the MTM script):

• Everywhere I put a <marker name="foo" value="x"/> I also put a <marker name="foo/prev"/> with the value of the previous marker named "foo".
• In order to find the spread-start value of "foo" I first search forward for "foo/prev" markers on the page-content (with an offset of -1 when we're on a right page),
• and if nothing is found I search backward for "foo" markers in the sequence (again with an offset of -1 when on a right page).

Firstly, the backward search should be in scope document or volume, as soon as that is supported (https://github.com/joeha480/dotify/issues/184).

Secondly, this method fails on the first page of the document or volume, i.e. on a right page when there is no left page (and currently also on the first page on a sequence, see issue brailleapps/dotify#143 EDIT: fixed). The reason is that when a value is assigned at the start of the document, the current implementation will behave as if it was assigned in the middle of the spread, and therefore no marker is found.

The way I currently see it, there are 3 solutions:

• For the backward search, use scope sequence but without a start-offset. However this means I would have to use something (unexisting) called spread-content for the forward search.
• I admit this implementation of spread-start is a bit hacky, so we could also consider supporting it more directly in OBFL/Dotify. (EDIT: but this doesn't match the Dotify model of scope + direction that well because the search happens in two directions.)
• I can create special page templates for the first pages of volumes. However for this to work selecting the first page in a volume must be supported in the use-when expression. (EDIT: problematic, see below.)

Borders are not doubled in double line spacing mode.

Expected:
| row1 |
|      |
| row2 |

Actual:
| row1 |

| row2 |

Implementing this would have the implication that borders may overlap on front 
and back of a paper in DLS-mode.

Original issue reported on code.google.com by [email protected] on 13 Jan 2014 at 2:09

Currently it only works with blocks.

I have a patch ready that fixes this. If you want I'll make a pull request.

OBFL may have to be updated too.

What steps will reproduce the problem?

    <sequence master="a">
      <block>
        <page-number ref-id="x" style="default"/>
      </block>
    </sequence>
    <sequence>
      <block id="x">
        ⠤⠤⠤
      </block>
    </sequence>

What is the expected output?

    <section>
      <page>
        <row>⠼⠃</row>
      </page>
    </section>
    <section>
      <page>
        <row>⠤⠤⠤</row>
      </page>
    </section>

What do you see instead? An error.

Original issue reported on code.google.com by bertfrees on 20 Oct 2014 at 3:27

As explained in braillespecs/obfl#60.

Table layout sometimes causes an empty page preceeding the table, see xxx.

Some preparations have been done, but MarkerProcessor is still used directly within ObflParser, and the versions of BrailleTranslator.translate() that accept TextAttributes are not used anywhere.

The formatter should check that the contents of xml-data is a single element and throw a descriptive exception if it isn't.

Currently, the algorithm that splits into volumes cannot control the number of volumes. This means that adding a lot of redundant breaks will cause the process to fail. FormatterImpl should continue the process until there is no more content.

A workaround would be to lower the maximum number of sheets in a volume until it naturally corresponds to the number of manual breaks.

Adding the possibility to append a user translation to the input, would allow 
processing of books that otherwise would fail. Initially, this could be 
character to character translations, but ultimately, a richer format is desired.

Original issue reported on code.google.com by [email protected] on 4 Apr 2014 at 8:03

What is the expected behavior of this?

<marker-indicator markers="foo" indicator="⠿"/>

...

<block>
  <marker class="foo" value="x"/>
  <block>
    ...
  </block>
</block>

It turns out this marker does not create an indicator, so I'm changing it to:

<block>
  <block>
    <marker class="foo" value="x"/>
    ...
  </block>
</block>

But is this a bug or not?

On the latest version of NLBs script I'm getting this exception when testing locally:

java.lang.RuntimeException: com.xmlcalabash.core.XProcException: java.lang.RuntimeException: Error while reformatting.
        at org.daisy.common.xproc.calabash.impl.CalabashXProcPipeline.run(CalabashXProcPipeline.java:246) ~[na:na]
        at org.daisy.pipeline.job.Job.run(Job.java:216) ~[na:na]
        at org.daisy.pipeline.job.impl.DefaultJobExecutionService$1.run(DefaultJobExecutionService.java:110) ~[na:na]
        at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_66-internal]
Caused by: com.xmlcalabash.core.XProcException: java.lang.RuntimeException: Error while reformatting.
        at org.daisy.pipeline.braille.dotify.calabash.impl.OBFLToPEFStep.run(OBFLToPEFStep.java:104) ~[na:na]
        at com.xmlcalabash.runtime.XAtomicStep.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.doRun(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipelineCall.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.doRun(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.extensions.Eval.run(Unknown Source) ~[na:na]
        at org.daisy.pipeline.braille.common.calabash.impl.PxTransformStep.run(PxTransformStep.java:143) ~[na:na]
        at com.xmlcalabash.runtime.XAtomicStep.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XCompoundStep.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.doRun(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipelineCall.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.doRun(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipelineCall.run(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.doRun(Unknown Source) ~[na:na]
        at com.xmlcalabash.runtime.XPipeline.run(Unknown Source) ~[na:na]
        at org.daisy.common.xproc.calabash.impl.CalabashXProcPipeline.run(CalabashXProcPipeline.java:242) ~[na:na]
        ... 3 common frames omitted
Caused by: java.lang.RuntimeException: Error while reformatting.
        at org.daisy.dotify.formatter.impl.FormatterImpl.getVolumes(FormatterImpl.java:149) ~[na:na]
        at org.daisy.dotify.formatter.impl.FormatterImpl.write(FormatterImpl.java:125) ~[na:na]
        at org.daisy.dotify.obfl.ObflParser.writeResult(ObflParser.java:1460) ~[na:na]
        at org.daisy.dotify.engine.impl.LayoutEngineImpl.convert(LayoutEngineImpl.java:117) ~[na:na]
        at org.daisy.pipeline.braille.dotify.calabash.impl.OBFLToPEFStep.run(OBFLToPEFStep.java:93) ~[na:na]
        ... 22 common frames omitted
Caused by: org.daisy.dotify.formatter.impl.PaginatorException: Cannot fit ???????????????????????? into a margin-region of size 2
        at org.daisy.dotify.formatter.impl.PageSequenceBuilder2.getMarginRegionValue(PageSequenceBuilder2.java:316) ~[na:na]
        at org.daisy.dotify.formatter.impl.PageSequenceBuilder2.paginate(PageSequenceBuilder2.java:257) ~[na:na]
        at org.daisy.dotify.formatter.impl.PageStructBuilder.newSequence(PageStructBuilder.java:37) ~[na:na]
        at org.daisy.dotify.formatter.impl.PageStructBuilder.paginate(PageStructBuilder.java:24) ~[na:na]
        at org.daisy.dotify.formatter.impl.FormatterImpl.getVolumes(FormatterImpl.java:147) ~[na:na]
        ... 26 common frames omitted

Does this look like a Dotify problem?

Since the pagination flow has been rewritten, repeated headers/footers could now be supported.

The current implementation of page breaks in tables is very limited. It only tries to break after a complete row. If that fails, it will break anywhere. There could be other options, such as paragraphs inside cells etc.

XSLTRenderingScenario cannot handle results with multiple root nodes. This is because xmlEventReader is used as an intermediary (instead of e.g. a DOMResult). This in turn is because the OBFL parser requires XMLEvents as input.

If padding>0 or table-border=NONE then the cell's outer borders (adjacent to the table's edges) should be rendered.

Add support for sharing header/footer and running text on the same row. This is 
done to save space in the embossed material.

Original issue reported on code.google.com by [email protected] on 15 Mar 2011 at 12:28

• Blocked on: #61

Some braille translation cannot be done while formatting, e.g. if there is a need for structural markers in braille that are specific to a single braille locale. This can be solved in pre-processing, but it could be useful to have a formal pre-translation interface accepting an OBFL document input and producing an OBFL document output (but with structural markers added).

Currently, if a manual break is inserted at some point to account for a single undesired volume break, volume breaks before the inserted manual break are also affected.

In combination with both manual volume breaks and manual editing, the current calculation might appear confusing to an editor. In this case, it would be more user friendly to set a target volume size (which isn't affected by the number of sheets to distribute), so that breaks preceding an inserted manual break remain in the same place as before. In other words, the value of this property would be used instead of the automatic target calculated based on the total number of sheets.

Example

If sheetCount is 120 and splitterMax is 50, the resulting volume sizes are (40, 40, 40). When introducing a break at sheet #90, the resulting sizes would be (45, 45, 30).

If a user doesn't want a manual break to affect breaks before the manual break, the splitterTarget property could be used. Setting splitterTarget to 40 would produce the volume sizes (40, 40, 10, 30) in this example.

isVolatile can either be true or false for a block depending on the contents. The volatility cannot shift between different passes. That breaks the assumption about what it means when a block is volatile. The correct way to do it would be:
if (uai != null) { return true; }

This is ok, because uai is final and cannot change. I guess this may affect performance or even functionality.

The error does not happen systematically. Joel says the reason could be some race condition due to the use of WeakReference in PageSequence. I understand that Joel has removed this class on master, so the problem should propably not exist anymore. However I'm creating this issue because it exists in version 3.1.0 which I am using.

If there are no variables or non-standard hyphenations, the braille translator result could be reused.

Keep-with-previous-sheets doesn't seem to work as expected when the block is longer than one sheet. Apparently, the sheet where the block begins is kept together with a number of previous sheets, instead of starting from the sheet where the block ends, which makes more sense.

Note that, although the exact behavior of keep-with-previous-sheets is unclear (see
braillespecs/obfl#56) and a clarification could have some impact on how a fix for this issue is implemented, the current behavior is incorrect and should be fixed.

Implement state object and closeable interface in OBFL-parser (to ensure that 
it is not reused).

Original issue reported on code.google.com by [email protected] on 17 Aug 2012 at 10:25

CrossReferenceHandler should handle reference searching instead of PageImpl.

We need a more powerful volume breaking algorithm in Dotify, in order to comply with the volume breaking rules specified in braille CSS.

Related issues:

• braillespecs/braille-css#2
• snaekobbi/requirements#30

FactoryManager in formatter uses TransformerFactory.newInstance() which doesn't work with OSGi. In other cases new net.sf.saxon.TransformerFactoryImpl() has been used.

In LayoutEngineTask, row 58, the validation result is not considered.

An exception should be thrown if pre-/post-content exceeds the maximum volume size without any content in between.

table-row-spacing > 0 is not supported.

The support for table cell borders could be extended, to support more cases.