• (disco)

Defect #11018635432 Specification: Printout can be infinitely long. Actual: Printout is limited to 3.4e+38 mm. Although this is sufficient for most situations, it is not infinite.

• (disco) in reply to HardwareGeek
`````` public override SizeF PaperSizeInMM
{
get { return new SizeF(110F, float.PositiveInfinity); }
}
``````

Fixed!

• (disco)

To put this in perspective: float.MaxValue here is 3.4x10^38 millimetres. This equates to about 11,018,635,432 gigaparsecs. A single parsec is 13 trillion kilometres; a gigaparsec is 1 billion of those. The observable universe is a sphere with a diameter of about 29 gigaparsecs.

Or about 386.4 million observable universes. Apparently.

• (disco) in reply to PJH

Knowing my math skills, I did no calculations beyond what the submitter suggested :)

• (disco)

Printing out that report....that my friends is how we go to mars and beyond.

• (disco) in reply to RFoxmich
RFoxmich:
Printing out that report....that my friends is how we go to mars and beyond.

Nonsense. You would only reach an altitude of 67km before you would have to change toner.

• (disco)

Infinite? Hmm. Trick question is where you put the end summary page.

• (disco) in reply to chreng
chreng:
Infinite? Hmm. Trick question is where you put the end summary page.

Page 42?

• (disco)
``````public override SizeF PaperSizeInMM
{
// Fuck you Bert
get { return new SizeF(110F, float.MaxValue); }
}
``````
• (disco) in reply to chreng
chreng:
Infinite? Hmm. Trick question is where you put the end summary page.

Just change the printer settings to print in reverse order. The infinitieth page will print first then.

• (disco)

Why would someone necessarily need to know the length of the paper? I suppose for tracking purposes.

But isn't there generally a "standard" that says "this font on this machine is X mm", or at least some sort of conversion?

So I'd think all you'd really need to do is take the number of rows (not counting the "header and footer" that we all know is on receipts), and multiply it by the size (in MM) of the font.

Couldn't you??

• (disco) in reply to Mikael_Svahnberg

Ahem, thermal printers.. No toner, see? You will run out of paper tho...

• (disco)

"[...] and Bert was much more comfortable with the looser specs in Agile projects."

Of course he is, if "agile" means much work for the developers and little work and planning for the Business Analysts, the Business Analysts are much more comfortable with it.

"But it wasn't just silly: it was bug-inducingly silly. On some versions of Windows, this would cause GDI+ to throw up its proverbial hands and emit a "Generic Error", crashing the self-check machine."

Why do they need GDI+ if it's only for self-checking (input validation?)? Seems to be more behind it and that's why the developer needs specs. And just from this code snippet I can't really see the WTF.

• (disco) in reply to HurleyBurley

Of course he is, if "agile" means much work for the developers and little work and planning for the Business Analysts, the Business Analysts are much more comfortable with it.

It's like this where I work. It seems like those above us are just flying by the seat of their pants as far as projects go...It would be like if you looked at a map, and said, "We're gonna start here, and end here", and then you just drove around until you got to your destination, instead of following the map.

• (disco) in reply to John2
John2:
Why would someone necessarily need to know the length of the paper? I suppose for tracking purposes.

But isn't there generally a "standard" that says "this font on this machine is X mm", or at least some sort of conversion?

So I'd think all you'd really need to do is take the number of rows (not counting the "header and footer" that we all know is on receipts), and multiply it by the size (in MM) of the font.

Couldn't you??

I think that's backwards. Why would you set the paper size to the size of the document rather than set the paper size to the actual size of the paper? The code looks like C#, so you could just open a PageSetupDialog and let the user deal with it - since he knows what size paper he has in the printer.

• (disco) in reply to Jaime

I think it's because you really won't know how long the paper will be once printed. You'll know the width of the paper, but the length could vary based on the number of purchased items, and what's included on the receipt. In other words, a receipt with 2 items on it may have a significantly shorter paper length than a receipt with 50 items on it.

• (disco) in reply to chreng

At the end.

• (disco) in reply to John2

Either set the page size to the size of a line with no margins or set the page size after rendering the content.

• (disco) in reply to Jaime
Jaime:
The code looks like C#, so you could just open a PageSetupDialog and let the user deal with it - since he knows what size paper he has in the printer.

The article did state that this was for a supermarket self-checkout. The paper size is fixed by the length of roll they can put in the machine, and users aren't going to have a clue what the size is (and that's true for both the end-users or the checkout supervisor).

• (disco) in reply to dkf

Yea, I missed that the first time.

• (disco)

Bert: Dear Ernie, it's an interesting question and I will let you do the study for the best accurate answer. Go buy 20 rolls of thermal paper for the specified printer. Then, in your office, on your table, unroll them and measure each of them. Well, in fact, to be sure, buy 5 packs of 20, if possible from each different manufacturers for that roll: we never sure which one is to be used by the customer, so better safe than sorry.

• (disco) in reply to PJH
PJH:
Or about [s]386.4[/s] **364.4** million observable universes **plus one ear**. Apparently.

FTFY. HTH.

• (disco)

Step 1: Write report: "How to get to Mars".

Step 2: Get a printer that adds new pages to the bottom of the pile rather than the top. (I've seen a fancy collating copier that did this, although I don't know if any such printers still exist as delivering the printout upside-down is much simpler.)

Step 3: Sit on the printer's output bin.

Step 4: Print report.

• (disco) in reply to PJH

Probably nitpicking, but THIS is the "right" formula.

• (disco) in reply to LorenPechtel

You're going to need a LOT of paper.

Anyone want to do a cost analysis of interplanetary travel via printer vs chemical rockets?

• (disco) in reply to chreng
chreng:
Infinite? Hmm. Trick question is where you put the end summary page.
Mikael_Svahnberg:
Nonsense. You would only reach an altitude of 67km before you would have to change toner.

Let me reply to both of these with a simple quote:

Hitchhikers Guide To The Galaxy:
Most readers [of Dr. Dan Streetmentioner's Time Traveler's Handbook of 1001 Tense Transformations] get as far as the Future Semiconditionally Modified Subinverted Plagal Past Subjunctive Intentional before giving up; and in fact in later editions of the book all pages beyond this point have been left blank to save on printing costs.
• (disco) in reply to swayde

Simple to solve: industrial paper-making is a continuous process, so just put the printer in the paper factory.

• (disco) in reply to HurleyBurley
HurleyBurley:
Why do they need GDI+ if it's only for self-checking
Self-check out. The article mentions supermarkets.

You usually get a piece of paper that's printed from a long paper roll once you're done.

• (disco) in reply to aliceif

To be fair, the right way to do is to write each line to a serial printer. Drawing it on a surface and sending it to a windows printer is trwtf... (I've done both, serial/text only is vastly preferable

• (disco)

How many Kessel Runs is that?

• (disco) in reply to operagost

Pineapple ;)

• (disco) in reply to LorenPechtel

You'd also better hope for no wind that day or you'll get blown over when you're 500 feet off the ground.

• (disco) in reply to dkf
dkf:
The article did state that this was for a supermarket self-checkout. The paper size is fixed by the length of roll they can put in the machine, and users aren't going to have a clue what the size is (and that's true for both the end-users or the checkout supervisor).

I'm glad I've yet to see a bug that chewed up an entire spool of receipt paper, but I bet they're relatively common.

• (disco)

I'm surprised nobody has thought of this:

To infinity and beyond....

Apologies to Buzz Lightyear!

• (disco) in reply to mott555
mott555:
You're going to need a LOT of paper.
Finding some way to stop the stack toppling is going to be a more serious issue.

This discussion puts me rather in mind of the Model Rockets and Billion-Story Building episodes of What If?. I suppose Updating a Printed Wikipedia is also somewhat relevant.

• (disco) in reply to Jerome_Grimbert
Jerome_Grimbert:
Go buy 20 rolls of thermal paper for the specified printer. Then, in your office, on your table, unroll them and measure each of them.

My Dad's cousin (what does that make him to me?) was in the Navy, and told of a similar trick they used to pull on noobs. They used teletype paper that had a carbon and a second sheet, so a copy was always produced. (This would be back in the '60s).

So you're showing the noob how to load the printer. You open the roll, and what you have is paper rolled so the layers are outer-carbon-inner. Right in front of the noob, you let the outer and carbon flip around the roll, which leaves the layers in inner-outer-carbon order. You grab a handy pair of scissors, zip off the uneven ends and then...

...discover that the factory made the roll wrong: inner-outer-carbon. At this point, the noob is like, "What does that mean?" So you tell the noob he has to unroll it out in the hallway and re-roll it in the correct order.

He said the C. O. finally told them to knock it off because the noobs were blocking the hallway.

• (disco) in reply to CoyneTheDup
CoyneTheDup:
My Dad's cousin (what does that make him to me?)

Count backwards the number of generations to a common ancestor. One generation: siblings. Two generations: First cousins. Three generations: Second cousins. Or, if you nearest common relative is a great-great-...grandparent, count the gs; that's the order of cousinship. If there is a different number of generations between the common ancestor and the two descendants, the smaller number is the order of cousinship, and the difference is the order of removal.

• (disco) in reply to kjordan2001

Looks like you found the one flaw in the plan.

• (disco) in reply to Snowman25

Sure, but why is the "in lightyears" needed? All you need is the paper size / size of universe in the formula, surely? Units-conversions don't matter, when you're dividing away the units...

• (disco)

To be fair, the tape of a Turing machine needs to be of infinite length if it is to solve all problems capable of being solved with a Turing machine. Perhaps Ernie is planning to make a Turing Machine Easter egg for POS terminals.

• (disco) in reply to CoyneTheDup
CoyneTheDup:
My Dad's cousin (what does that make him to me?)

cousin once removed, of course.

• (disco) in reply to FrostCat
FrostCat:
cousin once removed, of course.

:hanzo: by 11 discohours.

• (disco) in reply to HardwareGeek

Checking for :hanzo: is a :barrier: to posting.

• (disco) in reply to random_garbage

You are, of course, right.

• (disco) in reply to PJH
PJH:
The observable universe is a sphere

which certainly isn't because of any tampering with the light that reaches us due to relativity.

• (disco) in reply to Keith
Keith:
Just change the printer settings to print in reverse order. The infinitieth page will print first then.

Well, before we had some indication of progress.

Now it's just sitting there calculating totals.

Going to troll SE Math:

https://math.stackexchange.com/questions/1256200/infinite-averages

My nerd snipe continues

I mean if I order the numbers from largest to smallest, it converges, because there are infinitely more smaller numbers than the largest. But if I order the numbers from smallest to largest, it diverges, because I don't know what the largest number is.

If you use a converging series, the average will be (infinitesimally away from) the limit. If you don't use a converging series, the average is meaningless as a concept. Or you're using one of these series that hops around within bounds (e.g., alternating between 0 and 1); they're tractable for averaging too.

My nerd snipe continues

But it was funny to watch. :D

But if I order the numbers from smallest to largest, it diverges, because I don't know what the largest number is.

Not universally true. Consider the series 0, 1, 1.5, 1.75, 1.875, … where the amount you're adding each time halves. It is ordered strictly from smallest to largest, yet the average is (infinitesimally below) 2. Why is the average the limit? Because we can discard any finite prefix of the series and still get the same average from the infinite suffix ('cos it's infinite and so vastly more important).

That argument works for any converging series.

For a series that contains an infinitely repeating finite segment (after a finite prefix, see previous argument), e.g., 0, 1, 0, 1, 0, 1, …, the average of the series is the simple average of the repeating segment (in this case, ½). You can use a functional reduction of the series to prove that.

A fractal series… requires a better grasp of Analysis than I possess, but I'd guess that a more sophisticated functional reduction would be the way to go.