Printer Emulation..(ie ESC P printer emulation)

[alex_farlie]

Do any of the current BBC Micro emulators support "printer" Emulation?

Most software of the BBC micro era was written to allow for the use of Epson style control sequences, via VDU2..

Is a 'virtual' printer for the BBC micro emulators feasible so I can use old packages so that I can print from old software to "image", "PDF" or an OS supported printer mechanism without needing to change the old software...

[Pernod]

The BBC Micro in MAME supports virtual printers. You create a file for the printer which then collects all output codes to the printer. This works well for text documents, haven't tried any graphics.

[scruss]

I've been looking for something like this for a while. Haven't found anything useful yet. There are numerous commercial (and surprisingly expensive) solutions for commercial companies with ancient workflows

The Retro-Printer project showed promise, but it seems to have stalled. Its backend Epson→PDF software (in the free version, at least) is very limited. I'm a little surprised that no-one has emulated a printer at hardware level (Epsons were mostly Z80-based) with dots on paper as PDF output.

[alex_farlie]

On RISC OS I could use - FX80Emul http://www.sinenomine.co.uk/software/

It's a shame there isn't an equivalent for the BBC Micro emulators...

[Coeus]

In B-Em it is possible to redirect the parallel port to the clipboard:

pp.png (7.99 KiB) Viewed 9864 times

You can then paste that into another application. I have only tried this with text, though. The motivation was to be able, for example, to list a BASIC program and then paste it into a message here. When the parallel port is not directed to the clipboard in this way it drives an emulated DAC (sound).

Output to the serial port is sent to standard output. On Linux one should be able to execute:

Code: Select all

b-em | lp

and then select the serial printer, print something, quit B-Em and have it appear on the real printer. Equally one could redirect to a file:

Code: Select all

b-em > printfile

Unfortunately there is no job control, i.e. there is no way to say "this completes the print job, print this now". This should work in Windows too but I have never tested it. It is a bit clumsy though.

The issue of turning a stream of control codes graphical output is something B-Em does not even try to address. I'll be interested to see what that Retro Printer project has done.

[alex_farlie]

In B-Em it is possible to redirect the parallel port to the clipboard:
pp.png
You can then paste that into another application. I have only tried this with text, though. The motivation was to be able, for example, to list a BASIC program and then paste it into a message here. When the parallel port is not directed to the clipboard in this way it drives an emulated DAC (sound).

Output to the serial port is sent to standard output. On Linux one should be able to execute:

Code: Select all

b-em | lp

and then select the serial printer, print something, quit B-Em and have it appear on the real printer. Equally one could redirect to a file:

Code: Select all

b-em > printfile

Unfortunately there is no job control, i.e. there is no way to say "this completes the print job, print this now". This should work in Windows too but I have never tested it. It is a bit clumsy though.

The issue of turning a stream of control codes graphical output is something B-Em does not even try to address. I'll be interested to see what that Retro Printer project has done.

For PLAIN text , yes...

The issue for me would be the special effects... Like bold an underlining that things like View highlights were for, and the clipboard mode wouldn't cover the Epson style graphics mode which was used for screendumps, and output from tools like early DTP systems...
(Ponders if you could fake some of the text effects by use of suitable font choices to generate other formats... There were some Acorn User programs to convert spooled VDU output to PostScript, and HP-PCL style plotter formats I think...)

[Coeus]

For PLAIN text , yes...

The issue for me would be the special effects... Like bold an underlining that things like View highlights were for, and the clipboard mode wouldn't cover the Epson style graphics mode which was used for screendumps, and output from tools like early DTP systems...
(Ponders if you could fake some of the text effects by use of suitable font choices to generate other formats... There were some Acorn User programs to convert spooled VDU output to PostScript, and HP-PCL style plotter formats I think...)

There is a decision point right there as to whether you want retro look. The RetroPrinter project already mentioned takes the approach of drawing directly into a bitmap, i.e emulating the fonts and pin sizes of the real printers. That bitmap can then be output various ways. Another alternative approach would be to convert the stream into a more modern printer control language, for example something postscript-based. That would provide modern-looking output.

[Coeus]

The Retro-Printer project showed promise, but it seems to have stalled. Its backend Epson→PDF software (in the free version, at least) is very limited.

Limited in what respect? Looking round their website I found the code itself at https://github.com/RWAP/PrinterToPDF and had a look at PrinterConvert.c

I'd prefer that this was more than one module with the actual printer emulation in one module which one can initialise with a particular page size, push bytes into it and get completed bitmaps out again. Such things as timeouts, reading writing files and indeed the choice of the final output format belong outside this module.

But that has nothing to do with the quality or completeness of the emulation. To with have a test case, i.e. either a file containing a suitable ESC/P data stream or a series of steps to get a BBC micro to generate such a stream?

It is also worth noting that the GitHub repository has been forked. I don't know if any the forks are any better as I haven't checked them out yet.

I'm a little surprised that no-one has emulated a printer at hardware level (Epsons were mostly Z80-based) with dots on paper as PDF output.

That does seem more complicated than would be required, though probably an interesting project. In the case of the real hardware, part of the problem is timing the activation of the pins or ink jets to the position of the head.

[sweh]

Check out https://pd.spuddy.org/fs/source/usenet/ ... 0/epsonps/

This is from comp.sources.misc from 1991

Code: Select all

The program epsonps converts epson printer codes from an input file 
to PostScript. It is an excellent ASCII listing printer.
Command line options are provided for auto linefeed, auto carriage return, 
condensed mode, elite mode, output file name, IBM screen dump mode 
and paper type selection.

It is written in C and will compile and run on MS-DOS and Unix.  
A Unix makefile is provided.  
To compile for MS-DOS see the comments in the Unix makefile.

All Epson LX-800 and Star NL-10 codes are recognised except
    1: Download characters <ESC> %, <ESC> &
    2: Alignment <ESC> a
    3: Proportional printing <ESC> p
Most Epson LQ-800 printer codes are recognised.

I have no idea how good or complete it is.

[sweh]

Also, on Linux, there's "escp2topbm" as part of netpbm-progs

Code: Select all

       escp2topbm  reads  an  ESC/P2 printer control stream as input.  It pro-
       duces a PBM image as output.

       escp2topbm filters the raster graphic  content  from  an  Epson  ESC/P2
       printer  control  stream and writes the image it would print as a stan-
       dard (raw) PBM image.

       The input is from the file named by the  printfile  argument,  or  from
       Standard  Input if you don't specify printfile.  The output is to Stan-
       dard Output.

       escp2topbm understands compression modes 0 (uncompressed)  and  1  (RLE
       compressed) in the Epson input stream.

[Coeus]

Ok, so as a little experiment I started B-Em as noted above with the standard output to a file, entered some text into the version of view that comes package with MOS 3.20 on the master:

set the FX800 printer driver, picked serial printer and printed the file:

view2.png (2.11 KiB) Viewed 9818 times

Then I fed it through epsonps as referenced above by sweh and loaded the generated postscript file into ghostscript:

The above does have the bottom of the page cropped off.

Then I compiled PrinterToPDF and fed it into that. After working out it needed the input called Test1.prn I was able to get it to generate this output:

clearly some tweaking is required here.

Finally, I attach a ZIP of relevant files:

• example - the example file for VIEW
• FX800 - a view printer driver for the FX800
• test.prn - the stdout captured from B-Em, i.e. what should have gone to the printer
• test.ps - the output from the epsonps program
• page1.pdf - the output from PrinterToPDF

The .inf filew contain the load/exec adresses for the corresponding file for putting these on a floppy or for use by VDFS.

[Coeus]

Also, on Linux, there's "escp2topbm" as part of netpbm-progs

It turns out this only works if the printer has been switched into graphics mode and a bitmap sent. For text interspersed with escape sequences to control highlighting it complains "no image".

I don't know how useful it is to be able to get graphics by capturing the printer output. Certainly it is a bit of a round-about way to get a screen dump when running in an emulator as the emulator will likely support that feature directly (B-Em does) and even if not the host OS probably does. So it rather depends in there are some interesting programs that print other graphics, for example a DTP package.

[sweh]

At a first glance, the "epsonps" looks OK. Better than I expect! Would be interesting to see how well it handles longer results (eg is the page length correct).

escp2topbm... hmm. Maybe that'd work for something like PageMaker output? Probably would break with multi-pages, though.

[scruss]

Limited in what respect?

Hardly anything I fed to it produced useful output … in addition to zero documentation and misleading build instructions. Doesn't seem worth spending much time on.

[colonel32]

I don’t think the retro printer project has really stalled. Rich is still working on it, and he mentioned it on Facebook the other day.

[Coeus]

I don’t think the retro printer project has really stalled. Rich is still working on it, and he mentioned it on Facebook the other day.

I think the question for us is whether the ESC/P convert will see any updates.

In its current form is not easy to embed into an emulator to receive the printer output. At the core of that is the fact it expects to "pull" the printer characters from some port (or file) while the guest OS will be pushing characters to an emulated port. To make that work needs a second thread and a queue between the two, unless you rely on the OS running it in a separate process with a pipe in between (the Unix approach). In that respect epsonps is much easier to work with because it implements the state machine in a way that can have characters pushed into it.

Beyond the conversion engine itself, file handling etc. seems to make assumptions that are not valid beyond the retroprinter environment and error handing is poor - if you don't meet these expectations it typically core dumps.

Finally, the output from my test run was not very good. That may be something as simple as changing one of the config values.

I probably shan't have any time to spend on this in the next week and a bit.

[alex_farlie]

Also, on Linux, there's "escp2topbm" as part of netpbm-progs

It turns out this only works if the printer has been switched into graphics mode and a bitmap sent. For text interspersed with escape sequences to control highlighting it complains "no image".

I don't know how useful it is to be able to get graphics by capturing the printer output. Certainly it is a bit of a round-about way to get a screen dump when running in an emulator as the emulator will likely support that feature directly (B-Em does) and even if not the host OS probably does. So it rather depends in there are some interesting programs that print other graphics, for example a DTP package.

That was my thinking, I also recall some other word processor ( possibly Folio) used custom fonts that were output using 'graphics' mode..

Designer Castles, which I've mentioned elsewhere certainly used Epson style graphics mode to print it's pieces...
(Wonders if given that the data for those peices was almost certainly on the disc for the program, if it would be possible to decode it to a modern format..)

[scruss]

Just in case anyone is looking for other solutions, today I looked at:

• zub2/dotprint: Produce PDF output out of text files with dot matrix printer escapes. - this was quite dismal. Requires you to convert your old PRN files to UTF-8, and then it will likely fail to make any output.
• dosbox - while not a printer emulator as such, certain forks are supposed to contain very good Epson printer emulations. I did not find any of those forks, or find a way to enable printing.

In a similar vein to Custom Castles, someone's preserved the output from Brøderbund's The Toy Shop. I really should try to get this running on my Apple IIgs, as I have an unused Toy Shop in retail packaging.The VICE C64 emulator has great printing emulation, but Commodore's printers are a little unusual.

So far, then, I haven't found a useful printer emulator. PDF would be an ideal storage format, as it can have an invisible text layer over arbitrary graphics. This might allow the intended text to be included in a readable format while simultaneously retaining the DMP graphics.

[Coeus]

At a first glance, the "epsonps" looks OK. Better than I expect! Would be interesting to see how well it handles longer results (eg is the page length correct).

I did a little more on this and I can get useful multi-page output. Here is a document in View showing the margin commands to set up page length margins etc.

It is necessary to set the page length because View assumes it can simply output the correct number of lines and the printer will automatically end up on the next page. If you get the page length wrong it will end up out-of-sync so a block of blank space that comprises the footer and bottom margins of one page and the top and header margins of the next page will appear in the middle of the page. It would be better if View had an option to say instead of counting the lines of the bottom margin, just send an FF. Anyway where is the first twp pages of output:

Finally, I attach a ZIP with the raw output from view and the Postscript (as well as the above images).

[Coeus]

Also see https://github.com/stardot/b-em/issues/66

[scruss]

I've also just given ESCParser a shot, and it's the best I've tried so far.

Pros:

• handles bitmap graphics;
• includes almost dot-for-dot perfect graphics and text (it includes parts of the ROM of a Russian Epson clone to do this)

Cons:

• text is output as dot patterns, so is completely un-searchable and inaccessible;
• bitmap modes aren't always detected perfectly, resulting in oddly-sized images;
• the output files (PostScript) are huge.

I really think the VICE project might have something to help. They have a Star NL-10 emulator (Epson-compatible) in their source code.

[Coeus]

I've also just given ESCParser a shot, and it's the best I've tried so far.

I think that vindicates only adding the option to send raw printer output to a file in B-Em, at least for now. With various options, none of which is ideal, it is not worth spending the time integrating something and, by so doing, increase the build dependencies at the same time restrict people to once choice of ESC/P converter.

Later, if one is both a clear lead and also cross-platform then it will be worth going back to look at integration.

I also tried compiling ESCParser and it assumes Windows so I have forked it at https://github.com/SteveFosdick/ukncbtl-utils and hacked that to compile on Linux (with g++), hopefully without breaking Windows compatibility.

[Coeus]

Here is a side-by-side comparison of ESCParser mentioned above with epsonps:

It seems ESCParser does not implement bold. It is easy enough if you're generating postscript output and using a normal postscript for as postscript will do it for you. I wonder how the original printers did it. The two options I can think of are increase the force with which the pins hit the ribbon against the paper, or operate the pin twice in a slightly different position to get thicker lines.

[danielj]

Bold would double print with very slight offset as I recall?

d.

[scruss]

PostScript will only do bold for you if you've downloaded the bold variant to the printer and make the switch to that font explicitly. There's no "make this bold" command in PostScript as it ships.

DMPs did emphasis by reprinting the character with a slight shift, as you suspected:

Dot Matrix Bold and Double-Strike

When running at full speed, most pin printers can't print two horizontally adjacent dots: the pin hasn't enough time to return and fire¹. So you can either do:

1. half-speed one-pass bold, where another copy of the letter is printed 0.2 mm to the right of the original;
2. full-speed two-pass double strike, where another copy of the letter is printed 0.17 mm below the original.

Why yes, I am making an OTF font based on a ROM dump from an old Amstrad DMP-2000 …
--
¹: modern pin printers also slant the pin matrix by roughly 3° backwards to compensate for the high forward speed of the print head.

[Coeus]

So after my last message I have been experimenting with graphics output instead so I used the BASIC Mexican Hat program (from the short type-ins thread) to generate an image and then generated the screen dump with the Watford Electronics DUMPOUT ROM with the default EPSON settings.

Here is the side by side output:

On the left is the output from epsonps and on the right is ESCParser.

One of the issues I had was that the printer output from the BBC micro has only CR characters, no LF. This can be solved in epsonps because it has a -L option for auto line feed but there was no such option for ESCParser so I had to hack the source code. The epsonps program initially generated output that was too wide for a virtual piece of A4 paper so I had to hack the "scale" statement in the generated postsript to get it down to size.

[BeebMaster]

I did a little more on this and I can get useful multi-page output. Here is a document in View showing the margin commands to set up page length margins etc.
view.png
It is necessary to set the page length because View assumes it can simply output the correct number of lines and the printer will automatically end up on the next page. If you get the page length wrong it will end up out-of-sync so a block of blank space that comprises the footer and bottom margins of one page and the top and header margins of the next page will appear in the middle of the page. It would be better if View had an option to say instead of counting the lines of the bottom margin, just send an FF. Anyway where is the first twp pages of output:
page1.pngpage2.png

I think the page length needs to be set correctly in any event because the printer doesn't necessarily know what paper size is loaded. For a dot-matrix or daisy-wheel printer, the paper is fed round the barrel, and most of them have a sensor which detects when the end of the page is reached, so the printer doesn't strike the empty barrel (although some do). These printers will commence printing either immediately or after the first line feed, but other types of printer where the paper is held in a tray (such as laser printers) don't print until the whole page has been received (denoted either by receiving a form feed, or if the printer is clever enough, realising that the number of lines received corresponds to the page length and starting the print).

It looks like in the earlier example where a short length PDF page was produced that there might not have been a form feed at the end of the print - I can't see a form feed code in the .prn file of the multi-page document in the zip. The multi-page document is set to print a footer, and has a bottom margin of zero lines, meaning every page will be a full-length page, so it may have paginated correctly "by default". I wonder what happens if you turn off the footer and add a page break somewhere - does that result in a short page in the middle of the PDF?

[Coeus]

It looks like in the earlier example where a short length PDF page was produced that there might not have been a form feed at the end of the print - I can't see a form feed code in the .prn file of the multi-page document in the zip. The multi-page document is set to print a footer, and has a bottom margin of zero lines, meaning every page will be a full-length page, so it may have paginated correctly "by default". I wonder what happens if you turn off the footer and add a page break somewhere - does that result in a short page in the middle of the PDF?

OK, removing the footer and inserting an explicit page break like this:

And then printing and find the point in the file where the forced page break occurs gives this:

So even when view is not finishing the page with the footer it still does not send a form feed character but instead sends CR/LF pairs for however many lines it believes are required to move to the start of the next page.

Going back to your point about setting the page length, I have a vague memory from one of the Epson printers that there were some DIP switches on the printer itself that could be used to set the page length so that if any software did send an FF the printer would do the right thing. Whilst the printer may have been clever enough to avoid printing on an empty barrel it could not sense the perforations where fanfold paper was folded. I think I remember there also being a "top of form" button which could set the printer's internal line counter to zero.

[ThomasHarte]

Why yes, I am making an OTF font based on a ROM dump from an old Amstrad DMP-2000 …

Slight digression, but I had a quick look at what I did in ElectrEm a hundred trillion years ago, and when emulating an FX80-style printer it:

• embeds a Type 3 font directly into the PDF;
• in which it sets up a function to plot a single pin strike (i.e. draw a circle at the pin size); and
• which it then forms each glyph by serialising as a sequence of calls to the pin strike function.

Character forms were taken from Epson documentation. At no point do I recall implementing graphics output, and whatever version of the source eventually made it to GitHub is text only.

As I recall, output was very accurate, with arbitrary zooming and free selection of text for copy/paste, but whatever PDF reader I was using at the time rendered that type of file very, very slowly, even compared to more conventional PDFs. Maybe my PostScript was poor, or maybe nobody really cares to optimise support for PostScript type 3 fonts in their PDF viewers, but either way an ODF rendering sounds a lot smarter. Or even just plain old TTF. I guess each dot will require a little more geometry per quadratic versus cubic Beziers but I suspect you'll get away with a fairly crude approximation of a circle.

I actually remember the implementation being a real hassle, but with hindsight that might just have been the reading-the-documentation cost. The actual code, font tables excluded, is barely more than 400 lines. 400 terrible lines, per my experience and ability at the time, but nevertheless.

It definitely might be worth revisiting, even if I don't expect to hit the stated criteria of being a BBC emulator.

[rwap]

I just came across this and it is an interesting discussion. I am the author behind the software which runs on the RetroPrinter (www.retroprinter.com) and of course the public domain PrinterToPDF (https://github.com/RWAP/PrinterToPDF).

The main reason why we decided that we needed to re-invent the (typewriter) wheel, is because all of the various conversion routines we found on the internet seemed to stick at the ESC/P printer code set and even then not implement every command.

The conversion routine we developed is therefore designed to implement ESC/P2 (including 1440 and 720dpi graphics), including delta row and TIFF graphics compression modes (ESC.2 and ESC.3) mainly as an homage to the fact that my first ever attempt at C was to improve an existing printer driver for the Sinclair QL (ProForma) by adding 720 dpi and delta row / TIFF graphics compression.

The idea of releasing the GPL version of the conversion routine was to create a basis which others could transform into more of a finished product for converting files - but as with many GitHub projects, there are few people who are willing to contribute to the project. It has to make you smile when someone comments "I think the question for us is whether the ESC/P convert will see any updates.".

The answer is yes, of course, if other people want to get involved and contribute to it. If you are going to sit there and wait for me to update the GPL version of the code, then you might be waiting a while, as it has a low priority.

I was surprised by the attempted conversion and comparison with output from the epsonps program, as no-one has reported similar issues and certainly testing the conversion program with a Retro-Printer module attached to a Sinclair QL, the width and heigh of the printed output is correct as per the original code. Perhaps the issue is down to the page size / font density setting or something else...

As for current work - I am ooking to implement some more fonts for the Retro-Printer (supporting the full range of Epson fonts and character tables) - alas there does not seem to be anything suitable on the internet anywhere and Epson cannot assist due to how they claim the fonts are stored in the old inkjet ROMs.

I did of course initially consider using a font to enter the text directly into the generated PDF - but here we have the same issue - there are no suitable fonts which support the full set of international Epson character tables (well none that I can find) and how would you implement double-width and / or double-height printing without it affecting the height / width of the font respectively. Does anyone have any suggestions here - I have never programmed with raster fonts!