Installing ttf fonts in gvim in windows
Alexander Stepanov
do it, but this instruction is for linux. What to do if I have
windows?
Christian Brabandt
There should be no special install instructions as long as you have
mono-spaced fonts. You can't use proportional fonts on Windows.
See also the faq:
http://vimhelp.appspot.com/vim_faq.txt.html#faq-31.12
regards,
Christian
Tony Mechelynck
You can install your fonts like any other fonts are installed on your
OS: gvim (for Windows, and also any other gvim except GTK2) will use
them (TrueType, OpenType, bitmapped, whatever) if they are defined as
monospace: for instance, Courier New (a monospace true-type font) can be
used in gvim but Times New Roman (a proportional "serif" true-type font)
or Arial (a proportional "sans-serif" true-type font) cannot.
On some GUI flavours including Windows, you can see (in a popup menu)
all fonts acceptable to gvim by using
:set guifont=*
Best regards,
Tony.
--
'Twas the nocturnal segment of the diurnal period
preceding the annual Yuletide celebration, And
throughout our place of residence,
Kinetic activity was not in evidence among the
possessors of this potential, including that
species of domestic rodent known as Mus musculus.
Hosiery was meticulously suspended from the forward
edge of the woodburning caloric apparatus,
Pursuant to our anticipatory pleasure regarding an
imminent visitation from an eccentric
philanthropist among whose folkloric appelations
is the honorific title of St. Nicklaus ...
Alexander Stepanov
Tony Mechelynck
> Monospace fonts... That's very said. Thank you for explanation.
>
If you mean "very sad", this is due to the fixed size of the character
cell in gvim, something so fundamental to Vim's mode of operation that
it is not going to change.
In gvim for GTK2, the only gvim flavour which accepts even non-monospace
fonts, the result when using them is ugly, since they are still
displayed within constant-size character cells, with the consequence
that "narrow" characters (such as i) look lonely in the middle of a cell
too wide for them, while "wide" characters (not in the CJK sense, but
letters such as m) look cramped in a cell hardly wide enough to contain
them.
Best regards,
Tony.
--
If I have seen farther than others, it is because I was standing on the
shoulders of giants.
-- Isaac Newton
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.
-- Gerald Holton
If I have not seen as far as others, it is because giants were standing
on my shoulders.
-- Hal Abelson
In computer science, we stand on each other's feet.
-- Brian K. Reid
Mathew Brown
Personally, I use DejaVu Sans Mono (part of the DejaVu Fonts -
http://dejavu-fonts.org/wiki/Main_Page) on both Windows and Linux and
I'm very happy with it.
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
--
Mathew Brown
mathe...@fastmail.fm
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
Alexander Stepanov
in font list.
On 19 апр, 13:17, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
Christian Brabandt
> How to use non-monospace in gVim? Only monospace fonts are displayed
> in font list.
You can't on Windows.
regards,
Christian
Tony Mechelynck
> How to use non-monospace in gVim? Only monospace fonts are displayed
> in font list.
On gvim with GTK2 GUI (only on X11), you can but it's ugly because the
variable-width glyphs are displayed within constant-width screen cells.
If you really want it, just set the 'guifont' appropriately; then see
for yourself how ugly it is and change the 'guifont' back to some
sensible monospace font.
On all other flavours of gvim, including gvim for Windows, you can't.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
68. Your cat always puts viruses on your dogs homepage
Linda W
> How to use non-monospace in gVim? Only monospace fonts are displayed
> in font list.
If you use the cygwin version of 'gvim', and use the 'X11'
display, you'll be able to use variable spaced fonts. That's not
to say that they look 'great' A slightly better implementation is
using gvim on a linux box that has it's X11 character display built
with 'Pango', which can do a better (though still not ideal) job
of displaying proportional fonts.
One reason it does better is that it can allow the user
to specify what algorithm to use in displaying characters, based on
what font and the size of the font. It's a complex subject -- and while
the display of such characters isn't ideal, it has improved over the
situation, say 5-10 years ago. It may just be a matter of time before
it improves enough to make it legible.
Some tty-based programs do a better job of using proportional fonts
than others. It depends on the program.
Linda W
> On 19/04/11 09:36, Alexander Stepanov wrote:
>> Monospace fonts... That's very said. Thank you for explanation.
>>
>
> If you mean "very sad", this is due to the fixed size of the character
> cell in gvim, something so fundamental to Vim's mode of operation that
> it is not going to change.
Please don't continue to spread this misinformation. While the
current Vim may not support proportional fonts, it is already true that
Vim "fundamental mode of operation" has changed and supports displaying
characters that take more than 1 character cell. I.e. your information
is already outdated.
To say that Vim couldn't be further enhanced to accommodate
proportional characters, in a similar way, could easily be seen as
saying "Bram" isn' intelligent enough to figure out how to enhance vim
in this way. Since Vim already support character sets with multi-width
characters, I see no reason why that method couldn't be extended to support
proportional characters.
I.e -- instead of the current editor's support for 1 or 2-width
chars, one could use 1-10 width chars, with an 'i' taking 1 width, and
an 'M' taking 4-5, and asian chars taking 8-10.
Please stop claiming vim could never support multi-width
character sets, as it already does support bi-width character sets.
-l
Tony Mechelynck
> Tony Mechelynck wrote:
>> On 19/04/11 09:36, Alexander Stepanov wrote:
>>> Monospace fonts... That's very said. Thank you for explanation.
>>>
>>
>> If you mean "very sad", this is due to the fixed size of the character
>> cell in gvim, something so fundamental to Vim's mode of operation that
>> it is not going to change.
> ---
> Please don't continue to spread this misinformation. While the
> current Vim may not support proportional fonts, it is already true that
> Vim "fundamental mode of operation" has changed and supports displaying
> characters that take more than 1 character cell. I.e. your information
> is already outdated.
It's not outdated information, I was simplifying.
The size of Vim's character cell *is* fixed. The following uses are
possible:
- most characters use exactly 1 character cell each;
- CJK "wide" characters use exactly 2 character cells each;
- hard tabs use between 1 and 'tabstop' cells each, except if 'list' is
on _and_ there is no "tab:" part in 'listchars', in which case they are
regarded as ASCII control characters, see below;
- ASCII control characters (^@, ^A, ^B, etc.) use exactly 2 character
cells each; also upper-ASCII control characters if displayed with a
"tilde" or "bar" prefix instead of the circumflex used by "ordinary"
ASCII control characters;
- unprintable characters between 0x80 and 0xFF may use 4 cells each if
represented as <xx> (as when 'encoding' is UTF-8);
- unprintable Unicode characters higher in the BMP use exactly 6
character cells each (as <xxxx>)
- if there are any unprintable characters above the BMP, I think they
would use ten cells each, as <xxxxxxxx>
- the end-of-line character or character pair takes up no space on the
screen...
Changing any of the above would break compatibility with existing
scripts (and probably require huge rewriting in many parts of the C
code), something which Bram has always (wisely IMHO) refused to do
without reasons much more compelling than what you are advancing.
> To say that Vim couldn't be further enhanced to accommodate proportional
> characters, in a similar way, could easily be seen as
> saying "Bram" isn' intelligent enough to figure out how to enhance vim
> in this way. Since Vim already support character sets with multi-width
> characters, I see no reason why that method couldn't be extended to support
> proportional characters.
I'm not saying Bram is not intelligent enough, I'm saying the notion of
columns would go out the window, either breaking compatibility (if you
keep columns vertical) or breaking present nice looks of e.g.
'cursorcolumn' or of block-visual being a rectangle (if you keep the
existing meaning of what a column is in terms of characters). In fact
what I'm saying is thas Bram is wise enough... not to let himself be
swayed by the kind of arguments you are using. Sorry if I sound
insulting, it is not my intention.
> I.e -- instead of the current editor's support for 1 or 2-width chars,
> one could use 1-10 width chars, with an 'i' taking 1 width, and an 'M'
> taking 4-5, and asian chars taking 8-10.
>
> Please stop claiming vim could never support multi-width
> character sets, as it already does support bi-width character sets.
It's not as simple. Double-width characters could not be displayed at
all before it was decided to use 2 columns for them, so no compatibility
was broken. Now you would want to break compatibility with something
which works well, and for the dubious profit of making proportional
fonts look better.
>
> -l
>
Regards,
Tony.
--
Here is the fact of the week, maybe even the fact of the
month. According to probably reliable sources, the Coca-Cola people
are experiencing severe marketing anxiety in China.
The words "Coca-Cola" translate into Chinese as either
(depending on the inflection) "wax-fattened mare" or "bite the wax
tadpole".
Bite the wax tadpole.
There is a sort of rough justice, is there not?
The trouble with this fact, as lovely as it is, is that it's
hard to get a whole column out of it. I'd like to teach the world to
bite a wax tadpole. Coke -- it's the real wax-fattened mare. Not bad,
but broad satiric vistas do not open up.
-- John Carrol, San Francisco Chronicle
Linda W
> On 14/05/11 22:49, Linda W wrote:
>> Tony Mechelynck wrote:
>>> On 19/04/11 09:36, Alexander Stepanov wrote:
>>>
>>> this is due to the fixed size of the character
>>> cell in gvim, something so fundamental to Vim's mode of operation that
>>> it is not going to change.
>> ---
>> Please don't continue to spread this misinformation. While the
>> current Vim may not support proportional fonts, it is already true that
>> Vim "fundamental mode of operation" has changed and supports displaying
>> characters that take more than 1 character cell. I.e. your information
>> is already outdated.
>
> It's not outdated information, I was simplifying.
>
> The size of Vim's character cell *is* fixed. The following uses are
> possible:
> - most characters use exactly 1 character cell each;
> - CJK "wide" characters use exactly 2 character cells each;
So 1 character in a CJK font takes 1 or 2 character cells?
Doesn't that statement come across as a bit self-contradictory to you?
Doesn't it occur to use that the use of the term 'character
cell' doesn't describe that it is? If it was a character cell, any
character would fit.
You are using a definition of 'character (character cell)
to indicate something that holds a variable amount of a character (a full
or partial character).
This terminology is inaccurate and misleading as 1 cell doesn't hold
a full character, but really represents 1 space on the screen.
A better term, perhaps, would be 'spacing cell'. I would
agree that spacing cells are fixed lengths, but 'cells' to hold 1
character are either 1 or 2 spacing cells in length.
This is what I meant by the number of spacing cells/character
could be made, for example, 1-10 spacing cells/character. This would
allow up to 10 width variations to display 1 real character which would
likely accommodate proportional spacing accurate to within 1/10th of
a character.
We can always be correct in our statements if we use definitions
that don't describe what is actually going on, but use imprecise or
arbitrary definitions of terms in creating those statements.
For example, if I define 'character cell' to be "the cell which
contains all characters in a line', I could say that all vim lines are 1
character cell long -- and this is a fundamental feature of vim....etc.
This wouldn't be a definition that allows looking at, say, # of characters
per lines.