[PyX-user] Beamer and PyX

[Michael J Gruber]

Hi there,

I've been experimenting with PyX graphics included in beamer
presentations (the ubiquitious "beamer" LaTeX class), and noticed an
issue with fonts.

Typically, you want the same fonts in your included graphics that you
have in the surrounding document. The simplest way of achieving that is
using the same document class and font related preamble commands for PyX
that you use in your main document. Given how much font wrangling
beamer.cls does, that also seems to be the only realistic option (rather
than trying to emulate the font setup).

The attached beamer.tex includes a pdf generated from beamerpyx.py and
compares the result - the two lines should be identical, especially the
last part where the fon wrangling of beamer.cls becomes important.

The PyX file compiles only when I ask PyX to ignore (or merely warn
about) certain errors. Specifically:

begindoc
========

I can quell the message about the nav-file using texmessage.no_nav but
that leaves the stuff from hyperref, EveryShipOut and geometry.

Is there a reason not to ignore "nav"-warnings by default?
Can we maybe ignore the others by default, too, or at least provide a
default parser?

run
===

I have no clue why texmessage.load_def doesn't catch the fd-file messages.

specials
========

Is there a way to silence those warnings about ignored specials (other
than changing the overall logger level)?

Cheers
Michael

P.S.: The proper approach would be to create the slides from within PyX,
of course. :)

[André Wobst]

Hi Michael,

Post by Michael J Gruber
specials
========
Is there a way to silence those warnings about ignored specials (other
than changing the overall logger level)?

You need to write a texmessage parser for that. This might sound complicated, but it actually is very simple. A texmessage parser is just a function being called with one argument, a string, and it returns a string. The string it receives is the TeX output on the console. It the texmessage parser "understands" this message (or part of it), it has to remove this string from the TeX output, it is responsible for. The rest of the string is to be returned. That's it.

Best,


André

[Michael J Gruber]

Post by André Wobst
Hi Michael,

Post by Michael J Gruber
specials
========
Is there a way to silence those warnings about ignored specials (other
than changing the overall logger level)?

You need to write a texmessage parser for that. This might sound complicated, but it actually is very simple. A texmessage parser is just a function being called with one argument, a string, and it returns a string. The string it receives is the TeX output on the console. It the texmessage parser "understands" this message (or part of it), it has to remove this string from the TeX output, it is responsible for. The rest of the string is to be returned. That's it.

I don't think that the texmessage parser will catch the warnings about
specials from dvi/dvifile.py...

My post is really about these questions:

- Why doesn't texmessage.load_def (which is used by default) catch the
.fd file loads?

- Why isn't texmessage.no_nav used by default?

- Why aren't there defaults (or at least supplied parsers) that catch
the latex messages from a standard beamer.cls run?

- How do I silence dvifile.py's warnings about ignored specials without
ignoring all other warnings, or to put it differently: Why are they
warning and not info?

texmessage.ignore and logging.ERROR are the easy way out that most users
will take unless there is help from the shipped defaults
(texmessage.geometry or such).

Michael

[André Wobst]

Hi Michael,

Post by Michael J Gruber

Post by André Wobst
Hi Michael,

Post by Michael J Gruber
specials
========
Is there a way to silence those warnings about ignored specials (other
than changing the overall logger level)?

You need to write a texmessage parser for that. This might sound complicated, but it actually is very simple. A texmessage parser is just a function being called with one argument, a string, and it returns a string. The string it receives is the TeX output on the console. It the texmessage parser "understands" this message (or part of it), it has to remove this string from the TeX output, it is responsible for. The rest of the string is to be returned. That's it.

I don't think that the texmessage parser will catch the warnings about
specials from dvi/dvifile.py...

I'm sorry, I totally missed that. You're right.

Post by Michael J Gruber
- Why doesn't texmessage.load_def (which is used by default) catch the
.fd file loads?

Weird. Do you have an example? I failed to reproduce it here in some simple tests (your example included). Note that there was an surprisingly stupid bug in the texmessage.load_def, which has been fixed in PyX 0.14.1. Maybe you're still on an older version of PyX?

Post by Michael J Gruber
- Why isn't texmessage.no_nav used by default?

Because I hardly ever needed it. (I guess I never needed it at all.) But you're right: It probably doesn't make any harm. Maybe with the exception for piling up the package documentation with default settings hardly ever needed in regular use cases for PyX. But I'm willing to follow some wished by the community, if its not too esoteric. I'm doubtful that things like .nav files, geometry, everyshipout or hyperref are really a regular use case, but I'm fine to get outvoted.

Post by Michael J Gruber
- Why aren't there defaults (or at least supplied parsers) that catch
the latex messages from a standard beamer.cls run?

A simple question deserving a simple answer: Because nobody wrote it so far.

Post by Michael J Gruber
- How do I silence dvifile.py's warnings about ignored specials without
ignoring all other warnings, or to put it differently: Why are they
warning and not info?

Because non-pyx specials are ignored, and that should not be silenced. A warning is just the right thing IMHO. I don't know whether there is an elegant way to silence specific warnings programmatically. Probably, but I don't know. But to continue why ignoring specials should never be silenced by default, consider the following example using latex + dvips:

\documentclass{article}
\usepackage{helvet}
\begin{document}
\sffamily\char0
\end{document}

It results in a warning as Gamma is not available using the helvet package. (This is a rather funny special Jörg found years ago when implementing virtual fonts; the special comes from within a virtual font.) PyX behaves quite similarly for any special it does not know about (which is however quite different from the set of specials dvips can handle). I think, this is what "fail gracefully" for unknown specials is meant in the TeXBook by Knuth. Now do the same in pdflatex. It will silently ignore the special, which is horribly bad IMHO.

Post by Michael J Gruber
texmessage.ignore and logging.ERROR are the easy way out that most users
will take unless there is help from the shipped defaults
(texmessage.geometry or such).

I just had a look at the output of the geometry package. While I do understand that they inform about auto-guessing the driver (which can easily prevented by a driver=... argument), the funny thing is, that it remains to output the same information about the driver *on the top level* of the output when specified explicitly. Even on the default verbose=false mode. No message is a good message, whoa? (It would be silenced by PyX if it would not be echoed on the top level.) Now, PyX could silence it by a specific texmessage.geometry parser, right. Nobody wrote one so far, as geometry seems a rather uncommon setting for typesetting within PyX. Anyway, one needs to analyze the log output of geometry in all its variations to make a proper parser. Same goes for hyperref and the everyshipout warnings. I just have to say (well, or claim), that all that is really uncommon to be used from within PyX.

Hint: Instead of texmessage.ignore there also is texmessage.warn to get "strange" TeX running from within PyX but not silenced.

PyX tries to not be verbose, but not hide any information. This is really hard given the unstructured nature of LaTeX packages output. Suggestions for message parsers are welcome.

Best,


André