I could use a font that might be named 'nosuchglyph'. This could be used for testing a font on the web with a font stack specified something like
style="font-family:'Some Font Regular', 'nosuchglyph'"
Every glyph would be an appropriate missing-character glyph. It could be minimally the same glyph for every single character -- something like a black rectangle or a rectangle outline with a '?' in the middle, or some similar image to convey that this glyph is missing. More ideal would be a rectangle per Unicode character code with a tiny display of that character code, something like this ASCII art for, say, the character code U+4f4f:
[4f4f]
Whatever it is, for any glyph missing in "Some Font Regular" (in this example) the glyph in the output would come from "nosuchglyph".
This is nice for testing in order to see for a given font, say, "Some Regular Font" as in the example, which characters are from that font and which are missing. This is meant to ensure you do not get the normal substitution for missing characters, which would show the glyph from a font later in the stack or else from some default fallback font.
Related
I am trying to check whether the font contains a glyph for a given character. To achieve this, I have loaded the font by readFontFile() and get a glyph of the character. Then, I wanted to check whether the glyph texture is available. I tried the next code
osg::ref_ptr<osgText::Font> font = osgText::readFontFile("path_to_fft_font_file");
auto glyph = font->getGlyph(std::make_pair(32.0f, 32.0f), charcode);
auto texture_info = glyph->getTextureInfo(osgText::ShaderTechnique::GREYSCALE);
For all char codes (that are really supported by the font and that are not) the texture_info is nullptr.
I also tried to check glyph->getTotalDataSize(). It gives not a zero value if the character is not supported by the font but the font contains a glyph for none Unicode (usually looks like ▯).
Is there a way to check if the osgText::Font object contains a non-none glyph for the given character?
Encoding is maping that gives characters or symbols a unique value.
If a character is not present in encoding no matter what font you use it won't display correct fonts
Like Lucida console, arial or terminal
But problem is terminal font is showing line draw characters but other font is not showing line draw characters
My question is why terminal is behaving different to other font
Plz note
Windows 7
Locale English
For the impatient, the relevant link is at the bottom of this answer.
Encoding is maping that gives characters or symbols a unique value.
No, that are the specifics of a character-set, which maps certain characters to code points (using the Unicode terminology). Lets ignore the above for now.
If a character is not present in encoding no matter what font you use it won't display correct fonts Like Lucida console, arial or terminal
Font formats map Unicode code points to glyphs. Not all code points may be mapped for specific fonts - somebody has to create all these symbols. Again, lets ignore this.
Not all binary encodings may map to code points within a certain character set; this is possibly what you mean.
But problem is terminal font is showing line draw characters but other font is not showing line draw characters
Your terminal seems to operate on a different character set, probably the "OEM" or "IBM PC" character set instead of a Unicode compliant character set or Windows-1252 / ISO 8859-1 / Latin.
If it is the latter than you are out of luck unless you can set your output-terminal to another character set, as Windows-1252 doesn't support the box drawing characters at all.
Solutions:
If possible try and set the output to OEM / IBM PC character set.
If it is Unicode you can try and convert the output to Unicode: read it in (decode it) using the OEM character set and then re-encode it using the box drawing subset.
When selecting a character from the Wingdings font to insert into a document, MS Word 2015 and InDesign CS 5.5 show different glyph indices for at least some characters.
According to Word, the character I am looking for, Unicode 25A0 (black square), has a decimal Wingdings gid of 110.
The two online resources I found, http://www.alanwood.net/demos/wingdings.html and http://www.csn.ul.ie/~caolan/wingdings/proposal/, confirm that number.
Still, InDesign displays a gid of 132.
Why does InDesign show a different gid for the same glyph of the same font?
You are confusing the assigned Unicode codepoint or character set encoding with the glyph index.
This font uses a custom character set, and it's the character n (U+006E) that actually displays a square -- not the Unicode character U+25A0. If you insert an Arial Unicode MS black square in your text and then change the font to Wingdings, you will see the character disappear.
The glyph index as reported by InDesign has nothing to do with character sets, Unicode, and anything else. This index is just an increasing number for each separate glyph in a font -- of which there may be few, quite some, or a lot. Glyph indexes always start at 0, which indicates the 'missing character' character (and so is not useful to use), and every next glyph is enumerated. This enumeration is translated to Unicode or another character mapping through a font's encoding. The enumeration in itself means nothing: a font may contain 'A', 'B', 'C' as its first 3 glyphs, or it may contain '#', '☺', 'ó', or anything else.
This glyph order is entirely irrelevant to the working of the font itself, and for all practical end-user operations you may as well forget there is such a thing. (It's something else if you try to change the font of a certain glyph -- you may get to see another character because there is absolutely no need for two fonts to have the same glyph in the exact same position.)
You are looking at the wrong place in InDesign: the Glyphs panel shows all glyphs and always shows their glyph index (because all characters have one, per definition of 'glyph index'), but only their Unicode codepoint if one is assigned.
InDesign is somewhat smarter than Word in how it processes dingbat/symbol fonts: rather than lying and saying 'this "is" the letter n', it assigns a private Unicode codepoint; in this case, U+F06E. That way you can never accidentally assign another font and get the letter n.
This is wrt iText 2.1.6.
I have a string containing characters from different languages, for which I'd like to pick a single font (among the registered fonts) that has glyphs for all these characters. I would like to avoid a situation where different substrings in the string are printed using different fonts, if I already have one font that can display all these glyphs.
If there's no such single font, I would still like to pick a minimal set of fonts that covers the characters in my string.
I'm aware of FontSelector, but it doesn't seem to try to find a minimal set of fonts for the given text. Correct? How do I do this?
iText 2.1.6 is obsolete. Please stop using it: http://itextpdf.com/salesfaq
I see two questions in one:
Is there a font that contains all characters for all languages?
Allow me to explain why this is impossible:
There are 1,114,112 code points in Unicode. Not all of these code points are used, but the possible number of different glyphs is huge.
A simple font only contains 256 characters (1 byte per font), a composite font uses CIDs from 0 to 65,535.
65,535 is much smaller that 1,114,112, which means that it is technically impossible to have a single font that contains all possible glyphs.
FontSelector doesn't find a minimal set of fonts!
FontSelector doesn't look for a minimal set of fonts. You have to tell FontSelector which fonts you want to use and in which order! Suppose that you have this code:
FontSelector selector = new FontSelector();
selector.addFont(font1);
selector.addFont(font2);
selector.addFont(font3);
In this case, FontSelector will first look at font1 for each specific glyph. If it's not there, it will look at font2, etc... Obviously font1, font2 and font3 will have different glyphs for the same character in common. For instance: a, a and a. Which glyph will be used depends on the order in which you added the font.
Bottom line:
Select a wide range of fonts that cover all the glyphs you need and add them to a FontSelector instance. Don't expect to find one single font that contains all the glyphs you need.
Does unicode have characters in it similar to stuff like the things formed by the <kbd> tag in HTML? I want to use it as part of a game to indicate that the user can press a key to perform a certain action, for example:
Press R to reset, or S to open the settings menu.
Are there characters for that? I don't need anything fancy like ⇧ Shift or Tab ⇆, single-letter keys are plenty. I am looking for something that would work somewhat like the Enclosed Alphanumerics subrange.
If there are characters for that, where could I find a page describing them? All the google searches I tried turned only turned up "unicode character keyboard shortcuts" stuff.
If there are not characters for that, how can I display something like that as part of (or at least in line with) a text string in Processing 2.0.1?
(The rendering referred to is not the default rendering of kbd, which simply shows the content in the system’s default monospace font. But e.g. in StackOverflow pages, a style sheet is used to format kbd so that it looks like a keycap.)
Somewhat surprisingly, there is a Unicode way to create something that looks like a character in a keycap: enter the character, then immediately COMBINING ENCLOSING KEYCAP U+20E3.
Font support to this character is very limited but contains a few free fonts. Unfortunately, none of them is a sans-serif font, and the character to be shown inside should normally appear in such a font – after all, real keycaps contains very simple shapes for characters, without serifs. And generally, a character and an enclosing mark should be taken from the same font; otherwise they might be incompatible. However, it seems that taking the normal character from the sans-serif font (FreeSans) in GNU Freefont and the combining mark from the serif font (FreeSerif) of the same source creates a reasonable presentation:
I’m afraid it won’t work here in text, but I’ll try: A⃣ .
Whether this works depends on the use of suitable fonts, as mentioned, but also on the rendering software. Programs have been rather bad at displaying combining marks, but there has been some improvement. I tested this in Word 2007, where it works OK, and also on web browsers (Chrome, Firefox, IE) with good results using code like this:
<style>
.cap { font-family: FreeSerif; }
.cap span { font-family: FreeSans; }
</style>
<span class="cap"><span>A</span>⃣</span>
It isn’t perfect, when using the fonts mentioned. The character in the cap is not quite centered. Moreover, if I try to use the technique e.g. for the character Å (which is present on normal Nordic keyboards), the ring above A extends out of the cap. You could tweak this by setting the font size of the letter in the cap to, say, 85% of the font size of the combining mark, but then the horizontal position of the letter is even more off.
To summarize, it is possible to do such things at the character level, but if you can use other methods, like using a border or a background image for a character, you can probably achieve better rendering.