Re: [Quexf-discuss] Importing forms and banding

Hello Martin,
1.
The view formboxesgroupsbelow90 is not be required any more so this
warning can be safely ignored. The quexf.sql file creates real tables of
each view and then drops them and over writes them with a view at the
end of the statement. It does this to avoid any dependency problems. I
will remove it in the next bug fix version.
2.
The constants in functions.image.php are set to handle a 300DPI
monochrome (1 bit per pixel) file exported by Ghostscript.
Range checking should not be required, as each function that calls
imagecolorat() is passed an area to read on the image that should exist.
I think the issue here may be that the system assumes that the scanned
image will be a standard A4 page, and therefore at 300DPI will be
2480x3508 pixels
Instead of changing the constants/ranges in functions.image.php - please
try the following modifications:
functions/functions.import.php approx line 338:
exec(GS_BIN . " -sDEVICE=pngmono -r300 -sOutputFile=$tmp%d.png -dNOPAUSE
-dBATCH $filename");
to:
exec(GS_BIN . " -sDEVICE=pngmono -r300 -sPAPERSIZE=a4 -dPDFFitPage
-sOutputFile=$tmp%d.png -dNOPAUSE -dBATCH $filename");
admin/new.php approx line 46:
exec(GS_BIN . " -sDEVICE=pngmono -r300 -sOutputFile=$tmp%d.png -dNOPAUSE
-dBATCH $filename");
to:
exec(GS_BIN . " -sDEVICE=pngmono -r300 -sPAPERSIZE=a4 -dPDFFitPage
-sOutputFile=$tmp%d.png -dNOPAUSE -dBATCH $filename");
If you could also send through the PDF file you are using directly to me
that would be great.
The recommended scanner setting is for Monochrome (1bit), 300DPI, A4.
3.
I think the issues you have with banding are due to the imported
size/type of images - try again once you have made the changes above.
PNG's are dumped directly into a blob in the database, which can then be
read using php's imagecreatefromstring() function - there shouldn't be a
need to use adodb's functions.
I hope we can get to the bottom of these problems.
Regards,
Adam Zammit
Martin Smith wrote:
> Hello folks (I'm back :),
>
> I'm working on building a form and getting it working with queXF, and
> I've encountered a few troubles; I'm hoping perhaps someone has some
> suggestions or comments on how they use queXF (i.e. what works).
>
> Here's my list:
>
> 1. The data script database/quexf.sql has a warning with MySQL 5.0.54,
> specifically about "Unknown table 'formboxesgroupsbelow90'" when it
> tries to drop a view, if it exists, before creating it. Seemed weird,
> but overall didn't cause any problems as I always ran the script on an
> empty database.
>
> 2. functions/functions.image.php -- there's all kinds of constants in
> this file. I'm not sure they work with my images, and even worse, there
> is some missing range checking, so they don't just fail to find lines,
> they actually spit out errors. This biggest offender was
> "imagecolorat($image, $x, $y);" which I had to replace with
> "imragecolorat($image, min($x,imagesx($image)-1),
> min($y,imagesy($image)-1));". Once I checked ranges, it failed to find
> registration marks for cropping, but at least it didn't entirely blow up
> :).
>
> 3. admin/band.php:233 -- when I try to band a scanned PDF, I get all
> kinds of failures about not being able to pull the PNG data out of the
> database, e.g. "gd-png: fatal libpng error: Read Error: truncated data",
> "gd-png error: setjmp returns error condition", "Passed data is not in
> 'PNG' format". But showpage.php has no trouble with it -- I only get
> errors once I've selected a field box. Am I scanning at the wrong
> resolution or otherwise producing a file that GD can't compose with the
> red field indicator box? If I use the cleanly generated empty/blank PDF,
> it works great. When I use a higher quality scan, it can't find the
> barcode. When I use the lower quality scan, it breaks on the PDF images
> when banding (when it tried to alpha overlay the red boxes, I think).
>
> Overall, the storage mechanism for the PNGs looks like it should be
> using ADOdb's updateBlob(), and maybe that is causing some of my
> problems, though I can't figure out why cleanly generated Apache FOP
> PDFs work, and my scanned one blows up *only* once I select a field (...
> is it possible the image inside the scanned PDF isn't PNG, and the
> conversion to PNG fails? or I convert at a different dpi? or gd fails
> the overlay?).
>
> Let me know if I can send anyone the PDF I'm using, or if there's a
> recommended scanner setting (dpi, size, etc) for this kind of thing.
>
> Thanks,
>
> Martin Smith, Systems Developer
> martins@...
> Bureau of Economic and Business Research
> University of Florida
> (352) 392-0171 Ext. 221
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Quexf-discuss mailing list
> Quexf-discuss@...
> https://lists.sourceforge.net/lists/listinfo/quexf-discuss
>
>
--
Adam Zammit, Research Fellow in Survey Technology
Deakin University 221 Burwood Hwy, Burwood Australia.
Phone: 03 9251 7290 International: +61 3 9251 7290
Fax: 03 9244 6370 International: +61 3 9244 6370
Email: adam.zammit@...
Website: http://www.deakin.edu.au/buslaw/dcarf/
Deakin University CRICOS Provider Code 00113B (Vic)
Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.
Deakin University does not warrant that this email and any attachments are error or virus free.

Thread view

Hello folks (I'm back :),
I'm working on building a form and getting it working with queXF, and
I've encountered a few troubles; I'm hoping perhaps someone has some
suggestions or comments on how they use queXF (i.e. what works).
Here's my list:
1. The data script database/quexf.sql has a warning with MySQL 5.0.54,
specifically about "Unknown table 'formboxesgroupsbelow90'" when it
tries to drop a view, if it exists, before creating it. Seemed weird,
but overall didn't cause any problems as I always ran the script on an
empty database.
2. functions/functions.image.php -- there's all kinds of constants in
this file. I'm not sure they work with my images, and even worse, there
is some missing range checking, so they don't just fail to find lines,
they actually spit out errors. This biggest offender was
"imagecolorat($image, $x, $y);" which I had to replace with
"imragecolorat($image, min($x,imagesx($image)-1),
min($y,imagesy($image)-1));". Once I checked ranges, it failed to find
registration marks for cropping, but at least it didn't entirely blow up
:).
3. admin/band.php:233 -- when I try to band a scanned PDF, I get all
kinds of failures about not being able to pull the PNG data out of the
database, e.g. "gd-png: fatal libpng error: Read Error: truncated data",
"gd-png error: setjmp returns error condition", "Passed data is not in
'PNG' format". But showpage.php has no trouble with it -- I only get
errors once I've selected a field box. Am I scanning at the wrong
resolution or otherwise producing a file that GD can't compose with the
red field indicator box? If I use the cleanly generated empty/blank PDF,
it works great. When I use a higher quality scan, it can't find the
barcode. When I use the lower quality scan, it breaks on the PDF images
when banding (when it tried to alpha overlay the red boxes, I think).
Overall, the storage mechanism for the PNGs looks like it should be
using ADOdb's updateBlob(), and maybe that is causing some of my
problems, though I can't figure out why cleanly generated Apache FOP
PDFs work, and my scanned one blows up *only* once I select a field (...
is it possible the image inside the scanned PDF isn't PNG, and the
conversion to PNG fails? or I convert at a different dpi? or gd fails
the overlay?).
Let me know if I can send anyone the PDF I'm using, or if there's a
recommended scanner setting (dpi, size, etc) for this kind of thing.
Thanks,
Martin Smith, Systems Developer
martins@...
Bureau of Economic and Business Research
University of Florida
(352) 392-0171 Ext. 221

Hello Martin,
1.
The view formboxesgroupsbelow90 is not be required any more so this
warning can be safely ignored. The quexf.sql file creates real tables of
each view and then drops them and over writes them with a view at the
end of the statement. It does this to avoid any dependency problems. I
will remove it in the next bug fix version.
2.
The constants in functions.image.php are set to handle a 300DPI
monochrome (1 bit per pixel) file exported by Ghostscript.
Range checking should not be required, as each function that calls
imagecolorat() is passed an area to read on the image that should exist.
I think the issue here may be that the system assumes that the scanned
image will be a standard A4 page, and therefore at 300DPI will be
2480x3508 pixels
Instead of changing the constants/ranges in functions.image.php - please
try the following modifications:
functions/functions.import.php approx line 338:
exec(GS_BIN . " -sDEVICE=pngmono -r300 -sOutputFile=$tmp%d.png -dNOPAUSE
-dBATCH $filename");
to:
exec(GS_BIN . " -sDEVICE=pngmono -r300 -sPAPERSIZE=a4 -dPDFFitPage
-sOutputFile=$tmp%d.png -dNOPAUSE -dBATCH $filename");
admin/new.php approx line 46:
exec(GS_BIN . " -sDEVICE=pngmono -r300 -sOutputFile=$tmp%d.png -dNOPAUSE
-dBATCH $filename");
to:
exec(GS_BIN . " -sDEVICE=pngmono -r300 -sPAPERSIZE=a4 -dPDFFitPage
-sOutputFile=$tmp%d.png -dNOPAUSE -dBATCH $filename");
If you could also send through the PDF file you are using directly to me
that would be great.
The recommended scanner setting is for Monochrome (1bit), 300DPI, A4.
3.
I think the issues you have with banding are due to the imported
size/type of images - try again once you have made the changes above.
PNG's are dumped directly into a blob in the database, which can then be
read using php's imagecreatefromstring() function - there shouldn't be a
need to use adodb's functions.
I hope we can get to the bottom of these problems.
Regards,
Adam Zammit
Martin Smith wrote:
> Hello folks (I'm back :),
>
> I'm working on building a form and getting it working with queXF, and
> I've encountered a few troubles; I'm hoping perhaps someone has some
> suggestions or comments on how they use queXF (i.e. what works).
>
> Here's my list:
>
> 1. The data script database/quexf.sql has a warning with MySQL 5.0.54,
> specifically about "Unknown table 'formboxesgroupsbelow90'" when it
> tries to drop a view, if it exists, before creating it. Seemed weird,
> but overall didn't cause any problems as I always ran the script on an
> empty database.
>
> 2. functions/functions.image.php -- there's all kinds of constants in
> this file. I'm not sure they work with my images, and even worse, there
> is some missing range checking, so they don't just fail to find lines,
> they actually spit out errors. This biggest offender was
> "imagecolorat($image, $x, $y);" which I had to replace with
> "imragecolorat($image, min($x,imagesx($image)-1),
> min($y,imagesy($image)-1));". Once I checked ranges, it failed to find
> registration marks for cropping, but at least it didn't entirely blow up
> :).
>
> 3. admin/band.php:233 -- when I try to band a scanned PDF, I get all
> kinds of failures about not being able to pull the PNG data out of the
> database, e.g. "gd-png: fatal libpng error: Read Error: truncated data",
> "gd-png error: setjmp returns error condition", "Passed data is not in
> 'PNG' format". But showpage.php has no trouble with it -- I only get
> errors once I've selected a field box. Am I scanning at the wrong
> resolution or otherwise producing a file that GD can't compose with the
> red field indicator box? If I use the cleanly generated empty/blank PDF,
> it works great. When I use a higher quality scan, it can't find the
> barcode. When I use the lower quality scan, it breaks on the PDF images
> when banding (when it tried to alpha overlay the red boxes, I think).
>
> Overall, the storage mechanism for the PNGs looks like it should be
> using ADOdb's updateBlob(), and maybe that is causing some of my
> problems, though I can't figure out why cleanly generated Apache FOP
> PDFs work, and my scanned one blows up *only* once I select a field (...
> is it possible the image inside the scanned PDF isn't PNG, and the
> conversion to PNG fails? or I convert at a different dpi? or gd fails
> the overlay?).
>
> Let me know if I can send anyone the PDF I'm using, or if there's a
> recommended scanner setting (dpi, size, etc) for this kind of thing.
>
> Thanks,
>
> Martin Smith, Systems Developer
> martins@...
> Bureau of Economic and Business Research
> University of Florida
> (352) 392-0171 Ext. 221
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Quexf-discuss mailing list
> Quexf-discuss@...
> https://lists.sourceforge.net/lists/listinfo/quexf-discuss
>
>
--
Adam Zammit, Research Fellow in Survey Technology
Deakin University 221 Burwood Hwy, Burwood Australia.
Phone: 03 9251 7290 International: +61 3 9251 7290
Fax: 03 9244 6370 International: +61 3 9244 6370
Email: adam.zammit@...
Website: http://www.deakin.edu.au/buslaw/dcarf/
Deakin University CRICOS Provider Code 00113B (Vic)
Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.
Deakin University does not warrant that this email and any attachments are error or virus free.