Closed ralfhauser closed 7 months ago
Pure front-end implementation of veraPDF technology is certainly a very interesting idea. As veraPDF is Java-based, it would require porting its model parser to a JavaScript-based PDF engine like PDF.js or similar. This is a major development work, which is for the moment outside of the scope of veraPDF project. However, we would welcome such effort and would be ready to assist if someone tries to implement this.
Java to JavaScript transpilation works very well with J2CL (https://github.com/google/j2cl). The key advantage for such an approach would be that there is only one source base. However, it also has its challenges. On the one hand, this is due to the fact that the transpiler (at least J2CL) only supports a rather limited subset of the standard Java library, on the other hand due to existing incompatibilities between Java and JavaScript language. * (some more details below)
Therefore, I suggest to identify a key feature (e.g. basic in-browser validation of a1- vs. a2- vs. a3- compliance) and to further analyze how much effort this would be.
What do you think ?
If you have funding and there is agreement on a first pilot, I might even be able to organize some additional funds from a non-profit foundation.
* In order for your entire veraPDF universe to work in JavaScript, one would have to gear the entire source base to the transpilation, which includes, for example, the elimination of any method overloading (i.e. methods sharing the same name in the same class, to mention just one point). Ideally, therefore, a project should be aligned with the transpilation from the outset. This is obviously not the case here. An approach, that aims to adapt the entire source base, would involve considerable effort and might not be desirable for every use of the libraries. Therefore – as a fall-back - , it might make sense to implement a core section of the functionality of VeraPdf directly in JavaScript (or rather TypeScript – I could contribute there too).Or at least align only a small part of the existing source base for the transpilation. This would have to be evaluated. In any case, it would be a very worthwhile project to have a PDF/A validator for the browser. It would certainly make things easier and attract numerous additional users.
While this is of interest, there is quite a lot of work involved, and we're not clear how much. We unfortunately don't have funding to prioritise this at the moment, but if a suitably funded proposal was put forward, we would certainly consider it.
While this is of interest, there is quite a lot of work involved, and we're not clear how much. We unfortunately don't have funding to prioritise this at the moment, but if a suitably funded proposal was put forward, we would certainly consider it.
I guess whoever is interested/Roland might have to come up with a https://en.wikipedia.org/wiki/Minimum_viable_product specification and estimate the corresponding effort. The foundation at hand typically finances in the case of extension projects of already existing code about 20-45% of the cost of such MVPs ...
closing this issue for now due to inactivity and no actions planned
It is possible to transpile java such that the vast majority of functionality can also be used in the browser without requiring installation nor server interaction. The my-d foundation did that for qualified pdf signatures with https://www.my-d.org/index.php/www-my-d-org/discretepdfsigner/signature-browser
==> we would love to check pdf/a compatibility just locally with verapdf in the browser before signing (and we could contribute on the how to do that)