I'd like to generate beamer slides matching the main language of the target audience. The easiest way seems to facilitate the comment package and pack the individual slides into includecomment/excludecomment environments... (as suggested in a previous question).

However this breaks in various ways when non-ascii characters are involved depending on the location and character (and even document class) used, for example:

  • ./comment.cut:2: Package inputenc Error: Keyboard character used is undefined
  • ./comment.cut:1: Argument of \UTFviii@three@octets has an extra }.
  • ./comment.cut:3: Package inputenc Error: Unicode char \Uffffffffifnum (U+2E7) not set up for use with LaTeX.

How can I make the following MWE work and what's the underlying issue?







  • 1
    Why not just use a simple \if \else \fi? This is how I handle bilingual cases where some instances should use one language and some another. (I haven't tried with Beamer, though.) You shouldn't need fragile for the frame you show and, if that's forced by this approach, you really don't want to use it. At least, I wouldn't.
    – cfr
    Commented Jul 29, 2018 at 19:38
  • 1
    One downside is that it gets a bit more convoluted with more than two languages (which would be no problem for me). I need fragile all the time due to listings anyway and I think it slipped into the MWE because of that. However, I'd love to hear a better argument than 3+ language case.
    – stefanct
    Commented Jul 31, 2018 at 16:17
  • Since you have some responses below that seem to answer your question, please consider marking one of them as ‘Accepted’ by clicking on the tickmark below their vote count (see How do you accept an answer?). This shows which answer helped you most, and it assigns reputation points to the author of the answer (and to you!). It's part of this site's idea to identify good questions and answers through upvotes and acceptance of answers. Commented Nov 23, 2018 at 15:47

1 Answer 1


As I have found out while writing up the question, the issue is the comment package or more specifically that it writes out expanded characters to its intermediate file. See the original answer for more details.

The solution is to patch comment's WriteCommentLine and ThisComment commands by adding the following after loading comment:


Thanks egreg!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .