|
|
BTW where are stored national names in fonts? |
|
|
In NAME table. I’ll try to handle it at some point, but font identifier will remain the default name as reported by FreeType and is generally in en. Which could (if different from the displayed name) lead to some problems here and there (eg. if you want to hack a Scribus file, which is highly legitimate) but necessary to ensure some consistancy when sharing a file. And it’s only available in SFNT based fonts such as TTFs and OTFs. I don’t know about localized names in PS fonts, will have a look. |
|
|
It will be good if jghali adds the blocks U+0250-U+02AF: IPA Extensions U+02B0-U+02FF: Spacing Modifier Letters U+0300-U+036F: Combining Diacritical Marks to support phonetic symbols and U+3000-U+303F: CJK Symbols and Punctuation U+3040-U+309F: Hiragana U+30A0-U+30FF: Katakana U+4E00-U+9FA5: CJK Unified Ideographs U+FF00-U+FFEF: Halfwidth and Fullwidth Forms to support Japanese! |
|
|
Adding this support is not trivial. So, to the original reporter, please be patient with this feature request. It takes a lot to implement this and some parts of the fix are dependent on other third party libraries. |
|
|
http://www.omniglot.com/language/names.htm is a list of native/local names for languages in their own scripts What does this feature depend on exactly to implement? Reference: I think this is where it's at in trunk: https://github.com/scribusproject/scribus/blob/a75ace2009dd838f22aa99b5c8b0a2ecf57d03c8/scribus/langmgr.cpp#L86 |
|
|
According to Craig: <Kunda> we're at the mercy of the designated UI font chosen by user, right ? <MrB> Kunda: yes <MrB> if the glyphs are not in the current gui font then we need to do something entirely different, ie, render the text into an image and stick that in the menu <MrB> ...and i dont think we're planning on rendering any fonts into their own images any time soon :) |
|
|
related: 0011453 |
|
|
Merging 0011453 in to this bug. |
|
|
japanese font names not working.png (22,171 bytes) |
|
|
jghali writes in 0011453:0029982We could indeed do better on Windows when searching font family name. FontConfig uses the internal name table and uses FreeType family name as a last resort: http://www.opensource.apple.com/source/X11/X11-0.40/xc/extras/fontconfig/src/fcfreetype.c |
|
|
in my estimation I've assigned this to 1.5.3 since CTL has a high probability of being merged, we'll most likely need this issue to work as well. |
|
|
There are two issue here: * The font has bogus name entries for Macintosh platform marked as Mac Roman encoded while they are actually Japanese. * The font has correctly encoded name entries for Microsoft platform in UCS-2 encoding, but FreeType seems to prefer the Macintosh platform names. One way to fix this is to parse the name table entries our selves and prefer the Unicode encoded names (the Macintosh names tend to have all sorts of crap in it since it is rarely tested as most software will prefer other platforms when present). This what FontConfig does and it reports the correct font names. The other way is to change FreeType to do something similar and submit the patch upstream. (Here is a link for the name table for people who are not familiar with its arcane terminology https://www.microsoft.com/typography/otspec/name.htm). |
|
2016-05-07 15:22
|
font-name.png (31,955 bytes) |
|
|
I changed the CTL branch to read the family name from the name table directly and to prefer name records that are less likely to be broken: https://github.com/HOST-Oman/scribus/commit/9d853ea05312c5f8be32b0aea143a563e124ac5b, the screenshot shows this font being rendered correctly. |
- Anonymous
