Re: [ft-devel] The KaiU.ttf anomaly.

[suzuki toshiya]

Yet I've not checked anything, but it could be possible that
the special hinting in the tricky fonts consumes long time
(I remember the code chart generation with the tricky fonts
by Ghostscript show some contrast between unhinted fonts and
tricky fonts).

Current freetype.h tells as setting both of FT_LOAD_NO_AUTOHINT
and FT_LOAD_NO_HINTING can disable the hinting for tricky fonts.

  /*    FT_FACE_FLAG_TRICKY ::                                             */
  /*      Set if the font is `tricky', this is, it always needs the        */
  /*      font format's native hinting engine to get a reasonable result.  */
  /*      A typical example is the Chinese font `mingli.ttf' that uses     */
  /*      TrueType bytecode instructions to move and scale all of its      */
  /*      subglyphs.                                                       */
  /*                                                                       */
  /*      It is not possible to auto-hint such fonts using                 */
  /*      @FT_LOAD_FORCE_AUTOHINT; it will also ignore                     */
  /*      @FT_LOAD_NO_HINTING.  You have to set both @FT_LOAD_NO_HINTING   */
  /*      and @FT_LOAD_NO_AUTOHINT to really disable hinting; however, you */
  /*      probably never want this except for demonstration purposes.      */
  /*                                                                       */
  /*      Currently, there are about a dozen TrueType fonts in the list of */
  /*      tricky fonts; they are hard-coded in file `ttobjs.c'.            */

If it does not work well, it should be revised.

Regards,
mpsuzuki


Hin-Tak Leung wrote:
> Werner,
> 
> It is not possible to toggle hinting with either MingLiU or KaiU in ftview, 
> right?
> 
> I seems to remember many years ago before hinting was implemented/enabled, 
> they looks very bad - now that I understand hinting a lot more, I think the 
> problem with them is that they do very "creative" use of hinting to do 
> extremely large pixel movement to move stems into positions (instead of just 
> the half-pixel's for hinting in other fonts), and therefore does not work at 
> all without hinting. Is my understanding correct?
> 
> I am combing my stash of misc logs etc for my talk next week and found an 
> anomaly. The most time-consuming non-CJK fonts are times , times bold, arial, 
> arial bold - all around 20 mins; this seems glyph # related; but the most 
> timing consuming font is kaiu.ttf at 7 hours, above all the other CJK fonts, 
> including font collections, (which have bigger number of glyphs). mingliu.ttc 
> and mingliub.ttc took 1:45 and 3 hours respectively through font validator.
> simkai.ttf, which has a similar style, took almost exactly an hour. kaiu.ttf 
> is also on the small side as far as CJK fonts are concerned, file size wise.
> 
> So I am wonder why kaiu takes so long with font validator. What makes it 
> "special". So far I see it hasn't got embedded bitmap, but that's unrelated.
> 
> Hin-Tak
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>