Created attachment 23694 [details] css file before chanegs (that did not work) Hi, The attached CSS file is not getting parsed properly by the batick CSS parser. But, if I remove the following selector(with properties) from CSS I am able to parse it. body { background:#ffffff; margin:0; color:#333333; font:x-small Georgia Serif; font-size/* */:/**/small; font-size: /**/small; text-align: center; } I tried printing names in property function but with the above selector I managed to print only background. I am getting the following error message only when I try inputting the CSS text ps.parseStyleSheet(new org.w3c.css.sac.InputSource(new StringReader(src)));. [ java.lang.IllegalStateException ] nullnulljava.lang.IllegalStateException at org.apache.batik.css.parser.CSSLexicalUnit.getStringValue(CSSLexicalUnit.java:175) at CSSParser.property(CSSParser.java:82) at org.apache.batik.css.parser.Parser.parseStyleDeclaration(Parser.java:885) at org.apache.batik.css.parser.Parser.parseRuleSet(Parser.java:604) at org.apache.batik.css.parser.Parser.parseStyleSheet(Parser.java:233) at CSSParser.parseStyleSheet(CSSParser.java:48) at <filename>.run(<filename>.java:322) at java.lang.Thread.run(Thread.java:619) Please fix it and let me know. thanks
(In reply to comment #0) > The attached CSS file is not getting parsed properly by the batick CSS parser. > But, if I remove the following selector(with properties) from CSS I am able to > parse it. > > body { > background:#ffffff; > margin:0; > color:#333333; > font:x-small Georgia Serif; > font-size/* */:/**/small; > font-size: /**/small; > text-align: center; > } This might be related to bug 45663, a known issue in comment parsing: those comments in both "font-size" declarations hint towards that. Also, another possibility is the shorthand "font" declaration [1], which may be confusing the parser: the textual font-size ("x-small") or the font family ("Georgia Serif"). Decreased importance from "blocker" (which didn't make much sense) to "minor" as there seems to be an easy workaround [2] (removing the comments or changing the shorthand font declaration to a few declarations and/or enclosing font family with quotes). Could you confirm this? Also, note that the report's URL should be a "URL associated with the bug, if any" [3], usually pointing to some relevant mailing list discussion or Web page displaying the issue. The current URL doesn't seem to make much sense in this scope, apart from feeling like some kind of publicity. Please confirm this (and remove the URL) or enter some detail about the relationship with the issue... [1] http://www.w3.org/TR/SVG11/text.html#FontProperty [2] https://issues.apache.org/bugzilla/page.cgi?id=fields.html#importance [3] http://www.bugzilla.org/docs/tip/en/html/bug_page.html
(In reply to comment #1) I have changed the URL to the one on the blog (with style tag). Also, I tried changing the CSS as per your suggestion but unless I remove the body selector completely or shorten it down to the following batik cannot parse it. body { } Also, I cannot change the code myself because my program needs to check CSS files (on other websites) for certain keywords. So, this should be a blocker. > (In reply to comment #0) > > The attached CSS file is not getting parsed properly by the batick CSS parser. > > But, if I remove the following selector(with properties) from CSS I am able to > > parse it. > > > > body { > > background:#ffffff; > > margin:0; > > color:#333333; > > font:x-small Georgia Serif; > > font-size/* */:/**/small; > > font-size: /**/small; > > text-align: center; > > } > > This might be related to bug 45663, a known issue in comment parsing: those > comments in both "font-size" declarations hint towards that. > > Also, another possibility is the shorthand "font" declaration [1], which may be > confusing the parser: the textual font-size ("x-small") or the font family > ("Georgia Serif"). > > Decreased importance from "blocker" (which didn't make much sense) to "minor" > as there seems to be an easy workaround [2] (removing the comments or changing > the shorthand font declaration to a few declarations and/or enclosing font > family with quotes). Could you confirm this? > > Also, note that the report's URL should be a "URL associated with the bug, if > any" [3], usually pointing to some relevant mailing list discussion or Web page > displaying the issue. The current URL doesn't seem to make much sense in this > scope, apart from feeling like some kind of publicity. Please confirm this (and > remove the URL) or enter some detail about the relationship with the issue... > > [1] http://www.w3.org/TR/SVG11/text.html#FontProperty > [2] https://issues.apache.org/bugzilla/page.cgi?id=fields.html#importance > [3] http://www.bugzilla.org/docs/tip/en/html/bug_page.html
(In reply to comment #1) I also noticed something very interesting. When I removed the first line from body selector leaving below given CSS, batik was able to parse it. .. ... body { margin:0; color:#333333; font:x-small Georgia Serif; font-size/* */:/**/small; font-size: /**/small; text-align: center; } .. ... > (In reply to comment #0) > > The attached CSS file is not getting parsed properly by the batick CSS parser. > > But, if I remove the following selector(with properties) from CSS I am able to > > parse it. > > > > body { > > background:#ffffff; > > margin:0; > > color:#333333; > > font:x-small Georgia Serif; > > font-size/* */:/**/small; > > font-size: /**/small; > > text-align: center; > > } > > This might be related to bug 45663, a known issue in comment parsing: those > comments in both "font-size" declarations hint towards that. > > Also, another possibility is the shorthand "font" declaration [1], which may be > confusing the parser: the textual font-size ("x-small") or the font family > ("Georgia Serif"). > > Decreased importance from "blocker" (which didn't make much sense) to "minor" > as there seems to be an easy workaround [2] (removing the comments or changing > the shorthand font declaration to a few declarations and/or enclosing font > family with quotes). Could you confirm this? > > Also, note that the report's URL should be a "URL associated with the bug, if > any" [3], usually pointing to some relevant mailing list discussion or Web page > displaying the issue. The current URL doesn't seem to make much sense in this > scope, apart from feeling like some kind of publicity. Please confirm this (and > remove the URL) or enter some detail about the relationship with the issue... > > [1] http://www.w3.org/TR/SVG11/text.html#FontProperty > [2] https://issues.apache.org/bugzilla/page.cgi?id=fields.html#importance > [3] http://www.bugzilla.org/docs/tip/en/html/bug_page.html