| | <<<Back 1 day (to 2018/02/20) | 20180221 |
| paulgardiner | tor8: still looking at cutting down the size of mupdf in muso. -DTOFU_CJK gives a big win. You commented that when using that option, we need to implement load_system_cjk_font. Is that the case even when viewing only PDF docs? I realise that PDFs are supposed to embed fonts, but some don't. Is load_system_cjk_font part of the fallback mechanism? Are there other ways we should consider using... | 12:52.11 |
| | ...native fonts for fallback? | 12:52.13 |
| tor8 | paulgardiner: yes. load_system_cjk_font is part of the PDF fallback font system. | 12:54.33 |
| | for other missing fonts, we can mostly rely on the base14 fonts to provide the glyphs we need | 12:54.53 |
| | not so for CJK fonts | 12:54.55 |
| | so if we're building with TOFU_CJK we need some other way to provide CJK glyphs, which must be via system fonts using the callback you mentioned | 12:55.24 |
| | there are three ways PDF loads a missing font (i.e. not embedded fonts): | 12:57.31 |
| paulgardiner | Thanks tor8. That's clear now | 12:57.32 |
| tor8 | 1) its name is one of the base14 fonts -- we use it directly | 12:57.42 |
| | 2) its name is not a base14 font, we first try to use the load_system_font callback, and if that fails, use a base14 font | 12:58.07 |
| | 3) it's a CJK font, we first try to use the load_system_cjk_font callback, and if that fails, use the builtin CJK font (that you can disable with TOFU_CJK, and thus get nothing) | 12:58.35 |
| paulgardiner | So load_system_font, used in case 2, is less important, but might give a better match if implemented well? | 12:59.35 |
| tor8 | correct. | 12:59.42 |
| | we don't use it in any of our viewers, but sumatrapdf and other customers might. | 13:00.05 |
| | paulgardiner: actually, there is a slight modification to case 1. we do actually try the load_system_font callback but with the 'needs exact metrics' flag set to true | 13:01.40 |
| | it is a bit dangerous, but could be a way to get things working without embedding the 700kb of base14 fonts | 13:02.07 |
| paulgardiner | Okay interesting. And I think you say, they'd need to be type1 or CFF | 13:03.21 |
| tor8 | paulgardiner: I would be a lot more comfortable if they are. Things might work out otherwise, but I wouldn't bet on it. | 13:03.47 |
| | it would be entering uncharted territory (and it would be difficult to use the cluster to test, since a TTF font would render slightly differntly due to having different types of bezier curves) | 13:04.19 |
| | paulgardiner: an OTF font would work well enough, I think (but would need testing) | 13:05.02 |
| | since OTF is just a truetype wrapper around a CFF font | 13:05.20 |
| paulgardiner | Any good test files you can recommend for testing CJK fallback? | 13:05.32 |
| tor8 | not exactly sure how freetype handles encodings there though | 13:05.35 |
| | paulgardiner: there's a few files in tests_private/pdf/sumatra that would do | 13:06.27 |
| | 1149_-_japanese_vertical_punctuation_not_rotated.pdf or 1761_-_chinese_font_issue.pdf maybe | 13:08.30 |
| paulgardiner | Great. Thanks. | 13:12.42 |
| | Forward 1 day (to 2018/02/22)>>> | |
Log of #mupdf at irc.freenode.net.