Unicode character as value of CSS content property gives spurious error

[GoogleCodeExporter]

PROBLEM:

Unicode character as value of CSS content property gives spurious error "The 
character 'NEWLINE' is not allowed in 'STRING' expressions".

METHOD:

What steps will reproduce the problem
1. Add following rule to CSS.

.link:after {
    content: "】";
}

RESULT:

Spurious error, "The character 'NEWLINE' is not allowed in 'STRING' 
expressions".

EXPECTED:

Nothing. This should not be an error.

PLATFORM:

3.0, W8.

ADDITIONAL INFO:

Obvious workaround is to specify the character as a Unicode escape sequence, 
but this should not be necessary.

Original issue reported on code.google.com by bobmy...@gmail.com on 8 Apr 2013 at 1:33

[GoogleCodeExporter]

Can't reproduce the issue. Neither on Windows 8 nor on Win 7 nor on my Mac.

Original comment by tobias.c...@gmail.com on 8 Apr 2013 at 9:10

[GoogleCodeExporter]

It might coupled with an encoding issue in the CSS. bobmyers, could you send 
the exact CSS file that causes this error?

Original comment by markus.g...@gmail.com on 8 Apr 2013 at 9:13

[GoogleCodeExporter]

Here is the file.
The precise error message is:

WARNING: shiko-c-debug.epub/OEBPS/lib/css/series.css(88): The character 
'NEWLINE' is not allowed in 'STRING' expressions
WARNING: shiko-c-debug.epub/OEBPS/lib/css/series.css(111): The character 
'NEWLINE' is not allowed in 'STRING' expressions

Looking at this more closely, the first error occurs on the content: line of 

.link:before {
    content: "【リンク";
}

By the way, the above actually takes effect in the resulting book, so is being 
parsed correctly.

whereas the second occurs on the seemingly innocuous line

.answer h3 {
    font-size: 1em;
}

Thanks for looking at this.
Bob

Original comment by bobmy...@gmail.com on 9 Apr 2013 at 1:05

Attachments:

• series.css

[GoogleCodeExporter]

I'm very sorry, but I still can't reproduce the error even with the original 
CSS... Markus? Do you have better luck?

Original comment by tobias.c...@gmail.com on 9 Apr 2013 at 9:07

[GoogleCodeExporter]

The attached epub reproduces the problem:

bash 07:09 /tmp/opf $ epubcheck test.epub
Epubcheck Version 3.0

Validating against EPUB version 3.0
WARNING: test.epub/OEBPS/lib/css/series.css(5): The character 'NEWLINE' is not 
allowed in 'STRING' expressions

Check finished with warnings or errors

The css in question is:

@charset "UTF-8";

.link:after {
    content: "】";
}

FWIW this is \3011. However, many other ideographic characters I tried generate 
the same error.

--
Bob

Original comment by bobmy...@gmail.com on 10 Apr 2013 at 1:45

Attachments:

• test.epub

[GoogleCodeExporter]

Nope, sorry... Neither with Windows 7 nor Windows 8 (German locale).
But looking at your commandline, it seems you're using any other OS? Mac?
What system language are you using?

Original comment by tobias.c...@gmail.com on 10 Apr 2013 at 7:05

Attachments:

• issue262_win7-win8.png

[GoogleCodeExporter]

Well, I will see your two screenshots and raise you one (attached). The console 
session in an earlier comment was from cygwin, but as you can see the same 
error occurs (of course) when run from the Windows command line as the 
screenshot shows.

I downloaded source from SVN and identified the location in the source code 
(src/main/java/org/idpf/epubcheck/util/css/CssScanner.java) where this error is 
being generated.

I built but at least within the Eclipse environment the error is not reproduced 
either in Epubcheck 3.0 or Epubcheck Version 3.0.1-SNAPSHOT. 

This is certainly mysterious. Could it be some kind of Java versioning issue? 
Could the wrong version of some dynamically linked library be getting picked up?

To check my sanity I re-downloaded binaries of 3.0, same error.

C:\Users\Bob\Desktop>java -version
java version "1.7.0_13"
Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

My system language is English, but I'm not actually sure what "system language" 
means in Windows...is it different from "display language"?
--
Bob

Original comment by bobmy...@gmail.com on 10 Apr 2013 at 4:37

Attachments:

• Capture.JPG

[GoogleCodeExporter]

Hi Bob,
I cannot repeat this either on OS X, but think I found the problem either way; 
and if it turns out to be what I think, its a problem in EPUBCheck, not in your 
book!

If you have a chance, please download the snapshot build at [1], run it against 
your content, and let us know if things change in any way. 

[1] https://dl.dropbox.com/u/1007541/epubcheck-3.0.1-SNAPSHOT.zip

Original comment by markus.g...@gmail.com on 10 Apr 2013 at 5:37

• Changed state: Accepted
• Added labels: Milestone-3.0.1, Type-Defect

[GoogleCodeExporter]

I should note: the snapshot release linked to above contains code changes that 
have yet not been committed to the SVN.

Original comment by markus.g...@gmail.com on 10 Apr 2013 at 5:48

[GoogleCodeExporter]

The 3.0.1-SNAPSHOT binary fixes this bug.
What was the issue?
I do appreciate your prompt and proactive response to my little bug.
Regards,
--
Bob

Original comment by bobmy...@gmail.com on 11 Apr 2013 at 12:49

[GoogleCodeExporter]

Hi Bob,
the charset declared in css (utf-8) was not passed on properly after detection. 
This resulted in the css file being read using whatever is the default charset 
encoding on your system. 

Original comment by markus.g...@gmail.com on 14 Apr 2013 at 8:48

[GoogleCodeExporter]

This issue was closed by revision r458.

Original comment by markus.g...@gmail.com on 14 Apr 2013 at 8:48

• Changed state: Fixed

[GoogleCodeExporter]

So wow, a real bug. Thanks for dealing with this so expeditiously.

Original comment by bobmy...@gmail.com on 14 Apr 2013 at 8:50