"Cannot open raw file for reading"

[danmcb]

I built the code on a debian virtual machine, and I am using some raw files that I captured myself as input.

It seems to work OK - a bit slow but this is a VM, and some of that might be the SDL window. But once it has decoded the file it then tries to open a couple of "raw" files, one for reading, one for writing. and then core dumps because one files does not exist. (I see the message "I am at page 5" right before this.)

What is it trying to do here? it has decoded the information, why is it looking for another file to read?

[RWAP]

The SDL window does of course slow down conversion - but we are hoping others can spot ways to improve the speed of the conversion.

The conversion from bitmap to PNG and then from PNG to PDF is where the real bottle neck is (although ensure that you have imageMode set to 1, so that the PDF creation takes place in memory rather than via the file system).

Ideally it would be nice to see if writing any text direct to the PDF (using freeware PDF fonts) helped speed up things (as the conversion to PNG and PNG to PDF should have that much less information to cope with), or is there a tool to convert the bitmap direct to PDF I wonder?

But once it has decoded the file it then tries to open a couple of "raw" files, one for reading, one for writing. and then core dumps because one files does not exist. (I see the message "I am at page 5" right before this.)

What is it trying to do here? it has decoded the information, why is it looking for another file to read?

The PrinterToPDF is based on our own code for the Retro-Printer Module which is not based on a file input - but actually on data received over a centronics port connection. The software therefore stores the captured data to a .eps file for example and then loops around to wait for the next bit of captured data.

Where do you get the core dump?

[danmcb]

in function convertUnixWinMac( ... ) - basically it is trying to open a file for reading which does not exist. I'm not sure why - probably a configuration thing.

But for my purposes this is not so important. Because I would like to use the code on a microcontroller, I need to strip the code down so that all I have left is a module to convert an in-memory capture file (which I already have) to a bitmap which I can then convert to png by other means that do not use libpng. I can also lose all the colour stuff, as my image is BW.

Looking at the code - I see a couple of arrays - *printermemory and *imagememory - which of those is the decoded bitmap?

thanks!

Daniel

[RWAP]

in function convertUnixWinMac( ... ) - basically it is trying to open a file for reading which does not exist. I'm not sure why - probably a configuration thing.

This is the conversion file to convert line endings in an extracted raw file (to swap between CHR(10) and CHR(10)+CHR(12) for Windows).

Ensure that

Code: Select all

outputFormatText = 0

and then this function will be disabled.

But for my purposes this is not so important. Because I would like to use the code on a microcontroller, I need to strip the code down so that all I have left is a module to convert an in-memory capture file (which I already have) to a bitmap which I can then convert to png by other means that do not use libpng. I can also lose all the colour stuff, as my image is BW.

Looking at the code - I see a couple of arrays - *printermemory and *imagememory - which of those is the decoded bitmap?

The decoded bitmap is stored in *printermemory.

*imagememory is used for storing the PNG version

I have added some more notes on this to the printerconvert.c code on GitHub.

[danmcb]

thank you. what does *seedrow do? is that for compression?

By the way there was a place where it core dumped because seedrow and imagememory were pointing to the same array, but the code tried to free them both. In my code I just added a test to prevent that.

[RWAP]

thank you. what does *seedrow do? is that for compression?

Yes - this is for the ESC/P2 commands ESC.2 and ESC.3 (TIFF and Delta row compression) where the image is compressed for 720dpi printing.
Basically a 'seedrow' is created for the first line of the image - subsequent lines then only need specify which bits have changed.

For colour printing, the ESC/P2 format uses a seed row for each of the 4 colours (CMYK).

By the way there was a place where it core dumped because seedrow and imagememory were pointing to the same array, but the code tried to free them both. In my code I just added a test to prevent that.

Hmm - this needs to be copied across to the github - can you post details of the change please.

[danmcb]

I'm afraid that that is a bit hard to do, as my version of the code is now very different. I cleaned up a lot of GOTO's, putting things into functions, and in fact removed a lot of stuff that is not needed at all for my project. You'd hardly recognise my latest version except for a few core functions.

But if you search your code you'll see that under some circumstances these two pointers point to the same object in memory. All you really need to do is test the pointer before you call free on it I think.

[RWAP]

OK thanks - I have made a small change to the original PrinterToPDF source code.

It will be interesting to see your finished version of the code - please share any potential speed improvements you have spotted.