The text "THE NEW FUTURE OF YOUR COMPANY." is using a "web-safe" font. Web safe fonts are not a single font, but rather a list of fonts to try on the site visitor's computer. For example, selecting "Helvetica" in the Web Safe font list in Muse means that on a site visitor's computer the browser will use Helvetica, if it's available. However, if it's not available Muse will try "Helvetica Neue" and if that's not available "Arial" and if that's not available, any sans serif font. (This "font stack" is displayed in a tool tip if you linger over the name of a Web Safe font in the Muse font menu.)
Text that uses a "web safe" font is live in the browser and will reflow according to the font metrics of the actual font used. Web safe fonts are fast to download, friendly to search engines and screen readers, they enable site visitors to use "Find" in the browser to find words within the text and they enable selecting and copy/paste of text from the browser page. They also enable the user to change the size of the text, in some browsers, with the text reflowing and text frames growing and the layout reflowing accordingly.
The black box on the right in preview has increased in height because the text frame containing "THE NEW FUTURE OF YOUR COMPANY." was not tall enough to accommodate the extra line of text that resulted from the period wrapping to a new line. The line break caused the text frame to grow in height which caused the box below and the containing black box to grow.
There are many possible ways to avoid this depending on your priorities relative to maintain the design versus maintaining the advantages of using a Web Safe font.
1) Resize the height of the text frame in Muse Design view so that when the text wraps in the browser there's enough room for the extra line.
2) Resize the width of the text frame in Muse Design view so there's room for the period to prevent it wrapping to a new line. Note that this needs to accommodate the font metrics of Helvetica, Helvetia Neue or Arial.
3) Change to using a System Font. This will result in the text being output by Muse as an image. For this text to look it's best and an image, you'll want to set the fill color on the Text Frame to Black. This loses the advantages of using a web safe font, listed above, but will provide exactly what you see in Design view for all site visitors.
A 4th option will be available in a week when the first release of Muse is available. Muse release 1 includes support for 400+ Web Fonts served by Typekit. If you were to choose a font from that set of fonts, the same font would be used for all site visitors. This will result in the same line breaks for users on different browsers a high percentage of the time, but since some browsers support changing the size of the viewed text and the line breaking code is different in each browser you should still plan to accommodate some variance in line breaks for different site visitors on different machines/browsers.
Zak, it appears that Aaron is observing a quirky reflow of text on a single computer between design and preview modes in Muse. This would not be an issue of font substitution. While what you have said is relevant for other users, it does not seem to address why Muse is displaying two different text flows on the same computer. Isn't Muse supposed to render the same appearance between design and preview modes? Why can't the designer simply design in preview mode? A designer working in Firebug has a better view of their output than what Muse is producing for Aaron.
The difference in line breaking of live text (text frames that use web safe fonts) in Design view and Preview is due to the fact different code is responsible for line breaking in the two situations. We considered working to compensate for this, but decided the current behavior is actually very representative of the reality of viewing live text in different browsers (even on the same machine and with the same fonts). Differences in line breaks can be caused by the most minute of differences in calculations within two different line breaking algorithms, and each browser has it's own unique code for calculating line breaks. Thus by leaving this difference in place between Design view and Preview we raise the likelihood that Muse users will be forced to learn the idiosyncrasies of working with live text on web pages earlier in their website creation process, rather than after having taken their site live. Internally we've also discussed potential features that would show the Preview of a site using varying font metrics in order to simulate the changes in line breaks and text frame sizes that are likely to occur given specific font usage, but thus far such work has remained low on the overall priority list.