I'm trying to create a font using FontForge which is 'simply' the alphanumeric characters from Lato (original version) as well as the greek alphabet characters from Lato (extended version). I opened both fonts in FontForge and copied and pasted the greek letters over to the original version. I generated the font and displayed it in Google Chrome. But the characters that I've copied come out jagged / distorted. I've also tried opening the original font, then going to element and then merge fonts and selecting the extended version font and then generating a font from that but the same problem occurs.
The screenshot provided below shows the distortion going on. The top line shows how the letters should look. The bottom line shows how the letters actually look. Many of the letters - even the ones that were in the original (such as the 'a') - aren't displaying properly. The bottom and top of some characters has been flattened and for other characters, extended. Notice the top of the alpha, rho and epsilon are pointed and aren't smooth as they should be. The top of the beta has been flattened. Look at the top and bottom of the 'o' - both have been flattened as if to fit into a minimum allowable area.
If I zoom in a lot, the jagged edges become smooth again.
What can I do to fix this?
Related
I have a custom circular button on which I wish to set the lower left pencil unicode as title. I had tried setting the image, but for some reason the image isn't showing up, so I thought of showing the unicode character.
Unicode for lower left pencil is - U+1F589 (Resource - https://www.fileformat.info/info/unicode/char/1f589/index.htm)
Code - customButton.setTitle("\u{1F589}", for: .normal)
Issue - Doesn't work and just shows a question mark on the button.
If I use unicode for lower right pencil, then it works fine.
Code for right pencil - customButton.setTitle("\u{270E}", for: .normal)
Why isn't the code for left pencil working? Am I using the wrong way to set unicode characters for left pencil?
To display a character, it needs to be part of a font, and there is no system font on iOS or Mac that includes this character. In fact, I could only find two fonts on all of fontspace that include it. It is a very rare character.
Since it's been around since 2014 (Unicode 7.0), I doubt it will ever be picked up. It's a kind of a weird character. Neither it nor LOWER RIGHT PENCIL are emoji, so they aren't generally going to display the way you'd want them to, anyway. They're text-only glyphs.
There are a bunch of similar emoji, though:
🖊 U+1F58A LOWER LEFT BALLPOINT PEN
🖋 U+1F58B LOWER LEFT FOUNTAIN PEN
🖌 U+1F58C LOWER LEFT PAINTBRUSH
🖍 U+1F58D LOWER LEFT CRAYON
There is a right facing version of LOWER LEFT FOUNTAIN PEN, U+2711 WHITE NIB (✒️), if you need a matched set. The Swift is "\u{2711}\u{FEOF}".
Your code is fine. You just need to find another character. Lower-right pencil is an old character that has been around for a while judging by its unicode properties (v1.1 versus 7.0). I guess they never thought the need for a lower-left pencil, until now, and it just needs more time before it's (hopefully) more-widely adopted.
https://util.unicode.org/UnicodeJsps/character.jsp?a=270e&B1=Show
Lower-right pencil renders on the official Unicode character property analyzer.
https://util.unicode.org/UnicodeJsps/character.jsp?a=1F589&B1=Show
Lower-left pencil, however, doesn't render.
So apparently Overleaf now can render emojis using packages of Noto Color Emojis, where you can use {\NotoEmoji \symbol{"1F343} \symbol{"1F338} } to input an emoji with corresponding unicodes.
My question is how to input complex emojis that are composed of multiple emojis? For example, this one 👩👩👦👦, the unicode is U+1F469 U+200D U+1F469 U+200D U+1F466 U+200D U+1F466.
I've tried combinations like
\symbol{"1F469200d1f469200d...1f466}
\symbol{"1F469 200d 1f469 200d...1f466}
\symbol{"1F469} \symbol{"200d}...\symbol{"1f466}}
But none of them works.
You don't need to concatenate them. Here's the solution that I tried in Overleaf and it worked fine.
{\Large
\NotoEmoji
% family emoji
\symbol{"1F468}\symbol{"200D}\symbol{"1F469}\symbol{"200D}\symbol{"1F467}\symbol{"200D}\symbol{"1F466}
}
Expected Output
👨👩👧👦 Family: Man, Woman, Girl, Boy,
You can use the same trick for Emoji Skin Tone Modifiers in Overleaf where the modifier comes right after the emoji Unicode.
{\Large
\NotoEmoji
% Waving Hand emoji
\symbol{"1F44B}%
% Waving Hand: Light Skin Tone
\symbol{"1F44B}\symbol{"1F3FB}
}
Expected Output
👋
👋🏻
Here's the Overleaf Project page about Displaying Color Emojis in Latex that you can check out.
Updated 2020-11-28 : Adding emoji as an image in Latex
Since you mentioned adding emojis as images, I'm also including my solution for that.
\usepackage{tcolorbox}
% change font size here
\includegraphics[height=12]{family-man-woman-girl-boy.png}
The image can be downloaded from EmojiPedia.
I am trying to minimize the vertical distance between controls on a programmatically constructed Windows Form (using C#). This involves setting the Height property appropriately.
I have found that if the text of the control does not contain any letters with descenders in them (i.e. does not have any of the characters j, g, p, q or y) then the control Height can be smaller than when it does contain such letters (if it does contain letters with descenders then the descenders are chopped off if the Height isn't enough).
It will work fine to test for any of the above 5 characters as long as the language is English, or English - like, but I need to be able to cater for (just about) any language.
Is there a way, given some arbitrary Unicode character (and perhaps a font) to determine if that Unicode character has a descender or not?
There is no property defined for Unicode characters to indicate the presence of a descender, and it’s really a feature of glyph design rather than characters. For example, “Q” has a descenders in many fonts, and “J” has one in some. Besides, given the context, you should also consider diacritic marks placed below a letter, not just descenders of base letters. And probably diacritics above letters, too.
So you would need to read the font information (when available) about character dimensions, or tentatively draw characters in your software and measure their dimensions.
As a rule of thumb, any line height below 1.1 times the font size will cause problems with some characters and fonts. Using 1 (“setting solid”) is not enough, because characters may in fact extend outside the font size.
In Windows, you call GetPath() to get an array containing the X/Y coordinates of every point making up the perimeter or outline of the string of glyphs. Search the array for min/max, which will get you the rectangle exactly enclosing the string. Right to the edge of the letters.
I am not certain whether this is the right place to ask this, but I do not know of any other sites that would fit better. And the question has something to do with programming, so:
I Am Writing a formatted txt-guide. Please take a look at this excerpt: http://mad-gaksha.homelinux.net/public/width.txt. I need to have full-width characters displayed so that they occupy exactly twice the space as half-width characters. While monospaced fonts seems to work fine with only half-width chars, most fullwidth "fixed-width" fonts I've tried didn't produce the desired result.
In firefox, this works when I set the monospace font (Edit>Preferences>Content>Advanced)to "monospace". But only for a font-size of 14. Same thing with gedit, the fixed-width font MS-Gothic, works only for font sizes 13/14.
As I find this behaviour quite strange and wouldn't want my readers to be troubled by technical details, does anyone have suggestions or give any resources or could explain what's going on here? Why does it seem so hard just to display each glyph with a fixed size?
Thanks in advance for taking your time.
It looks like it's to do with rounding fractional pixels.
A font renderer may adjust horizontal positioning when the width of a glyph isn't a whole number of screen pixels. I believe the Cairo rendering used by gedit and Firefox on Linux doesn't do sub-pixel positioning for fonts so this may be necessary here.
In a true monospace font this doesn't matter because every glyph has the same width so receives the same treatment, but where there is a mixture of full- and half-width characters, the rounding won't be uniform unless the glyphs happen to be a whole number of pixels wide (which happens in your case at font size 14).
Note that on Windows for most small sizes, fonts like MS Gothic will be rendered using custom built-in bitmaps in the font file, instead of rendering the outlines and their metrics. This makes all glyphs necessarily a fixed number of pixels wide. However this does result in the typical old-school ‘jaggy’ rendering style.
If you are producing formatted-text files there is really nothing you can do about this. You can only hope that your target audience has Japanese monospaced fonts that are suitable and can switch to them at a particular font size.
I would agree with Clement's comment that using HTML to get the rendering you want would be more robust, modern and convenient. Using HTML for layout relieves you of having to worry about lining up characters, and allows you to get fonts that are less ugly than all that half-width-monospaced Latin.
Sorry if this isn't the right overflow for this question. I need a unicode character that is as long as ⎢ (23A2, LEFT SQUARE BRACKET EXTENSION) but lines up horizontally with ⎮ (23AE, INTEGRAL EXTENSION). Is there such a character?
Take a look at shapecatcher. If you draw a straight line, it shows plenty of different codepoints resembling |.
As already pointed out, exact placement and size may depend on the font, but if you know that the font is going to be a specific one (because you supply it), you could still find the character you're looking for.
It turns out this does depend on the font. If I use DejaVu Sans Mono, INTEGRAL EXTENSION is as long as I want it to be. This font appears to be almost exactly the same as the font I was using, Menlo, except for some small differences with some characters (including this one).