Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The pipeline2 application fails to parse the style sheet #60

Closed
PaulRambags opened this issue Aug 2, 2017 · 3 comments
Closed

The pipeline2 application fails to parse the style sheet #60

PaulRambags opened this issue Aug 2, 2017 · 3 comments

Comments

@PaulRambags
Copy link
Contributor

PaulRambags commented Aug 2, 2017

We have cloned https://github.com/daisy/pipeline-assembly.git and extended the POM with our own module by adding:

               <artifactItem>
                  <groupId>org.daisy.pipeline.modules.braille</groupId>
                  <artifactId>mod-dedicon</artifactId>
                  <version>1.6.2-SNAPSHOT</version>
               </artifactItem>

The resulting application won't parse our style sheet dedicon-default.scss
Parse errors occur on all unicode characters - no error occurs if you remove all unicode characters from the style sheet. Here is the list of all problematic characters:

  • '\200B' (lines 120, 348, 622)
  • U+2814 (lines 546, 649, occurs as a single character)
  • U+2806 (line 610, occurs as a single character)
  • U+2821 (line 631, occurs as a single character)
  • U+280C (line 640, occurs as a single character)

Please note that the unit tests do not have this problem. XProcSpecRunner parses the style sheet correctly when executing <px:apply-stylesheets stylesheets="../../main/resources/css/dedicon-default.scss">

@PaulRambags PaulRambags changed the title The pipeline2 application failes to parse the style sheet The pipeline2 application fails to parse the style sheet Aug 2, 2017
@bertfrees
Copy link
Member

This might have to do with daisy/jStyleParser#5 (see also daisy/pipeline-assembly#103). Davy knows more about it.

@dkager
Copy link
Contributor

dkager commented Aug 3, 2017

Looking back at the issues Bert mentioned I finally remembered that yes, I did struggle with this.
The hack solution is to add an environment variable:

  • Name: JAVA_TOOL_OPTIONS
  • Value: -Dfile.encoding=UTF8

NB: I also added -Xmx2048M there, because the Pipeline can get very hungry.

IIRC, the reason this was necessary is because the conversion process is spawned in a separate JVM that doesn't inherit this parameter. A cleaner solution would be to pass this parameter on when starting the conversion.

@PaulRambags
Copy link
Contributor Author

The -Xmx2048M option can best be omitted. It caused the Dedicon unit tests to take 2 GB of memory and run seemingly forever and then crash with a java.lang.OutOfMemoryError: GC overhead limit exceeded. Without this -Xmx2048M option, the unit tests take almost 4 GB of memory and run successfully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants