Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hyperref creates big boxes around lilyglyphs commands in TOC entries #87

Open
uliska opened this issue Feb 5, 2014 · 1 comment
Open
Assignees
Labels

Comments

@uliska
Copy link
Owner

uliska commented Feb 5, 2014

Reported by NickS on oll-user (ATM not present in the archives yet):

I've just started using lilyglyphs and I've noticed it interacts with the "hyperref" package to produce very large bounding boxes around section titles in the table of contents. This can be seen in the PDF generated by running xelatex on the following code:

\documentclass{article}
% for lilyglyphs
\usepackage{fontspec}
\usepackage{lilyglyphs}
% for use without lilyglyphs
% \newcommand{\doublesharp}{$\sharp\sharp$}
% \newcommand{\flatflat}{$\flat\flat$}
% for hyperlinks
\usepackage{hyperref}
\author{Author}
\title{Title}
\begin{document}
\maketitle
\tableofcontents
\section{\texorpdfstring{The B\doublesharp}{\ref{The Bdoublesharp} The B++}}
This is the B\doublesharp.
\section{\texorpdfstring{The C\flatflat}{\ref{The Cdoubleflat} The C--}}
This is the C\flatflat.
\end{document}

By comparison, if you comment out the two "usepackage" lines (for fontspec and lilyglyphs) and uncomment the two "newcommand" lines (for doublesharp and flatflat), the resulting PDF has normal bounding boxes (but of course not proper accidentals).

In any case the PDF bookmark names don't like any accidentals (hence I use the "++" and "--" in the 2nd parameter of \texorpdfstring ), but it would be great if the lilyglyph symbols could be displayed in the table of contents without the very tall bounding boxes.

@ghost ghost assigned uliska Feb 5, 2014
@uliska
Copy link
Owner Author

uliska commented Feb 5, 2014

Note that this issue is only present with xelatex. lualatex produces the expected result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant