An alternative zimlib implementation makes sense if it is done in another programming language than C++. I can think of scenarios where a zimlib for Java, PHP or Python may be interesting. /Manuel Tommi Mäkitalo schrieb: > On Dienstag, 20. Oktober 2009 13:57:08 emmanuel(a)engelhart.org wrote: >> Hi, >> >> I help currently someone wanting to build his own ZIM parser. >> I know this is not necessary... but he wants to do it and I find this is >> interesting to have someone trying to do that. >> >> I have remarked that on the wiki nothing is written about the >> compression: * How do we know if a cluster is compressed or not ? >> * What are the possible value (for different compression methods) ? >> >> Regards >> Emmanuel >> >> _______________________________________________ >> dev-l mailing list >> dev-l(a)openzim.org >> https://intern.openzim.org/mailman/listinfo/dev-l > > Hi, > > unfortunately there are several areas, which are not specified > completely. But luckily this compression flag is at least partly ;-) > > The first byte in a cluster specifies the compression. The value is: > 0 default (no compression) > 1 none (also no compression, I don't know, why vlado specified this in > zeno, but I take ist over to zim) > 2 zip (zlib) > 3 bzip2 (currently used in writer) > 4 lzma (not implemented in reader or writer due to lack of compression > library) > > You can find the flag here: http://openzim.org/ZIM_File_Format#Clusters. > The actual values are not documentated but can be found in the header > zim/zim.h as a enum. > > It is really no necessary to implement a parser but it does not hurt. It > helps discussing ideas for improvements. And it helps pushing zim as a > standard, if we encourage people to work with it. > > > Tommi > _______________________________________________ > dev-l mailing list > dev-l(a)openzim.org > https://intern.openzim.org/mailman/listinfo/dev-l