| |
 | Posted by Chad Joan |  Permalink Reply |
|
Chad Joan 
| I just spent a few days creating a wrapper for libpng. It isn't perfect, but I figured someone might want to know about this code. I also made libsane and libharu wrappers earlier.
libpng was the real pain of all of these, so I hope this saves someone about 3 days of work.
The wrappers are currently housed in my (hobby) scanning automation project:
https://github.com/chadjoan/autoscan/tree/master/src
The libpng wrapper converts the setjmp/longjmp error handling of the libpng C API into thrown exceptions in D code. It does this using C code so that the C compiler can get the setjmp right for sure, and also allows the C compiler to decipher the versioning macro maze and prevent linking breakage by pushing missing function detection into runtime. This requires generating a bunch of code.
The libsane wrapper (as in Scanner Access Now Easy) is much simpler. It also features some tests that can be compiled (on both C and D sides) to make sure that the type sizes and struct layouts agree on your system. Furthermore, a work-in-progress higher level abstraction for sane (sane/abstraction.d) provides a Range-based interface for some of sane's operations (the Range stuff is not API-stable at all, use at your own risk).
The libharu wrapper isn't too noteworthy: just your basic extern(C) and #define->enum stuff, and not even entirely complete. I am unlikely to put future work into this wrapper. I am probably going to avoid using PDFs because they can't be reprocessed easily once I generate them.
Caveats:
- The libpng wrapper lacks good build scripts. It is currently using some shell scripts that hardcode usage of gcc/dmd. I don't have time to make more appropriate scripts. Windows users will have to bring their own entirely.
- The libsane wrapper also lacks build scripts, but is so simple that you can probably figure it out.
- The libpng and libharu wrappers both lack self-tests for type-size and struct-layout agreement.
- The libharu wrapper is not a complete or exhaustive wrapper by any means.
- These are all for static linking, but some of these might be more appropriate to dynamically link. The only reason this isn't done right now is because of the work it would require and my lack of time.
- I can't guarantee future time investment on these. They are good enough at this point that they will sink much lower on my priority list as I move on to other parts of my project.
I would offer deimos inclusion, though I am not sure what the requirements are. I know I have a good list of caveats there, so this only makes sense if deimos accepts things on a "good enough for now; patches accepted" kind of basis.
|
