Scan2PDF

[Fangbeast]

At the end of the proc, the imagenumber and memory never get freed as the proc exits before that. That's one thing that should get fixed. It was a weak moment, sorry about that.

Not your fault, I figured that out myself!

Thinking outside the box for a moment, if the procedure works in one codebase and not another, it would be time to look at what the new codebase is doing and how it would affect what's existing.

Wish I knew. It works included or inline in the code above (SmegScan) without a problem. In the larger program, inline or included, it dies at that ImageNumber not initialised.

That's it, I am going to the home for feeble old bunny rabbits:):)

[IdeasVacuum]

Using the latest Scan2pdf.pb and EZTwain.pbi code posted, scanning crashes (in debug mode):

EZTwain.pbi : Line 458: ProcedureReturn SaveImage(ImageNumber,sPNGFileName,#PB_ImagePlugin_PNG)

[ERROR] The specified #Image is not initialised.

Edit: I'm using PB4.61 on WinXP 32bit. In EZTwain.pbi, Procedure hkTWAIN_WriteNativeToPNG, Line 455, the buffer is saved to a bmp file - that file is large, as expected, (scan of A4 sheet) but un-readable.

Also, just before the bmp save, some memory arithmetic is performed - looks fine for 32bit but possibly would be out on 64bit (how long is a long?).

[harkon]

Solved that problem. If used in a unicode project the string to create the header for the bitmap creates a bad header.

replace
PokeS(*BMPBuffer,"BM")
with
PokeW(*BMPBuffer, $42)
PokeW(*BMPBuffer+1, $4D)

where the bmp header is written in EZTwain.pbi

Once we found the problem it's obvious as to why PokeS() won't work in unicode. That's also why the BMP was unreadable, the header was broken.

Edit: we also discovered that PB4.60 and the ImagePlugin for PNG definitely did not like monochrome BMPs, but the JPG plugin didn't care. Of course the resulting PDF is much larger due to the fact that JPGs are all 24 bit anyway. I think there's a problem with the PNG plugin, and I have no idea if this has been fixed in 4.61 or if more problems have been created. Take a look at the bmp that's created and if it's fine then you'll know. Also post back if you know for sure monochrome conversions are working in 4.61

[Fangbeast]

Thanks for all your hard work Harkon, this stuff has come in very useful lately.

[IdeasVacuum]

Absolutely Magic stuff, very useful indeed. However, I was getting A4 images the size of a postage stamp
In the Procedure hkTWAIN_AquireToPDF, pdf_Image(sTempFileName, 0, 0, 8.5, 0) should be pdf_Image(sTempFileName, 0, 0, 210) for metric A4 page.

Also, same procedure, there is an elaborate naming of a temp file that gets deleted anyway..

[harkon]

A lot o the elaborate naming of the temp files that get deleted anyway was to manage having multiple pages. There is probably way better ways to do this, and much of what I was doing in initially debugging this stuck around as well. Feel free to just take what you need

Edit: BTW I never allowed for different page sizes as we just don't see A4 size here. This would be a pretty good enhancement.

[Fangbeast]

Harkon, if you are still around, I need some help.

Just fired up the scan program I based on your code back in 2012 and I am running PB 5.43(LTS) X86 and came upon this error:

POLINK: error: Unresolved external symbol 'SYS_CopyString'.
POLINK: fatal error: 1 unresolved external(s).

So I can no longer run the code and don't remember which version of PB this worked with. This is not definately something that I can solve.

[harkon]

Good to hear from you.

I haven't been as active here as I would have liked. I work mostly in Linux these days and don't have nearly as much time as I'd like for developing in PB.

The PurePDF lib seemed to have a few issues in newer versions of PB, so I migrated the lib to an include file and made the necessary changes. It will compile on V5.24 (x86) now. The original code was for version 4.41 as I recall.

You can get my updated code here;
https://dl.dropboxusercontent.com/u/653 ... Source.zip

Oh, and don't laugh at the code ... LOL. It still works for me and I use it at least a couple of times per week. I have not been able to get this to compile for X64 yet. As I have not yet had the need, I'm focusing on other things.

If you have any questions, please feel free to post back. I get notices via email so I'll know you posted.

[Fangbeast]

Harkon, thanks for this. I've altered SmegScan with your changes and it works a treat.

Now I need to 'massage' your code into my home inventory program. I need to keep the original picture *before* it is converted to a PDF in case one of my inventory items doesn't have a picture.

Seems to create a bmp and a png (Well, my code does )

Got some fixing to do as the pdf can't be found anywhere heheheheh.

[harkon]

In my code in the hkTWAIN_AquireToPDF() proc there is;

hkTWAIN_WriteNativeToPNG(hdib, sTempFileName)
hkTWAIN_WriteNativeToJPG(hdib, sTempFileName,7)

I commented out the .PNG creation in favor of .JPG because .JPGs are generally smaller. BMP is the intermediate format. The hkTWAIN procs (in the EZTWAIN.pbi include file) are my addition to the include, they weren't ported but added

I am really glad your code is working out. Let me know if you have any questions I might be able to help out with.

Cheers!

[Fangbeast]

I worked out where the pdf was being dumped as I had an error in my directory path creation statement.

What I would love to see (because I am a greedy old bugger!) would be that as I scan, the image gadget gets updated line by line.

But then, not even my canon scanner software does that.

I do have to figure out a bottleneck somewhere between the scan and the conversion as the form goes into "Not responding" when accidentally clicked but other than that, it is perfect.

Will be massaging code next week:):)

I thank you muchly!

[harkon]

Good info, thanks. As far as I knwo the scan happens and then data is transferred. I don't know if that is something that is scanner dependent or if that's just the way the EZTwain DLL works. It's people way above my pay scale that know about stuff like that ... LOL

[Fangbeast]

Ah well, I know what to do with it now and that's good.

Will be using the code in the home inventory to produce just an image for the item picture (No need for a pdf there) and then my document manager where I do need a PDF.

For the inventory, it will be single image so I won't need to show an interface. For the document manager, there may be more than one page so I will show the interface.

It's a win-win situation for me thanks to your code.

[harkon]

I'm happy you found it useful.

[Fangbeast]

I'm happy you found it useful.

Sure did. Got it integrated into my inventory program to scan and load the image into the imagegadget on the data form. Just a few path and naming things to fix.

My Canonscan software (not the driver) also crops the image to the scanned document edges so I will have to ask the graphics experts if there is a way to do edge recognition on an image to do this.

It's all looking good.