Notepad++ v6.9 is not displaying monospaced fonts properly. No matter what setting, the spaces have different width to the characters. Adjusting Global Styles in settings - Style Configurator... and stylers.xml didnt work.
Gladly I found the solution at last!
-> Look below
Solution Process
So I was using Notepad++ v6.9 and I was having problems with the display of monospace fonts.
Going through all settings under -Settings - Style Configurator..., I couldnt get it running properly.
Everything I tried lead to the same result: The spaces were of different width than my font. The spaces even adjusted with the zoom. So
I tried setting explicitly setting a monospace font for my used style.
I tried setting the styles via the stylers.xml. I especially set the fontName and fontSize to be equal between GlobalStyles and my theme but to no avail.
I tried adding fontStyle and fontSize to all parameters of GlobalStyles but that broke the theme completely.
I tried decreasing the font size so that it would fit the spaces. First problem: You cant set the fontsize lower than 5 via the settings. But you can via the stylers.xml. Second problem: The fontsize needs to be smaller than 1 and stylers.xml does not accept "0,8" nor "0.8" nor 0.8. Got it to work with "09". To match the space size it was necessary to set the font to 0.1, which looked fine till: Third problem: The space width adjusts with zoom level, whereas the font does not. So this was a dead end.
Next I stumbled upon the solution! I deleted the stylers.xml and reloaded Notepad++ and suddenly there were a lot more settings under Settings - Style Configurator... - Global Styles. (Enable global font, Enable global font size, Enable global font style, ... were not available before) And now everything works as expected!
I write this because I saw a lot of people with similar problems but couldnt find a solution. So this is for anyone else that comes across the same problem and for me for future reference.
I would be happy if it was helpful to you, that you give a short comment so more people can see this!
Best regards
Related
I am having trouble with something that appears to be trivial, namely how to name a font, so that I get multiple styles of the same font to tile, display nicely, import nicely using Inno Script Studio, work with C#, not to mention applications.
For instance, here is an Adobe font that work nicely, first what I see in Control Panel, then the TTF details. I will then show what I did with my font and how I do not see the exact same thing, even though I did seemingly the same thing.
Adobe Source Sans Pro Tiles
Adobe Source Sans Pro Details
Adobe Source Sans Pro Semibold: The purpose of a screenshot is to show what I see from the actual TTF using Birdfont font editor, plus version.
Here is the black:
PostScript Name: SourceSansPro-Black
Name: Source Sans Pro
Style: Black
Full Name: Source Sans Pro Black
Here is how I named the font that I am using on my project. The font name, Venera, is the font family and then these are the styles: 100 Extra Light, 300 Light, 500 Medium, 700 Bold, and 900 Black.
BTW, I tried with the numbers, without the numbers, with spaces, and no spaces. There was no combination that worked like what I see with the Adobe font.
PostScript Name: Venera-900Black
Name: Venera
Style: 900 Black
Full Name: Venera 900 Black
Here is the bold:
PostScript Name: Venera-700Bold
Name: Venera
Style: 700 Bold
Full Name: Venera 700 Bold
I did think that maybe styles cannot have embedded spaces, so I tried both 700Bold / 900Black as the Style and even just Bold / Black. The latter was my thought that Windows does not support numbers s part of style names.
What I see is the fonts not overlapping like Adobe, but stacked. One has to delete the TOP font to see that there is a font underneath. Needless to say, Word in such a case does not see both fonts.
Here is what I see after I install the 700 Bold bold font and then the 900 Black font. I took this screenshot after installing the 700 Bold style and before installing the 900 Black style, but the image is identical to what I see after 900 Black. The order makes no difference, I have to delete one font to see the other. The fonts are not stacked like what I see with Adobe. Restarting the computer makes no difference. Removing the numbers or spaces make no difference.
Image with BOTH fonts, just one would never know it from the screenshot.
I suspect that when I get this first part working that Inno Script wants the full name and not the font name as stated in the help material and pages here in SO, but first things first. I need to get the font behaving.
For whatever it is worth, I can set the style to Regular and then set the font name to: Venera700Bold and Venera900Black. I would then wind up with two different fonts that show Venera700Bold Regular and Venera900Black Regular in Control Panel. Inno Script Studio is then quite happy accepting Venera700Bold and Venera900Black as the font name in the Files section.
It is tempting to use this answer, but all the fonts are the same family and I would really rather do things the right way and not subject users to different fonts, especially when I have 7 different Avenir fonts that I have to do the same thing for.
The answer should be Font Name is alphanumeric with however many spaces. The style is alphanumeric with however many spaces. The full name, as the editor says is the concatenation of the font name and style. The unique name and PostScript name must have no spaces and have the style separated from the font name by a dash. Sadly, this recipe, which works for others, such as the Adobe font that I picked at random, does not work for me, so I am missing a piece to the puzzle in my understanding.
Thoughts?
The style names should not include the numeric weight values. The numeric values should only go into the font's 'OS/2' table, not in the name strings. If you include the numbers in the style string, then the OS or apps will probably get confused, treating the number as part of the family name.
If you tried just using "Bold", "Black" as the style names and that's not working, then I would suspect the tool used to create the fonts.
In this screenshot of my vimrc settings, I have installed the plugin vim-airline using vundle. After going through airlines docs, I found the set of lines to customise my airline.
The problem is the ones highlighted in red. The blue highlighted one works fine but the red one does not. The left one is same as right one. I tried using different Unicode symbols but does not work. Any workaround to this situation as this is troubling my OCD :P.
Thanks in advance.
This is a well-known issue related to the font (size and family) used in your terminal.
For a better display, you have two solutions:
Do not use arrows as separators
Configure your terminal emulator to use a patched font with the right size
If you prefer the first solution, make sure you have this code in your .vimrc:
let g:airline_right_sep = ""
let g:airline_left_sep = ""
If you prefer the other solution, take a look at this: https://github.com/powerline/fonts
I have used the Hack font with size 11 for a long time and the arrows are perfectly displayed in my editor...
I have Museo-300 mostly working with #font-face, but certain letter combinations like "ff" and "fi" are disappearing in Firefox (confirmed in v3.6 and v7.0.1). So "microfinance" becomes "micronance".
Note that I'm outputting these as individual letters, not as ligatures. When I view source on both the server and the browser, "coffee" for example is spelled with all six letters individually—not a unicode ligature character for "ff".
The output looks right in Opera, Chrome, Safari, and IE (even IE6).
I downloaded Museo-300 from MyFonts along with their web font example template.
#font-face {
font-family: 'Museo-300';
src: url('webfonts/151B6C_0.eot');
src: url('webfonts/151B6C_0.eot?#iefix') format('embedded-opentype'),url('webfonts/151B6C_0.woff') format('woff'),url('webfonts/151B6C_0.ttf') format('truetype'),url('webfonts/151B6C_0.svg#wf') format('svg');
}
and all the referenced files are in place. I invoke it like this:
font-family: 'Museo-300', sans-serif;
I tried a different font as a test (Code Pro Light Demo, also gotten from MyFonts) and Firefox dropps "fi" but not "ff" for that one.
An idea what's going wrong?
For anyone reading this in the future, note that as of FF 15 (I think) the syntax has now changed, and you'll need to use this:
-moz-font-feature-settings: "liga=0";
-moz-font-feature-settings: "liga" 0;
You can tell Firefox to skip looking for ligatures and treat them as regular characters by adding
-moz-font-feature-settings: "liga=0" in your font-face declaration.
In case others hit this problem, I resolved it with help from MyFonts technical support. I'm not sure whether this issues is specific to MyFonts, but I suspect it affects other web font sources.
Direct (Solvable) Cause
When a standard True Type font (TTF) gets processed into the multiple versions that are useful for a web font (EOT, SVG, WOFF), the processing tool or vendor can decide whether or not to include the font's full character set. Some will default to a reduced character set to reduce file sizes.
In my case, one or more of the generated web font files excluded ligatures, presumably considering them to be non-essential typographic tweaks. To fix the problem I used a custom web font builder at MyFonts to generate font files with the full character set.
(For MyFonts specifically this was at Order History > select relevant font > Webfont Kit Builder tab > Advanced, then check both "Complete Character Set" and "Keep OpenType Layout".)
Underlying Cause
My belief, which is only an educated guess:
I think Firefox is going out of its way to do nice typography, more so than other browsers. So when it sees something that it could render as a ligature ("fi", "fl", "ff", etc.) it tries to render the letters as a single ligature glyph rather than as two distinct characters. If your web font doesn't include the ligature glyphs, your letters will disappear. (If my guess is right, I'm surprised I haven't read about this problem before.)
Myfonts.com recently changed some display settings. Their support wrote back very quickly with the following info:
If you click on the Font image (the image that shows the sample),
which is located right above Kit Options, you will see the Complete
Character set and Keep OpenType Layout options.
This view is not currently available through Firefox though, but I was able to download the complete character sets using IE9.
This picture illustrates my predicament:
All of the characters appear to be the same size, but the space between them is different when presented in a RichEdit control compared with when I use ExtTextOut.
I would like to present the characters the same as in the RichEdit control (ideally), in order to preserve wrap positions.
Can anyone tell me:
a) Which is the more correct representation?
b) Why the RichEdit control displays the text with no gaps between the Asian Characters?
c) Is there any way to make ExtTextOut reproduce the behaviour of the RichEdit control when drawing these characters?
d) Would this be any different if I was working on an Asian version of Windows?
Perhaps I'm being optimistic, but if anyone has any hints to offer, I'd be very interested to hear.
In case it helps:
Here's my text:
快的棕色狐狸跳在懶惰狗1 2 3 4 5 6 7 8 9 0
apologies to Asian readers, this is merely for testing our Unicode implemetation and I don't even know what language the characters are taken from, let alone whether they mean anything
In order to view the effect by pasting these characters into a RichEdit control (eg. Wordpad), you may find you have to swipe them and set the font to 'Arial'.
The rich text that I obtain is:
{\rtf1\ansi\ansicpg1252\deff0\deflang2057{\fonttbl{\f0\fnil\fcharset0 Arial;}}{\colortbl ;\red0\green0\blue0;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\fs22\u24555?\u30340?\u26837?\u33394?\u29392?\u29432?\u36339?\u22312?\u25078?\u24816?\u29399?1 2 3 4 5 6 7 8 9 0\par\pard\'a3 $$ \'80\'80\cf1\lang2057\fs16\par}
It doesn't appear to contain a value for character 'pitch' which was my first thought.
I don't know the answer, but there are several things to suspect:
There are several versions of the rich edit control. Perhaps you're using an older one that doesn't have all the latest typographic improvements.
There are many styles and flags that affect the behavior of a rich editcontrol, so you might want to explore which ones are set and what they do. For example, look at EM_GETEDITSTYLE.
Many Asian fonts come in two versions on Windows. One is optimized for horizontal layout, and the other for vertical layout. That latter usually has the same name, but has # prepended to it. Perhaps you are using the wrong one in the rich edit control.
UPDATE: By messing around with Wordpad, I was able to reproduce the problem with the crowded text in the rich edit control.
Open a new document in Wordpad on Windows 7. Note that the selected font is Calibri.
Paste the sample text into the document.
Text appears correct, but Wordpad changed the font to SimSun.
Select the text and change the font back to Calibri or Arial.
The text will now be overcrowded, very similar to your example. Thus it appears the fundamental problem is with font linking and fallback. ExtTextOut is probably selecting an appropriate font for the script automatically. Your challenge is to figure out how to identify the right font for the script and set that font in the rich edit control.
This will only help with part of your problem, but there is a way to draw text to a DC that will look exactly the same as it does with RichEdit: what's called the windowless RichEdit control. It not exactly easy to use: I wrote a CodeProject article on it a few years back. I used this to solve the problem of a scrollable display of blocks of text, each one of which can be edited by clicking on it: the normal drawing is done with the windowless RichEdit, and the editing by showing a "real" RichEdit control on the top of it.
That would at least get you the text looking the same in both cases, though unfortunately both cases would show too little character spacing.
One further thought: if you could rely on Microsoft Office being installed, you could also try later versions of RichEdit that come with office. There's more about these on Murray Sargent's blog, as well as some interesting articles on font binding that might also help.
ExtTextOut allows you to specify the logical spacing between records. It has the parameter lpDx which is a const pointer to an array of values that indicate the distance between origins of adjacent character cells. The Microsoft API documentation notes that if you don't set it, then it sets it's own default spacing. I would have to say that's why ExtTextOut is working fine.
In particular, when you construct a EMR_EXTTEXTOUTW record in EMF, it populates an EMR_TEXT structure with this DX array - which looking at one of your comments, allowed the RichEdit to insert the EMF with the information contained in the record, whereby if you didn't set a font binding then the RTF record does some matching to work out what font to use.
In terms of the RichEdit control, the following article might be useful:
Use Font Binding in a Rich Edit Control
After character sets are assigned, Rich Edit scans the text around the
insertion point forward and backward to find the nearest fonts that
have been used for the character sets. If no font is found for a
character set, Rich Edit uses the font chosen by the client for that
character set. If the client hasn't specified a font for the character
set, Rich Edit uses the default font for that character set. If the
client wants some other font, the client can always change it, but
this approach will work most of the time. The current default font
choices are based on the following table. Note that the default fonts
are set per-process, and there are separate lists for UI usage and for
non-UI usage.
If you haven't set the characterset, then it further explains that it falls back to ANSI_CHARSET. However, it's most definitely a lot more complicated than that, as that blog article by Murray Sargent (a programmer at Microsoft) shows.
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