Re: ZXing version on C++ base for Windows CE and Windows (Mobile)

[Steven Parkes]

I appreciate the effort, but I'm not sure what to do with this. It's too big a change to be integrated as is. Keeping another complete copy of the C++ code parallel to the existing C++ port seems to me a bad idea. We have trouble enough keeping the existing C++ port up to date. Having more people contributing the existing port would be a lot more helpful than creating another port that's almost the same but requiring duplicate patching.

It'd be nice to integrate the changes into the existing C++ code base in more bite-sized chunks and see if we can integrate the differences in a way that works equally well with all ports. There are certainly places that the code could be made more portable.

On Jul 5, 2012, at 6:28 AM, hfneubauer wrote:

> Hi all,
> I would like to contribute a version of ZXing on C++ base compiled for Windows CE and other Windows platforms. With this it is possible to use the Microsoft eMbedded C++ compiler V 4 as well as MS Visual Studio 2005.
> I added the following 2D barcodes:
> - DataMatrix
> - QR Code
> - PDF417.
> (I didn't add 1D codes because I developed another 1D barcode decoder years ago for my company, Schweers Informationstechnologie.)
> Some notes:
> - I downloaded the C++ and Java source files yet in April 2012. This means that some changes that other ZXing developers have done since then are not yet part of this package.
> - Mostly I didn't change algorithms etc., however I added header files, debug messages, macro-dependent stuff ("_WIN32", "DEBUG", compiler versions, etc.), etc.
> - Since eMbedded c++ compiler cannot handle C++ streams (like "cout"), I had to avoid them in case of this compiler.
> - Because the object files are stored in one folder, I had to rename some CPP files ("Decoder.cpp" ==> "DecoderQR.cpp" (QR), "DecoderDM.cpp" (DataMatrix) etc.) in order to get unique object names. I didn't rename the header files.
> - Note that, for eMbedded C++, I did not use MFC, and I use the "usual" exception handling ("try", "catch" and "throw") instead of the macros.
> - In "NaNny.cpp" and "NaNny.h" I defined the two items "Not-a-number" (NAN) and "INFINITY" for the two compilers. They are used by some classed and methods.
> - For maximum and minimum values, in "EdgeDetector.h" "Maximum" and "Minimum" are defined for int and float types.
> - For eMbedded c++, I added a file "zxingwce.cpp" that exports two functions from a DLL. For Visual C++, there is a file "zxingwsdp.cpp". There are project files which might be modified to build a DLL.
>
> I also added PDF417 detection and decoding from the Java sources. For PDF417, I also added the PDF417RSDecoder for Reed-Solomon error correction. In Decoder::correctErrors and BitMatrixParser::processRow (both PDF417), I have added validation checks. Nevertheless, sometimes I realized misdecoding. Perhaps, someone can look upon the sources whether there is still the possibility to optimize and/or avoid some misdecodings.
> For the PDF417 large-integer decoding, I had to add a C++ "BigInteger" library with the kind permission of its author, Matt McCutchen.
>
> Have a nice day. Yours, hfneubauer
> <zxing-cpp-windows.zip>

[hfneubauer]

Hi Steven,
thank you for the answer. I would like to suggest the following steps:
- first to integrate the PDF417 stuff because it was earlier not part of the existing C++ code,
- then to discuss the issue of the duplicate C++ names in different folders and come to a solution (maybe we let the names unchanged, but add a note for Windows users that they can rename the affected files by themselves),
- then to integrate the changes in the rest of the project in order to be sure that at the end there's only one C++ port and it contains the latest release.
Regards,
Hartmut Neubauer

[Steven Parkes]

Sounds like a good approach.

I noticed that the pdf417 code is trying to include GF256. This was replaced a fair amount of time ago with the generic GF code.

What code did you port? Did you look at the svn trunk?

[hfneubauer]

No, the PDF417 code does not include the GF(256) error correction, but it uses the Galois field GF(929) for EC. The code for this was ported from the following Java source:
http://code.google.com/p/zxing/issues/attachmentText?id=817&aid=8170033000&name=pdf417-java-reed-solomon-error-correction-2.patch&token=0819f5d7446ae2814fd91385eeec6a11
(... you see that the original code was in C)
No, until now I didn't look at the svn. I have TortoiseSVN installed, but how can I configure it so that it would access the ZXing sources?
Regards, HFN.

[Steven Parkes]

> No, the PDF417 code does not include the GF(256) error correction, but it uses the Galois field GF(929) for EC.

My observation is simply that pdf417/decoder/Decoder.h includes zxing/common/reedsolomon/GF256.h which no longer exists.

> No, until now I didn't look at the svn.

Yeah, you definitely want to work based on trunk. Otherwise, there's almost no chance we'll be able to maintain the code. If the code is up to date with the java, it's fairly easy to look at the commits to the Java and port them to C++. If the C++ isn't up to date, that's almost impossible.

I don't know anything about Tortoise, but the (read only) svn repo url for trunk is http://zxing.googlecode.com/svn/trunk.

[awei]

hello，who can reply this question？thanks！

在 2012年9月13日星期四UTC+8下午10时13分06秒，awei写道：

hi  hfneubauer ,i used your this c++ version zxing code,and i write a sample,but when i run,the sample use zxgdecode.this function always throw a Exception.can you give me a test sample?

this blew is my some code:

  FILE *fp=fopen("\\test.bmp","r");

    BITMAPFILEHEADER fileheader;

    BITMAPINFO info;

    fread(&fileheader,sizeof(fileheader),1,fp);

    if(fileheader.bfType!=0x4D42)

    {//

        fclose(fp);

        return ;

    }

    UCHAR *buffer = NULL;

    //

    fread(&info.bmiHeader, sizeof(BITMAPINFOHEADER), 1, fp);

    //

    long width=info.bmiHeader.biWidth;

    long lwidth = width;

    /

    long height=info.bmiHeader.biHeight;

    long lheight = height;  

    DWORD size;

    if (info.bmiHeader.biSizeImage != 0)

    {//

        size = info.bmiHeader.biSizeImage;

    }

    else

    {//

        size = info.bmiHeader.biHeight*info.bmiHeader.biWidth*3;

    }

    buffer = new UCHAR[size];//

    if (buffer == NULL)

    {//

        delete[] buffer;

        return; 

    }

    //

    fseek(fp,fileheader.bfOffBits,0);

    fread(buffer,size,1,fp);

char pDecode[17];

memset(pDecode,0,20);

int  ileng =20;

zxgDecode(buffer,640,480,0,0,640,480,pDecode,&ileng);

free(p);

///////////////////////

CString strx;

strx.Format(L"decode result is%d,%s",x,pDecode);

MessageBox(strx);

在 2012年7月5日星期四UTC+8下午9时28分04秒，hfneubauer写道：

[hfneubauer]

Hi awei, your buffer pDecode is too small (17 bytes), and you fill it with 20 bytes, so it is no wonder that it throws and exception. Please define a bigger buffer and tell zxgDecode (via iLeng) the size of the buffer. Regards, hfneubauer