Processing terminated by xsl:message at line 2137 in css-to-obfl.xsl

[josteinaj]

This started happening between 3ea2d35 and b8a23ea. Those two commits have been built and are available under http://repo.nlb.no/pipeline/ using the updater, but not the intermediate commits. I haven't tried building the commits between them yet to determine which commit caused the issue.

The bug does not occur in all books, but it does happen with the book we use for system testing in our production system (which I can provide upon request). I have not yet tried to determine whether there is some specific part of the book that causes this issue.

I don't see an easy way to create a regression test for this issue. I can get the input for css-to-obfl.xsl which causes the error, but css-to-obfl.xsl depends on some Java stuff. The NLB translator is used, which is not available from the xprocspec tests in dotify-formatter. I don't think there's an easy way to import for instance css-to-obfl.xpl for use in a xprocspec test in mod-nlb either.

The tests in dotify-formatter has been disabled (presumably by mistake) since 039bbe2 as a result of adding a focus attribute to one of the tests. Three of the tests in test_format.xprocspec fail if that focus attribute is removed:

• 92: Tests combination of manual and automatic volume breaking.
• 93: Tests volume-break-inside: -obfl-keep(...)
• 107: Tests keeping blocks in the same volume.

[bertfrees]

After the last pull from pipeline-mod-braille there is no focus attribute anymore. Not sure I ran the dotify-formatter tests but I think I did. Regarding the "processing terminated" error, is that related? If not, I'm gonna need that test book.

[josteinaj]

115437.html.txt

This is the input file. The contents are obfuscated (same as in our automated tests).

This is the input book for our tests, but by the time it reaches the braille script it looks like the HTML above: https://github.com/nlbdev/produksjonssystem/raw/dab0d8ac7f12e44b7d4849116b8242f2d9b19585/tests/558237.epub

[josteinaj]

I discovered that the dotify-formatter tests had the focus attribute while trying to find the source of the error, but I don't think it's related.

[bertfrees]

I can't reproduce the error so I assume it has been fixed in the mean time. I did hit another issue though. When a th element contains a noteref, like in this book, it can result in notes being repeated, because the th may be repeated. The same is true when there are two different noterefs referencing the same note. In the past this didn't cause an error, there would just be an duplicated note at the bottom of the page or end of book. However after my latest changes this will cause an error in Dotify. Not sure yet how I should best fix that...

[josteinaj]

I haven't managed to test in on the latest version as I'm having trouble building the repo. (make RUBY=ruby dist-zip-minimal ends up in a .make/main.mk:254: recipe for target '.group-eval' failed) I'll try reproducing this issue again when I have things built.

[josteinaj]

I can build the linux distribution (but not the zip) locally. Had to fix the cli to be able to parse the version string for openjdk 10. Now I'm getting parse-content.xsl:23:: net.sf.saxon.trans.XPathException: A sequence of more than one item is not allowed as the value of variable $context (<a/>, <a/>). I'm not able to build the system with the Dockerfile currently, so I can't reproduce it with Docker yet.

[bertfrees]

The exception is because of the issue with noterefs inside tables that I mentioned above.

What do you mean by "I can build the linux distribution but not the zip"?

[josteinaj]

Oh, I must've had my head in two places when I wrote that. I meant I can build the linux distribution but not the minimal distribution.

(in the Dockerfile I can't build the linux distribution either)

[josteinaj]

I think the problem in the Dockerfile is that the .git folder is not availble:

[ERROR] Failed to execute goal ch.sbs:project-version-maven-plugin:1.0.0-SNAPSHOT:set-detailed-project-version (default) on project mod-nlb: Error computing detailed version: RuntimeException -> [Help 1]

[bertfrees]

Hmm, annoying. It seems that Christian does not ignore the .git folder when he builds his Docker image, but that's maybe not such a nice solution either.

[josteinaj]

On a build server, the .git folder might not be too big. I think Jenkins normally does a shallow(?) clone.

[bertfrees]

But will the git describe command work correctly with a shallow clone?

[josteinaj]

Don't know.

[bertfrees]

I can run your test book without errors now.