Investigate replacing Batik CSS

[spassarop]

Investigate replacing the CSS parser with something newer, more transparent and more open. Currently there are issues that result in wontfix caused by Batik doing things internally we can't see/change/affect.

This is useful to link/reference all issues related to Batik being a dependency.

[carlosame]

Switching to an alternative SAC parser should be trivial, and a few years ago I made a couple of SAC benchmarks which may be of interest here:

https://css4j.github.io/sac-mark.html

There is also the possibility of migrating to the newer NSAC api, which has explicit support for the latest CSS specs, but that would be a bit more work:

https://css4j.github.io/api/latest/io.sf.carte.css4j/io/sf/carte/doc/style/css/parser/package-summary.html

and please note that css4j is not published to Maven Central so you'd have to add a repository section to your POM file, pointing to the Maven repo at https://css4j.github.io/maven/.

[ahiltenkamp]

As a first step there is a PullRequest which allows to use a different SAC Parser.
All the Batik references are bundled in the CSS Parser in the batik sub package.
The CSS Parser to be used can be defined via System Property the default is the Batik based one provided with AntiSamy
A possible replacement can be also
https://mvnrepository.com/artifact/com.oxygenxml/oxygen-css-flute-parser/27.1.0.3

The first step allows to define a replacement - of course this then is untested and there is no guarantee that it works as executed

Pull Request #643

[carlosame]

As a first step there is a PullRequest which allows to use a different SAC Parser.

The SAC API cannot represent modern CSS and there are no actively maintained implementations anymore.

A possible replacement can be also https://mvnrepository.com/artifact/com.oxygenxml/oxygen-css-flute-parser/27.1.0.3

This seems to be based on the Flute parser which was written by the author of SAC as a proof of concept and had important limitations (for example no serialization so it would be useless here). The license of that artifact is not open source (nor is the source repository available) and it is not downloadable from Sonatype's repository, only from the proprietary Oxygenxml repository.

If using artifacts that are available from repositories other than Sonatype's is an option, then I'd suggest using

https://mvnrepository.com/artifact/io.sf.carte/css4j

which is based on the newer NSAC API, the SAC overhaul that I mentioned above.

[ahiltenkamp]

I totally agree.

We had a some issues which were related to the Batik Parser.
The oxygen css flute parser is at least one option that gets new releases if it is the best I don't know.

The PR is meant as an intermediate step for a cleaner structure providing the possibility to use an alternative implementation to the batik parser or for providing another implementation based on the AntiSamy CssParser which contains some bugfix / workaround without having fork antisamy or wait for a pull request to get accepted.

NSAC can / should be the next step

[carlosame]

The oxygen css flute parser is at least one option that gets new releases if it is the best I don't know.

That parser has a "software developer" license and cannot be used with Antisamy.