How to tell if a font supports character

[richard emberson]

I am using a linux system with console Vim 7.3 in an xterm.

If I start the xterm with font 10x20, then
if I enter
Cntl-V u 250C
I see BOX DRAWINGS LIGHT DOWN AND RIGHT character
and entering 'ga' shows that its there.
If I enter
Cntl-V u 2554
the BOX DRAWINGS DOUBLE DOWN AND RIGHT
does not show up,
but entering 'ga' shows that its there.

On the other hand, if I start the xterm with font
'-misc-fixed-medium-r-normal-*-20-*-*-*-*-*-iso10646-*'
then both characters are displayed and using 'ga'
shows them both just like using the 10x20 font.

Clearly, the non-unicode font 10x20 does not support
the extended BOX DRAWINGS DOUBLE character and it does
not get rendered.

Is there a way in Vim to tell if a character will actually
be rendered for the end viewer? So, a script can know not to
use that character. Or, must the end user of the script
always have to figure out that they must set some
configuration options to disable the use of such characters?

Thanks
Richard

--
Quis custodiet ipsos custodes

[Benjamin R. Haskell]

On Wed, 16 May 2012, richard emberson wrote:

> I am using a linux system with console Vim 7.3 in an xterm.
>
> If I start the xterm with font 10x20, then if I enter
> Cntl-V u 250C
> I see BOX DRAWINGS LIGHT DOWN AND RIGHT character and entering 'ga'
> shows that its there.
> If I enter
> Cntl-V u 2554
> the BOX DRAWINGS DOUBLE DOWN AND RIGHT
> does not show up, but entering 'ga' shows that its there.
>
> On the other hand, if I start the xterm with font
> '-misc-fixed-medium-r-normal-*-20-*-*-*-*-*-iso10646-*' then both
> characters are displayed and using 'ga' shows them both just like
> using the 10x20 font.
>
> Clearly, the non-unicode font 10x20 does not support the extended BOX
> DRAWINGS DOUBLE character and it does not get rendered.
>
> Is there a way in Vim to tell if a character will actually
> be rendered for the end viewer?

No, most(?)¹ terminal emulators don't have such a mechanism.

> So, a script can know not to use that character.

I'm not sure what you mean here. Why would a script care? If a user
opens a file in terminal Vim and it contains characters that can't be
displayed, the user can just quit and open it in another editor that can
display the characters (another terminal with a different font, or some
GUI program). The user can also, as you reported, edit the file anyway
(Vim won't corrupt the data -- it just won't be displayed properly).

Otherwise, if it's not a file, why does Vim come into play?

> Or, must the end user of the script always have to figure out that
> they must set some configuration options to disable the use of such
> characters?

Maybe a flag such as '--ascii' or '--no-unicode' to prevent the use of
"fancy" box drawing would be sufficient? `pstree`, for example, has
three modes:

-A|--ascii : ASCII characters
-G|--vt100 : VT-100 line drawing
-U|--unicode : Unicode box drawing characters

--
Best,
Ben

¹: I'm 90% sure you could finagle this through rxvt-unicode's Perl
extensions, but there's definitely no portable way to do it.

[richard emberson]

I am working on a plugin that draws.
I certainly can draw with characters such as:
'-', '|' and '+' which are supported by
all fonts. But, I'd like to do better for
those users that have fonts that support
the unicode box drawing characters. But, again,
how to tell if such a character will actually
be rendered.

Richard

Quis custodiet ipsos custodes

[Christian Brabandt]

Hi richard!

On Do, 17 Mai 2012, richard emberson wrote:

> I am working on a plugin that draws.
> I certainly can draw with characters such as:
> '-', '|' and '+' which are supported by
> all fonts. But, I'd like to do better for
> those users that have fonts that support
> the unicode box drawing characters. But, again,
> how to tell if such a character will actually
> be rendered.

You can't. You can only give the user a configuration option.

regards,
Christian
--

[Ben Fritz]

On Thursday, May 17, 2012 7:57:08 AM UTC-5, Benjamin R. Haskell wrote:
> > So, a script can know not to use that character.
>
> I'm not sure what you mean here. Why would a script care? If a user
> opens a file in terminal Vim and it contains characters that can't be
> displayed, the user can just quit and open it in another editor that can
> display the characters (another terminal with a different font, or some
> GUI program). The user can also, as you reported, edit the file anyway
> (Vim won't corrupt the data -- it just won't be displayed properly).
>
> Otherwise, if it's not a file, why does Vim come into play?
>

I can think of a few examples:

1. A plugin which displays markers in the sign column might want to use fancy Unicode arrow characters if supported, or a simpler "->" text if not. Eclim, for example, gives options allowing the user to specify the text to use for this reason, and defaults to using ASCII. http://eclim.org
2. A plugin which shows a call tree or something might want use fancy Unicode characters to draw lines between the tree items if supported, or simple ->, +, and | characters if not. http://www.vim.org/scripts/script.php?script_id=2368 is an example of this.
3. A plugin might just want fancy Unicode characters to show specific states, like an open or closed "fold", e.g. the Tagbar plugin. http://www.vim.org/scripts/script.php?script_id=3465

[Ben Fritz]

On Thursday, May 17, 2012 8:44:04 AM UTC-5, Richard wrote:
> I am working on a plugin that draws.
> I certainly can draw with characters such as:
> '-', '|' and '+' which are supported by
> all fonts. But, I'd like to do better for
> those users that have fonts that support
> the unicode box drawing characters.

Are you aware of the DrawIt plugin?

http://www.vim.org/scripts/script.php?script_id=40

[richard emberson]

Yes, thank you. I actually downloaded it last week
but have not looked at it in detail.
From its documentation it seems to indicate that
one can start the drawing mode with commands which
instruct it to assume only ascii or utf-8 or "double-bar"
mode - fuller unicode support. So, it does not seem to
auto-magically detect the font that is being used
or the level of drawing characters supported.

Richard

[Chris Jones]

On Wed, May 16, 2012 at 08:25:02PM EDT, richard emberson wrote:


> Is there a way in Vim to tell if a character will actually be rendered
> for the end viewer? So, a script can know not to use that character.
> Or, must the end user of the script always have to figure out that
> they must set some configuration options to disable the use of such
> characters?

I would imagine that Vim (or other terminal applications do not care and
that it is just a matter of whether the font provides a glyph for the
required character.

As I understand it, fontconfig is able to figure out from imbedded
tables what character range(s) is(are) covered by a given font.

If you run an ‘fc-scan /usr/share/fonts/../myfont’ from a shell prompt,
you should see a ‘charset: property, which looks like what you are
looking for... presumably a table where bits are set when the code point
is covered by the font... - I'm mostly guessing since I haven't found
any documentatiion that gives much detail.

OTOH, libfontconfig does provides an ‘FcCharSetHasChar’ function that
suspiciously looks like it may do what you need.

If it does, you would still have to figure out how to invoke the
function from a VimL script.. I believe python, perl, ruby.. etc.
provide bindings to libfontconfig, but I not sure VimL even provides
a mechanism where you could write your own.

If there's any truth in the above guesswork.. and you manage to figure
out the layout of fc-scan's ‘charset:’ output you could always use
VimL's ‘system()’ function to read it into a variable and figure it out
yourself.. neither pretty nor robust in the long run (any one could
decide to ‘improve’ the outpout of fc-scan at a later date)

A quick search of the fontconfig mailing list did not reveal anything
conclusive, so I would suggest asking them for assistance.

CJ

--
Focus follow mouse users will burn in hell!!!

[Charles Campbell]

richard emberson wrote:
>
> Yes, thank you. I actually downloaded it last week
> but have not looked at it in detail.
> From its documentation it seems to indicate that
> one can start the drawing mode with commands which
> instruct it to assume only ascii or utf-8 or "double-bar"
> mode - fuller unicode support. So, it does not seem to
> auto-magically detect the font that is being used
> or the level of drawing characters supported.

Nor does DrawIt impose whatever the current font may support on the
file, as the file may be intended
for those who don't have or use the current font; such as may happen
when sharing a file with nedit
users, for example. Instead, it lets the user decide what drawing
characters should be used.

Chip Campbell