Sorry for the late reply... been munged up with 'flu

Well you have 2 choices really - either leave your hardware proprietary and
write your own OS drivers, or write your own printer language interpreter
and use standard HP/Epson/IBM etc drivers.

I've been involved technically in printers for years, though not at the
actual design stage, but can tell you there is a LOT in writing an
emulation, especially if you choose something like PCL. (one of my jobs was
debugging new products before introduction.) Also, these languages are
geared up for specific resolutions - 300/600/1200 dpi for lasers and 240x216
or 360x360 dpi for dot matrix. Not sure about inkjet - I've never dealt with
them.

If you want to print more than bitmapped fonts I would take a look at GDI
(I'm assuming your host will be Windows-based here), and try outputting as a
raster device. I recall that the first mono GDI page printers had just 256k
of RAM, which is not nearly enough for a page buffer, let alone comms
buffering & CPU workspace, so the printers were little more than a real-time
imaging device. The downside is you're tied to a particular OS.

My company also has produced thermal POS printers before now, I'll see if I
can obtain a programming manual for one if you want.

Nick

> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of David VanHorn
> Sent: 28 January 2002 22:51
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [EE]:The internals of printers
>
>
> At 08:57 PM 1/27/02 +0000, Nick Ray wrote:
> >That covers a whole range of topics. Any particular type of printer?
>
> A line thermal printer that I am designing.
>
> >Some printers are raster-only devices, where the fonts are rasterised by
> >Windows (GDI takes care of this I think), others support
> vector-based fonts.
> >The Raw/EMF stuff is merely the spool file format.
>
> I have a raster only engine in the printer already. By that I mean a micro
> that accepts pixel line images, and it's job is to print those in high
> quality, as fast as possible.
>
> I have another engine that is given the job of managing the other systems
> in the printer, and converting "stuff" to pixel line images.
> This design initially started as an ASCII text input printer, and has
> "evolved".
>
> I like the idea of just getting pre-rasterized data from the PC/PDA, that
> certainly means less work for me.
>
> >If you're trying to produce formatted output from an embedded
> system I'd use
> >a high-level language like PostScript which is largely device
> independent,
> >and let the printer worry about where the pixels go. You might find some
> >useful snippets on Don Lancaster's page http://www.tinaja.com/
>
> I wonder about the complexity of this.
> For example, I don't have "pages", my media comes on a roll.
> HP-PCL is another one that's been discussed, and I understand there are
> several variants on both of these systems.
>

>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads