I work on a project and i want to know Why there is a difference in font size(width) on web between Windows and Mac OS X. I found that all the browsers on Mac will have the same size, but in the Windows it differ from browser to anther.
i frustrated and wait to here from you.
My question now why there is a difference in width between them?
There are many possible reasons:
Different fonts. Very few Mac fonts are identical to fonts on Windows. (It's not clear if you're expecting the Windows results to match the Mac results or just for them to be consistent on Windows.)
Different default sizes. Most browsers have defaults for font and size, and they may not all be the same.
Different interpretations of font size. When you say you want (for example) a 10-point font, it's not entirely well-defined what that means. There are true points (1/72.27 inch) but more commonly computer points (1/72 inch). Do you want the character cell height? With or without internal leading? Or did you mean the actual character height or merely the font's ascent? Different browsers may choose to interpret sizes differently.
Different resolutions. Browsers may handle different screen resolutions differently. Windows has a concept of a "logical inch", which is typically larger than a true inch on displays. But how much larger is customizable by the user. Some browsers may ignore the logical inch and use the actual DPI of the device (or at least what they think the DPI is--the OS may not actually know).
Different rendering technologies. Whether you use hinting, antialiasing, subpixel rendering (e.g., ClearType), or some combination of these can slightly affect the width of text (even if everyone agrees on the exact font and the exact vertical size).
Different scales. Most browsers provide a scaling feature, and it's possible that they aren't defaulting to the same value on different browsers. Also note that as you change the scale, the text width often won't scale linearly (see #5).
Any one of these issues can lead to differences in text width (which can cascade into different word wrapping choices), making pages look different from browser to browser and machine to machine. In many cases, you might have a combination of these issues thwarting consistency.
The solution is to design layouts to be flexible. Don't create implicit dependencies on font sizes by hardcoding things (like the size of a ) and expect the text to always fit. Generally, choose sizes relative to the size of the text, and be prepared for variation in the actual text size.
There's a difference because there is no standard that mandates the text size for web page rendering. And so browser vendors are free to render text at whatever size they wish.
I've run into this problem working on HTML ads that need to render consistently. In such situations, elements even a few pixels off can make a design look amateur.
One way to get more accurate cross-platform results is to specify pixel values rather than points or ems. Such text will render at the same size regardless of device resolution, and will still scale properly when zooming in and out. Even on a Retina/HD display, since a CSS pixel isn't necessarily the same as a device pixel.
In addition, forcing the use of either a web font or a very common font, along with explicitly setting the anti-aliasing method, will get you even closer to pixel-perfect results. I've found the code below to render nearly identically regardless of environment.
html, body {
font-family: Arial, sans-serif;
font-size: 13px;
-webkit-font-smoothing: antialiased;
font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
Related
Todays displays have a quite huge range in size and resolution. For example, my 34.5cm × 19.5cm display (resulting in a diagonal of 39.6cm or 15.6") has 1366 × 768 pixels, whereas the MacBook Pro (3rd generation) with a 15" diagonal has 2880×1800 pixels.
Multiple people complained that everything is too small with such high resolution displays (see example). That is simple to explain when developers use pixels to define their GUI. For "traditional displays", this is not a big problem as the pixels might have about the same size on most monitors. But on the new monitors with much higher pixel density the pixels are simply smaller.
So how can / should user interface developers deal with that problem? Is it possible to get the physical size of the screen? Is it possible to set physical sizes instead of pixel-based ones? Is that still a problem (it's been a while since I last read about it) or was that fixed meanwhile?
(While css seems to support cm, when I try here it, it is not the set size).
how can / should user interface developers deal with that problem?
Use a toolkit or framework that support resolution independence. WPF is built from the ground up to be resolution-independent, but even old framework like Windows Forms can learn new tricks. OSX/iOS and Windows (or browser if we're talking about web) itself may try to take care the problem by automatic scaling, but if there's bitmap graphic involved, developers might need to provide different bitmaps such in Android (which face most varying resolution and densities compared to other OS)
Is it possible to get the physical size of the screen?
No, and developers shouldn't care about it. Developers should only care about the class of the device (say, different UI for tablet and smartphone), and perhaps the DPI to decide which bitmap resource to use. Vector resource and font should be scaled by the framework.
Is that still a problem (it's been a while since I last read about it) or was that fixed meanwhile?
Depend on when you last read about it. Windows support is still spotty, even for the internal apps itself, and while anyone developing in WPF or UWP have it easy, don't expect major third party apps to join soon. OSX display scaling seems to work a bit better, while modern mobile OS are either running on limited range of resolution (iOS and Windows Phone) or handle every resolution imaginable quite nicely (Android)
There are a few ways to deal with different screen sizes, for example when I make mobile apps in java, I either use DIP(Density Independent Pixels; They stay at a fixed size) or make objects occupy a percentage of the screen with simple math. As for web development, you can use VW and VH (Viewport Width and Viewport Height), by adding these to the end of a value instead of px, the objects take up a percentage of the viewport. For example 100vh takes 100% of the viewport height. Then what I think is the best way to do it, but time consuming, is to use a library like Bootstrap that automatically resizes elements, even when the window is resized. W3Schools has a good tutorial on bootstrap and more detailed explainations on any of these options can be looked up with an easy google search.
The design of the GUI in today display diversity era is real challenge. I would suggest several hints, mainly about the GUI applications design:
Never set or expect constant pixel size of the text - the user can change it from the system settings of the OS. Use some real-world measures for the text and check its pixel size when drawing. Provide some way to put the random size text in the boundaries of the window.
Never set or expect constant pixel size of the GUI widgets. Try to position them on the window in some adaptive way - according to the size of the window. Most GUI widget toolkits today have such instruments.
Never set or expect constant pixel size dialog windows. Let the OS to choose the size for you and then use what you get (X). Or, if you need to set some size and position (Windows), define it as a percent of the screen size.
If possible use scalable image formats for the icons. SVG is great for icons actually. Using sets of bitmap icons with different sizes is acceptable, but highly non-optimal as memory use and still will not provide perfect scaling in most cases.
My question is about how font handling needs to be changed in order to work correctly under Windows 7. I'm sure that I've made an assumption about something that was valid before, but is no longer valid. But I don't even know where to begin looking! I'm praying someone can help! Here are the details as I understand them (I've also posted this question on a Microsoft Windows Developers forum, but they're not answering):
Yes, I'm behind the times (heck, I still write WIN32 code in plain C!) I have a 10 yr old DLL I wrote that mimics an even older DOS screen I/O library within the client area of a window. Needless to say, it only allows the use of fixed-width fonts. When some of the programs using the DLL have been moved to Windows 7, there is a strange flickering that appears when a fixed-width TRUE TYPE font is used (bitmap fonts still work perfectly.) We've tracked the problem down to the fact that a single character written with ExtTextOut is wider than it should be. I've checked the measurements three different ways (by using GetTextExtentPoint32 on a 132 character string and dividing by 132, by calling GetTextMetrics and even by using GetCharABCWidths for all 256 characters) and they all agree that the font is the same width. But ExtTextOut is rendering the background rectangle one or two pixels wider than the font width. Either than, or it is beginning the background rendering a pixel or two to the left of the position given in the parameters [I call it like this: ExtTextOut( hdc, r.left, r.top, ETO_OPAQUE, &r, &ch, 1, NULL ).] And remember, this EXACT code worked perfectly under Windows 2000, Windows XP and, with bitmap fonts on Windows 7 -- but it no longer works correctly with fixed-width true type fonts under Windows 7.
For anyone who isn't grasping what I need to do: try to imagine writing one character per square on a piece of graph paper. Every square uses the same font, but may have a different foreground and/or background color. I use TA_TOP|TA_LEFT text alignment, because it is the simplest and any consistently applied alignment should work for a fixed-width font.
What I'm seeing is that ExtTextOut is emitting a larger background rectangle than I've specified in the RECT * parameter. Since the rectangle I'm providing is created from the reported size of the font, this should NEVER happen -- and it never happened on Windows XP and earlier, and doesn't happen with bitmap (i.e. .FON) fonts under Windows 7, either. But it ALWAYS happens with fixed-width TrueType fonts under Windows 7. This is with the EXACT SAME EXECUTABLE running on Windows 2000, Windows XP and Windows 7 (32 & 64.) While I would love to simply say Windows 7 has a bug, I'm more inclined to believe that some fundamental assumption that I've made about font handling under Windows is no longer true (after 20 years of writing software for Windows.)
But I have no idea how or where to discover what that might be! Please, PLEASE help me!
--- ammendment ---
For anyone interested, I've managed to work around what I am considering a bug -- until I find documentation to the contrary. My workaround consists of two changes to my library:
Use the size returned from GetTextExtentPoint32() of an 'X' instead
of data from TEXTMETRICS.
Include the ETO_CLIPPING flag in all ExtTextOut() calls.
Previously, I was using tmHeight+tmExternalLeading for the number of pixels between the tops of consecutive rows of text, as is documented. I discovered that the size.cy value coming back from the GetTextExtentPoint32() wasn't the same and seemed more accurate. The worst example I found was the OCRB true type font. Here's what I saw in the debugger for the OCRB font I'd created (using the system font selection dialog):
ocrbtm.tmHeight = 11
ocrbtm.tmExternalLeading = 7
ocrbsize.cy = 11
So, for some reason that I've yet to discover, Windows is ignoring the external leading value defined for the OCRB font. Using the size value instead of the TM results in nice, neat, close packed text, which is just what I wanted.
The ETO_CLIPPING flag should not be necessary for me because I am setting the rectangle to exactly the dimensions of a single character and using ETO_OPAQUE to fill in the background (and overwrite the previous cell content.) But without the clipping flag, a single character is wider than either the size, text metric, or ABC width would indicate -- at least, that is true based on all of the documentation I've found so far.
I believe that HEIGHT issue has existed for a long time, but the rest was unnecessary until we ran our software under Windows 7. I'm appending this to my question to see if anyone can explain what I obviously don't understand.
-- ammendment 2 --
1: All documentation I can find says that tmHeight+tmExternalLeading should produce single spaced lines of text. Period. But that is not always true and I cannot find documentation indicating how Windows determines the different values that are sometimes returned by GetTextExtentPoint32().
2: under Win7 (maybe Vista) ExtTextOut started filling in a little more background than it should (by adding a couple extra pixels to the right), but only when a true type font is selected. It does this even if the rectangle is double the expected size of the character (in BOTH dimensions.) DPI/Scaling might be a factor, but since my system is set to 100%, it would seem that Windows is having trouble with a 1:1 scaling factor and that would seem to be a bug. The fact that it only affects true type and not bitmap (.FON) fonts also seems to rule out scaling (unless there is a bug in the scaling system), since Windows should attempt to scale all of the text, not just some of it. Also, there's a greyed (but checked) setting "Use Windows XP style DPI scaling" in the "Custom DPI Setting" dialog. Lastly, this entire issue may be a result of my running under the Windows Classic theme instead of one of the Aero or other Win7 native themes.
-- ammendment 3 --
Simply calling SetProcessDPIAware() has no effect on the issue I'm having. Since my problem exists at the 100% DPI setting (scale 1:1), if my problem is DPI-related, then I must have discovered a bug in the DPI virtualization because this is how Microsoft describes the feature:
This feature works by providing "virtualized" system metrics and UI elements to the application, as if it were running at 96 DPI. The application then renders to a 96-DPI off-screen surface, and the Desktop Windows Manager scales the resulting application window to match the DPI setting.
All of my settings show that I'm at 100% scaling, and looking in the custom settings box clearly shows that means 96 DPI. So, if the DPI virtualization from 96 DPI to 96 DPI is not working for my fixed-width true type fonts, then Windows has a problem, right? Or is there some function I need to call (or stop calling?) in order allow the DPI virtualizer to work correctly?
I'm still not convinced that the supposed scaling issue actually has as much to do with the font SIZE as I originally thought. That's because the problem is manifesting in the background rectangle being filled by ExtTextOut() instead of the text character being emitted. The background rectangle gets enlarged a bit when the font is true type. I've also now verified that this problem occurs whether using the Windows Classic theme or the standard Windows Aero theme. Now to build a simplified example so others can experiment with it.
-- ammendment 4 --
I've created a minimal demo program that shows what I'm seeing (and what I'm doing.) The Visual Studio 2010 project/source may be downloaded from http://www.svalli.com/files/fwtt.7z -- I intentionally didn't include executables because I don't want to risk spreading malware. The program has you choose a fixed-width font and then writes two 5x5 character grids to the client area, one created using the GetTextExtentPoint32 size and one using the TEXTMETRIC size as documented by Microsoft. The grids are in a black&white checkerboard pattern with a yellow on red character written last into the center to show the overlap effect (you may need a zoom utility to see it clearly.) The program also draws a string that starts with 5 X's just below the grid, starting at the same left offset, to be used as a comparison for my method of placing individual characters (I match the string.) The menu allows toggling clipping on/off in ExtTextOut and selection of other fonts. There is also a command line option dpiaware (case-sensitive) that causes the program to call SetProcessDPIAware() when it starts up, so that the effect of that call may also be evaluated.
From creating this I've learned that ExtTextOut is filling the correct background rectangle, but the character being rendered with an opaque background may be wider than it should be and may not even begin where ExtTextOut was told to begin drawing! I said "should be" because the character spacing I'm ending up with matches what I get when I have ExtTextOut render a whole string. The overlap may apparently be on either or both sides of the given rectangle, for example, OCRB adds an extra pixel to both the left and right sides of the character cell while the other true type fonts I've checked add two pixels to the right edge.
I really want to do this the "right" way, but I cannot find any documentation that shows what I'm doing wrong or am missing. Well, I am probably missing something for DPI Aware at scales other than 100%, but otherwise, I'm just baffled.
-- ammendment 5 --
Slightly less baffled... the problem is caused by ClearType. Turning off ClearType made all of the fonts work again. Turning ON ClearType under XP causes the same problem. Apparently ClearType can silently (until someone tells me how to detect it) stretch characters horizontally by a couple pixels in order to make space for the shaded pixels it adds to smooth things out.
Is clipping the only way around this problem?
-- ammendment 6 --
Partial answer to my clipping question above: When creating a new font I now do the following (in pseudo code):
CreateFontIndirect
SelectFont
GetTextMetrics
if( (tmPitchAndFamily & TMPF_TRUETYPE) && Win6.x or above )
if( SystemParametersInfo( SPI_GETCLEARTYPE ) )
lfQuality = NONANTIALIASED_QUALITY
DeleteObject( font )
CreateFontIndirect
Without enabling clipping this almost always works with the font sizes I'm using, though I've found a few that still render an extra pixel to the right (or left) of the character cell. Luckily, those appear to be free fonts found on the internet, so their overall quality might be below the standards of professional font foundries.
If anyone can find a better answer, I'd really, REALLY love to hear it! Until then, I think this is as good as it will get. Thanks for reading this far!
Make sure your code is high DPI aware, and then tell the OS that your process is DPI aware.
If you don't tell the OS that you're DPI aware, some of the measurement functions will lie and give you numbers based on the assumption that the display DPI is actually 96 dpi regardless of what it really is. Meanwhile, the drawing functions will try to scale in the other direction. For simple high-level drawing, this approach generally works (though it often leads to fuzzy text). For small measurements and precise placement of individual characters, this often results in round off problems that lead to things like inconsistent font sizes. This behavior was introduced in Windows Vista.
You can see it all the time in Visual Studio 2010+ as the syntax highlighter colors the text and words shift by a couple pixels here and there as you type. Really frickin' annoying.
Regarding the amendment:
tmExternalLeading is simply a recommendation from the font designer as to how much extra space to put between lines of text. MSDN documentation typically says, "the amount of extra leading (space) that the application adds between rows." Well, you're the application, so the "Right Thing To Do" is to add it between rows when you're drawing text yourself, but it really is up to you. (I suspect higher level functions like DrawText will use it.
It is perfectly correct for GetTextExtentPoint32 (and friends) to return a size.cy equal to tmHeight and to ignore tmExternalLeading. As the programmer, it's ultimately your choice how much leading to actually use.
You can see that this with some simply drawing code. Select a font with a non-zero tmExternalLeading (Arial works for me). Draw some text using TextOut and a unique background color. Then measure the text with GetTextExtentPoint32 and draw some lines based on the values you get back. You'll see that the background color rectangle excludes the external leading. External leading is just that: external. It's not in the bounds of the character cell.
// Draw the sample text with an opaque background.
assert(::GetMapMode(ps.hdc) == MM_TEXT);
assert(::GetBkMode(ps.hdc) == OPAQUE);
assert(::GetTextAlign(ps.hdc) == TA_TOP);
COLORREF rgbOld = ::SetBkColor(ps.hdc, RGB(0xC0, 0xFF, 0xC0));
::TextOutW(ps.hdc, x, y, pszText, cchText);
::SetBkColor(ps.hdc, rgbOld);
// This vertical line at the right side of the text shows that opaque
// background is exactly the height returned by GetTextExtentPoint32.
SIZE size = {0};
if (::GetTextExtentPoint32W(ps.hdc, pszText, cchText, &size)) {
::MoveToEx(ps.hdc, x + size.cx, y, NULL);
::LineTo(ps.hdc, x + size.cx, y + size.cy);
}
// These horizontal lines show the normal line spacing, taking into
// account tmExternalLeading.
assert(tm.tmExternalLeading > 0); // ensure it's an interesting case
::MoveToEx(ps.hdc, x, y, NULL);
::LineTo(ps.hdc, x + size.cx, y); // top of this line
const int yNext = y + tm.tmHeight + tm.tmExternalLeading;
::MoveToEx(ps.hdc, x, yNext, NULL);
::LineTo(ps.hdc, x + size.cx, yNext); // top of next line
The gap between the bottom of the colored rectangle and the top of the next line represents the external leading, which is always outside the character cell.
OCR-B is designed for reliable optical character recognition in banking equipment. Having a large external leading (relative to the height of the actual text) may be appropriate for some OCR applications. For this particular font, it's probably not an aesthetic choice.
I really have scoured Google for a similar question and found nothing, which confuses me.
Anyway, on this
http://dev.subverb.net/index.php
The menu writing is different thicknesses across the two browsers. It is the same in both when the font-weight is reduced to 500, but when it is 600 it is what I want in firefox but noticeably thicker in Chrome. This also breaks my design.
I just can't figure out what this might be...any ideas?
You can't rely on font-width consistency. It's not just across browsers that it differs, but it also differs considerably across operating systems. Instead you have to create your designs to allow for some leeway in font width.
For slightly better consistency, try using html 5 #font-face, which is now impemented across all modern browsers. But even then, width can't be gauranteed -- that will just guarantee that at least the font defintion is the same.
Finally, you could use images for perfect consistency, but that is strongly discouraged. It's better to just allow some wiggle room in your designs.
Don't use the numeric values of font-weight. They aren't useful for picking multiple weights of a font family because:
browser support is poor and inconsistent
font support (describing their weights as part of a complete family) is poor
none of the built-in OS fonts you'll use in your font-family: rules have extra weights other than normal and bold anyway.
font-weight: 600 has long been problematic. Both Opera and Chrome appear to use synthetically-created bold fonts on weight 600, rather than the genuine bold font variant that is used from weight 700 up. (Synthetic fonts are usually used when bold or italic is requested on a family that doesn't have a bold/italic variant.) In addition, on Firefox/OSX, 600 used to be taken as normal.
The correct weight value that aligns with bold is 700. Better just stick with the plain normal and bold values.
Incidentally, you've also got a font-family mis-spelling (san-serif should be sans-serif).
What are the use cases for defining distances in a web layout for pixels and percentages?
Is there any downside to using pixels with respect to multiple resolutions? Will they scale correctly?
Percentage layout
This is generally referred to as fluid layout. Your elements will take a defined percentage of the total space available to them. This available space is determined by the element's parent.
When using percentage layouts, it's a good idea to specify a min-width and max-width on your design so that it remains usable at very low and high resolutions.
Pros
Scales with screen size, therefore get to use more space if it's available.
Cons
Makes it more difficult to know the exact position of something on screen. As a result, it can make creating precise layouts more difficult.
Can lead to unexpected layouts if child elements are fixed width (i.e. an image) and end up being larger than their fluid width parent.
Pixel layout
This is usually known as fixed layout. Your element will always be the same defined pixel size and will not take available parent space into account.
Pros
Always know an element's exact size.
Creating precise layout is easier.
Cons
You don't scale with resolutions. Your layout will always be the same width, making for wasted space when people have high resolutions.
I'll reply to this one by telling you a true story.
We had a client which wanted a map view, made up of divs.
Suddenly, he decided he wanted zooming as well.
I had to change all those fine-grained pixel positions to percentages.
Causing the wrapping div to change width/height (in pixels) relatively, we got a nice and reasonable zooming effect.
NB: During design phase, I quickly drew up a prototype, I'm going to look it up for you...
Edit: Nope, nothing found, sorry.
For percentages you have to have a base value, so it would be something like an image that has a size set outside of the CSS, if you just use a percentage on a DIV, for example, it wouldn't have anything to base that off of except the actual size it was by its being filled with text, for example, so it would not be practical to use percentages as a way to size it as it would rarely produce the desired output, if you are re-sizing something with a pixel size, such as by using javascript, you could resize by a percentage that would resize the original value (in pixels)
They do different things.
Pixel values always relate to hypothetical pixels on the output device.
Percent values relate to the computed size of the containing block (for block elements) or the containing block's font size (for font sizes).
Em and pt values relate to the current font size.
If you want your item to scale with its container, use percentages. If you want it to scale with font size, use ems. If you don't want it to scale at all, use pixels.
And then there's IE6; whoever 'implemented' CSS in that thing obviously had no idea what the various CSS properties were supposed to do.
Be careful using percentages, webkit browsers don't calculate percentages correctly. It's all because webkit doesn't calculate subpixels correct.
Detailed information about this issue can be read here: Percentage bugs in webkit
I would recommend you to always use pixels to don't have any layout dimensions differences between browsers.
Most statistics out there for browser stats show you the resolution of the screen.
Thats fine for Windows where browsers typically open full screen and most people leave it as that. So if the browser stats say 1024x768 you just need to subtract a little width for the browser chrome.
On a Mac however browsers typically dont open full screen.
What kind of width is a mac browser likely to be when it opens as such.
I'm thinking of a width of 960 as recommended by what-is-the-best-absolute-width-for-a-webpage. However I'm wondering if this is equally as good width for a mac?
I'm not sure when Apple last made 1280x768 laptops or screens anyway so its probably a non issue. It just frustrates me a little that most places I find statistics on screen resolution dont show you the actual available width.
Design away, my friend. The Apple display packs many pixels.
A window will open to fullscreen on the Mac, no problem. It simply conserves space when it can, unlike the PC behavior, which will fill the screen regardless of how much space the site actually needs.
In other words, the case where the Mac doesn't open the window fullscreen is the case where the user has room to spare. So those are cases you don't need to worry about. If a Mac OS browser has to go fullscreen to fit the site, it will. But when the site is only 960px and the user has a gorgeous 2560x1600 cinema display, it will stop at 960, enough to eliminate the horizontal scrollbars.
The reason people notice this behavior is because apple displays are often too big, so the fullscreen is often not needed. The smallest display Apple ships on any notebook is a roomy 1280x800. The smallest iMac is already 1680x1050. They only get bigger from there.
As far as choosing your dimensions, the normal considerations apply. Play to your lowest common denominator. Simply know that the screen resolution of even a modest apple display will be on par with the industry standard. If you're willing to go 990 or 960 for the PC, it will also be acceptable for the Mac.
(source: akamai.net)
Most of the designers I work with are more concerned with making designs too narrow for Apple users. They design in the 960 pixel realm so that it works for the larger audience, and then they try to find creative ways of showing a little extra love to the owners of that giant cinema display.
Sidenote: #Taylor Marshall asks a good question: "What if the widths are all set to 100%? How big does [the browser window] get..?"
Without any constraints, Firefox will simply go fullscreen, like the MS Windows behavior. Safari will expand up to a width of 800px, unless the width is already greater than 800, in which case it maintains that width and only modifies the window height. Of course, if there aren't any hard width values, then the design is a liquid layout, so the concern about designing for a particular width is somewhat altered. Usually good liquid layouts, despite being displayed correctly at any dimension, are nonetheless designed to be viewed at reasonable window widths.
Instead of fretting about absolute widths, why not do percentages, and give it a min-width so that it doesn't start to look too terribly bad at lower resolutions?
The min-width could be where your 960 or 990 comes into play.
The stats you've read are based on actual screen sizes of visitors. If you're looking for stats on what size the average user's browser is at, you'll need to look elsewhere. Also I never browse full screen on windows or mac OS, and I consider a design that's wider than 960px or so to be very annoying. (it's 2^16+2^17+2^18+2^19)
I'm feeling lucky for browser size. See the second chart.