Dear Gordon, thank you for the report. Trying to reproduce your problem...
On 2017-01-14, gordon cooper wrote: ... > There was the problem, a Hyperlink with a irreconcilable character, a > beginning itemize dot, like this : > • http://www.debian.org/doc/FAQ/ch-pkgtools.en.html This was in an URL inset or Hyperlink inset, right? > Had a recent mysterious error when trying an Lyx to pdf conversion. > The same Lyx file converted to html immediately, no errors. How about XeTeX or LuaTeX with "non-TeX" (Unicode) fonts? Works here. > I had a coding error, ignored by one converter. A look at the source > code was not a success. This leads me to the assumption that you have set the inputencoding (Document>Settings>Language>Encoding) to "Unicode (utf8)". IMO, this is a good choice but not much tested on LyX unfortunately as LyX uses mixed 8-bit encodings by default wit 8-bit "TeX fonts". With the default encoding, the Source Pane shows the problematic character in red. > The program reported a Latex error but gave no error report. Here, with utf8 encoding, the error report said "tex capacity exceeded" while with an 8-bit encoding the error report was the more meaningfull "could not find LaTeX command for character ...". Also, inserting non-working Unicode characters into an URL inset is blocked while copying from somewhere works (but fails later). Interestingly, some high-bit characters (like äöü) work fine, others are mangled (ß becomes \T1\ss in the output) others are blocked (e.g. °) (I suppose, because it is "forced" in lib/unicodesymbols). The problem here is to prevent the wast of time you experienced without blocking valid use cases (e.g. export to HTML or with "non-TeX fonts"). Günter
