Weirdest thing -- after the latest Windows 10 update the --filetype= option no longer works.
Coincidence? I have tested it repeatedly, and get an "Error 225 - Unknown output format" on the command line when I attempt to use the option. It doesn't matter the output format.
Maybe other users could confirm my observation.
This is with the latest version of Zint.
Thank you for the bug report.
I tried on my current Windows 10 Creater Fall 64bit Pro GER with the official zint.exe 2.6.2:
zint.exe --direct --filetype gif -d 1234 > test.gifThe resulting file "test.gif" is a valid gif.
So, sorry, no error message here.
Could you please post an example which failes for you ?
Thank you,
Harald
Last edit: Harald Oehlmann 2017-12-11
Harald:
The attached example worked fine until a few days ago when my Windows 10 64bit Pro Engish was automatically updated to OS Build 16299.98, only afterwards did it not. I now realize I can work around this by specifying "-o QRCode.bmp" and not using --filetype=bmp, but I've had to go and change a lot of code where I had been specifying the file types. This is indeed with zint.exe 2.6.2.
What do you make of Error 225?
It continues today, after rebooting, clearing temp files, etc., so I am fairly confident it isn't going to "fix" itself. I can only attribute it to the Windows update, although I realize it seems strange for me to make that association.
Thanks,
Mike
I have the same OS-Version as you have.
Maybe, Robin may spread any clairty on Error 225.
It is generated in Line 1236 of library.c:
If you like, I (or you ;-) can make a debug build of zinz and you can put it in a C-Environment and look what is going wrong...
I have the same os-version...
Sorry,
Harald
Harald:
Interesting, same OS-Version, yet you don't experience this. It only occurred to me now (duh!) to try this out on another workstation, if I can find another 16299.98 machine.
Unfortunately I'm not up to (i.e. capable of) doing a debug build, and this indeed may not be necessary if the error can't be reproduced on another machine.
I'll keep you posted on what I find out...
Thanks again,
Mike
Hi Michael and Harald,
Sorry you have had this issue. I couldn't reproduce the error either on Windows or Linux, but on closer inspection of the code this is indeed a bug.
This is a classic uninitialised value problem. The value which you give in the --filetype= option is copied in to a string variable, but that string is not currently guaranteed to end with a NULL character - most of the time it will, but it depends on what that particular byte of memory was used for before. If, for example, there was an "a" in that memory location then the library will receive a request for filetype "bmpa" and since this is not one of the filetypes it recognises it will throw error 225. It is perfectly feasable that updating your OS just happened to arrange things in such a way to make this into an issue, but the problem itself is in Zint.
This is easily fixed in the code and so will not be a problem in the next release, but in the meantime my suggestion would be exactly the same workaround that you have already found.
Thanks for getting in touch and for documenting this so well.
Robin.
Robin,
great catch with so little info, wow !
Michael,
could you please confirm, that the test version "zint-2017-12-11.exe" in
https://sourceforge.net/projects/zint/files/zint/test/
fixes the issue.
Thank you,
Harald
Robin and Harald, hats off to you both!
Robin -- a special thanks for checking into and confirming this bug. I appreciate the explanation for what's going on.
Harald -- YES, the test version removes the error and generates a valid output. Thank you for uploading that modification so quickly. Please see before and after results in the attachment.
Mike
Ok, great - bug closed.
Thanks !