[pmwiki-users] PmWiki2PDF working?

John Rankin john.rankin at affinity.co.nz
Wed Sep 20 20:03:14 CDT 2006

On Thursday, 21 September 2006 11:22 AM, Joshua J. Kugler <joshua at eeinternet.com> wrote:
>On Wednesday 20 September 2006 15:05, John Rankin wrote:
>>> Can you provide more information aboout the problem? (I know *nothing*
>> about how beautifier works internally.)
>I'll try. :)  When the WikiPublisher PDF comes back, nothing generated by 
>Beautifier is displayed.  I'll have to try the other syntax highlighter in 
>the Recipe list.  Haven't had a chance yet.  You can see the glitch if you go 
>here:  http://wikiserver.eeinternet.com/Main/WikiPublisherBeautiferGlitches 
>and publish the PDF.

OK, beautifier generates:

<pre class='sourcecode'>
<font color="green">#!/usr/bin/perl -W</font>

<font color="blue">use</font> strict;
<font color="blue">use</font> warnings;

<font color="blue">use</font> Template;
<font color="blue">use</font> File::Copy;
<font color="blue">use</font> LWP::UserAgent;
<font color="blue">use</font> Text::CSV_XS;
<font color="blue">use</font> Date::Manip;

<font color="blue">my</font> $VERSION = '0.71';

and so on...

Leave aside use of the <font> tag, which is deprecated...

The PublishPDF plug-in generates:

#!/usr/bin/perl -W

use strict;
use warnings;

use Template;
use File::Copy;
use LWP::UserAgent;
use Text::CSV_XS;
use Date::Manip;

my $VERSION = '0.71';

This is because beautifier is hard-coding the <pre> and <font> tags,
or the tags are variables, but the installation has not provided
wikibook xml equivalents.

>> Wikipublisher ignores any html introduced by third party
>I guess I'm not 100% clear on that comment.  Do you mean no syntax highlighter 
>will work with Wiki Publisher?  Or am I not following you?  Is there 
>a "PmWiki way" of generating output vs. the way Beautifier is
>doing it?
It's the way beautifier is doing it, I believe.

The PublishPDF library causes PmWiki to output wiki markup to the
wikibook xml dtd instead of as xhtml. So, if the output contains
html tags, these will, in general, cause the processor to break,
as it assumes the output is in wikibook. To get around this, what
we do is qualify all our wikibook tags with a namespace, then in
post-processing remove any tags that don't contain the namespace
qualifier (ie any html tags), then remove the namespace qualifier, 
so we are left with wikibook xml.

PmWiki is markup agnostic by design. That means, everywhere
PmWiki uses an html tag, it's either in a variable, or in a
user-configurable function. This allows us to detect

  if ($format=='pdf')

and replace all PmWiki's standard markup rules (which produce
xhtml) with alternates, in our ccase to produce wikibook xml.

For example, in wikibook, <pre> --> <verbatim>; pmwiki never
produces <font>; and styles (usually) turn into <style> tags.

There are several options:

- teach beautifier to output wiki markup and let pmwiki
  handle everything -- then it should just work

- teach beautifier to use variables for every tag and
  provide wikibook equivalents externally if format is pdf

- add markup rules that execute after beautifier and before
  post-processing that map beautifier's html tags into wikibook

- insert the format==pdf check into beautifier so it becomes

My feeling is that the first or second options are likely to 
be the most robust.

For example, you might have in your local/config.php:

if ($format=='pdf') {
    $BeautifierTag['pre']  = 'tbook:verbatim';
    $BeautifierTag['font'] = 'tbook:style';

and so on. Then the beautifier code might contain

SDV($BeautifierTag, array('pre' => 'pre', 'font => 'font'));

Hope this helps.
John Rankin

More information about the pmwiki-users mailing list