As has been pointed out, there’s n allocation issue here.
To summarize: The download file is 1.07 Gb compressed, and over 7.5 Gb expanded, while Windows allows you 7.44 Gb of space on an 8 Gb card.
Going with the 16.04 beta 2 as a reference, there’s this to consider: That image was just over 4.5 Gb expanded, out of a 1.07ish compressed file.
The good folks who created the Pi port were kind enough to provide a two click solution for the need to expand the disk that was a manual operation in the prior release. It was two clicks because you had to click a button to reach the actual trigger.
My guess is that either they created the compressed file from an expanded image in error, or in an attempt to be helpful and eliminating the step, they inadvertently overlooked how Windows allocates reserved and user space on media.
The fact that that the compressed file is nearly the same size in the beta and release versions speaks to this theory. Empty space will compress to a couple of bytes. If there were additional packages, there would have been a noticeable size disparity between the two images.
Writing to a larger card will reveal the truth in the short term (I’ll be doing that tonight). In the long term, the best fix will be to withdraw the current compressed file and replace it with the unexpanded one like the beta was, or change the announcement to reflect needing a 16 Gb card for it.
Also, I just read about a Linux and Windows tool called etcher (check the DesignSpark Twitter feed). Since it’s a wrapper for the Unix dd command, the Windows port may work where the recommended Windows Disk Imager cannot…
Good luck to all!