Use CMap in Type0 fonts when CFF is not a CID font #10683
Conversation
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 2 Live output at: http://54.67.70.0:8877/c5fda57454cae19/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 2 Live output at: http://54.215.176.217:8877/23a24e24a4df85b/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/c5fda57454cae19/output.txt Total script time: 18.17 mins
|
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/23a24e24a4df85b/output.txt Total script time: 25.44 mins
Image differences available at: http://54.215.176.217:8877/23a24e24a4df85b/reftest-analyzer.html#web=eq.log |
|
Actually the PDF isn't broken. The spec mentions that CFF data can be used like this. Because the CFF doesn't support CIDs, glyph indexes are used as CID values. |
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/8c29a31e08c98cb/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/8c29a31e08c98cb/output.txt Total script time: 1.88 mins Published |
|
Nice find, thanks! |
|
/botio makeref |
From: Bot.io (Linux m4)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/3eb43a8fb7240a7/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 2 Live output at: http://54.215.176.217:8877/d0a9a3615312de1/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/3eb43a8fb7240a7/output.txt Total script time: 16.64 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/d0a9a3615312de1/output.txt Total script time: 22.95 mins
|
Fixes #9534
in which the PDF uses composite Type0 fonts and the embedded CFF data is not in CID font format. The problems are caused by the
Encodingentry whose value is an embedded CMap stream. The existing implementation ignores the CMap, so wrong glyphs are rendered.Most PDFs like this use
/Encoding /Identity-Hinstead. They have no problems and their rendering is not affected by this PR.