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?
Created attachment 23835 [details] 1-page PDF not rendering correctly
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).
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???
(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’
(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.