Formating Layout for Dynamic Receipt

[comment]

A few thoughts:

1. Contact the printer manufacturer; surely they have encountered this issue before.

2. Use a layout with no header and no footer (use only sub-summary parts and body); try setting the page height to equal the height of a receipt with one line item (i.e leading sub-summary + body + trailing sub-summary).

3. Re the logo, I don't see how it can work unless your portal is of fixed height (non-sliding). It seems to contradict your purpose of matching the page height to the number of items. Couldn't you use a tiled logo (or some other pattern)?

 

---

BTW, a while back there was a request here (from Bolivia, I think) to produce a RC4 hash string for an invoice that would prevent tampering with the invoice's data. This was mandated by the tax authorities there, I presume due to high fraud rate.

Edited December 5, 2013 by comment

[wedgeman]

A few thoughts:

1. Contact the printer manufacturer; surely they have encountered this issue before.

2. Use a layout with no header and no footer (use only sub-summary parts and body); try setting the page height to equal the height of a receipt with one line item (i.e leading sub-summary + body + trailing sub-summary).

3. Re the logo, I don't see how it can work unless your portal is of fixed height (non-sliding). It seems to contradict your purpose of matching the page height to the number of items. Couldn't you use a tiled logo (or some other pattern)?

 

---

BTW, a while back there was a request here (from Bolivia, I think) to produce a RC4 hash string for an invoice that would prevent tampering with the invoice's data. This was mandated by the tax authorities there, I presume due to high fraud rate.

 

 

Thx.

 

1. The printer per-say isn't really the problem.. It'll churn out a page as long (or as short) as you tell it to. Printers with cutters will cut the page whenver they see an "end of page" line, all of which is controlled by page setup. Perhaps I'm wrong, but I think the problem is tied to PageSetup settings....

 

2. I'll try the layout arrangement you describe.  But what do I tell "page setup" to consider the size of the paper to be?  If I tell it the paper is say, 1" tall, it'll come along and cut the page at every 1" until it's printed the whole layout in 1" increments...

 

3. I had in my mind a layout which could resize graphics according to the size of static data which would be on it (ie., if say, only 3 lines of items, a much smaller graphic centered on the page, on a page which is much shorter).... of course my ability to dream **MAY BE** a bit out of proportion to reality..

 

 

As to the idea of digital tampering process, I have fixed that to an extent.. I've got a hidden (non-visible to anyone but [full access] level field which contains a date/time stamp which is auto generated when the file is modified, which is then copied over to a static field at such time as the file is locked.  IF original stamp doesn't match current stamp, the file can't be modified or adjusted....

 

This however isn't the reason for the logo in the receipt -- -the idea is to make it difficult for average crooks to create (or modify) a fake copy of the receipt to make demands of the company.  With a light shade watermark, it's significantly more difficult, as it won't copy well, and is far more difficult to replicate.

 

 

 

 

At this point I'm seeing the issue of the watermark as more important than using a pretty/flexible "list view", so i'm running with my duct-tape model of multiple sized static pages with portals.

 

BUT the outcome of this is going to mean the issue has to be resolved in the future, as the client is going franchised, and the printer/page setup issue is going to have to be resolved prior to that......

[comment]

Re #1, I don't know. It doesn't seem like a reasonable behavior for a continuous feed printer. I mean what's the point of being continuous, if you going to stick to a preset page size? Unless they expect you to provide an end-of-page character in the feed - which (I think) is not feasible in Filemaker, or any other application I can think of. Soooo 80's.

[wedgeman]

Aggggg.. i'm gonna kill myself!  just accidentally deleted a LONG series of questions about this, because I got interrupted!  (anybody else find it easier to lock the door and turn off the phone to prevent interruptions?)

 

1. Comment, thanks.. YES, indeed, i found a firmware bump on the TSP100 that allows it to automatically chop off the page at the end of the label ... so there's no need to tell it a static layout size (I think).. (I'll report back on this when I've successfully finalized it and proven it to be working!)

 

2. LaRetta, i'm still lost as to part of your statements. AND my layout STILL isn't working. and I don't know what's the cause. And another week has come & gone.... argg!!!

 

a few questions:

1. You said:  "I only have time for quick look ... heading out the door ... but your sub-summary is based upon Invoices::InvoiceNo and it should be based upon InvoiceItems::ID.  And the sort needs to be changed to point to InvoiceItems:ID also."       Now I don't know what you meant by "the sort needs to be changed to point to InvoiceItems:ID also."....  can you explain WHERE to set a sort?  What is a sort? Where do you find it? I'm guessing you're referring to the Part setup? On Body, it only will refer to whatever the whole layout is based on. am I doing something wrong there?
2. I'm chasing my tail on getting a layout which properly returns the records in preview mode.
3. If my records ((invoice items) are the repeating target, then (I'm assuming) I should make the ENTIRE layout based on the InvoiceItems Table --  correct??
4. The Header should be based off the Invoice table, (Invoice::InvoiceID), right? (because it's a single summary item)
5. The Leading Summary should ALSO be off the Invoice::InvoiceID, correct?
6. The Body Should be off InvoiceItems::InvoiceID, ?? (yes, i went back & corrected the field name)..
7. The Trailing summary should be Invoice::InvoiceID??
8. THe Footer Should be Invoice::InvoiceID?

 

What I'm getting is a bunch of varying results which never return the correct item.. Its' not for lack of effort. I litterally printed out ALL your notes on this topic, taped them to my monitor, and worked till 3this morning.   and still not ending with anything that's usable....

[LaRetta]

 

1. can you explain WHERE to set a sort?  What is a sort? Where do you find it? I'm guessing you're referring to the Part setup? On Body, it only will refer to whatever the whole layout is based on. am I doing something wrong there?  Sort the records - Records > Sort and select InvoiceItems::InvoiceID.  When you have a sub-summary, the records must be sorted by the field defined in the sub-summary part.  It is called the 'break field' because it is the field which breaks the records into their sub-summary group.
2. I'm chasing my tail on getting a layout which properly returns the records in preview mode.
3. If my records ((invoice items) are the repeating target, then (I'm assuming) I should make the ENTIRE layout based on the InvoiceItems Table --  correct??  Yes and that is what you have from the file you presented - I checked it.
4. The Header should be based off the Invoice table, (Invoice::InvoiceID), right? (because it's a single summary item)  Headers are not summaries.  But no, the entire report should be based upon the table it represents - InvoiceItems.
5. The Leading Summary should ALSO be off the Invoice::InvoiceID, correct? No.  INVOICEITEMS::INVOICEID
6. The Body Should be off InvoiceItems::InvoiceID, ?? (yes, i went back & corrected the field name)..  The body is always based upon whatever table occurrence the layout is based upon.  In this case, you are working in the InvoiceItems table so yes, body is based upon InvoiceItems.  The entire report should be based upon InvoiceItems.  You can place fields from Invoices in the sub-summary part (such as ShipMethod) but the sub-summary parts must be based upon field in INVOICEITEMS.
7. The Trailing summary should be Invoice::InvoiceID?? No.
8. THe Footer Should be Invoice::InvoiceID?  No.

 

I had reviewed your file and presented step by step  ... please re-read my post #31. 

[comment]

so there's no need to tell it a static layout size (I think).. (I'll report back on this when I've successfully finalized it and proven it to be working!).

 

Please do, as it may help others as well as satisfy my own curiosity.

 

 

A note about headers/footers: a header is something that repeats on every page. As such, it has no logical place when printing to a continuous printer. At best, it will appear several times at seemingly random places in the printout. In the worst case, it may signify a premature "end of printout" to the printer. This is assuming that my hunch is correct and that you CAN print several pages "continuously". In any case, I would take them out of the equation - at least until you can figure out the printer's behavior in more detail.

[wedgeman]

First, a BIG thanks to LaRetta for giving me direction.  And **I PROMISE** I did exactly what she said! Well, mostly . But I had another issue in my own db which was killing the sort.. go figure.

 

Apparently I had something messed up in my db file, because I eventually re-created the entire layout and page in a new virgin FMP db, then copied it into mine, used the same scripts for sorting, etc, and it worked..  But I wouldn't have figured it out without her. Thanks!

 

Comment, you're dead-right on Footers... but apparently Headers don't act quite like footers (WRT summary list printing anyway).

 

 

IF there is a footer on a page (with thermal printing and cutting), it seems that the printer doesn't recognize an "end-of-page", so it just runs eternally (and it's a pain to re-roll a 200' spool of thermal paper to stuff it back in the printer)..    

 

Apparently this isn't the case with headers (why? I dunno). In my own rendition, I can't set any "page break" settings on the header (before or after), but it's a mute point (in my case anyway) - because one can't really "print multiple receipts" in this view (without the aid of a script to do the dirty work of collecting the correct LineItems, sorting by InvoiceID, and switching layouts).

 

Because you can't specify a pagebreak after a footer for some reason (nor can you specify BEFORE a header), the only solution (that I've found) is to have one or the other, but not both (ie., don't have both in the layout). So, I stuff my "static" info into the subsumm (trailing), and specify a break after it, so that fixes the end-of-page question....

 

 

On paper sizes.  I've simply chosen a very long length paper (2000mm), and set all to sliding up.. so it cuts off at the end of the data on the trailing sub-summary. (after experimentation, I put a tiny invisible part of a graphic lower on the page, to force it to give  a bit more clear space, though I suspect one could fix this with proper margin size adjustment)..

 

So... As long as your cutter-equipped thermal printer can be setup with a "continuous feed option" (in the print dialog under printer options), it should cut the paper as soon as it hits the end-of-page..   (Star didn't have this in the original firmware so it wasn't recognized for Mac PPD, but subsequent releases fixed this).

 

 

 

 

So I've attached a couple screenshots of a setup, that shows it in action... I've got a header, Sub (leading), Body, and Sub (Trailing), and it prints perfectly well.

 

 

So this is the process for the print script: start in Invoices table, GTRR to the layout, sort, do AppleScript [lpoption] to choose correct printer, do PageSetup, do print, return to original layout...

 

Voila!

 

All said it's a fast operation now.  I've got multiple layouts (one being the end-user receipt,another being a warehouse pick-sheet, and a third being the shipping dept's copy with barcode for scanning).  The script jumps to each one, spits out a copy, then at the end goes back to the invoice layout. And with the speed of modern thermals, it's a solution that appears seamless to the user..

 

 

"Related thermal printer stuff"  (for those in the future who wander past in search of help)..

 

 - -

 

First, because of the unique paper sizes in thermal printers (2.25" and 3.125" wide being primary sizes) there is a challenge with paper sizes as they're NOT standard call sizes within the OS. Ideally this would be done via script (Perform Applescript ["do shell script "lpoptions -d Star_TSP143__STR_T_001_ -o media=Letter""] ), but from what I can tell Apple decided to have the OS ignore 'lpoptions -o ' calls.. (perhaps someone can fill this in later??).

 

I haven't figured this out completely yet and am resorting to having to create Custom Paper sizes on each machine that's actually printing (to call the printer PPD and choose the correct paper size).. BUT this also requires me to have installed the CUPs drivers on every system on the network which may access that printer, and I'd love to bypass this... A bit annoying, but it works for now.

 

(If any folks figure this answer out, I'd love to hear it)

 

- -

 

Second - a footnote for those not familiar with lpoptions in Applescript or Terminal:  an lpstat -d command will return your OS-level default printer name. But that's the actual device name, NOT the "nice name" (as generally seen in System Preferences). 

 

AppleScript (and Terminal shell scripts) have to know the actual device name.. You can find it by going to Terminal ("lpstat -d " for default or "lpstat -p" for ALL)  OR, by opening the printer in Sys Preferences, and looking at Options & Supplies > General.

 

 

Hope this helps somebody else!