| Summary: | Allow the use of system fonts with custom callbacks. | ||
|---|---|---|---|
| Product: | MuPDF | Reporter: | Ronni Egeriis Persson <ronni> |
| Component: | mupdf | Assignee: | MuPDF bugs <mupdf-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chris.liddell, jackie.rosen, ojab, tor.andersson, zeniko |
| Priority: | P4 | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
PNG output from pdfdraw
PDF input to pdfdraw test2.pdf acrobat without arial.ttf |
||
Created attachment 8444 [details]
PDF input to pdfdraw
Forgot the command: mupdfdraw -o %d.png -r 144 doc.pdf Created attachment 8503 [details]
test2.pdf
Simplified file, showing a single char that mupdf gets wrong, but gs and acrobat get right.
The problem is the job uses the non-embedded CIDFont Arial,Bold which, being a "well known name", MuPDF is substituting ("through" Helvetica) with the NimbusSanL-Bold font.
Using a font as a substitute for a CIDFont doesn't work (in Ghostscript it would produce an error).
If I nobble the CIDFont loading so it uses DroidSansFallback (instead of NimbusSanL-Bold) as the substitute in the cut down job, I get the correct glyph out.
So, I think mupdf's CIDFont loading needs to be revised so it doesn't do the "well known name" lookup (and only does it for fonts).
Oh, and to OP: This type of problem is *exactly* why the PDF *strongly* recommends always embedding CIDFonts - if the font were embedded, the job would work fine. (In reply to comment #4) > If I nobble the CIDFont loading so it uses DroidSansFallback (instead of > NimbusSanL-Bold) as the substitute in the cut down job, I get the correct glyph > out. > > So, I think mupdf's CIDFont loading needs to be revised so it doesn't do the > "well known name" lookup (and only does it for fonts). I tried the same, and we only get the correct glyphs out for the 7-bit ascii characters. All extended latin characters are still wrong. Ghostscript shows the same problem. The issue is that we don't have arial.ttf and the file is constructed to use direct glyph indexing (an Identity-H encoding). If a font uses the Identity-H encoding it MUST be embedded for it to work portably. If Adobe Reader, Preview and other software can interpret the file correctly, so should MuPDF be able to. This is rather critical for my usage of this software. Is it really impossible to do some kind of workaround to make the document readable at least? Created attachment 8536 [details]
acrobat without arial.ttf
See attachment for how Acrobat renders the file when arial.ttf is not available. It also fails miserably.
We don't have a license to ship arial.ttf; and for portability reasons we don't use system fonts in MuPDF.
I see! Could it be a workaround to have arial.ttf available in the system or is there any other failsafe way of working around this issue? Ronni: In case you're compiling for Windows, one work-around would be to use the MuPDF from http://code.google.com/p/sumatrapdf/source/browse/trunk#trunk%2Fmupdf which is able to load arial.ttf from the system's Fonts directory. TODO: Add hooks / callbacks to Fitz font context to allow system fonts to be loaded if clients provide a function for it. I am compiling on Linux; Ubuntu 10.04LTS I have similar issue with file http://ojab.ru/mupdf.pdf (not attaching due to personal info in it) and mupdf from git (commit 8a11586f923bf202083e37a98f7f1140dc1a8cdb). There is also many warnings in console like: >warning: freetype load glyph (gid 621): invalid argument >warning: ... repeated 2 times ... >warning: cannot render glyph >warning: freetype load glyph (gid 651): invalid argument >warning: ... repeated 2 times ... >warning: cannot render glyph Is it the same bug or I should file another one? There is a function fz_install_load_system_font_funcs that you can use to load system fonts via callbacks. |
Created attachment 8443 [details] PNG output from pdfdraw Please find attached PDF and PNG. This is the only case in which I've experience this issue, however it is a bit odd case. To replicate the bug, convert PDF to PNG with the following command. I've also tried updating to the latest commit to your master branch in git.