1

The problem is actually quite simple yet I haven't found a working solution.

In the kvoptions package, you can define option keys for custom packages which take strings as a value, e.g.

% `mysty.sty`, assuming it is correctly saved in `$TEXMFHOME` and indexed
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{mysty}

% Preload input encoding and language, I'm German
\RequirePackage[utf8]{inputenc}
\RequirePackage[T1]{fontenc}
\RequirePackage[ngerman]{babel}

% Declare option, the value is then saved in `\mysty@sometitle`
\RequirePackage{kvoptions}
\DeclareStringOption{sometitle}
\ProcessKeyvalOptions*

\title{\mysty@sometitle}
\author{me}
\date{\today}

\endinput
% `myfile.tex`
\documentclass{article}

% Note the German *umlaut* `ü`, a non-ASCII character
\usepackage[sometitle={Programmiervorkurs für Erstis}]{mysty}

\begin{document}
    \maketitle
\end{document}

This would produce error messages, mostly of the form Missing } inserted (right before \maketitle) and To many }'s, whereas the (surprisingly) compiled PDF file looks really weird Weird PDF

Is there any way to fix that, i.e. let kvoptions understand utf8 input?


Actually, a similar question was asked here already.

Can I use kvoptions - DeclareStringOption with Spanish characters?

The problem is that both given solutions don't work anymore (at least for me):

  1. The original package author @Heiko Oberdiek provided the kvoptions-patch package, which can be loaded before mysty (see post for more). This package would solve all problems, but since version 3.14 of kvoptions, this package isn't supported anymore for LaTeX versions from October 2020 or newer (see kvoptions' documentation, chapter 4.1, p.12).
  2. User @egreg provided another solution by using \scantokens, which in my case would translate to
    % Right after `\ProcessKeyvalOptions*`
    \@ifundefined{mysty@sometitle}{}{%
        \scantokens\expandafter{\expandafter\def\expandafter\mysty@sometitle\expandafter{\mysty@sometitle}}%
    }
    
    I don't know much about low-level TeX/LaTex commands and such, but the provided solution doesn't work. Even without \@ifundefined... (won't \mysty@sometitle be defined after giving the option a value??), only the word immediate would disappear from the PDF (see image above).
  3. Inspired by @egreg, I tried something like this:
    % After `\ProcessKeyvalOptions*`
    \renewcommand{\mysty@sometitle}{\scantokens{\mysty@sometitle\empty}}
    
    But instead of the title, the PDF contains only @sometitle as the title. I guess the @ symbol ends the token list (which I don't want). Storing in a temporary variable doesn't help too. I don't know how to fix this.

1 Answer 1

1

enter image description here

This should work "soon" but will take a few updates.

kvoptions hasn't yet been updated to use the "raw" options passed from the document, the classical option argument gets passed through an edef and utf-8 characters get mangled, as you saw.

So for now add

\expandafter\let\csname [email protected]\expandafter\endcsname
\csname @raw@[email protected]\endcsname

To mysty.sty before processing the arguments.

\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{mysty}

%  replace the option string by the raw option string (requires a newish latex)
\expandafter\let\csname [email protected]\expandafter\endcsname
\csname @raw@[email protected]\endcsname

% Preload input encoding and language, I'm German
\RequirePackage[utf8]{inputenc} % not required unless you have an old latex.

\RequirePackage[T1]{fontenc}
\RequirePackage[ngerman]{babel}

% Declare option, the value is then saved in `\mysty@sometitle`
\RequirePackage{kvoptions}
\DeclareStringOption{sometitle}
\ProcessKeyvalOptions*

\title{\mysty@sometitle}
\author{me}
\date{\today}

\endinput

That should be enough but unfortunately the raw option string still gets processed at one point generating an error. That is fixed in the sources for the next LaTeX release (due Novermber 2021) but you can already use pdflatex-dev pre-release which includes this fix.

So pdflatex-dev myfile with mysty.sty as above produces the output shown with no error.

7
  • That's good news! So with the next release we'll be able to grab \usepackage option arguments before they get expanded? Is the same valid for l3keys2e as well?
    – gusbrs
    Commented Oct 10, 2021 at 13:27
  • 1
    @gusbrs the last few releases have saved the arguments as @raw@.... but don't actually use them, compatibility concerns make changing the default option handler hard, but gradually extension packages can use these koma script does already I think as does skillmon's set of packages, I will update kvoptions at some point. Commented Oct 10, 2021 at 13:31
  • Thanks! I had no idea we already had access to it. And, indeed, changing the default there is bound to be a delicate operation. I'm looking forward to see it coming one day though. :-)
    – gusbrs
    Commented Oct 10, 2021 at 14:00
  • I've checked l3keys2e and, as far as I can tell, it does not use @raw@opt@ at all. I'll check what Skillmon does with it.
    – gusbrs
    Commented Oct 10, 2021 at 14:06
  • Thanks, it works in my more complex project! Note that the magic hack must appear in front of all other packages (including babel and fontenc), not just kvoptions.
    – Gargantuar
    Commented Oct 10, 2021 at 17:32

You must log in to answer this question.

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