The font used in xterms is extremely compact yet readable. What font is that? The closest I've found that I can use in other other applications is DejaVu Sans Mono or Bitstream Vera Sans Mono. Those are as compact as xterms vertically but take up more space horizontally.
I'd really like to switch from xterms to Terminal.app and this is the one thing holding me back.
(I also think that font would be much better for emacs, xcode, or whatever editor.)
ADDED: In Terminal.app you can adjust the character and line spacing for any font. Is this possible in other applications?
I'm open to any other font that is as compact and readable as the xterm font. Dina looks really nice but it doesn't seem to work for Mac.
I have successfully gotten Emacs.App to use the beloved misc-fixed 7x14 font. And it looks GOOD.
1) download ucs-fonts.tar.gz from http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
2) extract the file 7x14.bdf
3) install FontForge (fontforge.sourceforge.net)
4) open 7x14.bdf in fontforge
5) in fontforge do File->Generate Fonts with "No Outline Font" and "Apple bitmap only sfont (dfont)"
6) save as /Library/Fonts/FixedMedium7x14.dfont
7) in your .emacs (setq default-font "-apple-Fixed-medium-normal-normal--14----m-0-iso10646-1")
8) WIN
I've really taken a liking to Inconsolata:
http://www.levien.com/type/myfonts/inconsolata.html
But it's not really appropriate for an xterm. Better as a programming font.
I'd strongly suggest Monaco 9pt, not anti-aliased:
Never seen anything as readable and space-efficient. Note that it's the same number of pixels wide as Monaco 10, but slightly shorter.
It's not exactly the same, but 10 point Monaco (with anti-aliasing turned off) is pretty darn close. I'd say it's actually a little better, because Monaco's 1/l and O/0 glyphs are more distinct than the X font's.
Here are alternatives I've tried. (Thanks to Will and others.)
Monaco 10pt with .9 line spacing (I don't know how to squish line or character spacing in anything other than Terminal.app) takes up exactly as much vertical and horizontal space as the xterm font. Without the line space squishing it takes up more vertical space. I don't think the squishing harms readability. Monaco has the advantage of slashed zeros but has worse angle brackets (they bump into adjacent characters awkardly, eg, "~>"). Upper case characters ("A" in particular) also don't look as good in Monaco. Mostly though, they are about the same.
Monaco 9pt fixes the angle brackets and is more vertically compact than the xterm font (same horizontally). Capital I is pretty sucky (hard to distinguish from l and i and |).
ProggyTiny from Proggy Fonts at 11pt. Setting the line spacing to .9 makes it vertically slightly more compact than X11's xterm font. Either way, it takes up exactly as much space horizontally. With or without line space squishing though, I find this option definitively worse than Monaco. The other Proggy varieties seem to not be as compact as the xterm font.
Anonymous at 10pt with .95 character spacing (I still don't know how to squish character or line spacing in anything but Terminal.app) and normal line spacing is exactly the same size as the X11 font. Squishing the character spacing causes upper case characters to touch each other very slightly and numbers are rather ugly that way. With vertical (line) space squishing it can be made more vertically compact than the xterm font without harming readability.
(Anonymous at 9pt is very very compact and still quite readable.) I really don't like the caret ("^") in this font, with or without squishing.
FixedMedium6x13 set to size 13 and line spacing 0.80 yields the xterm font exactly. My friend David Yang reports that this works flawlessly for him on Snow Leopard. I'm on Leopard and it's unusable for me (with squished line spacing that makes it as compact as X11) because there's some kind of refresh problem -- it cuts off the tops of the letters until the terminal window re-renders, like when you alt-tab away from it.
Others I intend to try:
Envy Code R: http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released
Inconsolata: http://www.levien.com/type/myfonts/inconsolata.html
Droid Sans Mono: http://en.wikipedia.org/wiki/Droid_(font)
Just use one of these:
http://henrik.synth.no/fonts/6x12.dfont
http://henrik.synth.no/fonts/6x13.dfont
http://henrik.synth.no/fonts/7x13.dfont
http://henrik.synth.no/fonts/7x14.dfont
You might want to adjust the line height to 0.85 when you select the font.
(Thanks to Marty Vona for the guide)
The font used in xterms is extremely
compact yet readable. What font is
that?
The font you are referring to is known as "fixed" or "6x13".
I started (but gave up) a "6x13 redux" which was meant to be one of those TrueType fonts that only looks good at one size but was usable in Terminal.app. I gave up because creating a font with UNICODE glyphs is a HUGE undertaking. Just look at this glyph table for 6x13. BTW, that "6x13 Redux" font I created only seems to work in Terminal.app on Tiger, not on Leopard.
The closest I've come to 6x13 is ProggySquare at 11pt.
My favorite pixel font is 'Dina ttf 10px' at 16pt on a dark background. It makes a great font for coding, since it has slashed zeros, and distinct characters.
You can find the Mac TrueType version at http://www.geenat.com/?p=66
and the original bitmap version at http://www.donationcoder.com/Software/Jibz/Dina/index.html
The Proggy font that Dina is based on is also really sharp at a small text size. Unfortunately, it is a little too small for me.
Additionally, you can use SIMBL plugins to tweak Terminal.app to better suit you. In addition to the color preferences, I find all the plugins below really helpful when using Terminal.
For a start the default colours in Terminal.app are difficult to see. To fix this, you can install Ciaran Walsh's custom color plugin.
SIMBL - http://www.culater.net/software/SIMBL/SIMBL.php
Custom colors - http://ciaranwal.sh/2007/11/01/customising-colours-in-leopard-terminal
Tab Switching (if you prefer CMD-1 instead of CMD-SHIFT-{}/arrow keys) - http://ciaranwal.sh/2007/12/10/tab-switching-in-terminal
Visor - http://visor.binaryage.com/
MegaZoomer for Fullscreen - http://ianhenderson.org/megazoomer.html
The IR_Black color scheme - http://blog.infinitered.com/entries/show/6
X11 default fonts are usually bitmap fonts, which aren't of any use to non-X applications ... on my Mac box, the default font for X11 apps seems to be -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1, corresponding to the file /usr/X11/lib/X11/fonts/misc/7x14-ISO8859-1.pcf.gz
You can display the character table with the command /usr/X11R6/bin/xfd -fn -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1 and check if it's the one you see in your xterms. If so, I'm afraid there's nothing to do: PCF fonts are (very) low resolution bitmap fonts, and that's why they look so good on screen, by the way (they just fit with your particular screen resolution); but they're no way other Mac OS X applications are going to use them.
I've been using Bitstream Vera Mono later DeJaVu Sans Mono (for more unicode characters) for quite a long time but I've switched a few months ago to the font used by Android, Google's OS for mobile phones, called Droid Sans Mono. It is really more readable for me. For Terminal.app, I do shrink it a bit horizontally though.
I've created the DinaPro font which is like the original Dina, but for Mac ... http://www.hexagonstar.com/blog/news/dinapro-coding-font-for-mac-released/
Try andale mono without anti-aliasing... it looks good on my mac pro 15in
Related
I was doing a visualization in this years adventofcode. My first stab just used plain ascii chars video here. Then I saw this image
Which I thought was really nice. However, when I attempted to put in these chars, they completely overlapped.
Is there a nice way to do this? I've tried installing gnu unifont as that sounded like a decent start, but no joy.
How do I use the terminal to print "letters" like this and have them come out nicely? I might be missing something fundamental about terminals + UTF8. If it matters, I'm using OSX terminal app, Anonymice Powerline Nerd Font Complete Mono font.
EDIT
Yes, the font didn't contain items which were encoded correctly (or was falling back?! if that's even possible, to items which weren't encoded correctly)
I ended up using the symbola font which, while not perfect, means I can draw this:
which is good enough!
It looks as if the "patched font" didn't set the font metrics properly. Terminals expect the font header to give a bounding box which applies to all characters. If the individual glyphs don't fall into the box, you'll get interesting effects like this.
This is bothering me for some time now.
With same source file, same theme (almost) the thickness of text between MacVim and Textmate is different.
I have linked to the screenshot .. here. There are 3 editors in it. Leftmost is sublime v3, middle is MacVim and rightmost is TextMate. The objective is to compare the font thickness. MacVim & sublime text is much thicker whereas TextMate is slicker (and sophisticated .. personal choice :) ). All this is on Mac OS X Mavericks with retina display.
I hope u all see the differences in the screenshot.
Note: for MacVim, toggling the anti-alias option does make some difference but still nothing compared to TextMate.
Questions:
Is there any configuration in VIM (or Mac OS) which governs the font thickness?
I am a primarily Vim user, so interested in solutions for VIM
(Out of curiosity) Why is the rendering different? I would assume that all the editors must be relying on underlying OS APIs
This has to do with subpixel antialiasing. Textmate disables this for themes with dark backgrounds: https://github.com/textmate/textmate/wiki/Hidden-Settings#controlling-font-smoothing
for MacVim subpixel antialiasing can be disabled with the terminal command:
defaults write org.vim.MacVim AppleFontSmoothing -int 0
I dont like colors. How can I tell emacs to
stick to just black and white for everything.
Higlighted text or the mode line can be
shown in reverse video (black text on white background)
I'm using Emacs 24 on windows under cygwin
in console mode.
I tried,
TERM=xterm-mono emacs --no-splash
which gives
emacs: Terminal type xterm-mono is not defined.
Also
emacs --no-splash --reverse-video
which shows some blues and some other colors too.
I already have the following in my .emacs:
(setq-default global-font-lock-mode nil)
(set-face-foreground 'mode-line "white")
(set-face-background 'mode-line "black")
M-x customize-face seems interesting but there's about
300 lines of options and I dont feel like changing that
many lines.
Disabling font-lock should get rid of most colours. Try this in your configuration:
(global-font-lock-mode -1)
I don't have Cygwin to test on, but it gives me white on black in a Linux terminal with emacs -nw.
Hmm... I don't like colors very much either, but the way I did it is to only change those faces that bothered me. I.e. go to a chunk of text with a color you don't like, then use M-x customize-face there (which should give you as default the face used for that color) and change that one (or if it inherits from another, you might prefer to change the one from which it inherits).
While there are hundreds of faces, in my experience, you can start by changing a small dozen.
This could probably also be asked as "Is kCTKernAttributeName a misnomer?"
I need to change the letter spacing/tracking of some text in iOS. (The font I'm using is a little too tight at small sizes.) There are core graphics routines that will change character spacing, but those routines don't handle Unicode. There are other core graphics routines that are defined in terms of glyphs but those seem like a world of hurt, among other things, not having the safety net of reverting back to system fonts for glyphs that don't exist in my font.
So core text seems like the way to do this and core text supports kCTKernAttributeName on CFAttributedString. I think this will do what I want, though this really isn't kerning since kerning is a generally a character-pair attribute and this (appears to be, from the docs) just a uniform adjustment to the glyph advance for all glyphs, i.e., tracking.
If anyone knows before I go down the rather painful path of converting to the core text API ...
kCTKernAttribute name should do what you want. Setting it over a range of text adjusts the inter-glyph spacing consistently, irrespective of the specific glyphs.
I think part of the problem is that kerning seems to have been a virtual synonym of tracking (it's still just "adjust the spacing between (letters or characters) in a piece of text to be printed" in the dictionary that comes with OS X), and is now adopting just the meaning of pair kerning because of the redundancy. Probably an etymologist would be better placed to comment on that side of things...
We have standard flex 3 project, and We have left everything as default, no change in style at all, and we deployed our project and noticed that on Mac the character spacing is very bad and overall look and feel is not as clear as that of windows.
Here is the difference, left one is Windows and right one is Mac.. the default flex font chosen by Adobe is "Verdana", the left one looks pretty, but right one looks as its width and character spacing, everything is incorrect. I assume verdana font may not be available on Mac, but in that case I supposed adobe should have given default standard font of good quality.
alt text http://akashkava.com/images/MacFlashFontProblem.png
What can we do to resolve this? Will embedding Verdana font in flex project style will help?
Mac OS X and Windows have different text rendering engines. I've heard it said that Mac OS X tries to preserve the character shape while Windows tries to align with screen pixels at small sizes.
That's going to result in differences between how fonts are rendered, and there's really no way to work around it.
Personally, I think the example on the right looks much nicer; the one on the left looks square, like it's being rendered at too small a size, while the one on the right looks more like the font is supposed to look.
It's not a solution, but Verdana is available on every OS X box. See this Apple doc for 10.5; I couldn't find one on 10.6 but there is one.