Rich M

OK sorry for the typo. However, the output is really odd - as it suggests the page is not getting set to white with erasepage() - called in line 408...

Hmm ... pixelColour does of course depend on what colours you are using - bit 0 = black, bit 1= magenta, bit 2 = cyan, bit 3 = voilet, bit...

Of course, it could also be a bug in the new CMYK lookup method for colour mixing - is the problem fixed by altering line 186 to read: `int colourMixMethod...

Nothing that I can find in the history of the code - that is what is confusing! Did you try the change to the lookupColour() function?

If you go to : https://github.com/RWAP/PrinterToPDF/blob/master/PrinterConvert.c You can then click on history and will see the various update history on github. Click on the title of one (say "Improvements to...

OK the black background is now fixed by changing line 471 from : `int pixelColour;` to read: `unsigned char pixelColour;` Not quite sure why this was needed on some versions...

Possibly the converted png resolution might have a bearing - we tell it to use 720dpi, but obviously libpng is not using that exact figure... However, at 720dpi, A4 paper...

Thankfully - it looks fairly simple - see https://github.com/libharu/libharu/wiki/API:-Graphics#HPDF_Page_TextOut If we use the HPDF_Page_TextRext() function, we can also support printer justification of the text if required (albeit based on a...

The main issues around this are: a) Handling of the various EPSON character sets and fonts which contain many non-standard characters b) How to handle double height (but single width...

Only if someone creates it - that was one of the reasons for releasing this version as open source. I don't have time or experience of converting C programs to...