Mysterious Magical Moving Lines in Microsoft Excel

[O5O]

A line drawn in Microsoft Excel seem here, not to be a line at all.

I was trying to find patterns for number factors, and started working
on this rather large 80MB spreadsheet to illustrate. I know this is
probably not the proper venue for doing this kind of work, but it
seemed appropriate for me at the time to try and get a handle on the
problem.

You can get the spreadsheet here, but it will probably take an hour to
download if you are the only one trying to get it. If you are sharing
bandwidth with someone else, it will obviously take longer.

http://christoffur.hopto.org/PrimesFL/FactorTableWithDiagonals32+65.xls

or you can view just the printed output in jpeg form here:

http://christoffur.hopto.org/PrimesFL/index.shtml

The problem here is with the line drawing from View->Toolbars->Drawing-

Line ... I tried with and without the shift key to limit angles to

multiples of 15 degrees, and this was the best I could come up with.
However when the slope becomes large enough, the lines begin to do
weird things in the spreadsheet like instead of piercing a gray cell
in the middle, it will walk around the outside and usually to the
left. After around line 28 I began to notice this behavior, and the
problem became more pronounced as the slopes of the lines continued to
increase.

When the pages of the spreadsheet are printed out separately, the
lines are no longer continuous, nor intersect the page boundaries at
the correct horizontal cell location, but become discontinuous
independent lines for each page with incorrect slopes and intercepts.
This of course makes tracking the higher order slopes by the use of
line drawing commands virtually impossible, unless perhaps if I were
of course to break the lines up into shorter segments that do not
extend page boundaries. Maybe. I haven't tried this yet, but it will
only work if the slopes can be reproduced accurately, which seems on
its face unlikely.

What we know is that all of the cells from E to ED have a common
column width of 10, and a row height of 14.25 making the slopes of the
angles between consecutive diagonal cells consistent. It appears
however that there are certain angles which Microsoft Excel is unable
to reproduce reliably. At least I have not yet been able to determine
how to acheive this feat.

As you can see from the spreadsheet output, the angles of low slope
which Excel is able to reproduce reliably are of no significant
interest because there are basically no interferring, or column
sharing lines. Where the slope is large and might reach closer and
closer to infinity, that is where the interest begins, but because
Excel is unable to correctly intersect the appropriate cells, the
excercise is at this point futile.

Any help from anyone with experience in this area would be greatly
appreciated.

Regards from,
Chris.

 

[O5O]

This problem changes when the page size is changed. Previously these
pages were printed to a "Microsoft Imaging Document" with a page size
of 35 inches by 35 inches which prints 15 pages total, and the lines
are then generally broken into discontinuous segments at the page
breaks.

http://primesfl.christopherthompson.me/index840.shtml

Notice that the lines with larger slopes that are drawn to the top of
the page where most of the lines intersect, all basically converge
into one thick line that appears to have the same slope, and the lines
drawn to column "Base 3" all appear to be parallel. This behavior
continues with each consecutive page, but some lines will break out of
the thick line and then follow the correct slope, until page 5 where
all of the slopes are actually incorrect from the intended slope.

When the page size is changed to 8-1/2 inches by 11 inches there are a
total of 28 pages printed, but the lines change slope differently
across the page breaks for some reason. I would print these out and
post them on the web like the above pages, but that would probably
take several additional days to complete. Instead It looks like I can
draw multiple lines with the correct slopes between the page breaks,
and then hopefully they will all appear correctly on the printouts.
Time will tell.

This will also take a great deal of time if I do it by hand like
before, so I will see if I can figure out a way to do it automatically
with a macro...

The thing that is interesting with the change of page size is that
when viewing the excel spreadsheet in "Page Break Preview" the lines
change with each movement within the spreadsheet using the up and down
scroll bar. At the top of page "one" when "Microsoft Office Document
Image Writer" 8.5 x 11 inches is selected, there are 12 lines to the
right of the thick solid looking line, but at the bottom of page one,
there are still twelve lines to the right of the thick one that
intersect the page break, but in actuality there are now 15 lines to
the right counting the lines that were started at the top but slope
out to intersect the right side page break. These lines seem to shift
from side to side across cells as the scroll bar moves up and down for
some reason.

Print preview also looks differently when looking at a "print preview"
of "Microsoft Office Document Image Writer" 8.5 x 11 inches than when
looking at a "print preview" of a real printer like "Epson Stylus R280
Photo Series" with the same page size. The "print preview" of the
Epson has only one thick line on page "one" that indicates the last
lines in column "Base 3" with the largest slopes, but the "Microsoft
Office Document Image Writer" has two thick lines originating at
column "Base 3." I can't seem to verify this hypothesis at this moment
for some reason, but I think that this "may" be related to the fact
that that the two printers are printing at different resolutions. The
MS Office Writer is printing at 300 DPI, where the Epson, I think, is
printing at 360 DPI.

Again the spreadsheet is here, but beware of over an hour to download:
http://primesfl.christopherthompson.me/FactorTableWithDiagonals32+65.xls

Has anyone else noticed that there is a slope "maximum" in Excel from
the "line draw" command? It appears to me that there is a range of
values of slope that is missing between vertical and some other value
of slope, but it doesn't appear to be a consistent value for some
reason.

 

[O5O]

You can view the differences in line drawing caused by change in
printer resolution.

I printed the first page only in three different resolutions according
to the Epson Stylus Photo R280.

The pages are printed on standard 8-1/2 x 11 inch paper and then
scanned into .jpg files for archival and online viewing purposes.

"Text & Image", "Photo", and "Best Photo." Photo and Best Photo appear
identical. I don't know exactly what the resolution is for these three
different selections, but it seems that "Text & Image" is around 350
or 360 DPI, and Photo or Best Photo might be 600 DPI.

Anyway page size is identical, and the lines that are drawn on the
print out are definitely different between Text & Image and the other
two formats for some reason.

Text & Image Quality:
http://primesfl.christopherthompson.me/P1TEXT2.JPG

Photo Quality:
http://primesfl.christopherthompson.me/P1PHOTO2.JPG

Best Photo Quality:
http://primesfl.christopherthompson.me/P1BPHOT2.JPG

Seems odd to me that print quality should change the slope of a line...

 

[O5O]

I don't know people... I can't believe that I am the only person in
the whole wide world of Microsoft Excel users that thinks that it is
important to draw "True" "Straight" "Fixed in Space" lines instead of
"Bogus-False" "Jagged" lines that wander across the spreadsheet as you
scroll up and down. After pursuing this problem in Visual Basic I have
determined that there are so many things to flutz with in the
properties editor of the shape object I guess I better go check out
OpenOffice.Org.

This one has me stumped. I tried changing the printer stuff to get
different slopes, but the spreadsheet view is just the same
regardless.

"Mysterious Magical Moving Lines"

Line 13 is the first line with the least slope to emerge from the
thick line when scrolling down. Something is changing on the screen as
this occurs either the slope of the thick line or the slope of line
13. Once it emerges, it seems to be correctly sloped as you can follow
the line down from row 186 column P all the way down to row 1720
column ED where the line pierces all of the highlighted cells directly
through the center. I can also follow this line back up from row 186
Column P up from "D0" through "100->110->120->130->140->150->160->210-

230->310->1110->11010->0" where the thick line apparently has this

same slope and pierces the same cells roughly through the centers.
This can be followed manually by starting at the first "D0" row 186
column P, and then arrow left 1, up 13 and left 1 repeatedly to the
top.

Line 22 however is supposed to be more steeply sloped, and also
appears as the leftmost part of the thick line. This line does not
emerge until around row 1258 column BG "22:0[57]". By the time you
scroll back up to row 1038, the line has shifted right 3 and 1/2
columns from where it should be.

The other weird thing that I notice is the parallel lines in this area
do a funny skew thing when the up / down scroll buttons on the excel
spreadsheet are pressed and held. All of the parallel lines bend...
Yes "all" of the "parallel lines" that are "not supposed to be
parallel" bend at a consistent vertical position on the spreadsheet
until the button icon is released. Whereas the bends instantly
disappear, and the lines all shift to a new horizontal location on the
spreadsheet and appear straight again.

I tried messing around with visual basic and looking for something
that changed within the line shape object, but nothing jumped out at
me as I moved my view screen to various locations in the spreadsheet
and the slopes were obviously different. Here are some typical values
for lines 13 and 22.

Line 13 Top = 44.25
Width = 7428
Visible = msoTrue
Rotation = 0
Placement = xlMoveAndSize (This looks suspicious
huh!)
Name = "Line 13"
LockAspectRatio = msoFalse (Again suspicious
looking)
Left = 218.25
ID = 1037
Height = 24459 (which is equal to nodes 24503.25 -
445.25)
ConnectionSiteCount = 2
Nodes Item1 Points(1,1) = 7646.25, Points(1,2) = 24503.25
Item2 Points(1,1) = 218.45, Points(1,2) =
44.25
BottomRightCorner/Cell/Whatever
Column=134, Row=1720
Orientation=-4128
Text=Value2="13:0[132]"
Top=24495.75
Width=56.25
VerticalAlign=-4107
Left=7615.5
HorizontalAlign=-4152
Height=RowHeight=14.25
ShrinkToFit=False
ColumnWidth=10
TopLeftCorner/Cell/Whatever
Column=3, Row=4
Orientation=-4128
Text="0"
Top=42.75
Width=123.75
VerticalAllign=-4107
Left=156
HorizontalAlign=-4152
Height=RowHeight=14.25
ShrinkToFit= (didn't check this
for some reason? So I don't know what the value was.)
ColumnWidth=22.86



Line 22 was virtually identical, except for the following
Nodes Item1 Points(1,1) = 7647, Points(1,2)=41433
Item2 Points(1,1) = 216,
Points(1,2)= 42.75
Height=41390.2
Left=216
Width=7431
T-L-C Column=3 Row=3
ColumnWidth=22.86
Left=156
Text="1"
Top=28.5
RowHeight=14.25
Width=123.75
B-R-C again was the same based on the "Nodes"
information... and never changed even as the line changed slope on the
screen.

Don't have a clue,
Chris

 

[O5O]

I don't know people... I can't believe that I am the only person in

            Left = 218.25
            ID = 1037
            Height = 24459     (which is equal to nodes24503.25 -
445.25)

Typeo Correction Follows
24503.25 - 44.25 = 24459
....
"not"
24503.25 - "445.25" = 24459

 

[O5O]

Problem Solved!

At least for me! Those who continue to rely on Microsoft Excel....

After loading up OpenOffice.Org all of the drawn lines lined up and
printed out exactly as intended.

In order of increasing file size:

http://primesfl.christopherthompson.me/FactorTableWithDiagonals32+65Page01-OOo-840x840.jpg

http://primesfl.christopherthompson.me/FactorTableWithDiagonals32+65Page01-OOo.mdi

http://primesfl.christopherthompson.me/FactorTableWithDiagonals32+65.pdf

http://primesfl.christopherthompson.me/FactorTableWithDiagonals32+65Page01-OOo.tif

http://primesfl.christopherthompson.me/FactorTableWithDiagonals32+65Page01-OOo-10500x10500.jpg

I'd like to thank everyone at OpenOffice.Org for their continued
support.

Chris.