Bug 706451

Summary:	cannot render glyph
Product:	MuPDF	Reporter:	Jorj <jorj.x.mckie>
Component:	mupdf	Assignee:	MuPDF bugs <mupdf-bugs>
Status:	UNCONFIRMED ---
Severity:	minor	CC:	donal.tong, robin.watts, sebastian.rasmussen
Priority:	P4
Version:	master
Hardware:	PC
OS:	Windows 11
Customer:		Word Size:	---
Attachments:	1-page PDF not rendering correctly bug2.pdf

Description Jorj 2023-03-06 07:22:21 UTC

When rendering the attached PDF, freetext issues a number of messages like "FT_Load_Glyph(GGRCZV+SourceHanSansCN-Normal,30426,FT_LOAD_NO_HINTING): invalid argument" and won't render the respective glyphs.

The MuPDF PDF viewer will consequently not rénder the page either (completely).
Other PDF readers like Foxit or evince on Linux however work flawlessly.

Question:
Can there anything be done about this?

Comment 1 Jorj 2023-03-06 07:25:16 UTC

Created attachment 23835 [details]
1-page PDF not rendering correctly

Comment 2 Robin Watts 2023-03-30 14:27:27 UTC

Created attachment 23930 [details]
bug2.pdf

Reduced to a file with a single font and a single char.

The char is given in the PDF as <6a6e>. ToUnicode correctly maps this as U+9664.

When we call Freetype, we work our way down to cff_charset_cid_to_gindex, which looks 0x6a6e up as 0. If instead we left it alone as 0x6a6e, it'd render the correct thing.

The calling code is:

    /* in a CID-keyed font, consider `glyph_index' as a CID and map */
    /* it immediately to the real glyph_index -- if it isn't a      */
    /* subsetted font, glyph_indices and CIDs are identical, though */
    if ( cff->top_font.font_dict.cid_registry != 0xFFFFU &&
         cff->charset.cids                               )
    {
      /* don't handle CID 0 (.notdef) which is directly mapped to GID 0 */
      if ( glyph_index != 0 )
      {
        glyph_index = cff_charset_cid_to_gindex( &cff->charset,
                                                 glyph_index );
        if ( glyph_index == 0 )
          return FT_THROW( Invalid_Argument );
      }
    }

(in cff_slot_load).

Comment 3 Donal 2023-04-13 07:26:05 UTC

while I use https://www.mupdf.com/wasm/demo/view.html to check the file bug2.pdf,
it run OK! 

the version libmupdf where I can get???

Comment 4 Donal 2023-04-14 01:10:12 UTC

(In reply to Robin Watts from comment #2)
> Created attachment 23930 [details]
> bug2.pdf
> 
> Reduced to a file with a single font and a single char.
> 
> The char is given in the PDF as <6a6e>. ToUnicode correctly maps this as
> U+9664.
> 
> When we call Freetype, we work our way down to cff_charset_cid_to_gindex,
> which looks 0x6a6e up as 0. If instead we left it alone as 0x6a6e, it'd
> render the correct thing.
> 
> The calling code is:
> 
>     /* in a CID-keyed font, consider `glyph_index' as a CID and map */
>     /* it immediately to the real glyph_index -- if it isn't a      */
>     /* subsetted font, glyph_indices and CIDs are identical, though */
>     if ( cff->top_font.font_dict.cid_registry != 0xFFFFU &&
>          cff->charset.cids                               )
>     {
>       /* don't handle CID 0 (.notdef) which is directly mapped to GID 0 */
>       if ( glyph_index != 0 )
>       {
>         glyph_index = cff_charset_cid_to_gindex( &cff->charset,
>                                                  glyph_index );
>         if ( glyph_index == 0 )
>           return FT_THROW( Invalid_Argument );
>       }
>     }
> 
> (in cff_slot_load).

I find that cannot render glyph after update the pr named ‘Extract CFF table from OpenType fonts in PDF’

Comment 5 Sebastian Rasmussen 2023-04-18 02:28:51 UTC

(In reply to Robin Watts from comment #2)
> The char is given in the PDF as <6a6e>. ToUnicode correctly maps this as
> U+9664.
> 
> When we call Freetype, we work our way down to cff_charset_cid_to_gindex,
> which looks 0x6a6e up as 0. If instead we left it alone as 0x6a6e, it'd
> render the correct thing.

I have seen the same behaviour when trying to render page2.pdf (different cid/gid of course) from bug 706060. Please read the discussion in that bug too.