Long menu hierarchies have no hard wrap

[wget]

I was writing a Windows-specific documentation about parameters and values to configure in gpedit.msc. I was using the \menu command to represent the hierarchy. As you know Microsoft is using pretty long hierarchy names, like this one (in French) \menu{Configuration de l’ordinateur > Modèles d’administration > Composants Windows > Chiffrement de lecteur BitLocker > Lecteurs du système d’exploitation > Autoriser Bitlocker sans un module de plateforme sécurisée compatible (requiert un mot de passe ou une clé de démarrage sur un disque mémoire flash USB)}.

While the path is cut when the item level changes, the problem arises for the last item which is much larger than the above level. In such a case, this LaTeX package isn't breaking very long keys, so that the text continues in the margin of the page, without having a line break when the text is too long to fit on the same line.

Do you have a solution to circumvent this issue or could please provide a fix?

Thanks in advance.

[tweh]

I understand your problem but unfortunately the styles use TikZ nodes to make the arrow boxes around the items in a list an such nodes are boxes which can’t split across lines. Also I’m not sure if menukeys is the best approach for this since the long boxes are very dominant

and for that IMHO no good idea from a designers point of view. I suggest using a more unobtrusive way like this:

which is implemented in this code:

\documentclass{article}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}

\usepackage{menukeys}

% new command for the split symbol
\newcommand{\paramsep}{%
   \hspace{0.4em plus 0.1em }%
   \raisebox{0.08ex}{%
      \tikz{%
         \draw (-1ex,0.5ex) -- (0,0.5ex);
         \fill (0,0) -- (0.5ex,0.5ex) -- (0,1ex) -- cycle;
      }%
   }%
   \hspace{0.4em plus 0.1em}%
}

% using menukeys' internals
\makeatletter

\tw@declare@style@simple*{params}{%
   {\sffamily\small\CurrentMenuElement}%
}[\paramsep]{blacknwhite}

\makeatother

\newmenumacro{\params}[>]{params}


\begin{document}
I was writing a Windows-specific documentation about parameters and values to
configure in gpedit.msc. I was using the \params{command} to represent the hierarchy.
As you know Microsoft is using pretty long hierarchy names, like this one (in French
n) \params{Configuration de l’ordinateur > Modèles d’administration > Composants
Windows > Chiffrement de lecteur BitLocker > Lecteurs du système d’exploitation >
Autoriser Bitlocker sans un module de plateforme sécurisée compatible (requiert un
mot de passe ou une clé de démarrage sur un disque mémoire flash USB)}.
\end{document}

I guess this is not the answer you expected but hope it helps, though.

[wget]

Yes, this was not the answer I was expecting, but thanks for your implementation idea.

I wonder when can we use \menu{Foo > Bar} since this is not "beautiful" from a designer point of view and breaks the layout. IMHO, it looks like this feature of your package is not working like expected. Even in this simple use case from my English documentation, look at the path at the right of the screen, the latter breaks the layout:

I assume we have no solution neither for this simple user case, other than using the implementation you provided above with the simple arrows?

Thanks in advance for your answer.

[tweh]

I completly agree with you, that the current implementation is not the optimal way, but actually I don’t know how to do it better ;-) but making breaks in such nodes possible is on my to-do-list. I don’t know when I find the time to work on it, though …

[Skillmon]

There are ways how this could be solved, but they require to not use TikZ nodes for the output.

Instead one could use ulem or soul, or, if LuaTeX is used, lua-ul to get line-breakable output. ulem wouldn't allow hyphenation, soul does break for complicated input, lua-ul is only available in one engine. If we would support line-breakable styles I'd not make them defaults, and in fact put them in separate files users could load (this doesn't have to be transparent to the user, but could be hidden inside some key=value interface used to select, define, or customise the styles).

Another possibility would be to use some marker with which the user could specify allowed breaking points, similar to manual hyphenation with \-. The mechanism would require splitting at that marker and outputting the parts separately but seamlessly (we could even provide a setting in which every space serves as such a break-point-marker).

[tweh]

Maybe it would be enough to only provide manual line breaks in an element an then making two nodes in the background with a prober right/left open style.