Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: [show CJK font full name instead font family name when preview fonts] #6763

Closed
windirt opened this issue Oct 7, 2020 · 9 comments · Fixed by #6786
Closed

FR: [show CJK font full name instead font family name when preview fonts] #6763

windirt opened this issue Oct 7, 2020 · 9 comments · Fixed by #6786
Milestone

Comments

@windirt
Copy link

windirt commented Oct 7, 2020

Does your feature request involve difficulty completing a task? Please describe.
not difficult

Describe the solution you'd like
when preview font name, if detect CJK font, showing the full font name which has CJK characters, instead showing the font family name which only contain english characters.
koreader

@poire-z
Copy link
Contributor

poire-z commented Oct 7, 2020

No alternative name seems to be accessible from the font library we use:
https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#ft_facerec

@windirt windirt reopened this Oct 7, 2020
@windirt
Copy link
Author

windirt commented Oct 7, 2020

in the doc, I found this. maybe useful.

family_name The face's family name. This is an ASCII string, usually in English, that describes the typeface's family (like ‘Times New Roman’, ‘Bodoni’, ‘Garamond’, etc). This is a least common denominator used to list fonts. Some formats (TrueType & OpenType) provide localized and Unicode versions of this string. Applications should use the format-specific interface to access them. Can be NULL (e.g., in fonts embedded in a PDF file). In case the font doesn't provide a specific family name entry, FreeType tries to synthesize one, deriving it from other name entries.

@windirt
Copy link
Author

windirt commented Oct 7, 2020

for example, here is the same ttf in kindle's custom font menu, it's CJK name can be recognized by kindle.
QQ20201007-233423@2x

@poire-z
Copy link
Contributor

poire-z commented Oct 7, 2020

Some formats (TrueType & OpenType) provide localized and Unicode versions of this string. Applications should use the format-specific interface to access them

I read that :) and what I meant is that our current library does not have the interface to access them. And adding other libraries just to get them feel a bit heavy :/

@NiLuJe
Copy link
Member

NiLuJe commented Oct 7, 2020

Does HB have methods to read those?

(Also: that kind of metadata is often quirky and/or bogus and/or wrong and/or outdated, so, here be dragons anyway).

@poire-z
Copy link
Contributor

poire-z commented Oct 7, 2020

Does HB have methods to read those?

Possibly: https://harfbuzz.github.io/harfbuzz-hb-ot-name.html

/**
 * hb_ot_name_id_t:
 * @HB_OT_NAME_ID_INVALID: Value to represent a nonexistent name ID.
 *
 * An integral type representing an OpenType 'name' table name identifier.
 * There are predefined name IDs, as well as name IDs return from other
 * API.  These can be used to fetch name strings from a font face.
 *
 * Since: 2.0.0
 **/
enum
{
  HB_OT_NAME_ID_COPYRIGHT               = 0,
  HB_OT_NAME_ID_FONT_FAMILY             = 1,
  HB_OT_NAME_ID_FONT_SUBFAMILY          = 2,
  HB_OT_NAME_ID_UNIQUE_ID               = 3,
  HB_OT_NAME_ID_FULL_NAME               = 4,
  HB_OT_NAME_ID_VERSION_STRING          = 5,
  HB_OT_NAME_ID_POSTSCRIPT_NAME         = 6,
  HB_OT_NAME_ID_TRADEMARK               = 7,
  HB_OT_NAME_ID_MANUFACTURER            = 8,
  HB_OT_NAME_ID_DESIGNER                = 9,
  HB_OT_NAME_ID_DESCRIPTION             = 10,
  HB_OT_NAME_ID_VENDOR_URL              = 11,
  HB_OT_NAME_ID_DESIGNER_URL            = 12,
  HB_OT_NAME_ID_LICENSE                 = 13,
  HB_OT_NAME_ID_LICENSE_URL             = 14,
/*HB_OT_NAME_ID_RESERVED                = 15,*/
  HB_OT_NAME_ID_TYPOGRAPHIC_FAMILY      = 16,
  HB_OT_NAME_ID_TYPOGRAPHIC_SUBFAMILY   = 17,
  HB_OT_NAME_ID_MAC_FULL_NAME           = 18,
  HB_OT_NAME_ID_SAMPLE_TEXT             = 19,
  HB_OT_NAME_ID_CID_FINDFONT_NAME       = 20,
  HB_OT_NAME_ID_WWS_FAMILY              = 21,
  HB_OT_NAME_ID_WWS_SUBFAMILY           = 22,
  HB_OT_NAME_ID_LIGHT_BACKGROUND        = 23,
  HB_OT_NAME_ID_DARK_BACKGROUND         = 24,
  HB_OT_NAME_ID_VARIATIONS_PS_PREFIX    = 25,

  HB_OT_NAME_ID_INVALID                 = 0xFFFF
};

typedef unsigned int hb_ot_name_id_t;

I don't think crengine should be the proxy for that, and neither xtext.
So, may be a small ffi/cdef wrapper to harfbuzz, just to see what kind of data is in there ? (If you feel like playing with it :)

@ezdiy
Copy link
Member

ezdiy commented Oct 7, 2020

No need to bother HB with this. It would just go back to freetype and ask it anyway :)

https://www.freetype.org/freetype2/docs/reference/ft2-sfnt_names.html
https://www.freetype.org/freetype2/docs/reference/ft2-truetype_tables.html#tt_name_id_xxx

That said, interpreting this stuff is pretty annoying. Add to this that a lot of chinese fonts just plaster those strings in big5/gb, with software having to do manual hacks to display stuff properly.

@poire-z
Copy link
Contributor

poire-z commented Oct 7, 2020

Had a try with adding a function to xtext to use the above Harfbuzz facilities (and not FreeType, as HB can use the current UI language tag and do the table inspection/lookup for us, and give us proper UTF8).

With my fonts, I only get something for zh_CN (Simplified chinese), nothing for zh_TW (Traditional Chinese, nothing for Japanese, nothing for any other languages (except for "Windings 2" ... which translate to... "Windings 2" in many languages :/).

I don't read chinese, but is the chinese stuff displayed there what you expect to see instead of the original font name (in parenthesis) ?
image image
image

static int xtext_getLocalizedFontName(lua_State *L) {
    // argument should be our Lua font object (face_obj), with
    // a getFallbackFont() callback.
    luaL_checktype(L, 1, LUA_TTABLE);
    lua_getfield(L, 1, "ftface");
    // We expect it to be a luajit ffi cdata, but the C API does not have a #define for
    // that type. But it looks like its value is higher than the greatest LUA_T* type.
    if ( lua_type(L, -1) <= LUA_TTHREAD ) {// Higher plain Lua datatype (lua.h)
        luaL_typerror(L, -1, "cdata");
    }
    // Get the usable (for Harfbuzz) FT_Face object
    FT_Face * face = (FT_Face *)lua_topointer(L, -1);
    lua_pop(L, -1); // remove ftface object
    hb_face_t * hb_face = hb_ft_face_create_referenced(*face);;
    char name[256];
    unsigned int len = 256;
    unsigned int res = hb_ot_name_get_utf8 (hb_face, HB_OT_NAME_ID_FULL_NAME, default_lang_hb_language, &len, name);
    hb_face_destroy(hb_face);
    if (res > 0) {
        lua_pushlstring(L, name, len);
        return 1;
    }
    return 0;
}

(For most people, it would be useless and expensive for nothing - I don't know if it should be an option, that people might enable and see nothing, and keep enabling and wasting cpu time for nothing - or just be enabled when lang= zh_CN...)

@windirt
Copy link
Author

windirt commented Oct 8, 2020

I don't read chinese, but is the chinese stuff displayed there what you expect to see instead of the original font name (in parenthesis) ?

The Chinese characters outside the parenthesis are indeed the font name I want to display.

ezdiy added a commit to ezdiy/koreader-base that referenced this issue Oct 8, 2020
Full binding, so as to avoid type dep annoynances in the future.
Primarily for mupdf font queries, but perhaps also more generally
cf koreader/koreader#6763
ezdiy added a commit to koreader/koreader-base that referenced this issue Oct 8, 2020
Full binding, so as to avoid type dep annoyances in the future.
Primarily for mupdf font queries, but perhaps also more generally,
cf koreader/koreader#6763
ezdiy added a commit to koreader/koreader-base that referenced this issue Oct 15, 2020
This is necessary for proper language support in mupdf with arbitrary
fonts in html/pdf - mupdf expects a real font server for its callbacks,
we're told abstract typeface, script and language that must be
accounted for whenever offering close-kin substitutes of a typeface.

There are marginal uses for this elsewhere, eg. localized font
names in UI - koreader/koreader#6763
ezdiy added a commit that referenced this issue Oct 20, 2020
Info about each face (l10n, name, family, style etc) is
now cached offline, so fonts can be queried ahead of time.

Fixes #6763
@Frenzie Frenzie added this to the 2020.11 milestone Oct 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants