• solidstate1991 (4/4) Oct 26 2019 https://github.com/ZILtoid1991/lzwford
• Andre Pany (6/10) Oct 27 2019 That is really great.
• solidstate1991 (16/21) Oct 27 2019 Probably it would be easier than the times I tried to rewrite

solidstate1991 <laszloszeremi outlook.com> writes:

https://github.com/ZILtoid1991/lzwford

The hardest part was to find one that could work with D easily.

I guess now Imageformats (and my own dimage) can have GIF and 
TIFF file support.

Andre Pany <andre s-e-a-p.de> writes:

On Sunday, 27 October 2019 at 00:59:00 UTC, solidstate1991 wrote:
 https://github.com/ZILtoid1991/lzwford

 The hardest part was to find one that could work with D easily.

 I guess now Imageformats (and my own dimage) can have GIF and 
 TIFF file support.

That is really great.

Side question, did you considered to rewrite a C library (e.g. 
https://github.com/vapier/liblzw) to D?

Kind regards
Andre

solidstate1991 <laszloszeremi outlook.com> writes:

On Sunday, 27 October 2019 at 16:19:58 UTC, Andre Pany wrote:
 That is really great.

 Side question, did you considered to rewrite a C library (e.g. 
 https://github.com/vapier/liblzw) to D?

 Kind regards
 Andre

Probably it would be easier than the times I tried to rewrite 
much more complex C++ libraries/apps to D, however I thought it 
would be sufficient enough to just write a binding for a library.

liblzw's biggest issue was that
a) It's output only.
b) It directly accesses files, which makes buffer reads and 
writes impossible to the point you have to pass the file path to 
a function. Using temp files would probably solve this problem, 
but it's extremely kludgy when you could just use memory buffers. 
Not to mention the wear on modern SSDs.

One of my plans was to port ncompress to D as a library with 
memory buffer reads/writes enabled, but before that I asked 
around and found libncompress, which is that for C. MAybe I'll 
add some higher level API for it in the fashion of std.zlib, only 
more stable.