UPD Mail Archive: Re: UPD> Point Of Sale printers.

Re: UPD> Point Of Sale printers.

From: Norbert Schade (norbertschade@oaktech.com)
Date: Mon Sep 10 2001 - 18:23:30 EDT

  • Next message: Norbert Schade: "UPD> some editing"

    it's some time ago that I dealt with POS printers.
    But some problems sound familiar.

    No, we haven't thought about those printers in UPDF in detail.
    I guess we could more or less solve the media size.
    Assuming we only print on the left roll, I propose a width of 2.534 inch (x
    90 = 228.06 pixel), as that would provide 228 pixel after any correct
    rounding. 2.54 inch may result in 229 pixels after rounding. Any value below
    2.534 inch (like 2.5334 or 2.53334, etc.) would be correct as well, but not
    result in a different number of pixels.
    With the length it's the old problem with rolls. Operating systems like MS
    Windows like to know the length upfront. So my feeling is that the only way
    to go is to define quite a long size (be sure that traditional solutions
    used in OS's or apps can report it with 16 bit; 15 bit would even be safer).
    But with that narrow width you should be on the safe side with 12 inch
    length (one of the guidelines I used was to be able to print any character
    size on one page, where the width kind of limits the height. You'd come to a
    virtual but reasonable size of custom_pos_2.534x12in .
    You'd need something to find out if a page is the last page - as you would
    need for any kind of roll handling in these OS's. And then you'd need a flag
    to tell to stop after printing the last line of data on the last page and
    not feed until page end. We do not have such a flag yet. That would be a
    media source specific attribute I guess.
    The resolution values of 90 x 72 dpi work even fine with virtual units of
    7200. Not a problem.
    Now the real problem might be the journal. I'd expect a special application
    to position everything properly for the double-size paper (you wouldn't
    print your letter here).
    Being afraid that the journal is not printed by a simple copy command, the
    driver would have to print every data twice (please confirm). That's
    certainly something we haven't thought about - and will not in short-term.

    That's my two cents. Perhaps somebody else has a better idea.
    Norbert Schade
    ----- Original Message -----
    From: "Mark Hamzy" <hamzy@us.ibm.com>
    To: <upd@pwg.org>
    Sent: Monday, September 10, 2001 5:17 PM
    Subject: UPD> Point Of Sale printers.

    > Hello,
    > Have you considered Point Of Sale (POS) printers in UPDF?
    > I am looking at a technical reference for one right now and it has an
    > interesting feature.
    > There are two rolls of paper in this printer and you can print to them in
    > the following
    > ways:
    > - Print only on the left roll. This is torn off and given to the
    > customer.
    > - Print on the left roll and print a duplicate to the right roll.
    > This roll is called a "journal" roll.
    > - Image the form size to be twice the size of the roll. Any print
    > data that does not fit onto
    > the left roll is overflowed and printed on the right roll. This
    > way you can print two
    > different things at one time.
    > Also, the roll paper is 228 pels wide at 90 dpi. This translates into a
    > form size of 2.5333333333333333333333333333333... inches. The length of
    > the form can be between 1/72 of an inch to an infinite length.
    > Mark
    > Take a look at the Linux Omni printer driver at
    > http://www.ibm.com/linux/ltc/projects/omni/

    This archive was generated by hypermail 2b29 : Mon Sep 10 2001 - 18:23:43 EDT