2

For several years now, I have been working intermitently with LaTeX on a book-length document using the memoir class. Due to their superior font-handling capabilities, I saved my work in mostly-identical XeLaTeX and LuaLaTeX versions, tending to favor the latter, due to its fuller implementation of the microtype package, but keeping up with the former, just in case. It appears I have now hit such a just-in-case moment, but I don't want to give up on the Lua if I can help it.

Ending a long hiatus with the project, during which I upgraded from Windows 7 to Windows 10, and then had to reload Win 10 when it became unstable. So then, needing to reinstall all software, including TeX, I installed TeXLive earlier this month (October 2016) in place of the MikTeX I had been using; I then made renamed copies of my two .tex files (saving the originals with their output for benchmark purposes), and compiled. In all aspects, the XeLaTeX version was identical to its earlier incarnation, when examined in the TeXworks PDF veiwer, while the LuaLaTeX version had two pages, both in the frontmatter, with instances of expanded vertical spacing, annoying but easily fixable; I may deal with those in a separate question.

But when I opened the LuaLaTeX version in Adobe Acrobat Reader DC (version 2015.020.20039), I discovered, as I began to scroll down, that many pages would not display. Whenever I would reach the top edge of one of these, an error message would pop up reading,

"There was an error processing a page. There was a problem reading this document (135)."

(A web search turned up no information concerning Acrobat Reader error 135.) Scrolling down into it, then, the offending page would be completely blank, yet the next non-error page would pick up right where it would have if the preceding page(s) had been there. The old PDF from January 2015, though, still displayed every page perfectly, as did both the orginal and freshly compiled XeLaTeX PDFs.

Thus, the problem lies in changes made specifically to the LuaLaTeX code sometime (per the .log files) BETWEEN LuaTeX, Version beta-0.76.0-2013062820 (rev 4627) (format=lualatex 2013.10.22) AND LuaTeX, Version 0.95.0 (TeX Live 2016/W32TeX) (format=lualatex 2016.10.18); OR, if in changes to one of the packages used in the document, changes that adversely affect LuaLaTeX but not XeLaTeX. LuaLaTeX does finish its compiling and doesn't seem to be aware that there is a problem. And, in the TeXworks viewer, no problem appears, aside from the vertical spacing issues on two pages, mentioned earlier.

With detailed examination, it became apparent that problem pages were any that included either of two of the fonts I am using: the freeware Chrysanthi Unicode, Version 3.1 (of which I use only five characters in the Unicode Dingbats block) and Latin Modern Mono Light 10 Bold, which I have set as my document's monospaced font with the fontspac command \setmonofont and mostly invoke with the verbatim-like {alltt} environment from the package of that name, but occasionally also with the \ttfamily command. (Oddly, Latin Modern Mono Prop 10 Regular, which I also use, has no such problem.)

Here is the MWE I attempted, to check first whether there is a problem using Unicode Dingbat block chararacters generally, and then to display both of the offending fonts, the Chrysanthi with both normal text and dingbat examples, and the LM mono font, using both methods of invoking it, with everything on separate pages, to see which would display and which would not.

\documentclass{memoir}  
\usepackage{luatextra}  
\usepackage{alltt}  
\setmainfont{DejaVu Sans}  
\setmonofont[Path=./Fonts/]{lmmonolt10-bold.otf}  
\newfontface\flourishfont[Path=./Fonts/]{chrysuni.ttf}  
\begin{document}  
Normal ASCII range characters in DejaVu Sans.  
\newpage  
Unicode characters 2756, and 276A through 276D, in DejaVu Sans:  
❖ ❪ ❫ ❬ ❭  
\newpage  
{\flourishfont  
Normal ASCII range characters in Chrysanthi Unicode.}  
\newpage  
{\flourishfont  
Unicode characters 2756, and 276A through 276D, in Chrysanthi Unicode:  
❖ ❪ ❫ ❬ ❭}  
\newpage  
{\ttfamily  
Latin Modern Mono Light 10 Bold using \textbackslash ttfamily.}  
\newpage  
{\begin{alltt}  
Latin Modern Mono \newline Light 10 Bold \newline using \{alltt\} environment.  
\end{alltt}}  
\end{document}

Unfortunately, as an MWE, it doesn't. Work, that is. Or maybe it does in its own way. Acrobat Reader won't open the PDF at all, but pops up with: "There was an error opening this document. This file is damaged and could not be repaired." The TeXworks viewer displays everything properly, as expected. The native PDF viewer in the Firefox browser also displays both document and MWE without without a hitch.

Checking for other options in Windows 10, the file's "Open with.." in the context menu suggests MicroSoft Edge as an option. Interesting result when I tried it. All pages in both document and MWE do open, and in both cases there is no problem with the LM Mono Light 10 Bold at all, while the Chrysanthi Unicode characters u2756, u276A and u276B, used only on the dedication page of the document, are not represented at all, while the other two, u276C and u276D, used only in the even-numbered (lefthand) page header, are represented in the document display as a grave-accent lowercase "a" (à) and an empty rectangle-outline. (Here again, both of the XeLaTeX and the older LuaLaTeX PDFs display correctly.) In the MWE, in Edge, page 3 is rendered as the nonsense string:

mj A lec aarc gl Alrg Slgamc,

while page 4 is displayed as:

Slgamc aarc 534 l 54 rmse 54 gl Alrg Slgamc

except that some of the spaces appear longer than they paste here, more like tabs, and even many of the "words" here are broken up by similar long "spaces" in Edge.

Sorry for the very long post, but I thought the more detail the better in tracking this down. If you see an error in my TeX syntax, etc., in the MWE that is causing it not to open at all in Acrobat Reader, please let me know and I will fix it.

closed as off-topic by cfr, Mensch, Troy, Przemysław Scherwentke, Stefan Pinnow Dec 27 '17 at 6:15

  • This question does not fall within the scope of TeX, LaTeX or related typesetting systems as defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Try using fontspec rather than luatexextra to see if you still get errors. What happens if you don't use alltt? Can you get errors wit a document with just LM so people can reproduce? What does the console/log say? Any warnings? – cfr Oct 27 '16 at 2:45
  • 2
    Also, what if you use TeX Live's copy of the LM font? Do you have the current version? – cfr Oct 27 '16 at 2:48
  • 1
    Sorry but your post is much too long. You have a (new) problem with a font and luatex and the reader. This can happen -- luatex, the font loader and adobe reader have changed and can have introduced a bug or can now trip over an existing bug in the font. The standard procedure for such problems is to make a minimal example, to ask people if they can reproduce it and to get some advice where to report the problem. Make one example for each font. And add a download source for external fonts. – Ulrike Fischer Oct 27 '16 at 7:43
  • 2
    Large parts of our post can be shortened to "it works in xelatex, and it worked in older lualatex, but now it is broken". The first step it to give other the means to test the issue. If they can long explanations are not really needed. I could reproduce your problem but it is gone with the prerelease of the next luaotfload version github.com/lualatex/luaotfload/releases – Ulrike Fischer Oct 27 '16 at 8:08
  • 4
    I'm voting to close this question as off-topic because could be reproduced only by guesswork with older versions of software. (See Ulrike's comment.) – cfr Dec 27 '17 at 1:37