On 03.05.2014 12:15, Frank Mittelbach wrote: > Am 02.05.2014 08:56, schrieb Ulrike Fischer: >> Am Thu, 1 May 2014 02:20:36 +0200 schrieb Heiko Oberdiek: >> >>> Thus inputenc is updated to version 2014/04/30 v1.2b, which only >>> prints a warning for encodings utf8, utf8x, ascii, x-ascii for >>> LuaTeX/XeTeX. >> >> I just remembered. Couldn't one add this need extension to utf8: >> inputenc: >> >> http://tex.stackexchange.com/a/119084/2388 > > not for this release due to timing if not for anything else. > > I think improving on the error message is > certainly helpful, however a solution would need to work in all cases > and should not draw on packages that may or may not be available. I am currently writing a package that implements a better error message, e.g.: ! Package inputenc Error: Unicode char ` ' (inputenc) (U+00A0/NO-BREAK SPACE) (inputenc) not set up for use with LaTeX. However, it would be helpful to have an interface/hook. The error message is thrown by macro \UTFviii@defined: \def\UTFviii@defined#1{% \ifx#1\relax \PackageError{inputenc}{Unicode\space char\space \string#1\space not\space set\space up\space for\space use\space with\space LaTeX}\@eha \else\expandafter #1% \fi } It is easy to redefine it. But any \inputencoding{utf8} overwrites the redefinition. And the package would also have to redefine \inputencoding, which I do not like. Suggestions: \def\UTFviii@defined#1{% \ifx#1\relax % Variant (a) \UTFviii@undeferr{#1}% % Variant (b) % \expandafter\UTFviii@undeferr\expandafter{\string#1}% \else\expandafter #1% \fi } \providecommand*{\UTFviii@undeferr}[1]{% % without "\string" in variant (b) \PackageError{inputenc}{Unicode\space char\space \string#1\space not\space set\space up\space for\space use\space with\space LaTeX}\@eha } (Small benefit: It would make `\UTFviii@defiend' slightly faster in the normal case, because less tokens need to be skipped.) The name \UTFviii@undeferr could be improved and moved out of the internals name space, e.g. \UndeclaredUnicodeCharacterError, to make it a more official interface. Your sincerely Heiko Oberdiek PS: > and should not draw on packages that may or may not be available. Of course external packages should not be used in utf8.def, thus this feature would have to be reinvented and therefore too late for TL2014, if someone wants to do it. Also there is some licensing trouble, because the feature needs UnicodeData.txt that goes with the following terms of use: http://www.unicode.org/copyright.html Quite free, but it requires the copyright and permission notice to appear with the data and in the documentation with the description of the changes. If a package has the license LPPL, how is a good correct way to deal with this? * Adding the copyright/permission/modification notice is the easy part. * What is the overall license. LPPL has stricter and lesser restrictions. * Or should the data file of the package that contains the UnicodeData (mapping code number to name) be separated and an exception made in the LPPL notice? * What about the .dtx file that includes all files?