Printer sloppiness?

[foxmuldr3]

In FPW2.6 we have reports that print properly to laser printers and PDF writers. When we switch to VFP9 the ones which were close (within 0.25 inches) on margins in 2.6 now fail to print to some laser printers, but work with PDF writers, reporting detail band 1 too big and the like.

Is there a setting in VFP to allow it to allow partially off-page fields (because nothing is really off-page)?

Something like:

SET ALLOWOVERFLOWPRINTING ON

Best regards,
Rick C. Hodgin

 

[Mike Lewis]

Rick,

Are you saying that you actually want to print within 0.25 inches of the edge of the paper? If so, this is outide the control of the software. It's a physical constraint of the printer. (The actual distance varies slightly with the make and model, as does the edge(s) affected, but it's always present.)

Or are you saying that you want to be able to design the report so that it knows to ignore the unprintable area at the edge of the sheet? If so, that's simply a matter of choosing the print area setting in the report's properties / page layout ("printable page" or "whole page").

If I've misunderstood the problem, my apologies.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[foxmuldr3]

Or are you saying that you want to be able to design the report so that it knows to ignore the unprintable area at the edge of the sheet? If so, that's simply a matter of choosing the print area setting in the report's properties / page layout ("printable page" or "whole page").

It is more along these lines.

And I guess my question then becomes, what is FPW 2.6 doing by default? And is there some setting in VFP9 that will have it operate that same way, so that the existing reports (which work correctly in 2.6) can be used without that modification?

We have nearly a thousand reports, and even creating a small app to programmatically go in and set this condition on every report would be tedious to fully debug.

Best regards,
Rick C. Hodgin

 

[Mike Lewis]

OK, Rick, I understand the problem now.

But even if you programmatically changed all the report files, would that solve the problem? Given that you will, in effect, be losing up to half an inch on the width of the page, wouldn't you have to go into each report individually to make minor adjustments to the positioning of the objectc?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Nigel Gomm]

Rick,

i think what you are seeing is a by-product of VFP9 using GDIPlus for rendering.

Does the problem go away when you set reportbehaviour 80 ?

hth

nigel

 

[foxmuldr3]

Does the problem go away when you set reportbehaviour 80 ?

We tried that. It didn't seem to change anything.

Best regards,
Rick C. Hodgin

 

[Mike Lewis]

Rick, have you totally rejected the idea of programmatically updating the FRX files? I take your point about it being "tedious to fully debug". But given the number of reports involved, I would think it would be the most promising approach.

And what about my point about having to squash up the controls because you are losing up to half an inch on the width? If that's not an issue, updating the FRXs should be fairly straightforward.

I'm not saying I know off-hand how to do it. I just want to establish if it is worth exploring.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[foxmuldr3]

Rick, have you totally rejected the idea of programmatically updating the FRX files? I take your point about it being "tedious to fully debug". But given the number of reports involved, I would think it would be the most promising approach.

The reports print correctly as they are in 2.6. They are failing in VFP9, and just barely at that. There are only a handful of them that we know are failing, which happens to be the ones near the margins, but there may be more.

I'd like to try to find a solution that doesn't require us doing anything to the reports, but sets the generated print behavior back to the way it worked in 2.6.

Is it possible to modify the report generator code to NOT produce that error if the detail band, for example, which is merely a populated list of table fields on a single page, partially fits on the page? To just allow it to go ahead and "be sloppy" and print outside of the specified area?

Best regards,
Rick C. Hodgin

 

[foxmuldr3]

Mike,

Another part you may not know is we have to maintain this app in 2.6. We are using several programmatic converters to migrate it from 2.6 to 9, and they are working splendidly.

However, these few reports are giving us nightmares. We also have another report that is generating asterisks for a numeric summed field in 9.0, but not in 2.6, on the same data.

I think VFP9's report writer is ... wonky.

Best regards,
Rick C. Hodgin
317-879-6374

 

[Mike Lewis]

Rick,

We haven't discussed which printer drivers you are using. Are you using the same drivers both in 2.x and 9.0? If not, that would explain the differences you are seeing, especially the asterisks in some of the numeric fields. This is not the fault of the VFP 9.0 report writer. It's because printers inevitably vary in their ability to render objects at precise positions and sizes.

Also, are you using scalable fonts, like TrueType, or printer-resident fonts? If the latter, that would again explain some of the differences.

By the way, I know you don't like the idea of programmatically changing the FRXs (and I can see your reasons for that), but I've been looking at the documentation for the structure of the FRX file, and can tell you that, to switch between setting the page to the entire page vs the printable area, you would modify the Top field in the report header record (always the first record in the table, I believe). Set it to .F. for the Printable Page, or .T, for the Whole Page. I'm just noting this here for the benefit of anyone else who has this problem.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[foxmuldr3]

We haven't discussed which printer drivers you are using.
(1) Are you using the same drivers both in 2.x and 9.0? If not, that would explain the differences you are seeing, especially the asterisks in some of the numeric fields. This is not the fault of the VFP 9.0 report writer. It's because printers inevitably vary in their ability to render objects at precise positions and sizes.

(1) Yes. Same machine, same printer.

Also, are you using scalable fonts, like TrueType, or printer-resident fonts? If the latter, that would again explain some of the differences.

Default fonts for added objects in these reports, size 6pt, 8pt and 10pt.

By the way, I know you don't like the idea of programmatically changing the FRXs (and I can see your reasons for that), but I've been looking at the documentation for the structure of the FRX file, and can tell you that, to switch between setting the page to the entire page vs the printable area, you would modify the Top field in the report header record (always the first record in the table, I believe). Set it to .F. for the Printable Page, or .T, for the Whole Page. I'm just noting this here for the benefit of anyone else who has this problem.

We can try that manually on a few of the trouble pages. I'm not opposed to it. As I say, I wrote an app we call FCON (Foxpro CONverter) which parses 2.6 source code and compensates for several issues we've found between 2.6 and 9.0.

I just don't like doing it that way unless it's required. Hope that makes sense.

Best regards,
Rick C. Hodgin

 

[foxmuldr3]

Set it to .F. for the Printable Page, or .T, for the Whole Page. I'm just noting this here for the benefit of anyone else who has this problem.

This most useful piece of advice did the trick, Mike. Thank you.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

> generating asterisks for a numeric summed field in 9.0, but not in 2.6, on the same data.
In reports this can denote too small width instead of overflow of the value range. And it happens all the time because the new gdiplus render engine does need a few pixels more, as nigel already mentioned.

It's a known bug:

http://spacefold.com/colin/posts/2005/08-18GDIplusinreports.html

Reportengine 80 may not solve that alone. It's a long way from 2.6 to 9 and other behavior changes may contribute. So even if mode 80 prints slimmer, it may still be wider than with the earlier 2.6 rendering.

There are new trim options, but only for character data type and they all will either clip off at the letter or word level or add an ellipsis (...) to shorten text in the middle. They didn't extended the "stretch with overflow" feature to enable stretching horizontally.

On the other side it would be bad to have 100 printed instead of 1100 in a bill or receipt, that's why you get *** then instead. It's the same as in Excel cells too narrow.

FoxPreviewer has a feature built in to change a report on the fly if that width overflow happens. Just look out for "lExpandField" here:

http://foxypreviewer.codeplex.com/wikipage?title=FAQS

Bye, Olaf.

 

[TamarGranor]

However, these few reports are giving us nightmares. We also have another report that is generating asterisks for a numeric summed field in 9.0, but not in 2.6, on the same data.

This one I'm pretty sure REPORTBEHAVIOR 80 will fix.

Tamar

 

[Olaf Doschke]

I would agree, Tamar, but nigelgomm proposed it and Rick already tried that with no luck. I suppose there's more to it, more chnages from the legacy foxpro report engine to the current one, that influence this. And maybe also the printers, maybe also Windows, if the old reports were rather printed from DOS.

Bye, Olaf.

 

[TamarGranor]

I was referring specifically to the asterisks for numeric fields, not the original problem.

Tamar

 

[Dan Olsson]

We can try that manually on a few of the trouble pages. I'm not opposed to it. As I say, I wrote an app we call FCON (Foxpro CONverter) which parses 2.6 source code and compensates for several issues we've found between 2.6 and 9.0.

Care to share that app? I have a few projects that could benefit...

 

[foxmuldr3]

Care to share that app? I have a few projects that could benefit...

Would love to! But I can't. It's owned by the company I work for. :-(

I am willing to walk you through all the issues we found, and give advice on the design and how we implemented it. You wouldn't need a full lexical parser like I wrote. Some of the fixes could be implemented much easier.

Primary issues we found (and some clever / hacky fixes):
(1) foxel conversion didn't work properly
(2) numeric inputs on memory variables not derived from table variables which exceed (2^31)-1 result in a momentary "Numeric Overflow" wait window message which doesn't affect anything, but is annoying. Fix was to m.var = m.var + (9999999999 - 9999999999).
(3) When applying the (2) fix, any @ get with a picture clause of "@K" it stopped working properly, so we padded the picture clause automatically of the length of the SIZE parameter for width (which is foxels, so it's whatever that value is rounded down) as repeating 9s, as in "@K 99999" for numeric inputs. We surrounded it with an IIF().
(4) On occasion, when the user presses enter on an input field it will accept a 0 amount. This is because the source code generator automatically adds DEFAULT 0 to each line. We changed it to pad that out with spaces, with another fix being to use DEFAULT &k_fcon_k, where k_fcon_k = IIF(TYPE("m.var") = "N", ALLTRIM(STR(m.var,i+d+1,d)), "0"), and the i and d variables are derived by counting the number of 9s in the picture clause to determine as integer 9 positions, and decimal 9 positions.
(5) If you use covers to hide controls in 2.6, they won't work properly. We had to create a shape_cover and a label_cover class which are objects added to thisForm, which then are brought to the top of the z-order. Also, the foxel-to-pixel conversion doesn't alway seem to work properly when you do this, so I created a cover_bumper class, which bumps the covers a few pixels each direction, width and height, so they can be manually positioned in VFP.
(6) In some cases it's desirable to maintain development only in 2.6, so I introduced the "*9*" line comment prefix, which will be removed by the converter so the code is written in 2.6, but then appears in the 9.0 conversion.

A few more. Can't remember them all. But, if you're interested I'll dig them up.

Best regards,
Rick C. Hodgin