Hi Michael, Am 31.01.2016 um 17:38 schrieb Michael J Gruber <[email protected]>:
> André Wobst venit, vidit, dixit 30.01.2016 22:32: >> Hi Michael, >> >> Am 30.01.2016 um 17:52 schrieb Michael J Gruber >> <[email protected]>: >>> 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. > My post is really about these questions: > > - 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? > - 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. > - 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. > - 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. > 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é -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) [email protected], http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________ PyX-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyx-user
