Re: [ft-devel] Text rendering error

[suzuki toshiya]

Sorry, the names of DLCLiShu and DLCHayBold are already included.
Maybe you refer legacy version of FreeType2. Only DFGothic-EB should
be added to the list of the names of tricky fonts. Due to the lack
of concrete fonts, some fonts are listed without checksum info
(e.g. see last commit on 2017-May-07), so it would be acceptable to
include the fix for family name.

> and if the subsetted font's family name is empty, we also add the subsetted 
> font's
> cvt/prep/fpgm checksums to FreeType?

Yes. Maybe, the fix for family name list would not resolve the
issue for 1.pdf & 2.pdf. For 3 fonts (DFGothic-EB, DLCLiShu, DLCHayBold),
no checksums are cared.

Regards,
mpsuzuki

address@hidden wrote:
> OK, so how do we fix this problem in the code inside?:
> 
> static const char trick_names[TRICK_NAMES_COUNT]
>                                  [TRICK_NAMES_MAX_CHARACTERS + 1] =
>     {
>       "DFKaiSho-SB",        /* dfkaisb.ttf */
>       "DFKaiShu",
>       "DFKai-SB",           /* kaiu.ttf */
>       "HuaTianKaiTi?",      /* htkt2.ttf */
>       "HuaTianSongTi?",     /* htst3.ttf */
>       "Ming(for ISO10646)", /* hkscsiic.ttf & iicore.ttf */
>       "MingLiU",            /* mingliu.ttf & mingliu.ttc */
>       "PMingLiU",           /* mingliu.ttc */
>       "MingLi43",           /* mingli.ttf */
>     };
> 
> --------------》
> 
> static const char trick_names[TRICK_NAMES_COUNT]
>                                  [TRICK_NAMES_MAX_CHARACTERS + 1] =
>     {
>       "DFKaiSho-SB",        /* dfkaisb.ttf */
>       "DFKaiShu",
>       "DFKai-SB",           /* kaiu.ttf */
>       "HuaTianKaiTi?",      /* htkt2.ttf */
>       "HuaTianSongTi?",     /* htst3.ttf */
>       "Ming(for ISO10646)", /* hkscsiic.ttf & iicore.ttf */
>       "MingLiU",            /* mingliu.ttf & mingliu.ttc */
>       "PMingLiU",           /* mingliu.ttc */
>       "MingLi43",           /* mingli.ttf */
> 
>       "DFGothic-EB",
> 
>       "DLCLiShu",
> 
>       "DLCHayBold",
>     };
> 
> and if the subsetted font's family name is empty, we also add the subsetted 
> font's
> cvt/prep/fpgm checksums to FreeType?
> 
> 
> 
> ------------------ Original ------------------
> From:  "suzuki toshiya"<address@hidden>;
> Date:  Thu, Nov 2, 2017 02:11 PM
> To:  "address@hidden"<address@hidden>;
> Cc:  "Werner LEMBERG"<address@hidden>; "freetype-devel"<address@hidden>;
> Subject:  Re: [ft-devel] Text rendering error
> 
> Dear Yan, Werner,
> 
> Sorry for lated response to this discussion.
> 
> It seems that DFGothic-EB in 1.pdf retains cvt/prep/fpgm
> tables, so it would be possible to include their checksums
> tricky font detector. I would try to find other PDFs
> including DFGothic-EB to confirm the checksums are stable.
> 
> Also, DLCLiShu and DLCHayBold in 2.pdf might be tricky.
> 
> Regards,
> mpsuzuki
> 
> 
> 
> 
> address@hidden wrote:
>> Werner and Toshiya-san, i found the base name is
>> DAWJQA+DFGothic-EB-WIN-RKSJ-H in the pdf file ,
>> maybe it is subsetted from the DFGothic_EB font.
>> so the DFGothic_XXX is the tricky' font?
>> and DFGothic_XXX font is not found in tt_check_trickyness.
>>
>>
>>
>> ------------------ Original ------------------
>> From:  "Werner LEMBERG"<address@hidden>;
>> Date:  Wed, Nov 1, 2017 05:20 PM
>> To:  "yinsen_yan"<address@hidden>;
>> Cc:  "freetype-devel"<address@hidden>; "mpsuzuki"<address@hidden>;
>> Subject:  Re: [ft-devel] Text rendering error
>>
>>
>>> This seems to be a subsetted `tricky' font.  However, all bytecode
>>> instructions have been stripped off from the glyphs...  Of course,
>>> this *must* fail :-)
>> Oops, sorry, there actually *is* bytecode in the glyphs and it works,
>> but only in v35 mode of the bytecode interpreter.  Because FreeType
>> can't detect the trickyness automatically, v40 is applied by default,
>> causing the bad rendering results.
>>
>> Toshiya-san, do you think it makes sense to add this subsetted font's
>> cvt/prep/fpgm checksums to FreeType?
>>
>>
>>     Werner
>>
>>
> 
>