Wrong bullet train oh-my-zsh theme render - oh-my-zsh

I have like an encoding error when the prompt is rendered.
I just installed the bullet-train theme for the oh-my-zsh plugin.
I installed the Powerline fonts as it is indicated in the bullet-train.zsh-theme file but though, my terminal doesn't seems to care.
It seems to be the right colors but there is "?" characters instead of the normal rendering.
Whereas it should be rendered like this: https://github.com/caiogondim/bullet-train-oh-my-zsh-theme
I have a MacBook Pro and I use iTerm2.

Install powerline font and pick one of those
https://github.com/powerline/fonts
For iTerm 2 users, make sure you go into your settings and set both the regular font and the non-ascii font to powerline compatible fonts or the prompt separators and special characters will not display correctly.

I finally fixed it by changing my settings for iTerm2:
simply change the font to a compatible one (powerline fonts)

Related

Powerline Glyphs Overlapping

Shown in the image below, the git prompt has overlapping glyphs.
I installed this theme by following the instructions listed Here. What doesn't make sense is that all prompts other than the git prompt look completely fine. So I guess the question is why would the git extension only be affected by this glyph misalignment?
I've been trying to do my best to research into any similar issues but could not find any thing outside of questions such as this.
The environment that I am using consists of the following
Kubuntu 15.04
Konsole
Tmux
zsh
xterm-256color
oh-my-zsh
powerline status bar
powerlevel9k theme
Font : ubuntu mono derivative powerline
My .zshrc contains these two lines to engage the powerlevel9k theme
ZSH_THEME="powerlevel9k/powerlevel9k"
POWERLEVEL9K_MODE="awesome-fontconfig"
Any insights on tweaking these glyphs will be incredibly helpful. So thanks in advance!
powerlevel9k uses in "awesome-*" mode the awesome-terminal-fonts. Some of the glyphs in there are double-width, which is why we added some extra whitespace to these icons (see here). Most of us use the "awesome-patched" mode, which requires pre-patched fonts, but is easier to install.
A quick shot would be to add some more whitespace. Could you try that, and if that works add a pull request? That would be nice.
Another guess in the wild is: what locale do you use? We had some strange issues with LANG=C. If that is the case on your machine, try setting it to a proper UTF8 one.

wkhtmltopdf custom font letter spacing

I'm running wkhtmltopdf on linux server (centos.10.x86_64). I'm trying to add "Times New Roman" font to the page. I see the fonts but on some font sizes it adds spaces between the letters. I tried setting the font by installing it on the machine (ttf) or by calling an external odf that I converted from the ttf or by adding it with base64 (css). It looks good on all, but it inserts spaces between the laters. I also tried to the dpi parameter but still the spaces are generated.
Generating the same pdf over MAC works perfectly (probably because the font comes with the machine)
Why does it happen and how can it be fixed ?
Thanks.
The image attached describes the bug. No spaces added in each of the fonts group.
The following the image text
abcdefg hijklmno pqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ
Was resolved using "svg" font format

Headless conver-to PDF soft-hyphen replaced with zero-width whitespace

i'm working on an webapp creating LibreOffice Documents that i want to convert to PDFs with unoconv and a headless libreoffice.
There is just one problem i can't solve: The soft-hyphens i include in the .odt are replaced with zero-width whitespaces in the resulting PDF. The Problem is not related to unoconv - i tried it directly with a headless libreoffice (same result). i tried both v 4.1.4.2 as well as 4.2.5.2.
i tried another font (Ubuntu) (i use Arial as the body font) as i expected that the missing Arial font on Linux causing the problem (i have the problem on the production server with debian 7 as well on a virtualbox with ubuntu 12.04).
i even installed the arial font in hope it caused the problem due to libreoffice inability to calculate where to set the "real" hyphens without the font file at hand.
strange thing: using LO 4.1.4.2 on my mac (headless of course) produces flawless PDFs. So the problem must be related to either linux or some missing "graphical" package in my server setup. i installed the hyphen-de package which results in hyphens based on the dictionary, but the specified soft-hyphens are still replaced with zero-width whitespaces.
the problem affects both body text as well as text boxes that are used for annotations.
i'd appreciate any hint very very much!
I had a similar problem.
I had to install the right language hyphenation package that fit with the document's language.

Chinese characters in IntelliJ IDEA 12 overlapped

I use IntelliJ IDEA to develop my Android project. I've encountered this issue when editing the string XML resource file today. The Chinese characters do show but just overlapped one by one. So basically all you see is a bunch of Chinese characters filled in and overlapped at single character space. Interestingly, when you try to delete those Chinese characters, you just delete the following XML closing tag but not the Chinese character itself...
Have tried copy/paste, same result. I am using the Windows 32bit version.
Can anybody help to fix this issue?
Please check this issue and linked issues for the problem background.
Right now when IDEA doesn't find the glyph to display in the current editor font that you have set in File | Settings | Editor | Colors & Fonts, Font, it starts to search for the first font that has this glyph and finds some font with incorrect metrics that displays overlapping glyphs.
When this request is implemented, you'll be able to specify the order of fall back fonts so that some properly working font is tried first.
At the moment the solution is to change the editor font to the one that has all the required glyphs and proper font metrics (or to find and uninstall the font that is tried first and is displayed incorrectly, note that when running under JDK 1.7 IDEA will also try .otf fonts, not just .ttf, that is why the behavior is different in IDEA 11 defaulting to JDK 1.6 and IDEA 12 that runs under JDK 1.7).

TTF webfont to desktop-useable TTF

I'm using a CC-BY FontAwesome typeface for icons on my Twitter Bootstrap-driven website. Now I want to use it in an image editor for a prototype of another website. But it does not work. I cannot use its webfont-TTF with my image editing application. How can I convert it to a normal font?
Please dont give me links to free-/shareware closed-source utilites. I want to know, why does this happening and implement my own script which would "fix" this font.
FontAwesome should work out of the box. Heres how to use it:
Download FontAwesome. Then open fonts/FontAwesome.otf and install it (either with fontbook on osx or by adding it to your fonts folder on windows).
Use the Cheatsheet to actually use specific icons. Find the icon you want there, select the icon and copy it.
Switch to your image editor, create a text item, set the font to FontAwesome, and paste the symbol you copied.
I assume you are talking about http://fontawesome.io/ .
If so there is nothing wrong with the TTF version of this font and no reason to convert it. I have tested the font on linux by dropping the .ttf file in /usr/share/fonts/ and it is useable in LibreOffice, Gimp and Terminal.
You problem is almost certainly one of:
The process you used to install the font
You aren't entering the correct Unicode characters or your image editor doesn't support Unicode.
However you failed to provide enough details. You haven't even defined what you mean by "it does not work". Please update your question with details like the process you used, a link to the actual font you downloaded and the operating system and image editor you're using.
In case you're still looking for a solution: the easy way is to convert the included SVG font to usable TrueType or OpenType, using e.g. FontForge or an online service.
AFAIK SVG fonts have no DRM flags, unlike TrueType.