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.
Related
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.
I am replacing my current Text components with TextMeshPro, and when replacing texts containing characters such as superscripts and subscripts, I am getting the error.
I am aware that in TextMeshPro there is the option <sub> </sub> and <sup> </sup> to create superscripts and subscripts, but I preferred to do it directly with characters, as I did with normal Text.
The doubt comes from the fact that some characters are recognized, and others not:
² (recognized)
⁵ (recognized)
⁶ (not recognized)
The subscripts, on the other hand, do not recognize even one of them.
This thread contains all the information on solving the problem.
https://forum.unity.com/threads/textmeshpro-does-not-recognize-subscripts-and-superscripts.1151834/
In short words,
I changed the default font to a font that supported superscripts and subscripts. From that font I created two TMP fonts, one static with the main ASCII characters and one dynamic for the rest of the characters. Then I added the dynamic font in the static font fallbacks, and fine. Add the static font to the TMP and that's it.
In xcode, developing for iOS "\u{1F3F3}\u{FE0F}\u{200D}\u{1F308}" is a rainbow flag.
"\u{1F3F3}" is a white flag, and "\u{1F308}" is a rainbow. The middle symbols "\u{FE0F}\u{200D}" are invisible symbols used to join these two together to make the rainbow flag symbol.
I am trying to combine unicode characters to make a rainbow infinity symbol, but not exactly sure how to implement this.
Not sure if there is an already existing unicode character or apple api I can use to do this, but would appreciate learning how to do this
I wouldn't mind having an infinity symbol over the rainbow flag either (like the apple anti-lgbt flag incident) as an alternative.
Emoji fonts are still just fonts. If they don’t contain a specific glyph, then they cannot display that glyph. The reason “🏳️🌈” looks like a rainbow flag is because someone drew a picture of a rainbow flag and then defined their font in such a way that the sequence <U+1F3F3, U+FE0F, U+200D, U+1F308> would be displayed using that specific image. Much like how someone first had to define the precise shape of the letter “A” in their font and then apply that glyph to the codepoint U+0041.
There is no image-rendering code that instinctively knows how to apply the colours of 🌈 to the shape of 🏳️ and then automatically generates a new glyph on the fly. It’s all explicitly pre-defined.
U+200D is the so-called Zero Width Joiner (ZWJ), so emoji sequences using that character are appropriately named Zero Width Joiner Sequences. They were originally invented by Apple to support emoji that weren’t part of the Unicode standard (in particular, variants of 💏, 💑, and 👪️ with different gender configurations), but later other vendors jumped on board as well and nowadays they are officially part of Unicode as an alternative way for defining new emoji without having to encode entirely new characters. Currently, about a third of all officially recommended emoji are ZWJ sequences.
In theory, any person can make up their own ZWJ sequences just by joining existing characters together (as was their original intent). In your case, “♾️+ZWJ+🌈” or <U+267E, U+FE0F, U+200D, U+1F308> would be an obvious sequence for a rainbow-coloured infinity symbol. You just have to create your own font containing the glyph you want, and then distribute that font to other people so that they can see the same glyph as you. There are just a few problems:
Making fonts with colourful glyphs is not easy. I couldn’t tell you whether there even exist freely available tools for that task.
There are four different formats for emoji fonts (used by Apple, Google, Microsoft, and Mozilla respectively) and they generally do not work on each other’s platforms, so you would need to create not just one, but several fonts unless you don’t care about people on other operating systems.
Installing your own fonts is not possible on most mobile phones, so your custom emoji would mostly only be available to desktop users.
I have an OpenType font with some optional glyphs selected by features. I've opened it in FontForge and I can see that the associated unicode code point is, for example, 0x1002a.
Is it possible to use this value to render the glyph in iText? I've tried calling showText() with a string containing the corresponding surrogate pairs ("\uD800\uDC2A") but nothing appears.
Is there another way to do this, or am I barking up the wrong tree?
We are using iTextSharp to create PDF's using a custom font and I am running into an issue with the unicode character 2120 (SM, Service Mark). The problem is the glyph is not in the custom font. Is there a way I can specify a fallback font for a field in a PDF? We tried adding a text field with Verdana so that the form had the secondary font embedded in it but that didn't seem to help.
First you need to find a font (ttf, otf,...) that has the character you need. Then you can use the FontSelector class and add the different fonts you want to use to this selector (see the FontSelectionExample). Now you can process every string:
FontSelector selector = new FontSelector();
selector.addFont(f1);
selector.addFont(f2);
Phrase ph = selector.process(some_string);
The FontSelector will return a phrase that consists of Chunks with font f1 for all the glyphs that are available in the first font, and Chunks with font f2 for the glyphs that couldn't be font in f1, but that are present in f2.
If you want the C# port of this example, please consult chapter 11.
Update
Using a FontSelector also works in the context of forms (as long as we're talking about AcroForm technology). It's really easy: you just need to add substitutions fonts to the form:
AcroFields form = stamper.getAcroFields();
form.addSubstitutionFont(bf1);
form.addSubstitutionFont(bf2);
Now the font defined in the form has preference, but if that font can't show a specific glyph, it will look at bf1, then at bf2 and so on. You can find an example demonstrating this functionality here.
Note that there's a difference between the first and the second example. In the first example we use a Font object, in the second, we use a BaseFont object.