Thanks to all for the assistance,
Using non-contiguous areas wouldn't work. The width of the pages was also
changing, not just the length. Originally I had the report on several
different tabbed worksheets, basically one page of calculations per
worksheet: but that was either getting printed on two pages, or scaled to
fit 1 page. I put everything onto a single worksheet, so that it is easier
to printout: at one stage I also had custom views defined, so that could
print all or part of the report.
Putting page breaks in also wouldn't work, since can still run over onto two
pages or still have the problem of variations in column width. Widths of
columns and row heights were changing from one machine to the next, and yet
normal style, and standard font are all the same, and the fonts have same
file size, file dates and version numbers.
I've checked the fonts, the printer drivers, and all options I can think off
in Windows and Excel that affect printing. But never really paid too much
attention to screen display settings before: it doesn't affect anything else
so why Excel?
But the DPI setting for the Display seems to be the cause. It doesn't seem
to affect Word but it makes a difference to Excel, one machine was set
DPI=80, and another DPI=120, my machine the default of DPI=96. It is only
supposed to be a screen display setting, but Excel appears to be using it to
calculate row height and column width and relating that to the paper size. I
expect items to appear larger or smaller on the screen, but not for it to
affect the underlying size of the items themselves.
What little I know about programming printing. In Delphi, both the screen
and printer have a canvas, and can draw/write directly to either canvas.
Alternatively can define a virtual canvas in memory, draw/write to that
canvas, then scale accordingly to either the screen or printer canvas,
noting the screen and paper seldom have the same proportions. These canvases
are a variation of a bitmap, and can have a higher resolution than either
the screen or printer.
What I said previously about a screen dump wasn't correct, it was a
simplistic way of distinguishing between defining an object and writing the
object directly to the printer using a vector graphics language like
postscript/HPGL, versus building a bitmap image of the complete page and
sending to the printer. My simplistic view was that Excel doesn't appear to
have an object definition of the printed page, instead it appears to use the
screen appearance of the worksheet to build the image of the printed page.
Appearances can be deceptive so it probably doesn't do that.
The VBA help says:
ColumnWidth Property:
One unit of column width is equal to the width of one character in the
Normal style. For proportional fonts, the width of the character 0 (zero) is
used.
RowHeight Property:
Returns the height of all the rows in the range specified, measured in
points.
As far as I know point size of fonts is related to the printed page, not the
screen: can zoom in and out on the screen. So calculations for height and
width should be based on the font definitions, not screen appearance. Expect
changes to the display to change width and height of worksheet cells in
pixels, but not to change dimensions in points and not in characters.
Given that the Display DPI settings are changing both the row height and
column width suggests the underlying definition is really in pixels, and the
pixels are translated to heights and widths in points and characters. Which
then results in the worksheet no longer fitting on the printed page. Hence
impression translating screen appearance to printed page.
If cell size truly defined in points/characters, then changing display DPI
wouldn't change the cell size, but would change the number of pixels used to
display on screen. Excel would then identify cell width and height to be the
same on all machines. It doesn't do this.
Better get back to being a structural forum.
Thanks again for the assistance.
Regards
Conrad Harrison
B.Tech (mfg & mech), MIIE, gradTIEAust
mailto:sch.tectonic@bigpond.com
Adelaide
South Australia
******* ****** ******* ******** ******* ******* ******* ***
* Read list FAQ at: http://www.seaint.org/list_FAQ.asp
*
* This email was sent to you via Structural Engineers
* Association of Southern California (SEAOSC) server. To
* subscribe (no fee) or UnSubscribe, please go to:
*
* http://www.seaint.org/sealist1.asp
*
* Questions to seaint-ad@seaint.org. Remember, any email you
* send to the list is public domain and may be re-posted
* without your permission. Make sure you visit our web
* site at: http://www.seaint.org
******* ****** ****** ****** ******* ****** ****** ********