Chaining multiple revPrintField's into one PDF

[rumplestiltskin]

The subject may be clear enough but, in case it's clear only to me, I'll explain.

I have a number of cards with a background field (and I'm probably thinking of HyperCard here so forgive me). Each card has that field filled with different data. I'd like to cycle through those cards issuing a "revPrintText" (for headers) and "revPrintField" but have all those "print jobs" end up in a single PDF of however many pages it takes with each page having a header of my choosing so the PDF (and the possible paper printout later) is sort of "self-collated" with a header that consists of a page number, the content of a specific "title" field that is on each card, and another piece of information I define programmatically. I'll note that I can live without the "page number".

It appears that revPrintText can do the header without a problem and revPrintField can print the field without a problem but how would one propose to combine the header of the former with the field data of the latter and then, to top it off, combine it all into a multi-page "report" of some sort?

I used to do this print job easily in HyperCard because of its excellent "report" capabilities (with the PrintToPDF Chooser Extension). Now, however, I'm stumped. revPrintText removes all the formatting (tab stops) that revPrintField keeps in place. If I "print card", I only see what's visible in the field (while, in fact, there are usually many more lines of data in each card's field).

Advice always gratefully accepted. Thank you!

Barry

[bogs]

Well, I'm not sure I got it totally, and my pardon if I'm completely off base, but if I wanted to take a bunch of fields and combine then print them, I'd stuff them into a variable or custom property or even an invisible field in order using the after statement. Something like

Code: Select all

on mouseUp
	put empty into tempContainer // some type of holder like mentioned...
	put field "yourField1" into tempContainer
	put cr & field "yourField2" after tempContainer
// or you could use a repeat loop to loop through all the fields you want..	
end mouseUp	

Of course, this might be too basic for what your looking to do, but if I wanted to join a lot of fields it is probably the way I'd tackle it initially.

[dunbarx]

Hi.

I do this in my current project. I build everything into one or more cards, and the "open printing to pdf" command creates either a single or multi-page document.

I cut through, I think, all your issues because I build cards. My data (and also, in my case, CAD-like graphic "drawings") all are trivial in their display attributes due to that simple method.

So, build cards?

Craig Newman

[rumplestiltskin]

Well, I'm not sure I got it totally, and my pardon if I'm completely off base, but if I wanted to take a bunch of fields and combine then print them, I'd stuff them into a variable or custom property or even an invisible field in order using the after statement. Something like

Code: Select all

on mouseUp
	put empty into tempContainer // some type of holder like mentioned...
	put field "yourField1" into tempContainer
	put cr & field "yourField2" after tempContainer
// or you could use a repeat loop to loop through all the fields you want..	
end mouseUp	

Of course, this might be too basic for what your looking to do, but if I wanted to join a lot of fields it is probably the way I'd tackle it initially.

Bogs,

You do understand the issue. I've been giving this some thought since I originally posted and arrived at a few options: One is a separate "report stack" idea with one card having one field; let's call it "field1". I've formatted the field to match the formatting of the source fields (each of which is on a separate card inside another stack). Your handler essentially does the heavy lifting; I'd put some extra info at the end (maybe the middle) of each loop as I arrive at the destination field simply to help define what one is looking at (which "record", so to speak). So far, so good. Here's where I'm falling down. Let's say we get all the data put into the destination field and I'm ready to print (to PDF). Obviously, the revPrintField command followed by choosing the proper output (PDF driver or "Open with Preview", etc.) accomplishes this. But the PDF (or paper) printout will very likely show the end of one source field's data and the beginning of the next all on one page. Certainly still better than nothing but each new "record" should appear on a new page (let's call each record a "chapter" and you see what I'm trying to accomplish - this isn't a book but a set of instructions, so to speak). I suspect (but don't know) that there isn't a "page feed" command I might drop into the field at a particular place.

Another option I could use, I suppose, is to use...

Code: Select all

create folder "some destination folder path"
open printing to pdf && {some nice combo of the the short date and short time}

...and revPrintField each source field in the stack so all the PDFs get deposited in one folder. Then I could use some terminal code to combine PDFs or call an Automator app to do it. (But what do I do on Windows? Probably something similar available there. Linux should have the same "combine PDFs" command somewhere.)

I began writing this right after you posted but had to go out for the evening. Thanks for your assistance. This is probably one of those things that enough discussion will turn on that light bulb.

Barry

[bogs]

One is a separate "report stack" idea

Boy, that sounds familiar...Oh yah, Rev2.1!

or even better, 'Report Builder' (same ide)

Report Builder_006.png (8.9 KiB) Viewed 4949 times

But I get the idea now, basically stuff all the different fields per page type thing, and your worried about them running together being in one container. I wonder if it wouldn't be possible to just print one card after the other, just like in that nifty tool from ye olden IDE days. Hmmm.

[rumplestiltskin]

But I get the idea now, basically stuff all the different fields per page type thing, and your worried about them running together being in one container. I wonder if it wouldn't be possible to just print one card after the other, just like in that nifty tool from ye olden IDE days. Hmmm.

revPrintField is nice because, no matter how many lines of info are present, everything gets printed regardless of it requiring 1 or more pages. The field will sometimes contain more than one card can show.

On each card there are also some single-line fields containing programmatically calculated totals. Better I show you:

In this screenshot (HC > OS9 > Sheepshaver > Sierra > Intel iMac ) you can see those "totals" fields at the lower right along with info at the upper left specifically ID'ing this operation. (BTW: In HC, I used six fields and sync'd the scrolling. Editing was done through various modal dialogs.)

Your suggestion to cycle through all the cards and essentially "copy & paste" stuff to another "report" card seems to be the way to go. I can also paste in the various data that ID this operation along with labeled totals. So revPrintField would be called every time -after- I visit one of these cards and copy everything over to the field in the "report" card. It's unfortunate that revPrintField always calls the Page Setup and Print dialogs instead of letting me programmatically bypass them. I'll head over to the appropriate page and make the suggestion (for future enhancements) that revPrintField permit some additional parameters like:

Code: Select all

revPrintField the name of field "myField" as PDF "mySavedPDFPath"

What remains, then, is to combine all the PDFs into one, multi-page PDF. I can call some terminal code or run an Automator script to accomplish this (on the Mac). A quick Google search reveals some solutions on Windows and Linux, as well.

[jacque]

You do understand the issue. I've been giving this some thought since I originally posted and arrived at a few options: One is a separate "report stack" idea with one card having one field; let's call it "field1". I've formatted the field to match the formatting of the source fields (each of which is on a separate card inside another stack). Your handler essentially does the heavy lifting; I'd put some extra info at the end (maybe the middle) of each loop as I arrive at the destination field simply to help define what one is looking at (which "record", so to speak). So far, so good. Here's where I'm falling down. Let's say we get all the data put into the destination field and I'm ready to print (to PDF). Obviously, the revPrintField command followed by choosing the proper output (PDF driver or "Open with Preview", etc.) accomplishes this. But the PDF (or paper) printout will very likely show the end of one source field's data and the beginning of the next all on one page. Certainly still better than nothing but each new "record" should appear on a new page (let's call each record a "chapter" and you see what I'm trying to accomplish - this isn't a book but a set of instructions, so to speak). I suspect (but don't know) that there isn't a "page feed" command I might drop into the field at a particular place.

I usually do what you describe only with more manual printing commands. I keep a template printing stack as a substack of the mainstack. You can print from it even if the stack is opened invisibly, which I do. The persistent elements are part of the template (headers, footers, etc.) The htmltext from each card is placed into the template's field to retain styling. The template's field can already have its tabstops set. Any scripted additions (a page number count, for example, or other dynamic field content) are inserted into their respective locations. Then I issue the "print card" command. This process can be done inside a repeat loop, one repetition for each card.

Use the pageHeights property to scroll the field contents if it will require more than one page. This can be a nested repeat loop inside the main one. Use "print break" to start a new page from the printer.

[bogs]

That sounds like gold of the realm advice to me.

[bogs]

or even better, 'Report Builder' (same ide)

You know, it is funny what you find when you go digging around. What I found was that the above mentioned 'report builder' stack was still sitting in the tools folder as of Lc 7.1.4. Not only that, but you can drop it into 8.1.x's plugin folder and open it as a palette I didn't actually test it or anything, but cycling through the tabs and menus didn't throw any errors.

I may take it for a spin later just for sh*** and grins