Portrait/Landscape

rbuser

Hi all,

Been a long day for a variety of reasons and I'll probably figure out
the solution after a half-night's sleep. But I can't see the forest for
the trees in my skull right now.

I'm still using D7/RB7 on this one because the program uses some
add-ons and stuff that I don't have (and won't have) with RB12, which
WILL get installed before I die or before George Mason upsets Ohio
State, whichever comes first. At any rate ....

I have two labels that are being printed out by two separate latest
model Zebra printers supposedly loaded with specific label stock. The
2.5x4 label prints in portrait mode and seems to work. The 4x6.75
version of the label sort of doesn't work. I designed it landscape and
for seven inches cuz we don't have access right now to 6.75in label
stock that is Canadian Standards Association approved. And we're even
out of the seven inch stock. Like I said, a long day. Sooooo, it's now
being 'tested' on EIGHT inch stock.

I thought all I had to do was adjust the printersetup.pagesize at
run-time. Wellllll, that didn't work. And whenever I changed poPortrait
to poLandscape or vice versa, I always seemed to truncate my form.
Afterwhich I just loaded the save report format and started changing
things at random again. All in all, hours that should have been devoted
to my winning bracket entry went on futile changes. And I've just lost
it.

Q1: How to I change the paper dimensions on the go, allowing me to
print that dang awkward label, but getting the labels out of the
printer, one at a time with no wasted labels between.

Q2: Best way to tell the printer to print in landscape or portrait
mode, NO MATTER what mode the label was actually designed in.

I know if I get a bazillion answers here, I'll know the answers when
I wake up. So, sorry in advance. But just in case ...

Thanks, GM

nicocizik

Hi Gary,

Does your application simply consist of loading a template into a report
object and printing? Any more information you can give me about your
application would be helpful in finding out exactly what is going on.

1. The key is to be sure you are setting any printer properties after
you load your template but before you are printing. As a test, try
creating a simple example where you print one label at the new defined
paper size and at portrait or landscape (no templates) and see if that
works. If so, my guess is that the printer properties are still be
overridden by the template or they are being set somewhere else in code.

2. Same idea as above, be sure you are changing the orientation of the
paper after the template is loaded.

3. Who knows, could be another cinderella year for George Mason!


Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico Cizik (Digital Metaphors) wrote:


Nico,

No, I'm not using a template. When I talked about reloading the
report file, I'm talking about in the IDE. I learned early to save any
report I have more than a little bit done on. Then I version the file
as I go ... and that's despite having AJC too. Freely admit to being
paranoid.

What's going on is that I don't know what paper dimensions I will be
trying to print this $)(*%#@$_)&*# label on. There is a LEAN
consultant, a $*(%$%Y_#$ idiot project manager and two new Zebra
printers, NEITHER of which shipped with the proper print ribbons. Oh,
and the #)($U#_$#$* project manager didn't buy a cable for either
printer. "You don't GET the cable with the printer?"
AAAAARRRRRGHHHHHHHHH!!!! And to top it off, when I asked for
sized-as-needed graphic for the big label, he managed to get a 3in
bitmap version of the graphics ... that have to shrink to 0.895 inches.
THEN complained about a (very) little pixilation.

I slept it off today. Wonderful thing this DoNotDisturb setting on my
VOIP. They apparently figured some stuff out, cuz nobody called me
today or gave up without leaving a message. I'll suss out the situation
tomorrow morning. If they still need me to figure this all out, I'll
probably be back here begging. Come noon, it's nothing but roundball
till Sunday night.

Duke over Kansas.

GM

rbuser

Nico Cizik (Digital Metaphors) wrote:


Nico,

Was on the site Friday. Instead of watching Texas and the Toronto
guys. Oh well. As mentioned in the prior post, no templates involved.

Without changing the report at all, I made it work ... almost. The
Labels are, indeed, 1.5inH x 4inW. What they didn't tell me was that
there was an 1/8 inch gap between the labels. Or that the labels had
rounded corners, making certain elements impossible to place as per the
original layout which basically covered every square millimetre with
something. At this point, I was still using all my original software
settings, which included a height of 1.5in for the paper and the band
height at 1.489in.

Sooooo, on-site with the Zebra ZM-400 300dpi printer, I changed the
custom paper dimensions to 41.275mm by 101.6mm. I had to put in a left
margin of 0.7mm to account for mis-alignment issues. I played around
with the Media Tracking setting because the other choices were feeding
extra blank labels through.Eventually, I settled on USE PRINTER
SETTINGS. But even that was wrong, leading to TopOfLabel creep of
between 1.5 and 2 mm (as closely as I could measure).

Much, MUCH more experimentation ensued. Here's what I found. We could
print the labels ONE AT A TIME. Each time the printer paper stock had
to be backed a smidge. The printer settings changes to 41.3mm from
41.275mm when you okay the box, unfortunately. (printing 1, 10 or even
100 labels means the difference is negligible. Printing 10,000 means it
DOES make a difference, theoretically)

AND, to successfully print, you had to click the preview button, then
the print button in the standard ReportBuilder dialog THEN PROPERTIES
in the Windows Print Dialog, IMMEDIATELY press OK in the properties
dialog, THEN press the print button in the print dialog and out came
ONE (1) label that wass right (or close enough). Try to print more than
one label and that smidge you didn't ADD to the top of the page meant
the labels crept up and, well, that was not good.

Back here at the Castle of Confusion, I moved elements into the
centre to give some leeway right/left. I moved the top most elements
down a tad*. I changed paper size to 1.5in (should it be 1.625in??) and
changed the band to 1.5 from 1.489.

Here's the report object from the DFM
object pip1: TppReport
AutoStop = False
DataPipeline = pipe2
PrinterSetup.BinName = 'Default'
PrinterSetup.DocumentName = 'Report'
PrinterSetup.Orientation = poPortrait
PrinterSetup.PaperName = 'Custom'
PrinterSetup.PrinterName = 'Default'
PrinterSetup.mmMarginBottom = 0
PrinterSetup.mmMarginLeft = 0
PrinterSetup.mmMarginRight = 0
PrinterSetup.mmMarginTop = 0
PrinterSetup.mmPaperHeight = 38100
PrinterSetup.mmPaperWidth = 101600
PrinterSetup.PaperSize = 142
Template.FileName = 'D:\pgms\Proj\ClearLabel.rtm'
DeviceType = 'Screen'
OutlineSettings.CreateNode = True
OutlineSettings.CreatePageNodes = True
OutlineSettings.Enabled = True
OutlineSettings.Visible = True
TextSearchSettings.DefaultString = ''
TextSearchSettings.Enabled = True
Left = 109
Top = 453
Version = '7.04'
mmColumnWidth = 0

This update fixed earlier problems with skipping labels and with
needing to go through going to Printer Properties. But it still seemed
to require that backup smidge. So, I added two boxes with the INCH
equivalents of the label size, intending to adjust them there, rather
than trying a programming change. I rewrote the printing procedure to
look like this:

procedure TFrmMain.SpeedButton1Click(Sender: TObject);
var
Kopies: Integer;
begin
Kopies := eClear.asInteger;
if Kopies < 1
then begin
ShowMessage('You have not input the number of copies');
exit;
end;
if Kopies > 99999
then begin
ShowMessage('You are limited to less than 100,000 copies');
exit;
end;
pip1.PrinterSetup.copies := eClear.asInteger;
pip1.PrinterSetup.printerName := printer1name;

// Add adjustment capability for label dimensions and orientation
// if chkPortrait.Checked
// then pip1.PrinterSetup.Orientation := 'poPortrait'
// else pip1.PrinterSetup.Orientation := 'poLandscape';
pip1.PrinterSetup.PaperHeight := clearHeight.AsFloat;
pip1.PrinterSetup.PaperWidth := clearWidth.AsFloat;
// end of added adjustments

pip1.Print;
end;

Welllll, THAT didn't work. First, I discovered I couldn't change
pip1.printersetup.orientation on the fly. poPortrait, 'poPortrait' and
0 each prevented a compilation. I gave up on that. Furthermore,
assigning the contents of the clearHeight and clearWidth boxes didn't
seem to have any good effect.

Any and all help gratefully received,
GM

PS: A tad is about 1.5 smidges [G]

nicocizik

Hi Gary,

1. The poLandscape and poPortrait enumerated types can be found in the
Printers.pas (Delphi) file. Add this to your uses clause to compile
successfully.

I am unsure why the paperwidth and paperheight did not take. One item
to try is to be sure your PaperName property is properly set to
"Custom". Note that for later versions of ReportBuilder access directly
to the driver has been greatly improved as well as handling of printer
properties.

Take a look at the following article on printing to continuous paper.
It may give you some clues or help with the design of your report.

http://www.digital-metaphors.com/rbWiki/Output/Printer/Continuous_Paper


Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico,

Looked at the wiki and I don't think it's applicable. And I think my
problem is a hardware malfunction at this point. There's certainly SOME
rollback in this printer. And I'm darned if I can figure out how to use
it's mark sensing feature to accurately reset page top (or form top or
label top or whatever the heck the term is). Since the idiot project
manager is working with a dopey hardware guy who thinks making the
printer work is NOT part of the purchase price, this might take awhile.
I've proven to the company owner that MY end of things works. And the
customer's 'relatively' happy with my 'version' of their product label.
So, I've dumped this on idiot and dope and will await their
pronouncement they think THEIR hardware is working. Then I'll attack it
again.

Will keep you posted. Thanks for your help, GM

rbuser

Gary Mugford wrote:


Nico,

The solution has been found. Label stock (or film as the idiot keeps
calling it). The label backing was supposed to be perforated every
1.625 inches, which it was WHEN NOT MEASURED UNDER STRESS. Apparently,
the perforations separated a little under the tension of the printer
and backing them up to 'cure' the feed creep just doubled (or I think
actually tripled) the actual damage to the perforation. Anyway, a new
role of their #$_(*%U@$_%*) film and the software worked correctly, as
it had from the second update on.

Go Butler GO!

GM