Recent Changes · Search:

Support the Project



edit SideBar


Installations with the previous release, 0.9.3f, are affected by the following problem:

Images are not working correctly for new installations using version 0.9.3f. There is an inconsistency between the old code and new configuration file format. This affects new installations; it does not affect installations that are upgrading. The bug is in the server code, and can be corrected by upgrading to the latest version, 0.9.3g. Alternatively, you can just upgrade the mkpdf/ file to that from the latest release, which will have the same effect as applying the change described in Michael Caerwyn’s bug report:.

Yesterday I downloaded and installed the available server, version 0.9.3f and started running it only to find that it was erroring out with image problems. Hunting through the code I found the following bit in
        $l =~ s/^\s*\"http(:\/\/)www\.wikipublisher\.org\/dtd\/([^\"]+)\">/ "\"file$1" . 
        $WikiPublisher::Config::src . "\/xml\/" . $2 . "\">" /eg;
As you can tell $WikiPublisher::Config::src isn’t really around anymore. I converted it to config(‘src’) and it was happy again.

Also, add use WikiPublisher::Configuration; to the start of the file.

Running the server on Mac OS X produces no output. Pressing (debug) shows this debug error in the LATEX part of the output:

   ! Font T1/cmr/m/n/10.95=ecrm1095 at 10.95pt not loadable:
   Metric (TFM) file not found.

This is followed by an ! Emergency stop after a “fontencoding” command. Security is ensured by storing data into

Simple temporary fix
When you see that in the debug output, run the command “mktextfm ecrm1095” from the terminal. The way TEX gets installed means that the user CGI scripts can’t write to where TEX stores font metrics and so the command mktextfm ecrm1095 fails.
The Mac OS X LATEX bundle omits some of the older T1 fonts. Download the font bundle from, expand the archive, and then from the terminal run:
     sudo mkdir -p /usr/local/teTeX/share/texmf.local/fonts/tfm/jknappen/ec
     sudo cp * /usr/local/teTeX/share/texmf.local/fonts/tfm/jknappen/ec/.
     sudo mkdir -p /usr/local/teTeX/share/texmf.local/fonts/source/jknappen/ec
     sudo cp ready-mf/* /usr/local/teTeX/share/texmf.local/fonts/source/jknappen/ec/.
     sudo texhash
That should fix it. — Mike Griffin

Another Mac OS X experience similar to the above. I had to do the following, in addition to the already mentioned:

  • Change the Add Handler? line for cgi scripts in /etc/httpd/httpd.conf to allow .pl extension
  • Make sure that all of the directory arguments to config() in were absolute directory paths (the file comes with some that look like $src/blah/blah, but there is no $src variable if one is using config() , as I understand it.
  • Follow the instructions above regarding the fonts, with one small change in the second line (seems to be a typo):
           sudo cp tfm/* /usr/local/teTeX/share/texmf.local/fonts/tfm/jknappen/ec/.

That took care of everything and the page rendered fine. This installation was on a G4 laptop

John Paolillo


First of I hope that is the good place to find help. I am trying to install the server using the “Install the Server”. Unfortunately, i get the “Access denied” message when i make a query. I checked my Approved Wiki Urls and everythings seems to be right.

It turned out that the server environment required to be renamed as mkpdf.cgi. This breaks the piece of code that extracts the url of the page being requested. We have updated the installation instructions to cover this case. An administrator can also test the access control screen manually by going to the Access Control.Approved Wiki Urls page and adding ?action=checkapproval&url= to the address in the browser address bar, then press return. It should return either “1 Approved” or “0 Unapproved” to your browser window.

By the way I am not sure to understand the step n°5. When it is written to untar the accescontrol.tar.gz, is it in the wikipublisher installation directory? (anyway I copied these files in my pmwiki installation’s local). My configuration is

  • pmwiki-2.1.5,
  • wikipublisher-2.0.4
The Access Control.Approved Wiki Urls script goes into the site’s pmwiki/local/ directory. It contains a function which adds a checkapproval action. This checks whether a supplied url is in the list of approved addresses. The server will return “Access denied” if this script is not installed. The Access Control.Splash Screen script also goes in the local/ directory. It adds extra CSS code to hide display of various page parts so the server splash screen just shows the message specified in the page body.

My last query is to know if it is possible to create a forum to talk about problems met during the installation.

In the first instance, you can use the Contact page to send us a message. We are looking into options for a special Wikipublisher forum, but it depends on the level of interest.

— Francois

I just installed the server on a Debian box using the directions on the “Install the Server” page. Everything went just fine except for one minor thing. The directions said to set $WikiPublisherUrlFmt. I had to look at the sample config file to figure out that it’s actually $WikipublisherUrlFmt (capitalization will get you every time). I edited the install instructions to reflect this.

The only other problem I’m having (and it’s with the client side, not the server side) is that my “wikilogo” is losing the <img> tag around the image path. So, instead of seeing my logo graphic on every page, I see the text of the path of the logo graphic.

—Jeff McClure

Found the “wikilogo” problem. pub/skins/latexpmwiki/pmwiki.tmpl in 2.0.1 had a bug.

This line:

<div id=‘wikilogo’><a href=‘$ScriptUrl’>$PageLogoUrl</a></div>

should look something like this:

<div id=‘wikilogo’><a href=‘$ScriptUrl’><img src=‘$PageLogoUrl’ /></a></div>

—Jeff McClure

See skins for details. The latexpmwiki template supports both text and image logos, whereas the default pmwiki template only supports images. To use an image logo with the latexpmwiki skin, the local/config.php that defines $PageLogoUrl needs to wrap the logo’s address in <img src=‘…’ />. We were torn between a desire to be compatible with the default PmWiki skin and a wish not to require a graphic logo. This is now also documented in the FAQ. As of the Monday, 6 March 2006 release, Wikipublisher detects if the logo is an image and wraps an <img /> tag around it if necessary.
—John Rankin

Some help for the unexpirenced linux users. I have installed the Server 0.9.3 on a Debian box like explained on the install the Server page. For the log, and if some other people are as stupid as me :-) It is nessecary to extract the Wikipublisher server somwhere were Apache (or what else webserer you use) can see it (it does not wirk in the root directory :-)!). I moved it to the cgi-bin folder of the server. Now comes my question. Which rights and which owner does the Wikipublisher server need? A tried chmod -R 755 cgi-bin and changed the chown to an apropiate user. I tested the with a confixx perl debug tool and it gave green light. But when i trie to run the from a browser an internal server error occures. (By the way i have doublechecked all dependencies) Many thancks in advance!

Hi - I noticed nobody has answered here and I had exactly the same problem. I solved it by editing the file and added the correct path to the use lib line and require line. I also installed the sever in the cgi-bin directory and put the inc file there too. Hope this helps.

—Dean Staub
The version 0.9.4 series should report any misconfigurations it finds, which may help resolve problems like this. You can also set up a symlink in cgi-bin to the file.

I installed wikipublisher version 2101 and wikibook 0.9.4 on an opensuse 10.1 machine. All required software dependencies were met with the default system install.

Now, if I try to make a pdf document with special characters (for german language: ä ö ü → Umlaute), I get an error and no pdf is created. But this is only the case when a formatting like a heading (!!) is used in the same line. It does not happen, when the Text in the Heading does not contain Umlaute!

The relevant error parts of the debug output are (identified by comparing a document created without and one with umlaute):

(/usr/share/texmf/tex/latex/amsfonts/umsa.fd) (./mt-msa.cfg)
(/usr/share/texmf/tex/latex/amsfonts/umsb.fd) (./mt-msb.cfg)
! Argument of \rs@autoTOL has an extra }.
<inserted text> 
l.65 \section{Fremdw\replacechar hrungen}

! Emergency stop.
<inserted text> 
l.65 \section{Fremdw\replacechar hrungen}

No pages of output.
Transcript written on doc.log.

ERROR: no PDF returned

The output for the correctly created document is:

(/usr/share/texmf/tex/latex/amsfonts/umsa.fd) (./mt-msa.cfg)
(/usr/share/texmf/tex/latex/amsfonts/umsb.fd) (./mt-msb.cfg)
(/usr/share/texmf/tex/latex/psnfss/ts1ptm.fd) [1{/var/lib/texmf/fonts/map/pdfte
x/updmap/}] (./doc.aux) ){/usr/share/texmf/fonts/enc/dvips/psnfss/8r.
Output written on doc.pdf (1 page, 25110 bytes).
Transcript written on doc.log.

Is this a bug? If so, it maybe wrong to post it here. Please let me know if other users also can produce such a strange behavior on installation (just post it here). And moreover - how can I fix this problem? Thanks for any information in this direction.

— Adrian Schmid
Accented Characters in a heading work on this site. By default, it uses a sans font for headings and serif for body text. What happens if you specify a serif font for headings, via the options button? See aslo Issue 00084.

I’ve installed Publish PDF? and Wikipublisher on a Cent OS? 4.4 machine, and I’m struggling to get it working. When I try to execute I’m getting a long delay and then:

“Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.0.59 (Cent OS?) Server at Port 80”

Evidently I’ve looked at the logs, but the errors are very non-specific, so in an effort to track down where the problem is occurring I’ve been popping lines into the scripts to return output to the browser and exit, and the line where I’m getting the long delay is in
    my $res = $ua->request(HTTP::Request->new
			   (GET => $c_url)); 

Looking at $c_url I see that it is the address to check for an approved URL, and when I paste it into my browser I get sent back a php file containing “1 Approved” just as I do from the equivalent URL at wikipublisher.

I’m OK as a PHP programmer, but perl is new to me, so I’m steadily trying to get to grips with how that line works, and to disect it and see where the problem lies, but I’ve spent a day on this already, so I thought I’d post in case anyone can give me any pointers. It is very possible I have done something silly…

If anyone else has had a similar experience and solved it I’d be very glad to know how. When I eventually track this down I’ll make sure I post it here if not.

Ben Clayton

At least one other person has had a similar problem. It appears that the web-server is unable to resolve the address of the URL approval page to the correct physical address of that page, so you are getting a server time-out. This is a server configuration problem, I think — it’s the same kind of problem you see in a browser if the link to the internet is down or the designated DNS is unavailable. Bypassing the URL approval check is unlikely to help, as the same problem may well occur when the Wikipublisher server issues its request to the wiki for the page being typeset. A web server administrator might be able to shed light on this.

Thank you so much John! This came down to the fact that this server is in our DMZ, but the DNS for it is on our web server, pointing back at the (Smoothwall) firewall which has both the DMZ and our internal network behind it. DNS requests from the big wide world AND from our internal network were resolving to the DMZ server fine, but DNS requests from the DMZ server itself were resolving to the external address of the firewall correctly, then getting no response - it seems that the firewall couldn’t cope with directing traffic back into the DMZ when the request originated from the DMZ. I’ve added static DNS entries to the firewall for the DMZ addresses which I need to resolve from the DMZ, and my issue has gone away! Thanks again!!!

(BTW, I was never intending to try to bypass the URL approval check, I was just trying to understand the perl line enough to work out exactly what it was doing when it failed, and therefore what I had done wrong. Thank goodness for open source!)

Next problem: now when I try to produce a PDF from my server which happily works via the public one I get a wikipublisher error report:

n: Main.UserNotes
action: texerror
wpaction: print
ptype: print
format: pdf
wpversion: 2001002

Debug gives what looks like reasonable XML in the ****SMLLINT section, then breaks on reaching **** XSLTPROC, thus:

tbcommon.xsl: Couldn't determine source path; no Saxon 6.5.x?
warning: failed to load external entity "/var/www/html/wikibook/xml/tbook-temp-file-bib.xml"
xsltApplyOneTemplate: fallback was not compiled
xsltApplyOneTemplate: fallback was not compiled
xsltApplyOneTemplate: fallback was not compiled
xsltApplyOneTemplate: fallback was not compiled
xsltApplyOneTemplate: fallback was not compiled
xsltApplyOneTemplate: fallback was not compiled

This seems identical to issue 00098, but no resolution was posted for that.

XSLT appears to be installed (Cent OS? base package libxslt.i386) and the location of xsltproc is correctly specified in as /usr/bin/xsltproc

The failures also occur in PDFLATEX:

This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
Document Class: extarticle 1996/10/08 v1.0 Non Standard LaTeX document class
(/usr/share/texmf/tex/latex/tools/varioref.sty) (./tbook.sty
pdflatex driver selected
pdflatex driver selected
! Font T1/cmr/m/n/10.95=ecrm1095 at 10.95pt not loadable: Metric (TFM) file not
<to be read again> 
l.95 \fontencoding\encodingdefault\selectfont

! Emergency stop.
<to be read again> 
l.95 \fontencoding\encodingdefault\selectfont

No pages of output.
Transcript written on doc.log.
/usr/share/texmf/fonts/tfm/jknappen/ec/ecrm1095.tfm: Permission denied
/usr/share/texmf/fonts/tfm/jknappen/ec/ecrm1095.tfm: Permission denied
kpathsea: Running mktextfm ecrm1095
mkdir: cannot create directory `/var': File exists
chmod: cannot access `/var': Permission denied
mkdir: cannot create directory `/var/lib': File exists
kpsestat: /var/lib/..: Permission denied
chmod: too few arguments
Try `chmod --help' for more information.
mkdir: cannot create directory `/var/lib/texmf': File exists
kpsestat: /var/lib/texmf/..: Permission denied
chmod: too few arguments
Try `chmod --help' for more information.
mkdir: cannot create directory `/var/lib/texmf/tfm': Permission denied
kpsestat: /var/lib/texmf/tfm/..: Permission denied
chmod: too few arguments
Try `chmod --help' for more information.
mkdir: cannot create directory `/var/lib/texmf/tfm/jknappen': Permission denied
kpsestat: /var/lib/texmf/tfm/jknappen/..: Permission denied
chmod: too few arguments
Try `chmod --help' for more information.
mkdir: cannot create directory `/var/lib/texmf/tfm/jknappen/ec': Permission denied
kpsestat: /var/lib/texmf/tfm/jknappen/ec/..: Permission denied
chmod: too few arguments
Try `chmod --help' for more information.
mktextfm: mktexdir /var/lib/texmf/tfm/jknappen/ec failed.
kpathsea: Appending font creation commands to missfont.log.

**** Generated XML, with images
1: <?xml version="1.0" encoding="iso-8859-1"?>
2: <!DOCTYPE article PUBLIC "-//Affinity Ltd//DTD wikibook 0.9.4//EN" 

Well - I’ve just tracked it down. As you predicted in your comments on 00098 this is nothing to do with the XSLTPROC errors - it is all to do with PDFLATEX. The script was being prevented from doing the necessary by SELINUX, which controls access not just by permissions (which were sufficiently open) but by running process. A command

chcon -R -h -t httpd_sys_script_rw_t /usr/share/texmf/* has opened things up enough to sort it out.

So - now we know.

Sorry to post something so long here - I suspect I won’t be the only one ever to come across the problem, however, as SELINUX will probably become more common, so hopefully someone might find this useful.

In conclusion re: my installation experiences. A right royal pain - but not because of issues with Wikipublisher, rather because of my unusual DNS situation and my security conscious OS. Thanks again for your help, and a great looking system.

Where exactly is the Approved Wiki URLs page that instruction 6 of the server installation refers to? Graham

  • After having solved a lot of issues for installing (perl-related) this interesting project, I can’t get my URL-approved. As our server is the only one here and only accessible from the inside of our company; there is no need for access control. So I was wondering if there was no possibility to disable this URL-check… I’ve tried a workaround in php, but it keeps failing… Unfortunately… Any hints? - Tom
    • The access control approval page address is defined in Commenting out the line that configures check_url will suppress the access control check.
Creative Commons License
Edit · History · Print · Recent Changes · Search · Links
Page last modified on 21 November 2016 at 02:57 PM