On 2019-04-10, Kornel Benko wrote: > Am Dienstag, 9. April 2019, 23:01:06 CEST schrieb Günter Milde: >> commit b32cf2a4c09291d4cd7a992ecbd8c9454cff5a37 >> Author: Günter Milde <[email protected]> >> Date: Tue Apr 9 22:52:31 2019 +0200
>> unicodesymbols: support Thai characters. > Wow, that are many new codes ... Code points? Fortunately, the Thai character block is manageably sized, even less than the recently added Hebrew. I don't want to add all arab or CJK characters, though. We should consider, whether to support Thai characters also in other languages, similar to Cyrillic and Greek. (For Hebrew, we need the correct language anyway, for RTL support.) > Tests with en-th_language-default.*_systemF fail with TL19 ... TL16. > For instance for en-th_language-default_pdf5_systemF: > LaTeX.cpp (719): Log line: Package polyglossia Info: Option: english > variant=american. > LaTeX.cpp (719): Log line: ! Undefined control sequence. > LaTeX.cpp (920): line: 30 > Desc: Undefined control sequence. > Text: ...ckslash inputencodingname \inputencodingname > The control sequence at the end of the top line > of your error message was never \def'ed. If you have > misspelled it (e.g., `\hobx'), type `I' and the correct > spelling (e.g., `I\hbox'). Otherwise just continue, > and I'll forget about whatever was undefined. > ! Package polyglossia Error: The current roman font does not contain the Thai > s The test samples were not designed for non-TeX fonts. I changed one to care for this and ignored the others. > The error is always at '\inputencodingname', no matter what language > env surrounding. Yes, \inputencodingname is from "inputenc" and not defined with "use non-TeX fonts". Removed from the sample where it is always utf8. The problem actually tested is solved in a local version of thai.ldf. I'll prepare a patch for upstream. Günter
