As shown in the picture, there's some blank space after full screen.
GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org
On Mac OSX 10.10.3 Yosemite
This is probably because Emacs windows are character-oriented, and your monitor's resolution is not an exact multiple of characters in size. You can test this by fiddling with your font, font size and / or screen resolution. You will probably find some combinations where the blank space disappears (though the overall effect may be negative).
Note that this is not a problem unique to Emacs. Many other character-oriented applications behave the same way, e.g. some terminals. Try resizing these types of applications; you will probably notice one of two things:
Instead of resizing continually the window dimensions will "jump" as it reaches sizes that can hold more or fewer characters.
The window will resize continually, but you will see blank space inside the window border like you are seeing with Emacs.
There is no really good general solution to this for fullscreen windows (Emacs frames). Some systems restrict Emacs' frame to the size of its windows, leaving a gap. Others may let the frame be whatever size it wants to be, but this results in the kind of thing that you're seeing.
In general, you'll have to find a combination of settings that make you happy. I have accepted that Emacs' frame doesn't cleanly fill my monitor, but that may not be an acceptable solution to you.
Related
I bought a new iMac 27 inch and one of the first things I did was installing my text editor of choice, Sublime Text. After a bit of writing code I noticed that the indentation with tabs is to wide. In the bottom left corner it says Tab Size: 4 but in fact one tab is as wide as 12 spaces. When changing the setting to Tab Size: 2 one tab is as wide as 6 spaces.
Could it be that Sublime multiplies the length of one tab with 3 because of the large resolution (2560 x 1440)? Does anybody know how to fix this issue?
EDIT:
I use the Ubuntu Mono font with 16px font size. When setting the option Indent Using Spaces everything works as expected. Here an image of the current situation with Tab Size: 4.
Sublime works fine on my iMac, so the screen resolution isn't the issue. Instead, I would suspect that you are using a proportional font instead of a fixed-width one. A likely cause of this is lacking the specified font on your new system - I use a non-system font with Sublime, and so need to install it on new computers before everything looks right to me.
With a proportional font, spaces tend to be rather small, especially when compared to "large" characters like D, W, e, s, etc., that take up a proportionally larger amount of horizontal space (hence the name proportional font). Additionally, a tab character may be calculated by Sublime to be a certain size as a function of the pixel size of the font, and so may bear no relation to the actual number of space characters it takes to equal the size of the tabstop. I know that in programs such as MS Word, tabstops are set in fractions of an inch (or cm, or pica, or whatever), and have no relation to the type or size of font being used.
All this is simplified with fixed-width fonts. All characters (even Unicode ones) take up the same horizontal width. Sublime calculates the width of tabs using the standard character width, so everything is consistent.
All that being said, how to fix your problem? The easiest way to determine if this actually is the problem is to set your "font_face" setting to Menlo, an Apple-designed fixed-width font that's been on all their systems since the early days of the Macintosh. If your code goes back to looking like normal, that was the issue. You can then search for whichever font you were using before, if you like, or take a look at my favorite font, linked above, or just keep using Menlo if you're not too picky.
Good luck!
I've tried to find an answer for this on MSDN, but I'm not getting a clear picture of how this is intended to work. All of my work is on Windows 8.1.
Here is my issue. I am working on a Laptop with a high resolution monitor, 3200x1800. I've been using EnumDisplayMonitors to get the bounding rectangle of my screen.
This seems to work fine if my display settings are default. But I've noticed that when I change the Window display settings to provide larger text, the resolution returned by EnumDisplayMonitor changes. Rather than getting 3200x1800 I will get 2133x1200.
I'm guessing since I asked for larger text, Windows chooses to represent the screen as a smaller resolution.
It seems that if I look at the virtual screen properties, everything is represented in the actual coordinates of my screen, i.e. 3200x1800. But the APIs for getting the window and monitor rectangles seem to operate on this "other" coordinate space.
Is there any documentation/Windows APIs to handle the conversion between these "other coordinates" and the "virtual coordinates"? i.e. if I want EnumDisplayMonitor or GetMonitorInfo to give me the true screen coordinates, how could I convert 2133x1200 to 3200x1800?
You have increased the DPI of the video adapter to 150% (144 dots per inch) to keep text readable and avoid having windows the size of a postage stamp. Quite necessary on such high resolution displays. But you haven't told Windows that your program knows how to deal with it.
So it assumes your program is an old one that was never designed to run on such monitors. It helps and lies to you. It gets your program to render its output to a memory buffer, then takes that output, rescales it by 150% and copies it to the video adapter. This is something you can see, text looks fuzzier if you put your program's output next to a program that doesn't ask for this kind of scaling, like Notepad.
And of course, it lies to you when you ask for the size of the screen. It tells you that it is 150% smaller than it really is. So that, after rescaling, a window you create will fill the screen.
Which is all just fine but of course not ideal, your program doesn't look as good as it should. You have to tell Windows that you know how to deal with the higher resolution. Do beware that this looks easier than it is in practice. Getting text to look crisp is trivial, it is bitmaps that are problematic. And in general a fertile source of bugs, even the big companies can get this wrong.
Before I start with an answer, let me ask: what are you really trying to do ? Or more specific - why do you need to know the monitor resolution ? The standard way to do this is to call GetWindowRect(GetDesktopWindow(), &rect) I'm not sure if the screen coordinates change based on DPI settings - but you should try that instead of GetMonitorInfo as the latter is for more advanced stuff. And if GetWindowRect still returns back a scaled rect, just call DPtoLP, LPtoDP or other mapping coordinate function as appropriate.
When you adjust the display settings as you described, you are actually changing the DPI settings of the screen. As such, certain APIs go into compatibility mode so that they allow the app to create larger elements and windows without knowing anything about this setting.
Why do you need to know the actual screen resolution since most of the windowing APIs will behave accordingly when the DPI scaling changes?
I suspect you could call SetProcessDPIAware or the manifest file equivalent. But do read this MSDN article first to understand DPI scaling.
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.
How can I get the terminal (or Visor/TotalTerminal) to smoothly scroll when it prints out text. So that I don't completely lose my sense of location when for instance showing git diffs. Or, when navigaiting long diffs in vim-mode using CTRL-D and CTRL-U. I don't want the terminal to "jump" to a new place, but rather smoothly flow to it.
(I'm using osx snow leopard)
You can't.
Terminal emulators work with lines and characters as their smallest units, not your display's pixels.
Consider each individual character as your terminal's pixel: just as your display can't show half pixels, your terminal can't show 1/2 or 1/4 or 1/8 of a character.
Smooth scrolling is the norm in GUI land because text (or any meaningful piece of information) is usually a lot taller than 1 pixel. You can hide parts of it without losing too much information. Up to a certain threshold, of course.
In CLI land, the smallest display unit is also the smaller bit of information. It's either there or not there.
So, smooth scrolling — pixel by pixel — doesn't really make sense and doesn't seem to be a trivial thing to implement.
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.