leptonica - Project Hosting on Google Code

Earlier this year Feb 16, 2010 issue 33 (/prog programs can't link with Windows DLL version of lepton...) reported by wingusr - What steps will reproduce the problem? 1. Try to build a DLL version of leptonica and then have ioformats_reg link to the DLL. What is the expected output? What do you see instead? I expect to be able to link ioformats_reg with the DLL version of leptonica. Instead I see: error LNK2001: unresolved external symbol _ImageFileFormatExtensions ioformats_reg.obj ioformats_reg What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. This turns out to be an insidious problem that's probably strewn throughout leptonica. To fix this SPECIFIC problem I had to change writefile.c from: l_int32 NumImageFileFormatExtensions = 16; /* array size / const char ImageFileFormatExtensions[] = {"unknown", to: LEPT_DLL l_int32 NumImageFileFormatExtensions = 16; /* array size / LEPT_DLL const char ImageFileFormatExtensions[] = {"unknown", in order to tell the MSVC compiler to export those two data items to the DLL. Additionally, ioformats_reg.c had to be changed from: extern const char ImageFileFormatExtensions[]; to: LEPT_DLL extern const char ImageFileFormatExtensions[]; I also had to change the project settings for ioformats_reg so that LEPTONLIB_IMPORTS is defined, then the following is done: #define LEPT_DLL __declspec(dllimport) But that seems a bit confusing to me since the same LEPT_DLL is used for both specifying DLL exports and imports (depending on whether you are building leptonica or a program that links with leptonica). In any case, any data that is supposed to be visible in leptonlib will have to be prefaced with LEPT_DLL. Additionally, any extern data in the prog programs will also have to be prefaced with LEPT_DLL. What steps will reproduce the problem? 1. Try to build a DLL version of leptonica and then have ioformats_reg link to the DLL. What is the expected output? What do you see instead? I expect to be able to link ioformats_reg with the DLL version of leptonica. Instead I see: error LNK2001: unresolved external symbol _ImageFileFormatExtensions ioformats_reg.obj ioformats_reg What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. This turns out to be an insidious problem that's probably strewn throughout leptonica. To fix this SPECIFIC problem I had to change writefile.c from: l_int32 NumImageFileFormatExtensions = 16; /* array size / const char ImageFileFormatExtensions[] = {"unknown", to: LEPT_DLL l_int32 NumImageFileFormatExtensions = 16; /* array size / LEPT_DLL const char ImageFileFormatExtensions[] = {"unknown", in order to tell the MSVC compiler to export those two data items to the DLL. Additionally, ioformats_reg.c had to be changed from: extern const char ImageFileFormatExtensions[]; to: LEPT_DLL extern const char ImageFileFormatExtensions[]; I also had to change the project settings for ioformats_reg so that LEPTONLIB_IMPORTS is defined, then the following is done: #define LEPT_DLL __declspec(dllimport) But that seems a bit confusing to me since the same LEPT_DLL is used for both specifying DLL exports and imports (depending on whether you are building leptonica or a program that links with leptonica). In any case, any data that is supposed to be visible in leptonlib will have to be prefaced with LEPT_DLL. Additionally, any extern data in the prog programs will also have to be prefaced with LEPT_DLL. Jan 17, 2010 issue 29 (rotateorthtest2 doesn't link) Status changed by dan.bloomberg - rotateorthtest2.c should not exist, and it will be removed in 1.65. The correct version of this file is the regression test: rotateorth_reg.c Status: Accepted rotateorthtest2.c should not exist, and it will be removed in 1.65. The correct version of this file is the regression test: rotateorth_reg.c Status: Accepted Jan 17, 2010 issue 32 (plotfile doesn't link) Status changed by dan.bloomberg - plotfile.c is no longer supported, was accidentally left in prog, and will be removed in 1.65. In early versions of leptonica, this was included so that you could generate a plot from a text file that was simpler than the gplot command files. However, there's really no reason for leptonica to supply a pidgin gplot language. The real usefulness of gplot is for making plots programmatically from data in Numas. Status: Accepted plotfile.c is no longer supported, was accidentally left in prog, and will be removed in 1.65. In early versions of leptonica, this was included so that you could generate a plot from a text file that was simpler than the gplot command files. However, there's really no reason for leptonica to supply a pidgin gplot language. The real usefulness of gplot is for making plots programmatically from data in Numas. Status: Accepted Jan 17, 2010 issue 31 (xtractprotos.c doesn't compile on Windows) Status changed by dan.bloomberg - Thanks for the bug and the fix. Will be fixed in 1.65. Status: Accepted Thanks for the bug and the fix. Will be fixed in 1.65. Status: Accepted Jan 17, 2010 issue 30 (dwamorph2_reg and dwamorph3_reg don't link?) commented on by dan.bloomberg - here's the other file of auto-gen'd code for all the linear Sels here's the other file of auto-gen'd code for all the linear Sels Jan 17, 2010 issue 30 (dwamorph2_reg and dwamorph3_reg don't link?) Status changed by dan.bloomberg - This is fixed as follows: (1) dwamorph1_reg.c is now just a generator of linear dwa C code: dwalineargen.c. It is no longer part of a regression test. (2) dwamorph2_reg.c --> (renamed) dwamorph1_reg.c (3) dwamorph3_reg.c --> (renamed) dwamorph2_reg.c Both of these require dwalinear.3.c and dwalinearlow.3.c to be available for compilation, so these will now be precomputed and in the prog directory. Then when you make dwamorph1_reg, it first compiles the dwalinear.3.c files, and links them. Likewise, dwamorph2_reg links those files. Will be fixed in 1.65 Status: Accepted This is fixed as follows: (1) dwamorph1_reg.c is now just a generator of linear dwa C code: dwalineargen.c. It is no longer part of a regression test. (2) dwamorph2_reg.c --> (renamed) dwamorph1_reg.c (3) dwamorph3_reg.c --> (renamed) dwamorph2_reg.c Both of these require dwalinear.3.c and dwalinearlow.3.c to be available for compilation, so these will now be precomputed and in the prog directory. Then when you make dwamorph1_reg, it first compiles the dwalinear.3.c files, and links them. Likewise, dwamorph2_reg links those files. Will be fixed in 1.65 Status: Accepted Jan 15, 2010 issue 32 (plotfile doesn't link) reported by tomp2010 - What steps will reproduce the problem? 1. Try to link plotfile What is the expected output? What do you see instead? I expect to link plotfile. I get an "unresolved external symbol gplotFromFile referenced in function main plotfile.obj" error. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. I see that plotfile is no longer in prog/Makefile. It should be removed from the prog directory. What steps will reproduce the problem? 1. Try to link plotfile What is the expected output? What do you see instead? I expect to link plotfile. I get an "unresolved external symbol gplotFromFile referenced in function main plotfile.obj" error. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. I see that plotfile is no longer in prog/Makefile. It should be removed from the prog directory. Jan 15, 2010 issue 31 (xtractprotos.c doesn't compile on Windows) reported by tomp2010 - What steps will reproduce the problem? 1. Try to compile xtractprotos.c. What is the expected output? What do you see instead? I expect to compile xtractprotos.c. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. VC++ doesn't like the following: char buf[L_BUF_SIZE]; You'll have to change L_BUF_SIZE to the following like other places in leptonica: #define L_BUF_SIZE 512 In VC++'s defense, it claims that C is more restrictive than C++. It purposely disallows this in c files. It CAN handle array initialization with static consts in C++ files. See http://msdn.microsoft.com/en-us/library/eff825eh.aspx for details. What steps will reproduce the problem? 1. Try to compile xtractprotos.c. What is the expected output? What do you see instead? I expect to compile xtractprotos.c. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. VC++ doesn't like the following: char buf[L_BUF_SIZE]; You'll have to change L_BUF_SIZE to the following like other places in leptonica: #define L_BUF_SIZE 512 In VC++'s defense, it claims that C is more restrictive than C++. It purposely disallows this in c files. It CAN handle array initialization with static consts in C++ files. See http://msdn.microsoft.com/en-us/library/eff825eh.aspx for details. Jan 15, 2010 issue 30 (dwamorph2_reg and dwamorph3_reg don't link?) reported by tomp2010 - What steps will reproduce the problem? 1. Try compile and link dwamorph2_reg and dwamorph3_reg. What is the expected output? What do you see instead? I expect to link dwamorph2_reg and dwamorph3_reg. dwamorph2_reg and dwamorph3_reg fail to link because of an "unresolved external symbol pixMorphDwa_3" error. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Maybe pixMorphDwa_3 is one of those auto-gen'ed functions that you have to create by running another program? If so, then I think the comments at the top of dwamorph2_reg and dwamorph3_reg should indicate the proper steps you need to go thru to run these regression tests. What steps will reproduce the problem? 1. Try compile and link dwamorph2_reg and dwamorph3_reg. What is the expected output? What do you see instead? I expect to link dwamorph2_reg and dwamorph3_reg. dwamorph2_reg and dwamorph3_reg fail to link because of an "unresolved external symbol pixMorphDwa_3" error. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Maybe pixMorphDwa_3 is one of those auto-gen'ed functions that you have to create by running another program? If so, then I think the comments at the top of dwamorph2_reg and dwamorph3_reg should indicate the proper steps you need to go thru to run these regression tests. Jan 15, 2010 issue 29 (rotateorthtest2 doesn't link) reported by tomp2010 - What steps will reproduce the problem? 1. Try compile and link rotateorthtest2. What is the expected output? What do you see instead? I expect to link rotateorthtest2. rotateorthtest2 fails to link because of an "unresolved external symbol returnErrorVoid referenced in function rotateOrthTest" error. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. It looks like returnErrorVoid() should be defined in utils.c but isn't? What steps will reproduce the problem? 1. Try compile and link rotateorthtest2. What is the expected output? What do you see instead? I expect to link rotateorthtest2. rotateorthtest2 fails to link because of an "unresolved external symbol returnErrorVoid referenced in function rotateOrthTest" error. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. It looks like returnErrorVoid() should be defined in utils.c but isn't? Jan 08, 2010 issue 28 (GIF file support is broken) Status changed by dan.bloomberg - Thanks Tom. All changes will be incorporated in 1.65. In pixRead(), use pixGetInputFormat() because the extension may be incorrect or missing, and we have just read the pix from file so we know the actual format. The nerve of the giflib, to close an open stream that was passed in to its functions!! Status: Started Thanks Tom. All changes will be incorporated in 1.65. In pixRead(), use pixGetInputFormat() because the extension may be incorrect or missing, and we have just read the pix from file so we know the actual format. The nerve of the giflib, to close an open stream that was passed in to its functions!! Status: Started Jan 08, 2010 issue 28 (GIF file support is broken) commented on by fatihtsp - Hi, thanks for your corrections.Leptonica164 can read gif images but when close the program it gives error. i guess it's due to gifiostub.c. it must be fixed. Thanks Hi, thanks for your corrections.Leptonica164 can read gif images but when close the program it gives error. i guess it's due to gifiostub.c. it must be fixed. Thanks Jan 07, 2010 issue 28 (GIF file support is broken) reported by tomp2010 - What steps will reproduce the problem? 1. Try to run gifio_reg. What is the expected output? What do you see instead? I expect to see various gif files created. Instead gifio_reg fails to compile under Windows, and when compilation errors are fixed, leptonica aborts with "file not open" error. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. First of all, gifio.c isn't part of the current leptonlib.vcproj file, only gifiostub.c is (I'll fix this). Next, gifio.c has to be changed to: #ifndef COMPILER_MSVC #include <unistd.h> #else #include <io.h> #endif and near line 76: #ifndef COMPILER_MSVC lseek(fd, 0, SEEK_SET); #else _lseek(fd, 0, SEEK_SET); #endif ---- Since EGifCloseFile() in egif_lib.c (called by pixWriteStream/pixWriteStreamGif) at line 760 does: if (File && fclose(File) != 0) { _GifError = E_GIF_ERR_CLOSE_FAILED; return GIF_ERROR; } writefile.c line 241, needs to be changed to: if (format != IFF_GIF) fclose(fp); --- Similar issue with DGifCloseFile() in dgif_lib.c at line 610 (called from pixReadStreamGif): if (File && (fclose(File) != 0)) { _GifError = D_GIF_ERR_CLOSE_FAILED; return GIF_ERROR; } so pixRead() in readfile.c, needs to be changed to: PIX * pixRead(const char filename) { FILE fp; PIX pix; l_int32 format; PROCNAME("pixRead"); if (!filename) return (PIX )ERROR_PTR("filename not defined", procName, NULL); if ((fp = fopenReadStream(filename)) == NULL) return (PIX )ERROR_PTR("image file not found", procName, NULL); pix = pixReadStream(fp, 0); format = getImpliedFileFormat(filename); if (format != IFF_GIF) fclose(fp); if (!pix) return (PIX )ERROR_PTR("image not returned", procName, NULL); return pix; } What steps will reproduce the problem? 1. Try to run gifio_reg. What is the expected output? What do you see instead? I expect to see various gif files created. Instead gifio_reg fails to compile under Windows, and when compilation errors are fixed, leptonica aborts with "file not open" error. What version of the product are you using? On what operating system? leptonlib-1.64 Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. First of all, gifio.c isn't part of the current leptonlib.vcproj file, only gifiostub.c is (I'll fix this). Next, gifio.c has to be changed to: #ifndef COMPILER_MSVC #include <unistd.h> #else #include <io.h> #endif and near line 76: #ifndef COMPILER_MSVC lseek(fd, 0, SEEK_SET); #else _lseek(fd, 0, SEEK_SET); #endif ---- Since EGifCloseFile() in egif_lib.c (called by pixWriteStream/pixWriteStreamGif) at line 760 does: if (File && fclose(File) != 0) { _GifError = E_GIF_ERR_CLOSE_FAILED; return GIF_ERROR; } writefile.c line 241, needs to be changed to: if (format != IFF_GIF) fclose(fp); --- Similar issue with DGifCloseFile() in dgif_lib.c at line 610 (called from pixReadStreamGif): if (File && (fclose(File) != 0)) { _GifError = D_GIF_ERR_CLOSE_FAILED; return GIF_ERROR; } so pixRead() in readfile.c, needs to be changed to: PIX * pixRead(const char filename) { FILE fp; PIX pix; l_int32 format; PROCNAME("pixRead"); if (!filename) return (PIX )ERROR_PTR("filename not defined", procName, NULL); if ((fp = fopenReadStream(filename)) == NULL) return (PIX )ERROR_PTR("image file not found", procName, NULL); pix = pixReadStream(fp, 0); format = getImpliedFileFormat(filename); if (format != IFF_GIF) fclose(fp); if (!pix) return (PIX )ERROR_PTR("image not returned", procName, NULL); return pix; } Jan 05, 2010 leptonlib-1.64.tar.gz (Leptonlib 1.64) file uploaded by dan.bloomberg - Labels: OpSys-All Labels: OpSys-All Jan 03, 2010 issue 20 (pixRotate() leaves shear lines on 1 bpp images) changed by dan.bloomberg - You probably thought I forgot about this... You are right: when you rotate a 1 bpp image you get horizontal and vertical shear lines. The horizontal ones are most visible when they go through a line of text, making the text even look tilted in some situations. And the eye is very sensitive to a line of shears, even a single pixel. There are various ways that have been suggested to prevent this. One way is to choose the horizontal shear lines to be in the white background between text lines (for horizontal text). Another is to put some randomness into the shearing, so that you don't get full lines of shear. Your suggestion is actually better. Here is a simple set of operations that does a pretty good job on your declaration of independence. I've added in some unsharp masking to counter the blurring in the convolution. angletorad = 3.14159 / 180.; pix1 = pixRead("doi.tif"); pix2 = pixConvertTo8(pix1, 0); pix3 = pixBlockconv(pix2, 1, 1); pixFindSkewSweepAndSearch(pix1, &angle, &conf, 2, 2, 3.0, 0.5, 0.01); radangle = angletorad * angle; pix4 = pixRotateAM(pix3, radangle, L_BRING_IN_WHITE); pix5 = pixUnsharpMasking(pix4, 1, 1.0); pix6 = pixThresholdToBinary(pix5, 128); pix7 = pixRotateBySampling(pix1, 0, 0, radangle, L_BRING_IN_WHITE); pixDisplay(pix6, 100, 100); pixDisplay(pix7, 600, 100); pixWrite("junkpix6", pix6, IFF_PNG); pixWrite("junkpix7", pix7, IFF_PNG); With some playing around to choose parameters, this would certainly be nice enough to put into the library. Summary: pixRotate() leaves shear lines on 1 bpp images Status: Started You probably thought I forgot about this... You are right: when you rotate a 1 bpp image you get horizontal and vertical shear lines. The horizontal ones are most visible when they go through a line of text, making the text even look tilted in some situations. And the eye is very sensitive to a line of shears, even a single pixel. There are various ways that have been suggested to prevent this. One way is to choose the horizontal shear lines to be in the white background between text lines (for horizontal text). Another is to put some randomness into the shearing, so that you don't get full lines of shear. Your suggestion is actually better. Here is a simple set of operations that does a pretty good job on your declaration of independence. I've added in some unsharp masking to counter the blurring in the convolution. angletorad = 3.14159 / 180.; pix1 = pixRead("doi.tif"); pix2 = pixConvertTo8(pix1, 0); pix3 = pixBlockconv(pix2, 1, 1); pixFindSkewSweepAndSearch(pix1, &angle, &conf, 2, 2, 3.0, 0.5, 0.01); radangle = angletorad * angle; pix4 = pixRotateAM(pix3, radangle, L_BRING_IN_WHITE); pix5 = pixUnsharpMasking(pix4, 1, 1.0); pix6 = pixThresholdToBinary(pix5, 128); pix7 = pixRotateBySampling(pix1, 0, 0, radangle, L_BRING_IN_WHITE); pixDisplay(pix6, 100, 100); pixDisplay(pix7, 600, 100); pixWrite("junkpix6", pix6, IFF_PNG); pixWrite("junkpix7", pix7, IFF_PNG); With some playing around to choose parameters, this would certainly be nice enough to put into the library. Summary: pixRotate() leaves shear lines on 1 bpp images Status: Started Jan 03, 2010 issue 27 (fpix_reg.c doesn't compile under Windows) Status changed by dan.bloomberg - fixed in 1.64 AFAIK. Windows.h included in fpix_reg.c and kernel_reg.c Status: Fixed fixed in 1.64 AFAIK. Windows.h included in fpix_reg.c and kernel_reg.c Status: Fixed Jan 03, 2010 issue 26 (gplot.c doesn't work under Windows) Status changed by dan.bloomberg - fixed in 1.64 Status: Fixed fixed in 1.64 Status: Fixed Jan 03, 2010 issue 25 (trctest.c doesn't link.) Status changed by dan.bloomberg - fixed in 1.64. trctest.c now resurrected. Status: Fixed fixed in 1.64. trctest.c now resurrected. Status: Fixed Jan 03, 2010 issue 24 (gthumb won't work under Windows) Status changed by dan.bloomberg - fixed in 1.64 Status: Fixed fixed in 1.64 Status: Fixed Jan 03, 2010 issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) Status changed by dan.bloomberg - fixed in 1.64 (AFAIK) Status: Fixed fixed in 1.64 (AFAIK) Status: Fixed Jan 03, 2010 issue 23 (adaptmaptest.c is hard to use since suggested example file w...) Status changed by dan.bloomberg - Fixed in 1.64. Yes, the demonstration is cheating to the extent that it doesn't show how to find the image region. That's another story, and the approach to auto-determining the image regions depends on the characteristics of the scan -- particularly on the expected variation in illumination. One approach is to do region growing outside the image, and hope that you don't grow into the image. Status: Fixed Fixed in 1.64. Yes, the demonstration is cheating to the extent that it doesn't show how to find the image region. That's another story, and the approach to auto-determining the image regions depends on the characteristics of the scan -- particularly on the expected variation in illumination. One approach is to do region growing outside the image, and hope that you don't grow into the image. Status: Fixed Jan 03, 2010 issue 21 (Change pixWrite() to automatically add file extension if mis...) Status changed by dan.bloomberg - fixed in 1.64. Adding filename extensions is OFF by default. Status: Fixed fixed in 1.64. Adding filename extensions is OFF by default. Status: Fixed Jan 03, 2010 issue 19 (psioseg_reg.c doesn't work under Windows) Status changed by dan.bloomberg - fixed in 1.64 Status: Fixed fixed in 1.64 Status: Fixed Jan 03, 2010 issue 17 (splitPathAtDirectory() in utils.c doesn't work under windows) Status changed by dan.bloomberg - fixed in 1.64 Status: Fixed fixed in 1.64 Status: Fixed Jan 03, 2010 issue 16 (genPathname() in utils.c doesn't correctly handle dir with w...) Status changed by dan.bloomberg - Fixed in 1.64 Status: Fixed Fixed in 1.64 Status: Fixed Jan 03, 2010 issue 14 (pixDisplay() doesn't work under Windows) Status changed by dan.bloomberg - All good suggestions for the regression tests. The golden files are TBD. We've settled on COMPILER_MSVC throughout. Although automatically adding file extensions is not the default, this can be enabled by changing WRITE_AS_NAMED to 0. Fixed for 1.64 Status: Fixed All good suggestions for the regression tests. The golden files are TBD. We've settled on COMPILER_MSVC throughout. Although automatically adding file extensions is not the default, this can be enabled by changing WRITE_AS_NAMED to 0. Fixed for 1.64 Status: Fixed Jan 03, 2010 issue 13 (adaptnorm_reg.c fails because missing test file lighttext.jp...) Status changed by dan.bloomberg - file added in 1.64 Status: Fixed file added in 1.64 Status: Fixed Jan 03, 2010 issue 12 (Many fopen() calls with mode argument "r"/"w" should probabl...) Status changed by dan.bloomberg - Fixed in 1-64. Status: Fixed Fixed in 1-64. Status: Fixed Jan 03, 2010 issue 11 (Warnings (and errors) on Visual Studio 2008 builds of 1.63) Status changed by dan.bloomberg - I believe the windows issues are now addressed by Tom's scripts and guide in 1.64. Status: Fixed I believe the windows issues are now addressed by Tom's scripts and guide in 1.64. Status: Fixed Jan 03, 2010 leptonlib-1.64.tar.gz (Leptonlib 1.64) file uploaded by dan.bloomberg - Labels: OpSys-All Labels: OpSys-All Jan 03, 2010 README-1.64.html (readme for leptonlib-1.64) file uploaded by dan.bloomberg - Labels: Type-Docs Labels: Type-Docs Jan 03, 2010 leptonlib-1.63.tar.gz (Leptonlib 1.63) file uploaded by dan.bloomberg - Labels: OpSys-All Labels: OpSys-All Jan 03, 2010 README-1.63.html (readme for leptonlib-1.63) file uploaded by dan.bloomberg - Labels: Type-Docs Labels: Type-Docs Older Dec 10, 2009 issue 27 (fpix_reg.c doesn't compile under Windows) changed by dan.bloomberg - Thanks for the fix. Modified kernel_reg.c in the same way. Will ship in 1.64. Status: Accepted Owner: dan.bloomberg Thanks for the fix. Modified kernel_reg.c in the same way. Will ship in 1.64. Status: Accepted Owner: dan.bloomberg Dec 10, 2009 issue 27 (fpix_reg.c doesn't compile under Windows) reported by tomp2010 - What steps will reproduce the problem? 1. Try to build fpix_reg using Visual Studio 2008 What is the expected output? What do you see instead? I expect to build fpix_reg. Instead I get: Error 1 fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory fpix_reg.c 26 What version of the product are you using? On what operating system? leptonlib-1.63a. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Commenting out the #include I see that it was providing sleep(). Windows has: VOID WINAPI Sleep( __in DWORD dwMilliseconds) Header: Declared in Winbase.h; include Windows.h. (I tried including Winbase.h, but that just gives lots of undefined errors, so bite bullet and include Windows.h) See attached fpix_reg.c for new version. What steps will reproduce the problem? 1. Try to build fpix_reg using Visual Studio 2008 What is the expected output? What do you see instead? I expect to build fpix_reg. Instead I get: Error 1 fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory fpix_reg.c 26 What version of the product are you using? On what operating system? leptonlib-1.63a. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Commenting out the #include I see that it was providing sleep(). Windows has: VOID WINAPI Sleep( __in DWORD dwMilliseconds) Header: Declared in Winbase.h; include Windows.h. (I tried including Winbase.h, but that just gives lots of undefined errors, so bite bullet and include Windows.h) See attached fpix_reg.c for new version. Dec 08, 2009 issue 16 (genPathname() in utils.c doesn't correctly handle dir with w...) commented on by dan.bloomberg - I don't think so. The calloc initialized charbuf to 0. After copying the (possibly munged) directory name, and appending the sepchar, all the remaining chars in charbuf are still 0. That's why I left it off. I don't think so. The calloc initialized charbuf to 0. After copying the (possibly munged) directory name, and appending the sepchar, all the remaining chars in charbuf are still 0. That's why I left it off. Dec 08, 2009 issue 16 (genPathname() in utils.c doesn't correctly handle dir with w...) commented on by tomp2010 - Just took a look at your change to genPathname() in utils.c You do: dirlen = strlen(charbuf); if (charbuf[dirlen - 1] != sepchar) /* append sepchar / charbuf[dirlen] = sepchar; strncat(charbuf, fname, namelen); return charbuf; Offhand, that looks to me like you clobber charbuf's trailing null with sepchar? In which case, strncat is going to be very confused. I think you still need my: charbuf[dirlen+1] = '\0'; Just took a look at your change to genPathname() in utils.c You do: dirlen = strlen(charbuf); if (charbuf[dirlen - 1] != sepchar) / append sepchar / charbuf[dirlen] = sepchar; strncat(charbuf, fname, namelen); return charbuf; Offhand, that looks to me like you clobber charbuf's trailing null with sepchar? In which case, strncat is going to be very confused. I think you still need my: charbuf[dirlen+1] = '\0'; Dec 06, 2009 issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) commented on by dan.bloomberg - A real headache! OK, I believe it's correct. File attached in case you want to try compiling ... A real headache! OK, I believe it's correct. File attached in case you want to try compiling ... Dec 06, 2009 issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) commented on by tomp2010 - Bleh. In looking that over I bet: if (dirlen > (MAX_PATH - 2)) should be: if (dirlen > (MAX_PATH - 3)) Since we are about to add two characters (and still need room for the trailing null). Again, c programming gives me a headache :P Bleh. In looking that over I bet: if (dirlen > (MAX_PATH - 2)) should be: if (dirlen > (MAX_PATH - 3)) Since we are about to add two characters (and still need room for the trailing null). Again, c programming gives me a headache :P Dec 06, 2009 issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) commented on by tomp2010 - Oh, aha, you mean: strncat(szDir, TEXT("\\"), MAX_PATH - strlen(szDir)); This concatenates "\" onto the end of szDir, so we get something like: dirname\ Which FindFirstFileA can interpret as all the files in dirname. In looking this change over, seems like I just took what you had before and quickly made the minimum changes. That's where the erroneous comment about where MAX_PATH is defined came from. Since you need to use things like: HANDLE INVALID_HANDLE_VALUE (you can't change this to invalidHandle :P ) WIN32_FIND_DATAA you have to include <windows.h> which includes everything. Eventually MAX_PATH will be defined when WinDef.h is included. Since you don't use TCHAR, you don't need to include <tchar.h> Given what Microsoft has to say about strncpy & strncat http://msdn.microsoft.com/en-us/library/xdsywd25(VS.80).aspx http://msdn.microsoft.com/en-us/library/tbyd7s1y(VS.80).aspx We should use strncpy_s & strncat_s instead: http://msdn.microsoft.com/en-us/library/5dae5d43(VS.80).aspx http://msdn.microsoft.com/en-us/library/w6w3kbaf(VS.80).aspx (This kind of stuff is why I like programming in Python or C# much better :P ) Here's what the function should look like #else /* COMPILER_MSVC / / "Listing the Files in a Directory" http://msdn2.microsoft.com/en-us/library/aa365200(VS.85).aspx / #include <windows.h> SARRAY getFilenamesInDirectory(const char dirname) { char szDir[MAX_PATH]; char tempname; l_int32 dirlen; HANDLE hFind = INVALID_HANDLE_VALUE; SARRAY safiles; WIN32_FIND_DATAA ffd; PROCNAME("getFilenamesInDirectory"); if (!dirname) return (SARRAY )ERROR_PTR("dirname not defined", procName, NULL); dirlen = strlen(dirname); if (dirlen > (MAX_PATH - 2)) return (SARRAY )ERROR_PTR("dirname is too long", procName, NULL); if (stringFindSubstr(dirname, "/", NULL) > 0) { tempname = stringReplaceEachSubstr(dirname, "/", "\\", NULL); strncpy_s(szDir, sizeof(szDir), tempname, _TRUNCATE); FREE(tempname); } else strncpy_s(szDir, sizeof(szDir), dirname, _TRUNCATE); strncat_s(szDir, sizeof(szDir), TEXT("\\"), MAX_PATH - strlen(szDir)-1); if ((safiles = sarrayCreate(0)) == NULL) return (SARRAY )ERROR_PTR("safiles not made", procName, NULL); hFind = FindFirstFileA(szDir, &ffd); if (INVALID_HANDLE_VALUE == hFind) { sarrayDestroy(&safiles); return (SARRAY )ERROR_PTR("hFind not opened", procName, NULL); } while (FindNextFileA(hFind, &ffd) != 0) { if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) /* skip dirs / continue; sarrayAddString(safiles, ffd.cFileName, L_COPY); } FindClose(hFind); return safiles; } #endif / COMPILER_MSVC / Oh, aha, you mean: strncat(szDir, TEXT("\\"), MAX_PATH - strlen(szDir)); This concatenates "\" onto the end of szDir, so we get something like: dirname\ Which FindFirstFileA can interpret as all the files in dirname. In looking this change over, seems like I just took what you had before and quickly made the minimum changes. That's where the erroneous comment about where MAX_PATH is defined came from. Since you need to use things like: HANDLE INVALID_HANDLE_VALUE (you can't change this to invalidHandle :P ) WIN32_FIND_DATAA you have to include <windows.h> which includes everything. Eventually MAX_PATH will be defined when WinDef.h is included. Since you don't use TCHAR, you don't need to include <tchar.h> Given what Microsoft has to say about strncpy & strncat http://msdn.microsoft.com/en-us/library/xdsywd25(VS.80).aspx http://msdn.microsoft.com/en-us/library/tbyd7s1y(VS.80).aspx We should use strncpy_s & strncat_s instead: http://msdn.microsoft.com/en-us/library/5dae5d43(VS.80).aspx http://msdn.microsoft.com/en-us/library/w6w3kbaf(VS.80).aspx (This kind of stuff is why I like programming in Python or C# much better :P ) Here's what the function should look like #else /* COMPILER_MSVC / / "Listing the Files in a Directory" http://msdn2.microsoft.com/en-us/library/aa365200(VS.85).aspx / #include <windows.h> SARRAY getFilenamesInDirectory(const char dirname) { char szDir[MAX_PATH]; char tempname; l_int32 dirlen; HANDLE hFind = INVALID_HANDLE_VALUE; SARRAY safiles; WIN32_FIND_DATAA ffd; PROCNAME("getFilenamesInDirectory"); if (!dirname) return (SARRAY )ERROR_PTR("dirname not defined", procName, NULL); dirlen = strlen(dirname); if (dirlen > (MAX_PATH - 2)) return (SARRAY )ERROR_PTR("dirname is too long", procName, NULL); if (stringFindSubstr(dirname, "/", NULL) > 0) { tempname = stringReplaceEachSubstr(dirname, "/", "\\", NULL); strncpy_s(szDir, sizeof(szDir), tempname, _TRUNCATE); FREE(tempname); } else strncpy_s(szDir, sizeof(szDir), dirname, _TRUNCATE); strncat_s(szDir, sizeof(szDir), TEXT("\\"), MAX_PATH - strlen(szDir)-1); if ((safiles = sarrayCreate(0)) == NULL) return (SARRAY )ERROR_PTR("safiles not made", procName, NULL); hFind = FindFirstFileA(szDir, &ffd); if (INVALID_HANDLE_VALUE == hFind) { sarrayDestroy(&safiles); return (SARRAY )ERROR_PTR("hFind not opened", procName, NULL); } while (FindNextFileA(hFind, &ffd) != 0) { if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) /* skip dirs / continue; sarrayAddString(safiles, ffd.cFileName, L_COPY); } FindClose(hFind); return safiles; } #endif / COMPILER_MSVC / Dec 06, 2009 issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) commented on by dan.bloomberg - Yes, a summer intern put in that windows patch, and I never looked closely at it until today. So I take it we should '#define MAX_PATH 260' here in sarray.c as well. (Your patch was in writefile.c). Please ignore the comment about "padding". Yes, a summer intern put in that windows patch, and I never looked closely at it until today. So I take it we should '#define MAX_PATH 260' here in sarray.c as well. (Your patch was in writefile.c). Please ignore the comment about "padding". Dec 06, 2009 issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) commented on by tomp2010 - My original comment said: //#include <WinDef.h> // for MAX_PATH (YUCKS, includes all sorts of other files) #define MAX_PATH 260 I don't know where the reference to stdlib.h came from. I thought I just copied that from YOU somewhere :) Which buffer are you talking about? strncpy is supposed to pad out szDir with null up to MAX_PATH. My original comment said: //#include <WinDef.h> // for MAX_PATH (YUCKS, includes all sorts of other files) #define MAX_PATH 260 I don't know where the reference to stdlib.h came from. I thought I just copied that from YOU somewhere :) Which buffer are you talking about? strncpy is supposed to pad out szDir with null up to MAX_PATH. Dec 06, 2009 issue 19 (psioseg_reg.c doesn't work under Windows) changed by dan.bloomberg - Thanks. Fixed for 1.64. Status: Accepted Owner: dan.bloomberg Thanks. Fixed for 1.64. Status: Accepted Owner: dan.bloomberg Dec 06, 2009 issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) commented on by dan.bloomberg - adding sarray.c adding sarray.c Dec 06, 2009 issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) changed by dan.bloomberg - Thanks. The changes are made and the file is attached. I have a couple of questions. First, we're using a MAX_PATH here, with a comment that it's defined in stdlib.h. But it's not in the unix stdlib.h. And furthermore, in writefile.c (also attached) we have set it to 260 because otherwise it brings in a lot of cruft. Also, I don't understand why the buffer seems to be padded out to the end with \. Does that even make sense? Status: Accepted Owner: dan.bloomberg Thanks. The changes are made and the file is attached. I have a couple of questions. First, we're using a MAX_PATH here, with a comment that it's defined in stdlib.h. But it's not in the unix stdlib.h. And furthermore, in writefile.c (also attached) we have set it to 260 because otherwise it brings in a lot of cruft. Also, I don't understand why the buffer seems to be padded out to the end with \*. Does that even make sense? Status: Accepted Owner: dan.bloomberg Dec 06, 2009 issue 17 (splitPathAtDirectory() in utils.c doesn't work under windows) changed by dan.bloomberg - Thanks for finding this. Will be fixed in 1.64. Status: Accepted Owner: dan.bloomberg Thanks for finding this. Will be fixed in 1.64. Status: Accepted Owner: dan.bloomberg Dec 06, 2009 issue 20 (pixRotate() rotates around the lower left corner NOT the ima...) commented on by tomp2010 - Ah... actually after further investigation with rotating larger angles (like 5 degrees), I discovered that the problem is NOT with pixRotate() but with my binImageDiff() routine. That was creating the diff image by starting out with the original image. This means the width & height are wrong unless you center that image within the rotated image's width and height. Sorry for false alarm. However, the artifacts are still there when you directly rotate 1bpp images. Ah... actually after further investigation with rotating larger angles (like 5 degrees), I discovered that the problem is NOT with pixRotate() but with my binImageDiff() routine. That was creating the diff image by starting out with the original image. This means the width & height are wrong unless you center that image within the rotated image's width and height. Sorry for false alarm. However, the artifacts are still there when you directly rotate 1bpp images. Dec 06, 2009 issue 22 (Tabs & spaces in source files) changed by dan.bloomberg - Yes, that is correct. It's better to insert spaces rather than tabs, so that the file appearance is independent of the tab setting in the editor. Because we don't use tabs in files, setting the tab size to 4 is only a matter of convenience when editing. I find that I don't use tabs at all. Status: Done Owner: dan.bloomberg Yes, that is correct. It's better to insert spaces rather than tabs, so that the file appearance is independent of the tab setting in the editor. Because we don't use tabs in files, setting the tab size to 4 is only a matter of convenience when editing. I find that I don't use tabs at all. Status: Done Owner: dan.bloomberg Dec 06, 2009 issue 24 (gthumb won't work under Windows) changed by dan.bloomberg - Thank you. Very good suggestion! This is now in writefile.c (attached) and will be in 1.64. Still to do: upgrade all the programs that explicitly call gthumb. All files will be written to /tmp, rather than the current directory. These changes will be incorporated into 1.64. Status: Accepted Owner: dan.bloomberg Thank you. Very good suggestion! This is now in writefile.c (attached) and will be in 1.64. Still to do: upgrade all the programs that explicitly call gthumb. All files will be written to /tmp, rather than the current directory. These changes will be incorporated into 1.64. Status: Accepted Owner: dan.bloomberg Dec 06, 2009 issue 26 (gplot.c doesn't work under Windows) changed by dan.bloomberg - Thanks for the fix. The repaired file is attached, and will go out with 1.64. Status: Accepted Owner: dan.bloomberg Thanks for the fix. The repaired file is attached, and will go out with 1.64. Status: Accepted Owner: dan.bloomberg

issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) commented on by tomp2010 - Oh, aha, you mean: strncat(szDir, TEXT("\\*"), MAX_PATH - strlen(szDir)); This concatenates "\*" onto the end of szDir, so we get something like: dirname\* Which FindFirstFileA can interpret as all the files in dirname. In looking this change over, seems like I just took what you had before and quickly made the minimum changes. That's where the erroneous comment about where MAX_PATH is defined came from. Since you need to use things like: HANDLE INVALID_HANDLE_VALUE (you can't change this to invalidHandle :P ) WIN32_FIND_DATAA you have to include <windows.h> which includes everything. Eventually MAX_PATH will be defined when WinDef.h is included. Since you don't use TCHAR, you don't need to include <tchar.h> Given what Microsoft has to say about strncpy & strncat http://msdn.microsoft.com/en-us/library/xdsywd25(VS.80).aspx http://msdn.microsoft.com/en-us/library/tbyd7s1y(VS.80).aspx We should use strncpy_s & strncat_s instead: http://msdn.microsoft.com/en-us/library/5dae5d43(VS.80).aspx http://msdn.microsoft.com/en-us/library/w6w3kbaf(VS.80).aspx (This kind of stuff is why I like programming in Python or C# much better :P ) Here's what the function should look like #else /* COMPILER_MSVC */ /* "Listing the Files in a Directory" http://msdn2.microsoft.com/en-us/library/aa365200(VS.85).aspx */ #include <windows.h> SARRAY * getFilenamesInDirectory(const char *dirname) { char szDir[MAX_PATH]; char *tempname; l_int32 dirlen; HANDLE hFind = INVALID_HANDLE_VALUE; SARRAY *safiles; WIN32_FIND_DATAA ffd; PROCNAME("getFilenamesInDirectory"); if (!dirname) return (SARRAY *)ERROR_PTR("dirname not defined", procName, NULL); dirlen = strlen(dirname); if (dirlen > (MAX_PATH - 2)) return (SARRAY *)ERROR_PTR("dirname is too long", procName, NULL); if (stringFindSubstr(dirname, "/", NULL) > 0) { tempname = stringReplaceEachSubstr(dirname, "/", "\\", NULL); strncpy_s(szDir, sizeof(szDir), tempname, _TRUNCATE); FREE(tempname); } else strncpy_s(szDir, sizeof(szDir), dirname, _TRUNCATE); strncat_s(szDir, sizeof(szDir), TEXT("\\*"), MAX_PATH - strlen(szDir)-1); if ((safiles = sarrayCreate(0)) == NULL) return (SARRAY *)ERROR_PTR("safiles not made", procName, NULL); hFind = FindFirstFileA(szDir, &ffd); if (INVALID_HANDLE_VALUE == hFind) { sarrayDestroy(&safiles); return (SARRAY *)ERROR_PTR("hFind not opened", procName, NULL); } while (FindNextFileA(hFind, &ffd) != 0) { if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) /* skip dirs */ continue; sarrayAddString(safiles, ffd.cFileName, L_COPY); } FindClose(hFind); return safiles; } #endif /* COMPILER_MSVC */

Oh, aha, you mean: strncat(szDir, TEXT("\\*"), MAX_PATH - strlen(szDir)); This concatenates "\*" onto the end of szDir, so we get something like: dirname\* Which FindFirstFileA can interpret as all the files in dirname. In looking this change over, seems like I just took what you had before and quickly made the minimum changes. That's where the erroneous comment about where MAX_PATH is defined came from. Since you need to use things like: HANDLE INVALID_HANDLE_VALUE (you can't change this to invalidHandle :P ) WIN32_FIND_DATAA you have to include <windows.h> which includes everything. Eventually MAX_PATH will be defined when WinDef.h is included. Since you don't use TCHAR, you don't need to include <tchar.h> Given what Microsoft has to say about strncpy & strncat http://msdn.microsoft.com/en-us/library/xdsywd25(VS.80).aspx http://msdn.microsoft.com/en-us/library/tbyd7s1y(VS.80).aspx We should use strncpy_s & strncat_s instead: http://msdn.microsoft.com/en-us/library/5dae5d43(VS.80).aspx http://msdn.microsoft.com/en-us/library/w6w3kbaf(VS.80).aspx (This kind of stuff is why I like programming in Python or C# much better :P ) Here's what the function should look like #else /* COMPILER_MSVC */ /* "Listing the Files in a Directory" http://msdn2.microsoft.com/en-us/library/aa365200(VS.85).aspx */ #include <windows.h> SARRAY * getFilenamesInDirectory(const char *dirname) { char szDir[MAX_PATH]; char *tempname; l_int32 dirlen; HANDLE hFind = INVALID_HANDLE_VALUE; SARRAY *safiles; WIN32_FIND_DATAA ffd; PROCNAME("getFilenamesInDirectory"); if (!dirname) return (SARRAY *)ERROR_PTR("dirname not defined", procName, NULL); dirlen = strlen(dirname); if (dirlen > (MAX_PATH - 2)) return (SARRAY *)ERROR_PTR("dirname is too long", procName, NULL); if (stringFindSubstr(dirname, "/", NULL) > 0) { tempname = stringReplaceEachSubstr(dirname, "/", "\\", NULL); strncpy_s(szDir, sizeof(szDir), tempname, _TRUNCATE); FREE(tempname); } else strncpy_s(szDir, sizeof(szDir), dirname, _TRUNCATE); strncat_s(szDir, sizeof(szDir), TEXT("\\*"), MAX_PATH - strlen(szDir)-1); if ((safiles = sarrayCreate(0)) == NULL) return (SARRAY *)ERROR_PTR("safiles not made", procName, NULL); hFind = FindFirstFileA(szDir, &ffd); if (INVALID_HANDLE_VALUE == hFind) { sarrayDestroy(&safiles); return (SARRAY *)ERROR_PTR("hFind not opened", procName, NULL); } while (FindNextFileA(hFind, &ffd) != 0) { if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) /* skip dirs */ continue; sarrayAddString(safiles, ffd.cFileName, L_COPY); } FindClose(hFind); return safiles; } #endif /* COMPILER_MSVC */

Earlier this year

Older