>
> so here is my solution:
> the last line of my groff script is:
> ".tm \\n[nl]"
> This shows me the page length in groff units.
> For convenience I put it in a footer macro.
Does this help…?
.de *pagesize* \" $1 = width, $2 = height
\\!x X papersize=\\$1,\\$2
.ll \\$2u-\\n(.o
.pl \\$1
..
.
.\" A4 portrait
.pagesize 8.3i 11.7i
Page 1
.
.\" A4 landscape
.bp
.pagesize 11.7i 8.3i
Page 2
Note that `\!x X papersize=\\n[length],\\n[width]` needs to appear at the *very
beginning* of a new page, before any output has been emitted (hence the use
of .bp in the snippet above).
Hope this helps. :)
— John
On Fri, 9 Dec 2022 at 19:33, Wim Stockman <wim.stock...@gmail.com> wrote:
> Hi ,
> Thanks Branden for your answer. but it wasn't really what I was looking
> for.
> I found a solution to set the right page length for each ticket.
> Like Deri said it cuts after each print job but I just needed to tell how
> long each ticket is.
>
> so here is my solution:
> the last line of my groff script is:
> ".tm \\n[nl]"
> This shows me the page length in groff units.
> For convenience I put it in a footer macro.
>
> Then in a bash script I have this:
>
> size=$(groff -P-p6.5c,7c -z kasticket.groff 2>&1)
> size=$(echo "scale=2;$size / 28346 + 0.5" | bc)
> groff -P-p${siz}c,7.2c kasticket.groff > kasticket.ps
>
> The first line gets the size from groff with -z option so no other output
> is given.
> the second converts the units to cm and adds a little bit of margin.
> The last line creates the ticket with the right length.
>
> Kind regards,
> Wim Stockman
>
>
>
> Op vr 9 dec. 2022 om 00:48 schreef Deri <d...@chuzzlewit.myzen.co.uk>:
>
> > On Thursday, 8 December 2022 17:19:49 GMT G. Branden Robinson wrote:
> > > Hi Wim,
> > >
> > > At 2022-12-08T15:51:07+0100, Wim Stockman wrote:
> > > > I am making a simple cash register with a ticket printer. and I want
> > > > to figure out how I can detect how long my physical paper should be
> > > > without cutting some text off. So I can set it for the device. The
> > > > width is fixed so that is no issue. Eventually I can run it in some
> > > > loop and detect when it stops having more than one page.
> > >
> > > I reckon I would have a couple of macros that open and close a
> > > diversion, then measure against an argument that specifies the limit
> > > imposed by the hardware (i.e., length of paper roll remaining).
> > >
> > > Here's a conceptual sketch.
> > >
> > > .de StartTicket
> > > . br
> > > . di Ticket
> > > ..
> > > .
> > > .de EndTicket
> > > . di
> > > ..
> > > .
> > > .while 1 \{\
> > > . StartTicket
> > > .\" input for ticket text goes here
> > > . EndTicket
> > > . if (\n[dn] > \n[ticket-printer-paper-length]) \
> > > . ab ticket too long for remaining paper; aborting
> > > .\}
> > >
> > > Please clarify if I've overlooked a requirement.
> > >
> > > Regards,
> > > Branden
> >
> > I'm probably missing something here, but ticket printers are normally
> > continuous rolls with a cutter, so isn't this a problem of controlling
> the
> > cutter rather than specifying a media size. There is usually a printer
> > option
> > to cut after each print job, so if you make each receipt a separate print
> > job,
> > it should do the cutting for you. Just give groff a sufficiently long
> page
> > length for the longest ticket you expect.
> >
> > I have a Brother thermal printer which I use for labels, but it will take
> > a
> > continuous role instead, and I believe it has a proprietary EscP command
> > for
> > controlling the cutting, so there may be a solution using something
> > similar.
> >
> > Cheers
> >
> > Deri
> >
> >
> >
> >
> >
> >
>
