There are a few minor flaws though. There was no real way to plug-in my custom
CSSDeclarationTransformer, so I had to create a new CSSNodeData class as well,
which is an exact copy of the original with only a single line changed. Also,
in my CSSDeclarationTransformer, I had to copy some methods that are defined
in the base class but have private access, such as genericPropertyRaw,
genericProperty, genericTermIdent, etc. This could probably be done somewhat
more elegant.
I'm using a slighty modified version of 1.7.0. The reason is threefold:
Because our application runs with the OSGi framework, we have to rebuild jStyleParser into an OSGi bundle with the appropriate manifest headers.
We are tied to Saxon, and because Saxon doesn't implement org.w3c.dom.traversal.TreeWalker, I had to write a generic TreeWalker and my own version of the Traversal class.
I fixed the :first-child pseudo-class (which didn't do anything yet) and added support for some CSS3 pseudo-classes, namely :last-child, :only-child and :nth-child.
Hi Bert, thank you very much for your comments. I will take a look at your
modification and I believe I will incorporate most of them into jStyleParser.
I will also think about the extensibility issue you mentioned.
Radek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having one more issue (on Windows only): When a document contains embedded
CSS, special unicode characters in the CSS are not parsed correctly. I think
it's because these characters are not encoded correctly before the data is
sent to ANTLR.
Hi Bert, it seems you have found a forgotten part of jStyleParser. The
encoding support is not complete yet and the parser is always using the
default system encoding. I have created a new 1.8.1 branch for finishing this.
Many thing are already prepared so it should not be too complicated.
Radek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have included all your extensions to the jStyleParser code. Thank you very
much for your contribution. Additionally, I have added a mechanism for
registering custom DeclarationTransformer implementations into CSSFactory and I have made the generic*() methods protected. I mean, you
could now extend the DeclarationTransformer and override the appropriate
methods in your BraileCSSDeclarationTransformer. Do you think it would solve
your situation? The code preview is in branch 1.8.2:
Hi,
First of all I want to say: Good Job!
I have implemented a flavor of CSS for embossed braille using jStyleParser. It
has some plain CSS properties and some custom properties. (Here is the
specification, in case you're interested: http://code.google.com/p/daisy-
pipeline/wiki/BrailleCSSProperties.)
Implementing it was a breeze. I really like the extensibility of jStyleParser.
Basically, all I had to do was create my own versions of SupportedCSS,
CSSProperty and CSSDeclarationTransformer. Here is my code:
https://github.com/daisy-consortium/pipeline-mod-braille/tree/master/braille-
css/src/main/java/org/daisy/braillecss.
There are a few minor flaws though. There was no real way to plug-in my custom
CSSDeclarationTransformer, so I had to create a new CSSNodeData class as well,
which is an exact copy of the original with only a single line changed. Also,
in my CSSDeclarationTransformer, I had to copy some methods that are defined
in the base class but have private access, such as genericPropertyRaw,
genericProperty, genericTermIdent, etc. This could probably be done somewhat
more elegant.
I'm using a slighty modified version of 1.7.0. The reason is threefold:
Because our application runs with the OSGi framework, we have to rebuild jStyleParser into an OSGi bundle with the appropriate manifest headers.
We are tied to Saxon, and because Saxon doesn't implement org.w3c.dom.traversal.TreeWalker, I had to write a generic TreeWalker and my own version of the Traversal class.
I fixed the :first-child pseudo-class (which didn't do anything yet) and added support for some CSS3 pseudo-classes, namely :last-child, :only-child and :nth-child.
You can find all the patches here: https://github.com/daisy-consortium/osgi-
libs/tree/master/jstyleparser/src/main/patches.
That's it. Maybe you'll consider incorporating some of these changes.
Thanks,
Bert Frees
Hi Bert, thank you very much for your comments. I will take a look at your
modification and I believe I will incorporate most of them into jStyleParser.
I will also think about the extensibility issue you mentioned.
Radek
Cool. Thank you very much!
I'm having one more issue (on Windows only): When a document contains embedded
CSS, special unicode characters in the CSS are not parsed correctly. I think
it's because these characters are not encoded correctly before the data is
sent to ANTLR.
I noticed line 53 in the CSSInputStream class:
On Windows, the default encoding probably doesn't support special unicode
characters and encodes them as question marks. Is there a way to change this
field?
Thanks,
Bert
Hi Bert, it seems you have found a forgotten part of jStyleParser. The
encoding support is not complete yet and the parser is always using the
default system encoding. I have created a new 1.8.1 branch for finishing this.
Many thing are already prepared so it should not be too complicated.
Radek
Great, thanks!
The charset support is available in the SVN trunk. It will be included in the
next release. Briefly:
Any feedback is welcome.
Radek
Hi Bert,
I have included all your extensions to the jStyleParser code. Thank you very
much for your contribution. Additionally, I have added a mechanism for
registering custom DeclarationTransformer implementations into
CSSFactory and I have made the generic*() methods protected. I mean, you
could now extend the DeclarationTransformer and override the appropriate
methods in your BraileCSSDeclarationTransformer. Do you think it would solve
your situation? The code preview is in branch 1.8.2:
http://cssbox.svn.sourceforge.net/viewvc/cssbox/jstyleparser/branches/1.8.2/s
rc/cz/vutbr/web/
Radek
Hi Radek,
Looks very good. This solves my problem indeed. Thanks!
Thank you also for the improvements on encoding support.
Bert