Windows Cyrillic + Finnish
Windows Cyrillic + Finnish is a modification of Windows-1251 that was used by Paratype to cover languages that use the Cyrillic script such as Russian, Bulgarian, and Serbian Cyrillic on a Finnish language keyboard. This encoding is supported by FontLab Studio 5.[1] This encoding is missing the letters Š and Ž which are used in loanwords in Finnish and can be replaced by the digraphs SH and ZH.
Character set
The following table shows Windows Cyrillic + Finnish. Each character is shown with its Unicode equivalent and its decimal code.
_0 | _1 | _2 | _3 | _4 | _5 | _6 | _7 | _8 | _9 | _A | _B | _C | _D | _E | _F | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0_ 0 |
NUL 0000 |
SOH 0001 |
STX 0002 |
ETX 0003 |
EOT 0004 |
ENQ 0005 |
ACK 0006 |
BEL 0007 |
BS 0008 |
HT 0009 |
LF 000A |
VT 000B |
FF 000C |
CR 000D |
SO 000E |
SI 000F |
1_ 16 |
DLE 0010 |
DC1 0011 |
DC2 0012 |
DC3 0013 |
DC4 0014 |
NAK 0015 |
SYN 0016 |
ETB 0017 |
CAN 0018 |
EM 0019 |
SUB 001A |
ESC 001B |
FS 001C |
GS 001D |
RS 001E |
US 001F |
2_ 32 |
SP 0020 |
! 0021 |
" 0022 |
# 0023 |
$ 0024 |
% 0025 |
& 0026 |
' 0027 |
( 0028 |
) 0029 |
* 002A |
+ 002B |
, 002C |
- 002D |
. 002E |
/ 002F |
3_ 48 |
0 0030 |
1 0031 |
2 0032 |
3 0033 |
4 0034 |
5 0035 |
6 0036 |
7 0037 |
8 0038 |
9 0039 |
: 003A |
; 003B |
< 003C |
= 003D |
> 003E |
? 003F |
4_ 64 |
@ 0040 |
A 0041 |
B 0042 |
C 0043 |
D 0044 |
E 0045 |
F 0046 |
G 0047 |
H 0048 |
I 0049 |
J 004A |
K 004B |
L 004C |
M 004D |
N 004E |
O 004F |
5_ 80 |
P 0050 |
Q 0051 |
R 0052 |
S 0053 |
T 0054 |
U 0055 |
V 0056 |
W 0057 |
X 0058 |
Y 0059 |
Z 005A |
[ 005B |
\ 005C |
] 005D |
^ 005E |
_ 005F |
6_ 96 |
` 0060 |
a 0061 |
b 0062 |
c 0063 |
d 0064 |
e 0065 |
f 0066 |
g 0067 |
h 0068 |
i 0069 |
j 006A |
k 006B |
l 006C |
m 006D |
n 006E |
o 006F |
7_ 112 |
p 0070 |
q 0071 |
r 0072 |
s 0073 |
t 0074 |
u 0075 |
v 0076 |
w 0077 |
x 0078 |
y 0079 |
z 007A |
{ 007B |
| 007C |
} 007D |
~ 007E |
DEL 007F |
8_ 128 |
Ђ 0402 |
Ѓ 0403 |
‚ 201A |
ѓ 0453 |
„ 201E |
… 2026 |
† 2020 |
‡ 2021 |
ˆ 02C6 |
‰ 2030 |
Љ 0409 |
‹ 2039 |
Њ 040A |
Ќ 040C |
Ћ 040B |
Џ 040F |
9_ 144 |
ђ 0452 |
‘ 2018 |
’ 2019 |
“ 201C |
” 201D |
• 2022 |
– 2013 |
— 2014 |
˜ 02DC |
™ 2122 |
љ 0459 |
› 203A |
њ 045A |
ќ 045C |
ћ 045B |
џ 045F |
A_ 160 |
NBSP 00A0 |
Ў 040E |
ў 045E |
Ó 00D3 |
¤ 00A4 |
Ґ 0490 |
¦ 00A6 |
§ 00A7 |
Ё 0401 |
© 00A9 |
Ä 00C4 |
« 00AB |
¬ 00AC |
SHY 00AD |
® 00AE |
Ö 00D6 |
B_ 176 |
° 00B0 |
± 00B1 |
Å 00C5 |
å 00E5 |
ґ 0491 |
µ 00B5 |
¶ 00B6 |
· 00B7 |
ё 0451 |
№ 2116 |
ä 00E4 |
» 00BB |
ó 00F3 |
É 00C9 |
é 00E9 |
ö 00F6 |
C_ 192 |
А 0410 |
Б 0411 |
В 0412 |
Г 0413 |
Д 0414 |
Е 0415 |
Ж 0416 |
З 0417 |
И 0418 |
Й 0419 |
К 041A |
Л 041B |
М 041C |
Н 041D |
О 041E |
П 041F |
D_ 208 |
Р 0420 |
С 0421 |
Т 0422 |
У 0423 |
Ф 0424 |
Х 0425 |
Ц 0426 |
Ч 0427 |
Ш 0428 |
Щ 0429 |
Ъ 042A |
Ы 042B |
Ь 042C |
Э 042D |
Ю 042E |
Я 042F |
E_ 224 |
а 0430 |
б 0431 |
в 0432 |
г 0433 |
д 0434 |
е 0435 |
ж 0436 |
з 0437 |
и 0438 |
й 0439 |
к 043A |
л 043B |
м 043C |
н 043D |
о 043E |
п 043F |
F_ 240 |
р 0440 |
с 0441 |
т 0442 |
у 0443 |
ф 0444 |
х 0445 |
ц 0446 |
ч 0447 |
ш 0448 |
щ 0449 |
ъ 044A |
ы 044B |
ь 044C |
э 044D |
ю 044E |
я 044F |
Letter Number Punctuation Symbol Other Undefined
gollark: This is why you should use osmarks.tk osmarksbrowser.
gollark: Try NodeOS!
gollark: Or Great Information Transfer.
gollark: Git stands for GIT Is Tremendous.
gollark: The stages of git clone are: Receive a "pack" file of all the objects in the repo database Create an index file for the received pack Check out the head revision (for a non-bare repo, obviously)"Resolving deltas" is the message shown for the second stage, indexing the pack file ("git index-pack").Pack files do not have the actual object IDs in them, only the object content. So to determine what the object IDs are, git has to do a decompress+SHA1 of each object in the pack to produce the object ID, which is then written into the index file.An object in a pack file may be stored as a delta i.e. a sequence of changes to make to some other object. In this case, git needs to retrieve the base object, apply the commands and SHA1 the result. The base object itself might have to be derived by applying a sequence of delta commands. (Even though in the case of a clone, the base object will have been encountered already, there is a limit to how many manufactured objects are cached in memory).In summary, the "resolving deltas" stage involves decompressing and checksumming the entire repo database, which not surprisingly takes quite a long time. Presumably decompressing and calculating SHA1s actually takes more time than applying the delta commands.In the case of a subsequent fetch, the received pack file may contain references (as delta object bases) to other objects that the receiving git is expected to already have. In this case, the receiving git actually rewrites the received pack file to include any such referenced objects, so that any stored pack file is self-sufficient. This might be where the message "resolving deltas" originated.
References
- https://www.fontlab.com/font-editor/fontlab-studio-5/. Missing or empty
|title=
(help)
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.