I'm fairly new to FontForge, and I just want to merge two fonts for my specific usage.
I know how to merge two fonts from this question and I'm aware of TTF, ... 65535 lookup limits, so I'm trying to Detach & Remove Glyphs... for some glyph ranges, and for this:
I need to know how many glyph is defined, so I can decide which range to detach and remove. It seems fairly simple info, but I can not find where it is shown.
is there any menu or macro to show the current number of defined glyphs in FontForge?
I was looking for the same info. This will give you the number of defined glyphs fairly quickly:
fontforge -lang=ff \
-c 'Open($1); SelectWorthOutputting(); Print($selection)' "$FONTFILE" \
2>/dev/null |tr -d '][' |tr , '\n' |grep -c 1
The SelectWorthOutputting() function fills an array with ones for each defined glyph, so we can print this out and filter it to get the count.
I think found an answer, however it may not be the best approach. as FontForge saves projects in plain text, we can search for StartChar: keywords in the saved project file (project_name.sfd), which each section started by a StartChar: defines one glyphs in the font project. so if we count them we may know how many glyphs has been defined in the font file, for example, in bash the command:
grep -E "^StartChar\:" project_name.sfd | wc -l
would count them for us, and then we may know how many glyphs has been define so far.
This question pops up as first Google hit, so I'll just place this for posterity, but the proper code answer is from #Jerry Penner.
It's also possible from the program GUI to obtain the info in a quick dirty way:
Reduce the number of displayed glyphs via Encoding > Compact menu
Select the last glyph in your font
At the top right below the menu will be displayed the glyph "number" starting from 0 (so in below picture example the total count is 270).
Note: the number displayed is for the current compact view, not the actual glyph number in the font.
Related
original
<someTag></someTag>
but after running:
xmlstarlet fo --omit-decl --indent-spaces 1
it becomes
<someTag/>
but I need it to not shrink it and keep the original format
<someTag></someTag>
fo --html didn't help complaining about invalid tags (but will not complain w/o it)
The ed -L will also shrink it, and with -P (to keep whitespace) will not indent, and I need the indenting.
PS.: I found a lot of questions/answers but none related to xmlstarlet.
xmlstarlet c14n xml-file outputs Canonical XML which is intended for comparing XML documents. Among other things, canonicalization converts empty elements to start-end tag pairs and forces lexicographic attribute order so beware that output may have more changes than you wanted.
The c14n encoding will...
Add <![CDATA[textcontent]]> tags to text fields with spaces
Not preserve comments unless the additional --with-comments or --exc-with-comments commands line parameters are used
Main question
I would like to add powerline characters at the start and at the end of the selected completion, like this:
Started the completion menu by inserting c and pressing the TAB key.
Moved right in the completion menu by pressing the right arrow key.
Moved down in the completion menu by pressing the down arrow key.
Is there any way to make zsh look/behave like in the pictures?
Note
Added powerline triangle + blank character at the beginning and blank character + powerline triangle at the end should somehow be accounted when columns are created to keep the alignment correct.
Bonus
Add 2 blanks at the beginning of every completion in the list, so that when the completion is selected it doesn't look like the text was moved to the right.
( This issue can be seen by comparing the completion with and without the selection. )
Alternative question
In case that previously explained behavior is impossible to get without changing the zsh source code, is it at least possible to add powerline triangle only at the end of the selected completion?
My unsuccessful attempts
I have tried using the lc, rc, and ec variables in the list-colors style but that didn't help:
Completion list was badly aligned and it created all kinds of visual problems.
Symbols were inserted in all elements of the completion list, not just the selected one.
I have also tried using the ma variable, but I couldn't properly insert a character at the beginning:
The variable expects only a number that represents a color and it is probably wrapped in some escape sequences, so the output did not look as expected.
This works for me.
zstyle ":completion:*:default" list-colors ${(s.:.)LS_COLORS} "ma=48;5;153;1"
Uses my LS_COLORS and then ma sets the background of my selection to bold and color 153 from https://jonasjacek.github.io/colors/.
Found from https://www.zsh.org/mla/users/2010/msg00811.html
I have the following in my .zshrc:
setopt PROMPT_SUBST
precmd(){
echo""
LEFT="$fg[cyan]$USERNAME#$HOST $fg[green]$PWD"
RIGHT="$fg[yellow]$(date +%I:%M\ %P)"
RIGHTWIDTH=$(($COLUMNS-${#LEFT}))
echo $LEFT${(l:$RIGHTWIDTH:)RIGHT}
}
PROMPT="$ "
This gives me the following screenshot
The time part on the right is always not going all the way to the edge of the terminal, even when resized. I think this is due to the $(date +%I:%M\ %P) Anyone know how to fix this?
EDIT: Zoomed in screenshot
While your idea is commendable, the problem you suffer from is that your LEFT and RIGHT contains ANSI escape sequences (for colors), which should be zero-width characters, but are nevertheless counted toward the length of a string if you naively use $#name, or ${(l:expr:)name}.
Also, as a matter of style, you're better off using Zsh's builtin prompt expansion, which wraps a lot of common things people may want to see in their prompts in short percent escape sequences. In particular, there are builtin sequences for colors, so you don't need to rely on nonstandard $fg[blah].
Below is an approximate of your prompt written in my preferred coding style... Not exactly, I made everything super verbose so as to be understandable (hopefully). The lengths of left and right preprompts are calculated after stripping the escape sequences for colors and performing prompt expansion, which gives the correct display length (I can't possibly whip that up in minutes; I ripped the expression off pure).
precmd(){
local preprompt_left="%F{cyan}%n#%m %F{green}%~"
local preprompt_right="%F{yellow}%D{%I:%M %p}%f"
local preprompt_left_length=${#${(S%%)preprompt_left//(\%([KF1]|)\{*\}|\%[Bbkf])}}
local preprompt_right_length=${#${(S%%)preprompt_right//(\%([KF1]|)\{*\}|\%[Bbkf])}}
local num_filler_spaces=$((COLUMNS - preprompt_left_length - preprompt_right_length))
print -Pr $'\n'"$preprompt_left${(l:$num_filler_spaces:)}$preprompt_right"
}
PROMPT="$ "
Edit: In some terminal emulators, printing exactly $COLUMN characters might wrap the line. In that case, replace the appropriate line with
local num_filler_spaces=$((COLUMNS - preprompt_left_length - preprompt_right_length - 1))
End of edit.
This is very customizable, because you can put almost anything in preprompt_left and preprompt_right and still get the correct lengths — just remember to use prompt escape sequence for zero width sequences, e.g., %F{}%f for colors, %B%b for bold, etc. Again, read the docs on prompt expansion: http://zsh.sourceforge.net/Doc/Release/Prompt-Expansion.html.
Note: You might notice that %D{%I:%M %p} expands to things like 11:35 PM. That's because I would like to use %P to get pm, but not every implementation of strftime supports %P. Worst case scenario: if you really want lowercase but %P is not supported, use your original command subsitution $(date +'%I:%M %P').
Also, I'm using %~ instead of %/, so you'll get ~/Desktop instead of /c/Users/johndoe/Desktop. Some like it, some don't. However, as I said, this is easily customizable.
I am confused about the covert command of GraphicsMagick.
According to the documentation (http://www.graphicsmagick.org/convert.html), the synopsis of convert command is:
convert [ options ... ] input_file output_file
According to the above synopsis, I can execute the convert command in the following way:
Example 1:
gm convert -strip -scale x400 inputFile.jpg outputFile.jpg
The above command is executed successfully. Now, I ran the the same command with different index position of the options.
Example 2:
gm convert inputFile.jpg -strip -scale x400 outputFile.jpg
The above example executed successfully. The above example's index position of the options are different, does not match against the synopsis.
My question is, which example is correct?
I fear the answer is partly philosophical, partly folklore, partly opinion and partly flexibility of GraphicsMagick and partly rigidity of manpages. Let me explain...
To understand the answer, you need to differentiate between settings and operators. #KurtPfeifle did a great job here which, for the sake of completeness, I will summarise as follows:
Some parameters are settings - they set and retain their value till the end of the command or till changed. For example, -size sets the size of all canvases created after it is set on the commandline. Until the point it is first set, the default canvas size is 1x1, after it is set it remains till the end of the command.
Some parameters are operators - they generally perform some image processing, such as thresholding or converting to greyscale. These ones operate on all images currently in the image list.
Maybe an example will help. First, we use the -size setting:
gm convert -background none xc:red -size 5x5 xc:lime xc:blue -size 10x10 xc:magenta +append setting.png
Initially, the default size was 1x1, so the red canvas comes out at 1x1. Then I changed the setting and it remained at 5x5 for the lime and blue canvases till I changed it to 10x10 for the magenta one. Those were settings and they set things up for the images yet to come.
Now, I do a similar thing with the -colorspace operator:
gm convert xc:red xc:lime xc:blue -colorspace gray +append operator.png
And you see that the -colorspace operator has changed all the images that were already in the image list, i.e. they process images that have previously been added to the list.
If you like, you could simplify things and say "settings apply to all that is to come, and operators apply to all that has gone". Although I am sure there are counter-examples.
The order of the commandline options was rationalised a few years back and GraphicsMagick permits some flexibility to retain some backward compatibility. That is probably the best explanation of your actual question.
So, in general, you should declare settings as soon as posssible on the commandline and apply operators at the point that makes most sense depending on what images are currently in your list.
Another reason is that it would be very cumbersome, to the point of unintelligibility, if all the GraphicsMagick combinations and permutations were put in a conventional manpage. Can you imagine:
gm convert [[[operators|settings]|[settings|operators]] image] [[settings|operators]|[operators]] ...
I've searched through several answers here and through Google, but I'm still not sure what's going wrong with my prompt.
According to the documentation I've read, this should work
setopt prompt_subst
autoload -U colors && colors
PROMPT="%{[00m[38;5;245m%}test %D%{[00m%}"
My prompt is the following, however:
[00m[38;5;245mtest 15-07-01[00m
Note that the date expansion actually worked, so prompt substitution is working. The ZSH man pages for prompt expansion states that %{...%} should be treated as a raw escape code, but that doesn't seem to be happening. Passing that string to print -P also results in the output above. I've found example prompts on the Internet for ZSH that also seem to indicate that the above syntax should work. See this for one example - the $FG and $FX arrays are populated with escape codes and are defined here. I've tried this example directly by merging both the files above, adding setopt prompt_subst to the beginning just to make sure it's set, then sourcing it and the prompt is a mess of escape codes.
The following works
setopt prompt_subst
autoload -U colors && colors
PROMPT=$'%{\e[00m\e[38;5;245m%}test %D%{\e[00m%}'
I get the expected result of test 15-07-01 in the proper color.
I've tested this on ZSH 5.0.5 in OSX Yosimite, 5.0.7 from MacPorts, and 4.3.17 on Debian, with the same results. I know I have provided a valid solution to my own problem here with the working example, but I'm wondering why the first syntax isn't working as it seems it should.
I think this all has to do with the timeless and perennial problem of escaping. It's worth reminding ourselves what escaping means, briefly: an escape character is an indicator to the computer that what follows should not be output literally.
So there are 2 escaping issues with:
PROMPT="%{[00m[38;5;245m%}test %D%{[00m%}"
Firstly, the colour escape sequences (eg; [00m) should all start with the control character like so \e[00m. You may have also seen it written as ^[00m and \003[00m. What I suspect has happened is one of the variations has suffered the common fate of being inadvertently escaped by either the copy/paste of the author or the website's framework stack, whether that be somewhere in a database, HTTP rendering or JS parsing. The control character (ie, ^, \e or \003), as you probably know, does not have a literal representation, say if you press it on the keyboard. That's why a web stack might decide to not display anything if it sees it in a string. So let's correct that now:
PROMPT="%{\e[00m\e[38;5;245m%}test %D%{\e[00m%}"
This actually nicely segues into the next escaping issue. Somewhat comically \e[ is actually a representation of ESC, it is therefore in itself an escape sequence marker that, yes, is in turn escaped by \. It's a riff on the old \\\\\\\\\\ sort of joke. Now, significantly, we must be clear on the difference between the escape expressions for the terminal and the string substitutions of the prompt, in pseudo code:
PROMPT="%{terminal colour stuff%}test %D%{terminal colour stuff%}"
Now what I suspect is happening, though I can't find any documentation to prove it, is that once ZSH has done its substitutions, or indeed during the substitution process, all literal characters, regardless of escape significations, are promoted to real characters¹. To yet further the farce, this promotion is likely done by escaping all the escape characters. For example if you actually want to print '\e' on the command line, you have to do echo "\\\e". So to overcome this issue, we just need to make sure the 'terminal colour stuff' escape sequences get evaluated before being assigned to PROMPT and that can be done simply with the $'' pattern, like so:
PROMPT=$'%{\e[00m\e[38;5;245m%}test %D%{\e[00m%}'
Note that $'' is of the same ilk as $() and ${}, except that its only function is to interpret escape sequences.
[1] My suspicion for this is based on the fact that you can actually do something like the following:
PROMPT='$(date)'
where $(date) serves the same purpose as %D, by printing a live version of the date for every new prompt output to the screen. What this specific examples serves to demonstrate is that the PROMPT variable should really be thought of as storage for a mini script, not a string (though admittedly there is overlap between the 2 concepts and thus stems confusion). Therefore, as a script, the string is first evaluated and then printed. I haven't looked at ZSH's prompt rendering code, but I assume such evaluation would benefit from native use of escape sequences. For example what if you wanted to pass an escape sequence as an argument to a command (a command that gets run for every prompt render) in the prompt? For example the following is functionally identical to the prompt discussed above:
PROMPT='%{$(print "\e[00m\e[38;5;245m")%}test $(date)%{$(print "\e[00m")%}'
The escape sequences are stored literally and only interpreted at the moment of each prompt rendering.