So I cloned a book that a faculty member would like to use.
Somewhere on 7 different pages of this 600 page volume are unicode characters that caused the PDF export with prince to fail. Since the PDF export failed, I can’t see the chapter or page it was on. How would a master detective find the characters that need to be changed?
The full error log is below.
Array
(
[time] => Wed Feb 24 21:47:32 2021
[user] => beckej
[site_url] => https://excelfordecisionmaking.pressbooks.sunycreate.cloud
[blog_id] => 15
[theme] => McLuhan
[warning] => 1
[url] => http://excelfordecisionmaking.pressbooks.sunycreate.cloud/format/xhtml?timestamp=1614203246&hashkey=ef32900cb9a9439ebbbc8803e51394b9
)
Wed Feb 24 21:47:27 2021: ---- begin
Wed Feb 24 21:47:31 2021: page 58: warning: no font for Geometric Shapes character U+25E6, fallback to ‘?’
Wed Feb 24 21:47:31 2021: page 68: warning: no font for Geometric Shapes character U+25AA, fallback to ‘?’
Wed Feb 24 21:47:31 2021: page 306: warning: no font for Arrows character U+2193, fallback to ‘?’
Wed Feb 24 21:47:31 2021: page 342: warning: no font for Japanese character U+30C4, fallback to ‘?’
Wed Feb 24 21:47:32 2021: page 480: warning: no font for General Punctuation character U+2033, fallback to ‘?’
Wed Feb 24 21:47:32 2021: page 551: warning: no font for General Punctuation character U+2033, fallback to ‘?’
Wed Feb 24 21:47:32 2021: page 575: warning: no font for Latin character U+0043, fallback to ‘?’
Wed Feb 24 21:47:32 2021: internal error: no available fonts
Wed Feb 24 21:47:32 2021: ---- end
@beckej This is a tricky one! Are you able to view the XHTML preview for the book at https://excelfordecisionmaking.pressbooks.sunycreate.cloud/format/xhtml?debug=prince? That’s be the first place I’d try to look, because that preview will try to use the pagedjs module to give you a PDF preview of the book in your browser. If that doesn’t work, perhaps changing the book’s body font in PDF theme options to one of the Noto fonts or GNU FreeFont serif might help?
Those fonts were designed to have more complete glyph sets for the range of unicode characters. This ‘Shapeshifter’ feature is available in the McLuhan theme as of our 2.10.5 release.
But its nice that Shapeshifter is part of the McLuhan now! I must have missed it when it was released. Switching fonts took care of all but two problem characters, and I was able to search for the Japanese character (the author had used it as part of an emoji).
The last character that I just can’t find is https://www.htmlsymbols.xyz/unicode/U+0043 which is basically a capital C. It’s so close to C that I can’t search for it, because when I cut and paste the unicode capital C, it just converts it into a normal C.
Can you look in the text editor or try the search and replace function? Can you generated an XHTML export and search in it? Do you have a rough idea of the chapter that included the preceding character (24 pages earlier) at least? Just brainstorming here …
Search and Replace worked for the Japanese character. But the problem with the “Latin C” character is that my browser keeps replacing whatever the Latin capital C is with a more standard character, even when I carefully copy and paste.
I think I’m just going to give up for now. Thank you for your help, and for your suggestion to try different fonts. At this point, 1 character on some page is holding up the entire book.
I wish that it would do the export PDF with a ? so I could just go to the page that prince told me and find the character. I tried looking through the xhtml source created from the process, and then searching for every ? in the book, but I didn’t find it. I’m guessing that my browser was able to substitute a standard C for it.
@beckej Don’t know if this is helpful, but I just cloned the book to one of our staging networks and produced a PDF export, which completed without errors(!). See Excel For Decision Making – Simple Book Publishing (the print PDF is exportable there). Not sure what’s different between your and my set up? Maybe try cloning the original book and re-exporting? Maybe it’s a system font difference? Maybe something else with your server/Prince/DocRaptor setup? If you share the diagnostics page info, I can do a quick comparison to see if I see anything else odd.
I’m using McLuhan, for the export. I will share 2 error logs. One when I use “Theme Default” for font, and one when I use one of your suggested fronts.
Platform: OS X
Browser Name: Chrome
Browser Version: 88.0.4324.192
User Agent String: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.192 Safari/537.36
WordPress Configuration
Network URL: http://pressbooks.sunycreate.cloud/
Network Type: Subdomain
Version: 5.6.2
Language: en_US
WP_ENV: Not set
WP_DEBUG: Enabled
Memory Limit: 64M
Pressbooks Configuration
Version: 5.18.1
Book Theme: McLuhan
Book Theme Version: 2.11.0
Root Theme: Aldine
Root Theme Version: 1.9.0
@SteelWagstaff The error message “internal error: no available fonts” showed up despite not having an specific characters that it didn’t understand. In my last export, there were no characters that it didn’t understand, but the export still failed.
Is this possible a bug in the new shapeshifter feature? Do I need to install different fonts on a my server or do an update of some kind?
@beckej I’m seeing this error even in your first message. I think it’s a Prince error – here’s a relevant post I found from their forums: internal error - no available fonts - Prince forum with an answer from Mike Day, the lead developer on that project.
It looks like you have recent, compatible versions of Pressbooks and McLuhan installed, so should be all set to use Shapeshifter. We don’t have this error/problem on any of our production/staging instances, so I suspect that your issue is with your server config/Prince setup. Good luck!
Thanks for all your help. The last link was what helped me. Installing the fonts and all of the other issues went away. I put a suggestion in for the documentation page to add an extra bullet that Linux servers need to have Microsoft fonts installed.
might simply not be in the database yet. For the time being, I only use glyphs from free Unicode fonts to avoid licensing problems. The algorithms behind the character recognition could handle many more characters, so I hope to extend the database in the near future. See the Unicode list if you want to know which Unicode blocks are currently supported.
