Dreamweaver extract feature

Question

Hi everybody! How are you all? In DWCC, I am using the extract feature from Photoshop which I really like and find very helpful. Just one odd thing I noticed. For example, When you load a mockup and I click on a logo. (I know I should drag it over to put in as an image but just for the sake of example) It will show a drop down of the CSS properties and I can also copy the text. I created a div called #top and I copied the properties. I then copied the text and pasted it in, in the body of the doc so it was <div id="top">Text</div> Really easy and helps with time.
I noticed, that the logo which is a name seems to not fit the width and height that I was given in the extract. It always pushes the last name to the next line. I don't know why. I find it to be very odd. I will include screen pics. When I drag the logo over as an image, there is no issue because it just comes directly from Photoshop. I have been scratching my head trying to figure out why this is doing this. If I repeat everything I just said but used the word Web Design or something else it may work but then the height might be a bit off. If I type in text for a paragraph type of thing, it seems to be fine.
I created a sample mockup just to show you what I mean.
Any idea what is going on? Shouldn't the width and height match the same as the mockup? Here are some screen pics to show you what I mean. Any help would be appreciated.
Thanks!
This first screen pic shows the extract information from the name Mark Samburg.
     This second image shows what happens when I copy the styles and text. See how it bumps to the next time?
This third image shows the code.

Answer 1

I think there is some misinformation in this thread.
1) As far as I can tell, the reason why the OP's text breaks to the next line probably is caused by rounding the text size up instead of down. The extract screenshot is taken at 67.97% size, and when the DW screenshot is scaled down at that size, the extract and dw results look identical (minus the line break). I copied the same code, and decreased the font size by 1px; then it fits perfectly well. That is why I surmise that the font-size is rounded up instead of rounded down, and it happens to break the line in this and similar instances. This has nothing to do with Extract and Photoshop basing their calculations on a base of 72ppi, in my opinion.
2) the ppi setting for images on the web has no bearing at all on how those images are displayed in a browser, whether mobile or desktop. An image at 512px x512px with a 1000ppi setting and the same image with a 1ppi setting display identical in any browser. The save for web function in Photoshop removes this type of meta data, btw.
3) for screen work ppi has no real relevance. PPI is more confusing than helpful at this point. As far as I am concerned we should be talking about pixel pitch, which is what device manufacturers tend to use anyway, and it would prevent all the confusion in regards to dpi and other ppi related myths. Also read on below, and read up on this confusing mess here:
Pixels Per Inch Awareness and CSS Px
4) with retina screens a block of four pixels is generally treated as if it were one pixel by designers/web devs. Saying a designer must export their graphics at 72ppi or 96ppi has no meaning: the actual resolution in pixels is important. When a Photoshop mockup is setup in 960px width, the ppi itself is completely irrelevant. A header image at 960px by 400px renders on both non-retina and retina screens as exactly that in a static layout. For retina screens ideally a version at twice that resolution is available for the best quality (especially for GUI work): in this case a retina screen no longers treats a block of four pixels as one, and will use the full resolution of the 2x image to render it. (Note: the actual pixel conversion depends on the device's screen ppi, of course.)
Saying a designer should export at 96ppi to prevent pixelation on retina screens is a half-truth at best: it has little to do with ppi, but rather with the actual pixel dimensions/resolution of an image. If a device such as a Nexus 7 with a 323ppi screen displays an image meant to display at 512x512px created for regular screens, it will look quite fuzzy and unsharp. Let's say this is a 72ppi version, and now create a 96ppi version: 683x683px. That version will still result in a fuzzy looking version for retina screens.
Ideally we would have to create a 2134 by 2134px image instead to cater for a screen like that. But this PPI setting is only viable for this particular device at 323ppi. And ppi as a measuring stick quickly becomes quite redundant anyway under these circumstances.
Such large imagery is generally avoided, because visually most of us would not be able to discern the difference between this and a two-up image on small screens. Bandwidth also plays an important role, of course, with such a large version congesting mobile traffic too much.
Thus, we tend to choose the middle-ground for photos: 1024px by 1024px (around 150ppi, give or take). A factor of two. For GUI work or very sharp illustrative artwork this may not work very well, however. In those cases a higher resolution version would become a requirement.
That is why anyone interested in exporting bitmap work from Photoshop should be using Generator: it makes it very simple to export a low res and 2x version of the artwork (and other versions with varying formats and sizes, if need be). Then we would use an image picturefill to decide which version to display depending on the screen/device type.
When fluid design come into play, a designer should create the non-retina version at the highest resolution that is required for the maximum width. In code this can then be set to a (max-)width of 100%, so that it accommodates the layout width automatically. For retina screens a 2x version again would work well.
Another option is to save a giant version at a very low jpg quality, which can work quite well, depending on the photo. And I have failed to mention the type of image formet in relation to the best compression algorithm - which would take as much text to write about ;-)
In a nutshell, over-generalizing the web export procedure without more quantification and qualification is to be avoided. For a certain category of graphics SVG would be the best option. For others still png 8 or 24 bit. A nice comparison writeup:
retina-revolutie-follow-up
Unfortunately in Dutch, but still quite interesting.
5) the save for web function is indeed in dire need of an update, that much is true. According to W3C standards, CSS2/3 work on the basis of a 96ppi standard, and SfW is still stuck in CSS1 times. On the other hand, ppi does nothing for images for the web, so... I would not say this is much of an issue in real practical sense, as I have explained above.
More importantly, it still does not even support 8bit png files with full transparency(!). This is unforgivable. Really, it is. Another reason to switch to Generator, which does support that option. But honestly, even Generator cannot compete with the likes of Color Quantizer for png optimization, and RIOT (Radical Image Optimization Tool) for jpg optimization. Avoid Save For Web for meaningful optimization, and instead either save out a full quality png file for later optimization in CQ or RIOT, or use Generator, and optimize those a second time in CQ or RIOT. Or other tools such as ImageOptim, PngCrush, and so on. Anything BUT SfW, which is sadly responsible for huge energy wastage across the net, because most designers have no inkling how bad it is in terms of image optimization.
Images extracted with that extract function should also be checked again for optimization, by the way.