Label fonts change spontaneously at runtime

[ccbryan]

This one is surpassingly strange...

My application has been running for years (and years) without any problems such as this one. We recently made some changes in the network environment (Citrix, print server, etc.) We had lots of problems getting our printing sorted out, especially two .lbx formats, a hang tag and a receipt. By juggling drivers and printer settings we have mostly ironed these out, but now we are in a pattern where everything pretty much goes OK except that every day around 1:45 these two labels begin printing crazy. Typically the hangtag will begin to print as a tiny version of itself in the upper left corner of the page - or it will lose track of which printer tray it is supposed to be on, and the receipt font will become enormous and the receipt 4 feet long. This happens more or less simultaneously to multiple locations runnning the application via Citrix. Restarting the application once or twice usually puts things back right. Strangely, only these labels seem to suffer from this; reports (.frx) seem immune

These changes are spontaneous; both labels are inside inside the compiled exe and all locations are running the same executable. We have checked event logs on all the servers involved (Citrix, printserver, dataserver) but see nothing amiss.

I just wonder if anyone has experienced anything like this... ???


Chandler

 

[Olaf Doschke]

No. Does this affect the preview only or the printed documents as well? As you say Citrix, I could believe a remote desktop optimization uses remote client fonts to display forms including the report preview, at the server side there is no problem. This is typically done to accelerate the graphics the client sees, the desktop of the server is not sent to the connected clients, but GDI plus commands, and that only draws halfways what is really happening on the server side. You have to have the same fonts at each client to see the screen as it really is.

Bye, Olaf.

 

[ccbryan]

That's a good thought, Olaf. These labels aren't ordinarily previewed, but I could throw a preview in there... thanks!

 

[Dan Freeman]

every day around 1:45 these two labels begin printing crazy

That's a REALLY specific observation and I've seen observations like this before.

What else is going on in your environment around 1:45? Is there a large compressor or other large piece of equipment being powered up in your facility (or your neighbor's) that might be messing with the power supply? (Which might just mess up a printer's brains?)

I've seen this several times (although it has been a few years) in industrial environments, or even office environments in industrial complexes.

What the heck is happening at 1:45?

 

[ccbryan]

Hi Dan, I admit it's not as specific as 1:45:00, more like every day between 1:30 and 2:00.

The application and all the servers live at location A, a light manufacturing and office facility. The workstations/printes using the app are in 9 different retail locations in various states; this app is not used at location A. These font issues only affect my application at the retail stores; printing at location A is fine. So it's not power fluctuations affecting the printers themselves... The problem has to be "at" location A because all the retail locations are affected similarly... Maybe power issues at the print server, though it's hard to see how a server-side power issue would affect my app selectively...

We have scoured (and are scouring!) scheduled tasks, event logs, etc. on all the servers involveed, but to no avail as of yet.

I feel as though it has to be a print server/printer driver issue, but I'm not expert enough in that area to even say something intelligent about it.... I'm just beating the bushes. Thanks for taking the time to reply.

Chandler

 

[Dan Freeman]

Well that didn't clear up much.

Are you saying that you have disparate and far-flung locations running an application that relies on print servers at the mothership location to print locally?

Why on earth would you do that?

We have 1500+ retail locations using our software and printing at all hours of the day and night and it would never occur to us to question ANYTHING happening at the home office for something going wrong at the local stores.

Or ... wait ... are the flung locations printing at the mothership location? Why?

Dan

 

[Olaf Doschke]

I'm puzzled, if retail locations print at their own location, how is that connected with the central location at all?

It seem it rather just is the classic printer info embedded, not working for retail locations. Remove printer info from your reports.

It would be the first time this would only affect printing at certain times, though, so somehow a connection to some print server is involved. Why? VFP can print directly to a printer without a printer server involved, at least you don't need a central printer spooler. That setup seems really awkward.

Bye, Olaf.

 

[ccbryan]

Here's some more information, courtesy of our network guy. The printing problems began showing up when we changed the environment in which the Fox application runs (of course!). Printing issues in the Fox application were pervasive immediately after the change, but we've gotten them whittled down to just the ones desribed above.

OLD ENVIRONMENT (never saw these font issues)
Server OS: Microsoft Windows Server 2003 R2 x86
Citrix version: citrix 4.5 presentation server
Print server: Microsoft Windows Server 2003 R2 x86
Visual Fox Pro version: 7.0

NEW ENVIRONMENT
Server OS: Microsoft Windows Server 2008 R2 x64
Citrix Version: Citrix XenApp 6.5
Print Server Microsoft Windows Server 2008 R2 x64
Visual Fox Pro version: 9 SP2

Items that have not changed

1. All locations connect to the corporate office where the servers are located via Corporate VPN

2. The printers that are physically at the remote locations are installed on the print server and therefore published to the users via Citrix policies using the manufacturer supplied printer drivers. They communicate between corporate office and remote via the above mentioned VPN

Chandler

 

[Mike Lewis]

Hi Chandler,

I haven't been following this thread in detail, so my apologies if this has been covered before.

Of the four items that you say have changed, it seems to me that the most likely culprit is the VFP version (from 7 to 9). If you have changed the VFP version, that suggests that you have recompiled the application. That in turn suggests you have made some changes to the application. My guess is that one of those changes to the application is the thing that's causing the problem.

In order to verify this, can you now revert to the previous version of the application - at least on a temporary basis, to see if the problem goes away? That will at least tell you where to focus your efforts.

My bet is that the problem is ultimately caused by the wrong printer driver being used for the labels. But we can follow that up in detail if the above assumption turns out to be correct.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[DSummZZZ]

I've had several issues with report forms acting funky in VFP9 which were written in earlier versions. One of which I am planning on opening another thread on.
My 'cure' to the latest problem was to issue the SET REPORTBEHAVIOR 80 just before running the report, then set it back afterward for other reports.
VFP9 definitely generates output differently than prior versions. For better or worse sometimes.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[JRB-Bldr]

now we are in a pattern where everything pretty much goes OK except that every day around 1:45 these two labels begin printing crazy

more like every day between 1:30 and 2:00.

So you are saying that the remainder of the day (before and after) the application prints out the labels just fine?

The printers that are physically at the remote locations are installed on the print server and therefore published to the users via Citrix policies using the manufacturer supplied printer drivers. They communicate between corporate office and remote via the above mentioned VPN

Does this problem occur at ALL of the remote locations during that time frame or only at a limited number of the locations?

Good Luck,
JRB-Bldr

 

[Dan Freeman]

My 'cure' to the latest problem was to issue the SET REPORTBEHAVIOR 80

NOTE: This is a perfectly valid solution! Report generation under GDI+ produces different results than simple GDI and the output can be different. (Numeric fields tend to take more space in GDI+, for example.)

If you haven't had time to test and adjust a report, keep it in the old environment. Perfectly acceptable.

NOTE: SET REPORTBEHAVIOR 80 is the VFP9 default setting. You do have to go out of your way to set it otherwise.

My understanding is that with ENGINEBEHAVIOR 90, VFP generates a multi-page TIFF file where before it generated individual pages in the printer driver's native preference but I could be wrong. It's a dusty memory.

None of this would (or I should say *should*) cause something that happens on a schedule, however.

The time of day thing still rings a bell with me.

 

[ccbryan]

First, thanks everyone for taking an interest!

Mike, The upgrade of Citrix and the move from a 32-bit to 64-bit Citrix server (plus the upgrade of the print server) caused all kinds of printing problems in my application, mostly in the areas of failure to print, print to wrong tray, print to wrong printer. Prior to this things had been fine for ten + years! We made quite a few changes in the setup and structure of the Fox app -- and to the print server and the way we handle Citrix printing -- in pusuit of these problems, the 7 to 9 VFP upgrade among them. It was, as I have said, only .lbx labels that were affected, not reports. The labels in question are 1) four different hangtag .lbx's , which are on 5X7 paper and print on the same laser printers as reports, but from a different tray, and 2) receipts, which print on STAR printer.

I still don't have any idea why it's just these labels that are affected... the ONLY thing they have in common is that they are lbx.

Dave, thanks I had not been aware of SET REPORTBEHAVIOR. I'm putting that in this morning and we'll see if it helps.

JRB, yes for most of the day these same labels print fine with no problem. Then in the early afternoon several stores in quick succession will reprort these crazy font sizes. It's acually hard to say whether all stores are affected or just some... it depends on whether they are printing receipts or hangtags during the 'error time'. They are relatively high-end retail stores, and going an hour or two without a sale is not unusual. There are nine locations and normally we hear from at least 4 or 5 (the busier ones).

We're continuing to investigate...

Chandler

 

[Mike Lewis]

Chandler, you say:

... all kinds of printing problems in my application, mostly in the areas of failure to print, print to wrong tray, print to wrong printer.

You know, that really does sound like the printer environment being embedded in the LBX files.

If you haven't already done so, it would be worth taking a moment to open the LBX in the label designer. In the Report menu, look for the Printer Environment command. If it has a tick against it, click on it (to remove the tick), then save the file.

If the Printer Environment command wasn't ticked, then I'm wrong and you'll have to keep looking.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ccbryan]

Mike, that was one of the changes I made to fix those printing errors. This was in VFP7 before moving to VFP9 (before there was a 'save printerenvironmnent' checkbox)... I opened each hangtag and receipt .lbx as a table and in the EXPR field replaced the printer with a printer variable like so:

DRIVER=winspool
DEVICE=&gPrinterHang
OUTPUT=
ORIENTATION=0
PAPERSIZE=135
ASCII=135
COPIES=1
DEFAULTSOURCE=259
PRINTQUALITY=600
COLOR=2
DUPLEX=1
YRESOLUTION=600
TTOPTION=2
COLLATE=0

And now in VFP9 the 'save printerenvironment' check box is empty. 'gPrinterHang' is assigned at login when the user selects his hangtag and receipt printers. This was instrumental in fixing the first round of problems.

 

[ccbryan]

Now I've got some data! The preview I put in there has produced results:

Today around 12:30pm one store (that we know of) experienced a crazyfont... a hangtag all scrunched up tiny in the upper left corner of the form (these errors produce a perfectly formed hangtag about 1 by 0.5 inches; under a microscope it looks perfect). It looked that way in Preview as well. This takes it out of the realm of power surges and into... what? Is the printer driver involved in print preview? The label form itself (definitely contained in the executable, I verified today) isn't changing.

Now we know (I think we know anyway) that the error is internal to the processing within VFP. So... anybody?

Chandler

 

[DSummZZZ]

Have you tried issuing CLEAR RESOURCES every now and then?
It's a stretch, but I'm wondering if it would make a difference.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[JRB-Bldr]

Now we know (I think we know anyway) that the error is internal to the processing within VFP

But since you also say: for most of the day these same labels print fine with no problem it makes that assumption less certain.

If something were going on within the VFP application it would generally mess things up at all times time of day - not just within a specific time frame.

Regardless, are there any operations within the VFP application that are run only preceeding the problematic time frame?

By that I mean, could some other VFP operation (preceeding the print operation) be leaving 'junk' in memory and/or in environment settings which could be affecting the printing?

Are there any non-VFP applications that are run prior to the problematic time frame which might be changing printer settings and not 'cleaning house' afterwards?

Also - after the problematic time frame, do the labels revert to printing OK again on their own?

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Chandler, you asked "Is the printer driver involved in print preview?"

Yes, it is. It's the printer driver that knows the exact font metrics, and also such variables as the size of the page's unprintable area. These apply both to the hard copy and the preview. So, yes, the printer driver is involved in the preview. So the latest behaviour you are seeing does not eliminate the driver as the source of the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

What Mikes says is important, but also very logic. How could you have a "What you see is what you get" preview of a report, if the printer driver wouldn't be involved? You must then assume, the preview is only close to what you will get, just generating the gdi graphics, that will be sent to the printer. I actually don't know, but the reasons (eg margins, printable area) speak for involvement of the printer driver.

One thing, which comes to mind is settings for font sizes. Do clients perhaps change this from the normal windows dpi settings? That causes several issues in VFP, eg also in pageframe page tabs, AFAIR. It might also cause trouble in printing, though it wouldn't explain, why just a portion of the report prints at the wrong place and in the wrong size.

Bye, Olaf.