A few changes and improvements

[xaf]

Those commits allow to fix a number of different problems that I found using pdfpc-latex-notes. Moreover, some new features are provided, such as managing the font size of the notes as a package option (not to have to edit the generated pdfpc file each time) and managing the use for \ and \par in notes without needing to use a sed in the generated pdfpc file.

[ivanick87]

.ca

[rjoberon]

Works nicely with overlay specifications now but has problems with character encoding: utf-8 characters in notes are converted to latin1 which is a problem for pdfpc. This could be due to the processing of the notes (to support \\ and \par) in combination with packages like babel.

In my example \pnote{äöü} together with \usepackage[utf8]{inputenc} and \usepackage[ngerman]{babel} produces latin1-encoded characters in the .pdfpc file which pdfpc does not show.

[cebe]

In my example \pnote{äöü} together with \usepackage[utf8]{inputenc} and \usepackage[ngerman]{babel} produces latin1-encoded characters in the .pdfpc file which pdfpc does not show.

thats bad, any idea how to fix this?

[xaf]

Will try and check if I can fix that as soon as possible. @rjoberon do you have a minimal working example to reproduce the issue?

I tried a bit, and it seems that when I removed the \unexpanded as we need to resolve \ and \par, it also expands the UTF-8 characters. Any idea on how to expand only some commands ?

[rjoberon]

@XaF With this input (test.tex):

\documentclass{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
\usepackage{../includes/pdfpcnotes}

\begin{document}
\begin{frame}
  schön
  \pnote{- schön}
\end{frame}
\end{document}

I get the following output (test.pdfpc):

[file]
test.pdf
[notes]
### 1
- sch\366n

Note that I have inserted the \366 here manually as my browser converted it to the letter "ö" - hexdump -C test.pdfpc shows that this is latin1:

00000000  5b 66 69 6c 65 5d 0a 74  65 73 74 2e 70 64 66 0a  |[file].test.pdf.|
00000010  5b 6e 6f 74 65 73 5d 0a  23 23 23 20 31 0a 2d 20  |[notes].### 1.- |
00000020  73 63 68 f6 6e 0a                                 |sch.n.|
00000026

With this file pdfpc does not show me any notes.

After recode latin1..utf8 test.pdfpc this is indeed utf-8:

00000000  5b 66 69 6c 65 5d 0a 74  65 73 74 2e 70 64 66 0a  |[file].test.pdf.|
00000010  5b 6e 6f 74 65 73 5d 0a  23 23 23 20 31 0a 2d 20  |[notes].### 1.- |
00000020  73 63 68 c3 b6 6e 0a                              |sch..n.|
00000027

And pdfpc correctly shows "schön" as a note.

Note that \usepackage[T1]{fontenc} has an influence on that. If I remove that line from test.tex, I get the following test.pdfpc:

[file]
test.pdf
[notes]
### 1
- sch\protect \unhbox \voidb@x \bgroup \U@D 1ex{\setbox \z@ \hbox {\char 127}\dimen@ -.45ex\advance \dimen@ \ht \z@ \fontdimen 5\font \dimen@ }\accent 127\fontdimen 5\font \U@D o\egroup n

... which does not work with pdfpc either. ;-)

This happens with the following version of pdflatex:

> pdflatex -version
pdfTeX 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian)
kpathsea version 6.2.2
Copyright 2016 Han The Thanh (pdfTeX) et al.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.28; using libpng 1.6.28
Compiled with zlib 1.2.8; using zlib 1.2.8
Compiled with poppler version 0.48.0

My current workaround is to (automatically) call recode after each run of pdflatex ... so it's not a big problem.

[abooij]

@rjoberon, I can't get this to work with the current version either. So is this really a fair "bug" of @XaF's work?

[rjoberon]

You are right. This also happens with the old/current version. I will create an issue for this problem.

[muelli]

Can we somehow fast-track the font size in 772a43b7a71f84afd1e1ff1b3be48de84e1dc31c?

Given that the generated pdfpc flie often seems to require some post-processing, I suggest optionally writing to a differently named file, e.g. \jobname.pdfpc.in, s.t. it can be incorporated into a Makefile-based workflow.