Last 7 days

• 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.

Last 30 days

• 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
• Dec 06, 2009

  issue 26 (gplot.c doesn't work under Windows) reported by tomp2010   -   What steps will reproduce the problem? 1. Run histotest What is the expected output? What do you see instead? I expect to see a histogram displayed. Instead nothing is displayed. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. The gnuplot for windows executable is called wgnuplot.exe. Also, the standard gp426win32.zip distribution does not have an X11 terminal. I presume that the gp426win32x11.zip distribution does but I didn't try that because it assumes you have a X11 server running. gplot.c needs the following changes: gplotMakeOutput() changes: #ifndef COMPILER_MSVC if (gplot->outformat != GPLOT_X11) snprintf(buf, L_BUF_SIZE, "gnuplot %s &", gplot->cmdname); else snprintf(buf, L_BUF_SIZE, "gnuplot -persist -geometry +10+10 %s &", gplot->cmdname); #else if (gplot->outformat != GPLOT_X11) snprintf(buf, L_BUF_SIZE, "wgnuplot %s", gplot->cmdname); else snprintf(buf, L_BUF_SIZE, "wgnuplot -persist %s", gplot->cmdname); #endif gplotGenCommandFile() changes: else /* gplot->outformat == GPLOT_X11 */ #ifndef COMPILER_MSVC snprintf(buf, L_BUF_SIZE, "set terminal x11"); #else snprintf(buf, L_BUF_SIZE, "set terminal windows"); #endif

  What steps will reproduce the problem? 1. Run histotest What is the expected output? What do you see instead? I expect to see a histogram displayed. Instead nothing is displayed. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. The gnuplot for windows executable is called wgnuplot.exe. Also, the standard gp426win32.zip distribution does not have an X11 terminal. I presume that the gp426win32x11.zip distribution does but I didn't try that because it assumes you have a X11 server running. gplot.c needs the following changes: gplotMakeOutput() changes: #ifndef COMPILER_MSVC if (gplot->outformat != GPLOT_X11) snprintf(buf, L_BUF_SIZE, "gnuplot %s &", gplot->cmdname); else snprintf(buf, L_BUF_SIZE, "gnuplot -persist -geometry +10+10 %s &", gplot->cmdname); #else if (gplot->outformat != GPLOT_X11) snprintf(buf, L_BUF_SIZE, "wgnuplot %s", gplot->cmdname); else snprintf(buf, L_BUF_SIZE, "wgnuplot -persist %s", gplot->cmdname); #endif gplotGenCommandFile() changes: else /* gplot->outformat == GPLOT_X11 */ #ifndef COMPILER_MSVC snprintf(buf, L_BUF_SIZE, "set terminal x11"); #else snprintf(buf, L_BUF_SIZE, "set terminal windows"); #endif
• Dec 05, 2009

  issue 25 (trctest.c doesn't link.) changed by dan.bloomberg   -   This was an old program, not supported in the makefile. I've rejuvenated it (attached), and it will be distributed in 1.64. BTW, if you run the example command suggested at the top of that file, you will perhaps see one way to approach the difficult problem of figuring out where the image regions are -- a question that you asked earlier in issue 23, with reference to adaptmaptest.

  Status: Accepted

  Owner: dan.bloomberg

  This was an old program, not supported in the makefile. I've rejuvenated it (attached), and it will be distributed in 1.64. BTW, if you run the example command suggested at the top of that file, you will perhaps see one way to approach the difficult problem of figuring out where the image regions are -- a question that you asked earlier in issue 23, with reference to adaptmaptest.

  Status: Accepted

  Owner: dan.bloomberg
• Dec 05, 2009

  issue 25 (trctest.c doesn't link.) reported by tomp2010   -   What steps will reproduce the problem? 1. Build trctest.exe What is the expected output? What do you see instead? I expect to build trctest.exe. Instead the build fails because neither pixLinearTRC() or pixLinearTRCGray() are valid functions? What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below.

  What steps will reproduce the problem? 1. Build trctest.exe What is the expected output? What do you see instead? I expect to build trctest.exe. Instead the build fails because neither pixLinearTRC() or pixLinearTRCGray() are valid functions? What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below.
• Dec 04, 2009

  issue 16 (genPathname() in utils.c doesn't correctly handle dir with w...) changed by dan.bloomberg   -   This fix will be in 1.64.

  Status: Accepted

  Owner: dan.bloomberg

  This fix will be in 1.64.

  Status: Accepted

  Owner: dan.bloomberg
• Dec 04, 2009

  issue 16 (genPathname() in utils.c doesn't correctly handle dir with w...) commented on by dan.bloomberg   -   Thanks. I've made the changes to utils.c, and tested it. The file is attached.

  Thanks. I've made the changes to utils.c, and tested it. The file is attached.
• Dec 04, 2009

  issue 23 (adaptmaptest.c is hard to use since suggested example file w...) commented on by tomp2010   -   Wow works nicely. But it seems a little like cheating to have to specify the "Location of image region" as XS, YS, WS, HS. Does some example exist that shows cleanup of wet-day.jpg but using an auto-determined image region? Would pageseg.c's pixGetRegionsBinary() do this somehow?

  Wow works nicely. But it seems a little like cheating to have to specify the "Location of image region" as XS, YS, WS, HS. Does some example exist that shows cleanup of wet-day.jpg but using an auto-determined image region? Would pageseg.c's pixGetRegionsBinary() do this somehow?
• Dec 04, 2009

  issue 24 (gthumb won't work under Windows) reported by tomp2010   -   What steps will reproduce the problem? 1. Try adaptmaptest.c. What is the expected output? What do you see instead? I expect to see all the junk_write_display* files I think. Nothing. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Unfortunately, all prog programs that do something like: system("gthumb junk_write_display* &"); will have to be changed to something like this to work under Windows: pixDisplayMultipleImages("junk_write_display*"); where pixDisplayMultipleImages() is something like: /*! * pixDisplayMultipleImages() * * Input: filepattern * Return: 0 if OK; 1 on error */ l_int32 pixDisplayMultipleImages(const char *filepattern) { char buffer[L_BUF_SIZE]; #ifdef WIN32 char pathname[MAX_PATH]; char *dir; char *tail; #endif PROCNAME("pixDisplayMultiple"); if (!filepattern || strlen(filepattern) == 0) return ERROR_INT("filepattern not defined", procName, 1); #ifndef COMPILER_MSVC snprintf(buffer, L_BUF_SIZE, "gthumb %s &", filepattern); system(buffer); #else // irFanView wants absolute path for directory _fullpath(pathname, filepattern, sizeof(pathname)); splitPathAtDirectory(pathname, &dir, &tail); snprintf(buffer, L_BUF_SIZE, "i_view32.exe \"%s\" /filepattern=\"%s\" /thumbs", dir, tail); system(buffer); FREE(dir); FREE(tail); #endif return 0; } (As it turns out _fullpath will automatically change / to \ if necessary so this should still work even if filepattern contains the wrong style pathsep chars.)

  What steps will reproduce the problem? 1. Try adaptmaptest.c. What is the expected output? What do you see instead? I expect to see all the junk_write_display* files I think. Nothing. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Unfortunately, all prog programs that do something like: system("gthumb junk_write_display* &"); will have to be changed to something like this to work under Windows: pixDisplayMultipleImages("junk_write_display*"); where pixDisplayMultipleImages() is something like: /*! * pixDisplayMultipleImages() * * Input: filepattern * Return: 0 if OK; 1 on error */ l_int32 pixDisplayMultipleImages(const char *filepattern) { char buffer[L_BUF_SIZE]; #ifdef WIN32 char pathname[MAX_PATH]; char *dir; char *tail; #endif PROCNAME("pixDisplayMultiple"); if (!filepattern || strlen(filepattern) == 0) return ERROR_INT("filepattern not defined", procName, 1); #ifndef COMPILER_MSVC snprintf(buffer, L_BUF_SIZE, "gthumb %s &", filepattern); system(buffer); #else // irFanView wants absolute path for directory _fullpath(pathname, filepattern, sizeof(pathname)); splitPathAtDirectory(pathname, &dir, &tail); snprintf(buffer, L_BUF_SIZE, "i_view32.exe \"%s\" /filepattern=\"%s\" /thumbs", dir, tail); system(buffer); FREE(dir); FREE(tail); #endif return 0; } (As it turns out _fullpath will automatically change / to \ if necessary so this should still work even if filepattern contains the wrong style pathsep chars.)
• Dec 04, 2009

  issue 23 (adaptmaptest.c is hard to use since suggested example file w...) changed by dan.bloomberg   -   Thanks. This will be included in 1.64. I've attached the image here for you.

  Status: Accepted

  Owner: dan.bloomberg

  Thanks. This will be included in 1.64. I've attached the image here for you.

  Status: Accepted

  Owner: dan.bloomberg
• Dec 04, 2009

  issue 23 (adaptmaptest.c is hard to use since suggested example file w...) reported by tomp2010   -   What steps will reproduce the problem? 1. Run adaptmaptest.exe What is the expected output? What do you see instead? Certain #defines seem customized for wet-day.jpg, so I'm not sure what I'm supposed to see. In addition, adaptmaptest.exe (and many other prog programs) assumes the presence of gthumb which won't work under Windows. I'll file a separate issue for this since fix is somewhat complicated. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below.

  What steps will reproduce the problem? 1. Run adaptmaptest.exe What is the expected output? What do you see instead? Certain #defines seem customized for wet-day.jpg, so I'm not sure what I'm supposed to see. In addition, adaptmaptest.exe (and many other prog programs) assumes the presence of gthumb which won't work under Windows. I'll file a separate issue for this since fix is somewhat complicated. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below.
• Dec 04, 2009

  issue 22 (Tabs & spaces in source files) reported by tomp2010   -   What steps will reproduce the problem? 1. View any source file. What is the expected output? What do you see instead? I expect source code to be consistently indented. I see the correct indentation as long as the VS2008 tab settings are set as described below. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. I gather that you assume people have tabs set to 8 spaces, indent size is 4 spaces, and that indenting inserts spaces (not just tabs)? In VS2008notes.htm I should add a section on setting the correct tab settings for viewing Leptonica source files: Tools > Options | Text Editor | C/C++ | Tabs Tab Size: 8 Indent Size: 4 [x] Insert Spaces [ ] Keep Tabs rather than say: Tab Size: 4 Indent Size: 4 [ ] Insert Spaces [x] Keep Tabs

  What steps will reproduce the problem? 1. View any source file. What is the expected output? What do you see instead? I expect source code to be consistently indented. I see the correct indentation as long as the VS2008 tab settings are set as described below. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. I gather that you assume people have tabs set to 8 spaces, indent size is 4 spaces, and that indenting inserts spaces (not just tabs)? In VS2008notes.htm I should add a section on setting the correct tab settings for viewing Leptonica source files: Tools > Options | Text Editor | C/C++ | Tabs Tab Size: 8 Indent Size: 4 [x] Insert Spaces [ ] Keep Tabs rather than say: Tab Size: 4 Indent Size: 4 [ ] Insert Spaces [x] Keep Tabs
• Dec 03, 2009

  issue 21 (Change pixWrite() to automatically add file extension if mis...) commented on by tomp2010   -   Better send the current library source. Things are still changing quite a bit for 1.64 I gather? I might as well bite the bullet now and see if everything still compiles :)

  Better send the current library source. Things are still changing quite a bit for 1.64 I gather? I might as well bite the bullet now and see if everything still compiles :)
• Dec 03, 2009

  issue 21 (Change pixWrite() to automatically add file extension if mis...) commented on by dan.bloomberg   -   Here are the header files. There are a significant number of changes to readfile.c as well (from the jp2 addition). I can bundle up the current library source and send it if you wish.

  Here are the header files. There are a significant number of changes to readfile.c as well (from the jp2 addition). I can bundle up the current library source and send it if you wish.
• Dec 03, 2009

  issue 21 (Change pixWrite() to automatically add file extension if mis...) commented on by tomp2010   -   Latest writefile.c doesn't compile because things like L_DISPLAY_WITH_IV and IFF_JP2 are missing. I guess I need the latest imageio.h and some other header file.

  Latest writefile.c doesn't compile because things like L_DISPLAY_WITH_IV and IFF_JP2 are missing. I guess I need the latest imageio.h and some other header file.
• Dec 03, 2009

  issue 14 (pixDisplay() doesn't work under Windows) commented on by tomp2010   -   Yeah, I guess if a later routine tries to open filename, it won't be able to open filename.ext. I suppose you could write both--with and without the extension (bleh). (2) Putting all output files in /tmp sounds like a good idea. Currently the prog directory gets filled up with all sorts of image files after you run a few of the prog programs. IMO the src and prog directories really ought to be "readonly" (except for auto-generated .c files). You might even consider using your mainName variable as a unique prefix for each program's output files. A further complication would be to put _reg.c program output in a /tmp/regressionTest directory. Then theoretically you could just do a compare of the entire directory to make sure all the output files are still correct.

  Yeah, I guess if a later routine tries to open filename, it won't be able to open filename.ext. I suppose you could write both--with and without the extension (bleh). (2) Putting all output files in /tmp sounds like a good idea. Currently the prog directory gets filled up with all sorts of image files after you run a few of the prog programs. IMO the src and prog directories really ought to be "readonly" (except for auto-generated .c files). You might even consider using your mainName variable as a unique prefix for each program's output files. A further complication would be to put _reg.c program output in a /tmp/regressionTest directory. Then theoretically you could just do a compare of the entire directory to make sure all the output files are still correct.
• Dec 03, 2009

  issue 14 (pixDisplay() doesn't work under Windows) commented on by dan.bloomberg   -   In answer to your comment 5 questions: (1) yes, let's go with COMPILER_MSVC, for the reasons you gave (2) I prefer snprintf() because it's safer. As for cygwin, when I've used it, it was easiest to include everything. (3) chooseDisplayProg() is a new function that lets you choose from among the unix display programs. If you have windows, you just get i_view by default.

  In answer to your comment 5 questions: (1) yes, let's go with COMPILER_MSVC, for the reasons you gave (2) I prefer snprintf() because it's safer. As for cygwin, when I've used it, it was easiest to include everything. (3) chooseDisplayProg() is a new function that lets you choose from among the unix display programs. If you have windows, you just get i_view by default.
• Dec 03, 2009

  issue 21 (Change pixWrite() to automatically add file extension if mis...) commented on by dan.bloomberg   -   Ooops. See Issue 14: I mistakenly put responses for pixWrite() there. Summary here: Proposing to keep pixWrite() default operation as is, but to make it easy to have pixWrite() modify the input filename when there is no extension. I've attached the current version of writefile.c, which has the proposed changes to both pixDisplay() and pixWrite().

  Ooops. See Issue 14: I mistakenly put responses for pixWrite() there. Summary here: Proposing to keep pixWrite() default operation as is, but to make it easy to have pixWrite() modify the input filename when there is no extension. I've attached the current version of writefile.c, which has the proposed changes to both pixDisplay() and pixWrite().
• Dec 03, 2009

  issue 14 (pixDisplay() doesn't work under Windows) commented on by dan.bloomberg   -   On third thought, I'm a bit uneasy about this change to pixWrite() because it will certainly break existing programs. So my current proposal is two-fold: (1) have a preprocessor variable control whether the names change or not, with the initial (default) to no changes. Anyone who wants extension appending can change this before compiling. (2) I'll change every output filename in prog/ to append the correct extension. Attached is the new writefile.c according to (1). Question: for (2), should I uniformly put all these output files in /tmp?

  On third thought, I'm a bit uneasy about this change to pixWrite() because it will certainly break existing programs. So my current proposal is two-fold: (1) have a preprocessor variable control whether the names change or not, with the initial (default) to no changes. Anyone who wants extension appending can change this before compiling. (2) I'll change every output filename in prog/ to append the correct extension. Attached is the new writefile.c according to (1). Question: for (2), should I uniformly put all these output files in /tmp?
• Dec 03, 2009

  issue 19 (psioseg_reg.c doesn't work under Windows) commented on by tomp2010   -   As per the discussion in Issue 14, use COMPILER_MSVC instead of WIN32.

  As per the discussion in Issue 14, use COMPILER_MSVC instead of WIN32.
• Dec 03, 2009

  issue 14 (pixDisplay() doesn't work under Windows) commented on by tomp2010   -   I was wondering the same thing about WIN32 vs COMPILER_MSVC when I realized that my VS2008notes.html and .vcproj file don't define COMPILER_MSVC (or snprintf) when building leptonlib-1.63\prog programs. After doing a bit of research, I see from "C/C++ Preprocessor Reference Predefined Macros" (http://msdn.microsoft.com/en-us/library/b0084kay.aspx) that _WIN32 and _MSC_VER are the only "predefined" macros that meet our needs. WIN32 seems to be automatically added by the C/C++ New Project wizards, but it can be absent from manually compiled builds. I personally like WIN32 (or _WIN32) since they're more well-known, but the case might be made they aren't necessarily specific just to the MSVC compiler? I suppose it depends on whether any of the other supported compilers also define _WIN32 and WIN32 and whether it makes a difference given the way leptonica uses those definitions. _MSC_VER otoh is compiler specific, but it's perhaps too easy to accidentally say MSC_VER instead of _MSC_VER. Both _WIN32 and _MSC_VER are defined at least back to Visual Studio 2003 (and are also defined in the upcoming VS 2010). After thinking about it, the safest thing is for leptonica to use COMPILER_MSVC consistently (and mention in the README that you're using that instead of WIN32 or _WIN32). Then you have complete control over its semantics. If you agree, I need to make a few minor changes to VS2008notes.html and the .vcproj files. --- While looking at writefile.c I was a bit surprised that snprintf(buffer, L_BUF_SIZE, "rm -f /tmp/junk_display.*"); seems to work (at least I didn't notice any error messages about it before). Turns out I've installed cygwin on my system which has a bunch of unixy type programs, including rm. I suppose I should add this to VS2008notes.html. I added all the default cygwin stuff which is undoubtedly overkill. I'll need to investigate the minimum packages people need. It also looks like I need to add /D "snprintf=_snprintf" to VS2008notes.html and my .vcproj when building leptonlib-1.63\prog programs. --- Is chooseDisplayProg() ever called by leptonica? I notice that it probably won't do the correct thing under Windows.

  I was wondering the same thing about WIN32 vs COMPILER_MSVC when I realized that my VS2008notes.html and .vcproj file don't define COMPILER_MSVC (or snprintf) when building leptonlib-1.63\prog programs. After doing a bit of research, I see from "C/C++ Preprocessor Reference Predefined Macros" (http://msdn.microsoft.com/en-us/library/b0084kay.aspx) that _WIN32 and _MSC_VER are the only "predefined" macros that meet our needs. WIN32 seems to be automatically added by the C/C++ New Project wizards, but it can be absent from manually compiled builds. I personally like WIN32 (or _WIN32) since they're more well-known, but the case might be made they aren't necessarily specific just to the MSVC compiler? I suppose it depends on whether any of the other supported compilers also define _WIN32 and WIN32 and whether it makes a difference given the way leptonica uses those definitions. _MSC_VER otoh is compiler specific, but it's perhaps too easy to accidentally say MSC_VER instead of _MSC_VER. Both _WIN32 and _MSC_VER are defined at least back to Visual Studio 2003 (and are also defined in the upcoming VS 2010). After thinking about it, the safest thing is for leptonica to use COMPILER_MSVC consistently (and mention in the README that you're using that instead of WIN32 or _WIN32). Then you have complete control over its semantics. If you agree, I need to make a few minor changes to VS2008notes.html and the .vcproj files. --- While looking at writefile.c I was a bit surprised that snprintf(buffer, L_BUF_SIZE, "rm -f /tmp/junk_display.*"); seems to work (at least I didn't notice any error messages about it before). Turns out I've installed cygwin on my system which has a bunch of unixy type programs, including rm. I suppose I should add this to VS2008notes.html. I added all the default cygwin stuff which is undoubtedly overkill. I'll need to investigate the minimum packages people need. It also looks like I need to add /D "snprintf=_snprintf" to VS2008notes.html and my .vcproj when building leptonlib-1.63\prog programs. --- Is chooseDisplayProg() ever called by leptonica? I notice that it probably won't do the correct thing under Windows.
• Dec 03, 2009

  issue 14 (pixDisplay() doesn't work under Windows) commented on by dan.bloomberg   -   I've attached the current version of writefile.c, including the modifications to pixWrite() for adding the extension and to pixDisplay() for using 3+1 display programs. Question: how should we be tagging the windows-only sections? Should we use #ifdef WIN32 throughout, rather than #if COMPILER_MSVC? What is the most simple, consistent way to do this?

  I've attached the current version of writefile.c, including the modifications to pixWrite() for adding the extension and to pixDisplay() for using 3+1 display programs. Question: how should we be tagging the windows-only sections? Should we use #ifdef WIN32 throughout, rather than #if COMPILER_MSVC? What is the most simple, consistent way to do this?
• Dec 03, 2009

  issue 21 (Change pixWrite() to automatically add file extension if mis...) changed by dan.bloomberg   -   This is an excellent suggestion, even without the issue with windows. It will be included in 1.64. Thanks Tom!!

  Status: Accepted

  Owner: dan.bloomberg

  This is an excellent suggestion, even without the issue with windows. It will be included in 1.64. Thanks Tom!!

  Status: Accepted

  Owner: dan.bloomberg
• Dec 02, 2009

  issue 21 (Change pixWrite() to automatically add file extension if mis...) reported by tomp2010   -   What steps will reproduce the problem? 1. Run adaptnorm_reg.c under Windows What is the expected output? What do you see instead? Output is as expected but not as convenient as it could be under Windows. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Under Windows, it's very difficult to view "junk" images created by prog programs when they don't have an extension. You have to look thru the code to determine the appropriate extension type, and then manually rename the file before you can open it (Or you could unilaterally open all extensionless files with IrfanView I suppose). I propose changing pixWrite() in writefile.c so that it automatically adds an extension to the filename by doing the following: l_int32 pixWrite(const char *filename, PIX *pix, l_int32 format) { FILE *fp; char *pextension; char *filebuf; PROCNAME("pixWrite"); if (!pix) return ERROR_INT("pix not defined", procName, 1); if (!filename) return ERROR_INT("filename not defined", procName, 1); splitPathAtExtension(filename, NULL, &pextension); if (strlen(pextension) == 0) { if ((filebuf = (char *)CALLOC(strlen(filename) + 10, sizeof(char))) == NULL) { if (pextension) FREE (pextension); return ERROR_INT("filebuf not made", procName, 1); } if (format == IFF_DEFAULT) format = pixGetInputFormat(pix); if (format == IFF_UNKNOWN) { if (pixGetDepth(pix) == 1) format = IFF_TIFF_G4; else format = IFF_PNG; } strcpy(filebuf, filename); strcat(filebuf, "."); strcat(filebuf, ImageFileFormatExtensions[format]); } else { filebuf = (char *) filename; } if (pextension) FREE (pextension); fp = fopen(filebuf, "wb+"); if (filebuf != filename) FREE(filebuf); if (fp == NULL) return ERROR_INT("stream not opened", procName, 1); if (pixWriteStream(fp, pix, format)) { fclose(fp); return ERROR_INT("pix not written to stream", procName, 1); } fclose(fp); return 0; }

  What steps will reproduce the problem? 1. Run adaptnorm_reg.c under Windows What is the expected output? What do you see instead? Output is as expected but not as convenient as it could be under Windows. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Under Windows, it's very difficult to view "junk" images created by prog programs when they don't have an extension. You have to look thru the code to determine the appropriate extension type, and then manually rename the file before you can open it (Or you could unilaterally open all extensionless files with IrfanView I suppose). I propose changing pixWrite() in writefile.c so that it automatically adds an extension to the filename by doing the following: l_int32 pixWrite(const char *filename, PIX *pix, l_int32 format) { FILE *fp; char *pextension; char *filebuf; PROCNAME("pixWrite"); if (!pix) return ERROR_INT("pix not defined", procName, 1); if (!filename) return ERROR_INT("filename not defined", procName, 1); splitPathAtExtension(filename, NULL, &pextension); if (strlen(pextension) == 0) { if ((filebuf = (char *)CALLOC(strlen(filename) + 10, sizeof(char))) == NULL) { if (pextension) FREE (pextension); return ERROR_INT("filebuf not made", procName, 1); } if (format == IFF_DEFAULT) format = pixGetInputFormat(pix); if (format == IFF_UNKNOWN) { if (pixGetDepth(pix) == 1) format = IFF_TIFF_G4; else format = IFF_PNG; } strcpy(filebuf, filename); strcat(filebuf, "."); strcat(filebuf, ImageFileFormatExtensions[format]); } else { filebuf = (char *) filename; } if (pextension) FREE (pextension); fp = fopen(filebuf, "wb+"); if (filebuf != filename) FREE(filebuf); if (fp == NULL) return ERROR_INT("stream not opened", procName, 1); if (pixWriteStream(fp, pix, format)) { fclose(fp); return ERROR_INT("pix not written to stream", procName, 1); } fclose(fp); return 0; }
• Dec 01, 2009

  issue 20 (pixRotate() rotates around the lower left corner NOT the ima...) reported by tomp2010   -   What steps will reproduce the problem? 1. Try rotating an image using pixd = pixRotate (pixs, radians, L_ROTATE_AREA_MAP, L_BRING_IN_WHITE, w, h); What is the expected output? What do you see instead? Image is rotated around lower left corner instead of center. The comment for pixRotate states: (1) Rotation is about the center of the image. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Attached are a sample 300 dpi image, and its deskewed version. Also attached is a multipage tiff that shows the differences (this was designed more for images with FEW differences so it's a bit pyschedelic). The first page shows red for new pixels, green for removed pixels. The 2nd page is the new image, the 3rd is the original image, the 4th is just the added pixels, and the 5th is just the erased pixels. (The source for binImageDiff() is in the LeptonicaVS2008Samples.zip I sent you for inclusion in the next release). You can see that the image is mostly unchanged near the lower left corner, whereas big differences occur near the top right. If pixRotate() was rotating about the center, I would expect to see the unchanged pixels near the center instead. Also note the artifacts introduced by doing L_ROTATE_AREA_MAP (which implicitly converts the 1bpp image to gray), and then saving the result as IFF_TIFF_G4. Text lines that start with: causes; and accordingly right, it is their duty of repeated injuries to tyrants only. He has dissolved have noticeable horizontal shifts in the middle of them. Even using 600 dpi images doesn't eliminate the artifacts. I've found that instead of directly rotating 1bpp images, its better to convert explicitly to gray, block convolve, rotate using area mapping, and then theshold back down to 1bpp.

  What steps will reproduce the problem? 1. Try rotating an image using pixd = pixRotate (pixs, radians, L_ROTATE_AREA_MAP, L_BRING_IN_WHITE, w, h); What is the expected output? What do you see instead? Image is rotated around lower left corner instead of center. The comment for pixRotate states: (1) Rotation is about the center of the image. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Attached are a sample 300 dpi image, and its deskewed version. Also attached is a multipage tiff that shows the differences (this was designed more for images with FEW differences so it's a bit pyschedelic). The first page shows red for new pixels, green for removed pixels. The 2nd page is the new image, the 3rd is the original image, the 4th is just the added pixels, and the 5th is just the erased pixels. (The source for binImageDiff() is in the LeptonicaVS2008Samples.zip I sent you for inclusion in the next release). You can see that the image is mostly unchanged near the lower left corner, whereas big differences occur near the top right. If pixRotate() was rotating about the center, I would expect to see the unchanged pixels near the center instead. Also note the artifacts introduced by doing L_ROTATE_AREA_MAP (which implicitly converts the 1bpp image to gray), and then saving the result as IFF_TIFF_G4. Text lines that start with: causes; and accordingly right, it is their duty of repeated injuries to tyrants only. He has dissolved have noticeable horizontal shifts in the middle of them. Even using 600 dpi images doesn't eliminate the artifacts. I've found that instead of directly rotating 1bpp images, its better to convert explicitly to gray, block convolve, rotate using area mapping, and then theshold back down to 1bpp.
• Dec 01, 2009

  issue 19 (psioseg_reg.c doesn't work under Windows) reported by tomp2010   -   What steps will reproduce the problem? 1. Try running psioseg_reg using Windows. What is the expected output? What do you see instead? Program fails because it can't write to non-existent directory. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. mkdir doesn't like paths with / in them under Windows. Later call to ps2pdf also fails. You have to add both Ghostscript lib and bin directories to system path (but that's not really psioseg_reg's fault). Change system("mkdir /tmp/junkimagedir"); system("mkdir /tmp/junkmaskdir"); to: #ifdef WIN32 system("mkdir \\tmp\\junkimagedir"); system("mkdir \\tmp\\junkmaskdir"); #else system("mkdir /tmp/junkimagedir"); system("mkdir /tmp/junkmaskdir"); #endif

  What steps will reproduce the problem? 1. Try running psioseg_reg using Windows. What is the expected output? What do you see instead? Program fails because it can't write to non-existent directory. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. mkdir doesn't like paths with / in them under Windows. Later call to ps2pdf also fails. You have to add both Ghostscript lib and bin directories to system path (but that's not really psioseg_reg's fault). Change system("mkdir /tmp/junkimagedir"); system("mkdir /tmp/junkmaskdir"); to: #ifdef WIN32 system("mkdir \\tmp\\junkimagedir"); system("mkdir \\tmp\\junkmaskdir"); #else system("mkdir /tmp/junkimagedir"); system("mkdir /tmp/junkmaskdir"); #endif
• Dec 01, 2009

  issue 18 (getFilenamesInDirectory() in sarray.c doesn't correctly hand...) reported by tomp2010   -   What steps will reproduce the problem? 1. Try running psioseg_reg using Windows. It calls convertSegmentedPagesToPS("/tmp/junkimagedir", "/tmp/junkmaskdir", 2.0, 0.15, 190, 0, 0, "junkfile.ps") which will eventually fail. What is the expected output? What do you see instead? I expect to be get all the filenames in a directory. Instead no filenames are returned (and this causes a crash later on). What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Change the beginning of getFilenamesInDirectory() to: getFilenamesInDirectory(const char *dirname) { SARRAY *safiles; WIN32_FIND_DATAA ffd; size_t length_of_path; CHAR szDir[MAX_PATH]; /* MAX_PATH is defined in stdlib.h */ HANDLE hFind = INVALID_HANDLE_VALUE; CHAR *tmpDirname; PROCNAME("getFilenamesInDirectory"); if (!dirname) return (SARRAY *)ERROR_PTR("dirname not defined", procName, NULL); length_of_path = strlen(dirname); if (length_of_path > (MAX_PATH - 2)) return (SARRAY *)ERROR_PTR("dirname is to long", procName, NULL); if (stringFindSubstr(dirname, "/", NULL) > 0) { tmpDirname = stringReplaceEachSubstr(dirname, "/", "\\", NULL); strncpy(szDir, tmpDirname, MAX_PATH); FREE(tmpDirname); } else { strncpy(szDir, dirname, MAX_PATH); } szDir[MAX_PATH - 1] = '\0';

  What steps will reproduce the problem? 1. Try running psioseg_reg using Windows. It calls convertSegmentedPagesToPS("/tmp/junkimagedir", "/tmp/junkmaskdir", 2.0, 0.15, 190, 0, 0, "junkfile.ps") which will eventually fail. What is the expected output? What do you see instead? I expect to be get all the filenames in a directory. Instead no filenames are returned (and this causes a crash later on). What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Change the beginning of getFilenamesInDirectory() to: getFilenamesInDirectory(const char *dirname) { SARRAY *safiles; WIN32_FIND_DATAA ffd; size_t length_of_path; CHAR szDir[MAX_PATH]; /* MAX_PATH is defined in stdlib.h */ HANDLE hFind = INVALID_HANDLE_VALUE; CHAR *tmpDirname; PROCNAME("getFilenamesInDirectory"); if (!dirname) return (SARRAY *)ERROR_PTR("dirname not defined", procName, NULL); length_of_path = strlen(dirname); if (length_of_path > (MAX_PATH - 2)) return (SARRAY *)ERROR_PTR("dirname is to long", procName, NULL); if (stringFindSubstr(dirname, "/", NULL) > 0) { tmpDirname = stringReplaceEachSubstr(dirname, "/", "\\", NULL); strncpy(szDir, tmpDirname, MAX_PATH); FREE(tmpDirname); } else { strncpy(szDir, dirname, MAX_PATH); } szDir[MAX_PATH - 1] = '\0';
• Dec 01, 2009

  issue 17 (splitPathAtDirectory() in utils.c doesn't work under windows) reported by tomp2010   -   What steps will reproduce the problem? 1. Try running psioseg_reg using Windows. It calls convertSegmentedPagesToPS("/tmp/junkimagedir", "/tmp/junkmaskdir", 2.0, 0.15, 190, 0, 0, "junkfile.ps") which will eventually fail. What is the expected output? What do you see instead? I expect to be able to split paths. Instead the entire path is returned (or nothing). What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Change if ((lastslash = strrchr(cpathname, '/'))) { to: if ((lastslash = strrchr(cpathname, sepchar))) {

  What steps will reproduce the problem? 1. Try running psioseg_reg using Windows. It calls convertSegmentedPagesToPS("/tmp/junkimagedir", "/tmp/junkmaskdir", 2.0, 0.15, 190, 0, 0, "junkfile.ps") which will eventually fail. What is the expected output? What do you see instead? I expect to be able to split paths. Instead the entire path is returned (or nothing). What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. Change if ((lastslash = strrchr(cpathname, '/'))) { to: if ((lastslash = strrchr(cpathname, sepchar))) {
• Dec 01, 2009

  issue 16 (genPathname() in utils.c doesn't correctly handle dir with w...) reported by tomp2010   -   What steps will reproduce the problem? 1. Try running psioseg_reg using Windows. It calls convertSegmentedPagesToPS("/tmp/junkimagedir", "/tmp/junkmaskdir", 2.0, 0.15, 190, 0, 0, "junkfile.ps") which will eventually fail. What is the expected output? What do you see instead? I expect to be able to build concatenated paths. Instead paths with / and \ are created. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. I'm not sure the following is the best solution but it works. Perhaps more thought needs to be done on the whole annoying Windows pathsep issue rather than piecemeal fixing issues after the fact? genPathname() should be changed to: genPathname(const char *dir, const char *fname) { char *charbuf; l_int32 dirlen, namelen; char *tmpDirname; PROCNAME("genPathname"); if (!dir) return (char *)ERROR_PTR("dir not defined", procName, NULL); if (!fname) return (char *)ERROR_PTR("fname not defined", procName, NULL); dirlen = strlen(dir); namelen = strlen(fname); if ((charbuf = (char *)CALLOC(dirlen + namelen + 10, sizeof(char))) == NULL) return (char *)ERROR_PTR("charbuf not made", procName, NULL); #if COMPILER_MSVC if (stringFindSubstr(dir, "/", NULL) > 0) { tmpDirname = stringReplaceEachSubstr(dir, "/", "\\", NULL); strcpy(charbuf, tmpDirname); FREE(tmpDirname); } else { strcpy(charbuf, dir); } #else strcpy(charbuf, dir); #endif if (charbuf[dirlen - 1] != sepchar) { charbuf[dirlen] = sepchar; charbuf[dirlen+1] = '\0'; } strcat(charbuf, fname); return charbuf; }

  What steps will reproduce the problem? 1. Try running psioseg_reg using Windows. It calls convertSegmentedPagesToPS("/tmp/junkimagedir", "/tmp/junkmaskdir", 2.0, 0.15, 190, 0, 0, "junkfile.ps") which will eventually fail. What is the expected output? What do you see instead? I expect to be able to build concatenated paths. Instead paths with / and \ are created. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. I'm not sure the following is the best solution but it works. Perhaps more thought needs to be done on the whole annoying Windows pathsep issue rather than piecemeal fixing issues after the fact? genPathname() should be changed to: genPathname(const char *dir, const char *fname) { char *charbuf; l_int32 dirlen, namelen; char *tmpDirname; PROCNAME("genPathname"); if (!dir) return (char *)ERROR_PTR("dir not defined", procName, NULL); if (!fname) return (char *)ERROR_PTR("fname not defined", procName, NULL); dirlen = strlen(dir); namelen = strlen(fname); if ((charbuf = (char *)CALLOC(dirlen + namelen + 10, sizeof(char))) == NULL) return (char *)ERROR_PTR("charbuf not made", procName, NULL); #if COMPILER_MSVC if (stringFindSubstr(dir, "/", NULL) > 0) { tmpDirname = stringReplaceEachSubstr(dir, "/", "\\", NULL); strcpy(charbuf, tmpDirname); FREE(tmpDirname); } else { strcpy(charbuf, dir); } #else strcpy(charbuf, dir); #endif if (charbuf[dirlen - 1] != sepchar) { charbuf[dirlen] = sepchar; charbuf[dirlen+1] = '\0'; } strcat(charbuf, fname); return charbuf; }
• Dec 01, 2009

  issue 15 (stringFindSubstr() in utils.c doesn't properly handle NULL p...) changed by dan.bloomberg   -   Exactly. Dereferencing a null ptr! Thanks for finding this careless mistake.

  Status: Fixed

  Owner: dan.bloomberg

  Exactly. Dereferencing a null ptr! Thanks for finding this careless mistake.

  Status: Fixed

  Owner: dan.bloomberg
• Dec 01, 2009

  issue 15 (stringFindSubstr() in utils.c doesn't properly handle NULL p...) reported by tomp2010   -   What steps will reproduce the problem? 1. pass NULL ploc argument to stringFindSubstr(). What is the expected output? What do you see instead? I expect the ploc argument to be optional. Instead program crashes. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. utils.c line 948 should be changed from: if (*ploc) to: if (ploc)

  What steps will reproduce the problem? 1. pass NULL ploc argument to stringFindSubstr(). What is the expected output? What do you see instead? I expect the ploc argument to be optional. Instead program crashes. What version of the product are you using? On what operating system? leptonlib-1.63. Microsoft Visual Studio 2008 SP1 with latest updates also applied. Windows XP Pro SP3. Please provide any additional information below. utils.c line 948 should be changed from: if (*ploc) to: if (ploc)
• Nov 25, 2009

  issue 14 (pixDisplay() doesn't work under Windows) commented on by dbloomb...@google.com   -   It looks fine. When you've finished the windows readme (including the build/link parts) I'll modify it for the current status of linux display. We can select the default viewer in writefile.c depending on the compiler flag. And if you wish, you get your name on the windows readme. There's a precedent for this, and I prefer to give this credit -- for example, see Brockman's documentation file: http://leptonica.org/highlevel.html

  It looks fine. When you've finished the windows readme (including the build/link parts) I'll modify it for the current status of linux display. We can select the default viewer in writefile.c depending on the compiler flag. And if you wish, you get your name on the windows readme. There's a precedent for this, and I prefer to give this credit -- for example, see Brockman's documentation file: http://leptonica.org/highlevel.html
• Nov 24, 2009

  issue 13 (adaptnorm_reg.c fails because missing test file lighttext.jp...) changed by dan.bloomberg   -   Oops. Here's the file. It will be included with 1.64.

  Status: Accepted

  Owner: dan.bloomberg

  Oops. Here's the file. It will be included with 1.64.

  Status: Accepted

  Owner: dan.bloomberg
• Nov 24, 2009

  issue 14 (pixDisplay() doesn't work under Windows) commented on by tomp2010   -   I guess it's alright if you can call a function to change the viewer (rather than editing writefile.c). But by default, under Windows, it should use IrfanView. Otherwise, in order to try any of the prog directory programs that use pixDisplay(), you'd first have to edit the program. Any new users wouldn't realize why nothing was being displayed. Attached is an extraction of the relevant part of my upcoming README.

  I guess it's alright if you can call a function to change the viewer (rather than editing writefile.c). But by default, under Windows, it should use IrfanView. Otherwise, in order to try any of the prog directory programs that use pixDisplay(), you'd first have to edit the program. Any new users wouldn't realize why nothing was being displayed. Attached is an extraction of the relevant part of my upcoming README.
• Nov 24, 2009

  issue 14 (pixDisplay() doesn't work under Windows) changed by dan.bloomberg   -   Thanks again! For 1.64 I've already modified pixDisplay*() to take one of xv, xli and xzgv, none of which are available on windows. So adding IrfanView for windows is an excellent and timely addition to the mix. There will be a function that you invoke to choose the current default viewer.

  Status: Started

  Owner: dan.bloomberg

  Thanks again! For 1.64 I've already modified pixDisplay*() to take one of xv, xli and xzgv, none of which are available on windows. So adding IrfanView for windows is an excellent and timely addition to the mix. There will be a function that you invoke to choose the current default viewer.

  Status: Started

  Owner: dan.bloomberg