I check if my TTF file has kerning information using FT_HAS_KERNING, and this returns true.
I then use:
FT_Vector delta;
FT_Get_Kerning( face, prev, next, FT_KERNING_DEFAULT, &delta );
to determine the kerning value, but both delta.x and delta.y have values of 0.
From the docs it seems that this means an error has occurred - how can I debug what the problem is even though FT_HAS_KERNING returns true?
All I want to do is fix the spacing between characters, as they currently appear strangely spaced.
I ended up downloading the TTX tool to look inside my TTF file and it turns out there was no kerning information in here for the pairs I desired.
With parameter FT_KERNING_DEFAULT it always returns 0.
See FT Kerning Mode.
Use FT_KERNING_UNFITTED instead.
Related
Is there a way to store subscript and superscript values in the Progress database, for example, chemical symbols and formulas, such as C2H5OH, and is it possible to display them ?
I tried copying from Word and pasting into fill in string fields but it doesn't format correctly, it doesn't recognize subscripted values and it is displayed as C2H5OH.
After some testing I've come this far:
1) You need to start your session with startup parameter -cpinternal utf-8 ie
prowin32.exe -cpinternal utf8
Depending on your need you might also need to set -cpstream utf-8 and possibly -cpcoll basic (or something else that matches your needs).
When I did this I had some strange crashes - but that might be because I edited a file saved in another codepage?
2) You need to get the data into your system (perhaps you already have it?).
I used Word and information found here and further explained here. The subscript font setting are just font settings (not unicode) so don't let that fool you (copy-pasting from your question is exactly the same). Basically you need to write the hexadecimal value of the subscript 2 (2082) in Word and then press Alt + X.
Assuming you want to write the actual data in a Progress based GUI I haven't been successful so far. Perhaps you could look at changing registry values as described in the links and continue along that path. I don't want to do that for just basic testing...
3) You will need a font with decent support for these characters. Some fonts don't support them at all!
Segoe UI:
Default system font (possibly) MS Sans Serif:
Arial:
5) Database? I'm unsure if you will need to use CLOB-fields to store this in your database or not. Most likely you shouldn't.
Hope this is enough to at least get you started!
I'm typing up a table with org mode, where the equal sign(=) if the first character in the cell and it want to start a formula. how do I get it to display the symbol without it being a formula, of a way to use formulas to display it. I get errors when I use single quotes, and I see the Unicode decimal value when using double quotes.
I have tried the following
='=+'
="=+"
they give
#ERROR
[61, 43]
Use an escaped entity, \equal{} and it should display as you wish. See the variable org-entities for others you can use.
I'm a bit late :D
There may be a better way, but you can try with :='(format "=+")
Source: https://emacs.stackexchange.com/questions/19183/can-i-use-formula-to-manipulate-text-in-org-mode-table
When I ran into this problem just now, I found that I was able to get around it by replacing the equals sign with some other similar-looking character. Two which come to mind are ꞊ ‘U+A78A MODIFIER LETTER SHORT EQUALS SIGN’ and ⹀ ‘U+2E40 DOUBLE HYPHEN’.
I want to implement a class to read vorbis comments. I know that a field will start with a field name, followed by an equal sign and the value. But how does it end? Documentation makes me think that a semicolon will end the field but I checked an ogg file with a hex editor and I cannot see any.
This is how I think it should look like in a file :
TITLE=MY SUPER TITLE;
The field name is title, followed by the equals sign and then the value is MY SUPER TITLE. And finally the semicolon to end the field.
But instead inside my file, the fields look like this :
TITLE=MY SUPER TITLE....
It's almost as above but there is no semicolon. The .'s are characters that cannot be displayed. I thought okay, it seems like the dots represent a value that will say "this is the end of the field!!" but they are almost always different. I noticed that there are always exactly 4 dots. The first dot has always a different value. The other free have usually a value of 0. But not always...
My question now, how does a field end? How do I read this comment?
Also, yeah I know that there are libraries and that I should use them instead of reinventing the wheel over and over again. I will use libraries later but first I want to know how to do it myself. Educational purpose only.
Each field is preceded by a little-endian 32-bit integer that indicates the number of bytes to read. You then convert the bytes to a string via UTF8.
See NVorbis' implementation (LoadComments(...)) for details.
When working in the Moovweb SDK, length("çãêá") is expected to return 4, but instead returns 8. How can I ensure that the length function works correctly when using Unicode characters?
This is a common issue with Unicode characters and the length() function using the wrong character set. To fix it you need to set the charset_determined variable to make sure the correct character set is being used before making the call to length(), like so in your tritium code:
$charset_determined = "utf-8"
# your call to length() here
In Unicode, there is no such thing as a length of a string or "number of characters". All this comes from ASCII thinking.
You can choose from one of the following, depending what you exactly need:
For cursor movement, text selection and alike, grapheme clusters shall be used.
For limiting the length of a string in input fields, file formats, protocols, or databases, the length is measured in code units of some predetermined encoding. The reason is that any length limit is derived from the fixed amount of memory allocated for the string at a lower level, be it in memory, disk or in a particular data structure.
The size of the string as it appears on the screen is unrelated to the number of code points in the string. One has to communicate with the rendering engine for this. Code points do not occupy one column even in monospace fonts and terminals. POSIX takes this into account.
There is more info in http://utf8everywhere.org
Until now I used a texture (bitmapfont) for font rendering, but I'm trying to get freetype2 working. All my strings are SHIFT_JIS encoded and my only Problem is now to get from freetype the right glyph to a proper SHIFT_JIS bitsequence. But it seems harder than I expected. To example "亜" has the charcode "0x889F" (byte 1 is set to 136 and byte 2 is 159) - that's according to the SHIFT_JIS encoding. So I called the function:
FT_Select_Charmap(face, FT_ENCODING_SJIS);
and try then to load a glyph with that charcode:
FT_Load_Char(face, 0x889F, FT_LOAD_RENDER );
But I receive some random glyph. It cant be a font-specific problem, because I tried already different fonts with the same result (and yeah, they provide a shift-jis charmap). To example "0" (zero) should be at position 0x0030 - but its in fact at 0x002D. Not all characters have an constant offset of 3, otherwise there would be no problem... I think my "FT_Load_Char" call, pass the charcode parameter in a wrong way - but cant guess how it would be right. Already tried:
FT_Load_Char(face, FT_Get_Char_Index(face, 0x889F), FT_LOAD_RENDER );
But then I receive another random glyph.
So, how can I pass the charcode to FT_Load_Char if not the default charmap is selected?
Any advice would be really helpful. Thank you.
If anyone will find this later with a similiar problem:
I ended up with converting the character codes on the fly to unicode (using icu4c). It seems like there`s a problem with a lot of japanese SJIS font headers (they can not selected via the freetype enums - only if you list all available charsets of one of these fonts and then choose the right manually - platform ID & encoding ID aren't identical for all of these fonts too). But that wasn't a proper solution for my needings (because using different fonts), so I finally decided to use Icu4c.
Hopefully this will be helpful to someone.