Recent Changes · Search:

Support the Project

Wikipublisher

PmWiki

edit SideBar

Wikipublisher.InstallationExperiences History

Hide minor edits - Show changes to output

21 November 2016 at 02:57 PM by John Rankin - remove unauthorised links
Deleted lines 303-304:

[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.medicaljobsaustralia.com/|Health Careers]] | [[http://www.medicaljobsaustralia.com/jobs/australia/nurses-and-midwives/|NursinginAustralia]]
Changed lines 3-4 from:
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 [[http://goo.gl/CZJAoJ|hargahape]]. The bug is in the Image.pm server code, and can be corrected by upgrading to the latest version, 0.9.3g. Alternatively, you can just upgrade the mkpdf/Image.pm file to that from the latest release, which will have the same effect as applying the change described in Michael Caerwyn's bug report:.
to:
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 Image.pm server code, and can be corrected by upgrading to the latest version, 0.9.3g. Alternatively, you can just upgrade the mkpdf/Image.pm file to that from the latest release, which will have the same effect as applying the change described in Michael Caerwyn's bug report:.
Changed lines 23-27 from:
Security is ensured by storing data into a [[http://infosafe.fr|safe for servers]]


:Simple temporary fix:When you see that in
the debug output, run the command "mktextfm ecrm1095`" from the terminal [[http://goo.gl/A50dRQ|kulkas sharp]]. 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.
to:
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.
Changed line 44 from:
* Make sure that all of the directory arguments to config() in mkpdf.inc were absolute directory paths (the file comes with some that look like $src/blah/blah [[http://goo.gl/LEzugP|sepeda giant]], but there is no $src variable if one is using config() , as I understand it.
to:
* Make sure that all of the directory arguments to config() in mkpdf.inc 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.
Changed line 305 from:
[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.rushtonfinancial.com.au|Best Investment]]
to:
[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.medicaljobsaustralia.com/|Health Careers]] | [[http://www.medicaljobsaustralia.com/jobs/australia/nurses-and-midwives/|NursinginAustralia]]
Added line 23:
Security is ensured by storing data into a [[http://infosafe.fr|safe for servers]]
Changed lines 3-4 from:
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 Image.pm server code, and can be corrected by upgrading to the latest version, 0.9.3g. Alternatively, you can just upgrade the mkpdf/Image.pm file to that from the latest release, which will have the same effect as applying the change described in Michael Caerwyn's bug report:.
to:
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 [[http://goo.gl/CZJAoJ|hargahape]]. The bug is in the Image.pm server code, and can be corrected by upgrading to the latest version, 0.9.3g. Alternatively, you can just upgrade the mkpdf/Image.pm file to that from the latest release, which will have the same effect as applying the change described in Michael Caerwyn's bug report:.
Changed lines 25-26 from:
: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.
to:
:Simple temporary fix:When you see that in the debug output, run the command "mktextfm ecrm1095`" from the terminal [[http://goo.gl/A50dRQ|kulkas sharp]]. 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.
Changed line 44 from:
* Make sure that all of the directory arguments to config() in mkpdf.inc 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.
to:
* Make sure that all of the directory arguments to config() in mkpdf.inc were absolute directory paths (the file comes with some that look like $src/blah/blah [[http://goo.gl/LEzugP|sepeda giant]], but there is no $src variable if one is using config() , as I understand it.
Added lines 304-305:

[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.rushtonfinancial.com.au|Best Investment]]
29 January 2016 at 11:33 AM by John Rankin - remove spam links
Deleted lines 303-304:

[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.rushtonfinancial.com.au|Best Investment]]
Deleted lines 301-302:
* All papers shall be store in a safety place, against the fire, and best option is use of a burglar and fire safe watch on http://www.infosafe.fr for more details about safe ( in French )
Added lines 304-305:

[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.rushtonfinancial.com.au|Best Investment]]
Deleted lines 278-279:
All papers shall be store in a safety place, against the fire, and best option is use of a burglar and fire safe watch on http://www.infosafe.fr for more details about safe ( in French )
Added line 302:
* All papers shall be store in a safety place, against the fire, and best option is use of a burglar and fire safe watch on http://www.infosafe.fr for more details about safe ( in French )
Added lines 279-280:
All papers shall be store in a safety place, against the fire, and best option is use of a burglar and fire safe watch on http://www.infosafe.fr for more details about safe ( in French )
Deleted line 306:
[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.rushtonfinancial.com.au|Best Investment]]
Changed line 305 from:
[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.usapropertyinvestors.com.au|Property Investment]]
to:
[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.rushtonfinancial.com.au|Best Investment]]
Added line 305:
[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.usapropertyinvestors.com.au|Property Investment]]
07 January 2016 at 03:17 PM by John Rankin - remove spam links
Changed lines 24-25 from:
All papers shall be store in a safety place, against the fire, and best option is use of a burglar and fire safe watch on http://www.infosafe.fr for more details about safe ( in French )
to:
Deleted lines 304-305:

[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.usapropertyinvestors.com.au|Property Investment]]
Changed lines 305-307 from:
** The access control approval page address is defined in mkpdf.inc. Commenting out the line that configures check_url will suppress the access control check.
to:
** The access control approval page address is defined in mkpdf.inc. Commenting out the line that configures check_url will suppress the access control check.

[[http://www.papdan.com/seo-services-search-engine-optimisation.php|SEO Melbourne]] | [[http://www.phillro.com.au/p/industrial-2/airless-spray-packages-2/|Airless Spray]] | [[http://www.usapropertyinvestors.com.au|Property Investment]]
29 August 2014 at 04:18 AM by JamesDolopi -
Added lines 23-24:

All papers shall be store in a safety place, against the fire, and best option is use of a burglar and fire safe watch on http://www.infosafe.fr for more details about safe ( in French )
04 August 2014 at 01:14 PM by John Rankin - remove spam link and answer question
Deleted lines 59-60:
All papers shall be store in a safety place, against the fire, and best option is use of a burglar and fire safe watch on http://www.infosafe.fr for more details about safe ( in French )
Changed lines 302-303 from:
* 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 acces 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
to:
* 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 mkpdf.inc. Commenting out the line that configures check_url will suppress the access control check.
Added lines 59-60:

All papers shall be store in a safety place, against the fire, and best option is use of a burglar and fire safe watch on http://www.infosafe.fr for more details about safe ( in French )
Changed lines 298-302 from:
Where exactly is the '''Approved Wiki URLs''' page that instruction 6 of the server installation refers to? Graham
to:
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 acces 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
30 May 2010 at 04:59 PM by Graham Chiu -
Changed line 298 from:
Where exactly is the ""Approved Wiki URLs"" page that instruction 6 of the server installation refers to? Graham
to:
Where exactly is the '''Approved Wiki URLs''' page that instruction 6 of the server installation refers to? Graham
30 May 2010 at 04:58 PM by Graham Chiu -
Added lines 297-298:

Where exactly is the ""Approved Wiki URLs"" page that instruction 6 of the server installation refers to? Graham
04 May 2007 at 03:04 AM by Ben Clayton - Solved SELINUX/font issue
Deleted lines 183-184:
Now I'm getting a "...does not appear to be in Wikipublisher XML" message. I hope I haven't broken something on my travels... Here goes on tracking that one down.
Changed lines 185-186 from:
Ben
to:

-----

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:
[@url: http://gmwiki.irax.com/pmwiki.php?n=Main.UserNotes
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:
[@
**** XSLTPROC
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 (CentOS base package libxslt.i386) and the location of xsltproc is correctly specified in mkpdf.pm as /usr/bin/xsltproc

The failures also occur in PDFLATEX:
[@
**** PDFLATEX
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
(./doc.tex{/usr/share/texmf/pdftex/config/pdftex.cfg}
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
(/usr/share/texmf/tex/latex/extsizes/extarticle.cls
Document Class: extarticle 1996/10/08 v1.0 Non Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size11.clo)
(/usr/share/texmf/tex/latex/base/exscale.sty))
(/usr/share/texmf/tex/generic/babel/babel.sty
(/usr/share/texmf/tex/generic/babel/english.ldf
(/usr/share/texmf/tex/generic/babel/babel.def)))
(/usr/share/texmf/tex/latex/tools/varioref.sty) (./tbook.sty
pdflatex driver selected
pdflatex driver selected
(/usr/share/texmf/tex/latex/base/inputenc.sty
(/usr/share/texmf/tex/latex/base/latin1.def))
(/usr/share/texmf/tex/latex/base/fontenc.sty
(/usr/share/texmf/tex/latex/cyrillic/t2aenc.def)
(/usr/share/texmf/tex/latex/base/t1enc.def)
! Font T1/cmr/m/n/10.95=ecrm1095 at 10.95pt not loadable: Metric (TFM) file not
found.
<to be read again>
relax
l.95 \fontencoding\encodingdefault\selectfont

?
! Emergency stop.
<to be read again>
relax
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"
.
.
.
continues...@]


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.
03 May 2007 at 09:49 PM by Ben Clayton - DNS problem resolved
Changed lines 180-188 from:
->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.
to:
->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!!!

Now I'm getting a "...does not appear to be in Wikipublisher XML" message. I hope I haven't broken something on my travels... Here goes on tracking that one down.

(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!)\\
Ben
03 May 2007 at 01:43 PM by John Rankin - response to server error question
Changed lines 178-180 from:
Ben Clayton
to:
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.
02 May 2007 at 07:58 PM by Ben Clayton - Issue with execution on CentOS 4.4
Changed lines 156-178 from:
->AccentedCharacters 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(s.) 00084]].
to:
->AccentedCharacters 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(s.) 00084]].

-----

I've installed PublishPDF and Wikipublisher on a CentOS 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 (CentOS) Server at bsg.irax.com 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 mkpdf.pm:\\
[@ 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
23 March 2007 at 02:30 PM by John Rankin - link to accented characters
Changed line 112 from:
to:
[@
Changed line 134 from:
to:
@]
Changed line 136 from:
to:
[@
Changed line 150 from:
to:
@]
Added lines 155-156:

->AccentedCharacters 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(s.) 00084]].
15 March 2007 at 11:08 AM by Adrian Schmid -
Changed lines 109-110 from:
Now, if I try to make a pdf document with special characters (notably for german language: -> Umlaute), I get an error and no pdf is created. The relevant error parts of the debug output are (identified by comparing a document created without and one with umlaute):
to:
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):
Changed lines 151-162 from:
It is interesting to note that while I have an installation running on ssl and another without ssl, the one with ssl seems to have a problem with the Umlaute, whereas the one without ssl does not have this problem and creates the pdf. Now my guess would be that this is some configuration issue... but which?

I also tried to change the character encoding in the config.php file to UTF:
$XMLEncodingFmt = 'utf-8';
...but no result.

I suppose, a similar issue was mentioned here:
http://www.wikipublisher.org/wiki/index.php?n=Issues.00084

Any help in this would be very useful.
If I find an answer, I will post it here
.
to:
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.
15 March 2007 at 10:55 AM by Adrian Schmid -
Changed lines 111-115 from:
XSLTPROC
tbcommon
.xsl: Couldn't determine source path; no Saxon 6.5.x?

warning: failed to load external entity "
/home/admispconfig/ispconfig/web/doc/wikibook/xml/tbook-temp-file-bib.xml"
to:
(/usr/share/texmf/tex/latex/psnfss/ot1ptmcm.fd)
(/usr/share/texmf/tex/latex/psnfss/omlptmcm
.fd)
(/usr/share/texmf/tex/latex/psnfss/omxpsycm
.fd)
(
/usr/share/texmf/tex/latex/base/ulasy.fd)
(
/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>
\par
Changed line 123 from:
Emergency stop.
to:
! Emergency stop.
Added lines 133-150:
The output for the correctly created document is:

(/usr/share/texmf/tex/latex/psnfss/ot1ptmcm.fd)
(/usr/share/texmf/tex/latex/psnfss/omlptmcm.fd)
(/usr/share/texmf/tex/latex/psnfss/omxpsycm.fd)
(/usr/share/texmf/tex/latex/base/ulasy.fd)
(/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/pdftex.map}] (./doc.aux) ){/usr/share/texmf/fonts/enc/dvips/psnfss/8r.
enc}</usr/share/texmf/fonts/type1/urw/times/utmri8a.pfb></usr/share/texmf/fonts
/type1/urw/helvetic/uhvb8a.pfb></usr/share/texmf/fonts/type1/urw/times/utmr8a.p
fb>
Output written on doc.pdf (1 page, 25110 bytes).
Transcript written on doc.log.

It is interesting to note that while I have an installation running on ssl and another without ssl, the one with ssl seems to have a problem with the Umlaute, whereas the one without ssl does not have this problem and creates the pdf. Now my guess would be that this is some configuration issue... but which?
Deleted lines 157-159:
And as a last thing - strangely, if I create a pdf from this very page, it works fine.

Is this due to a library on my system not converting the characters to ISO Code?
Deleted line 158:
15 March 2007 at 07:24 AM by Adrian Schmid -
Added lines 133-137:
I suppose, a similar issue was mentioned here:
http://www.wikipublisher.org/wiki/index.php?n=Issues.00084

And as a last thing - strangely, if I create a pdf from this very page, it works fine.
15 March 2007 at 07:11 AM by Adrian Schmid -
Changed line 111 from:
**** XSLTPROC
to:
XSLTPROC
Changed line 119 from:
! Emergency stop.
to:
Emergency stop.
Changed lines 127-128 from:
***** ERROR: no PDF returned
to:
ERROR: no PDF returned
Changed line 138 from:
to:
-- Adrian Schmid
15 March 2007 at 07:10 AM by Adrian Schmid -
Changed line 106 from:
I installed wikipublisher version 2101 and wikibook 0.9.4 on a opensuse 10.1 machine.
to:
I installed wikipublisher version 2101 and wikibook 0.9.4 on an opensuse 10.1 machine.
Added line 113:
Deleted line 115:
Added lines 129-132:
I also tried to change the character encoding in the config.php file to UTF:
$XMLEncodingFmt = 'utf-8';
...but no result.
Deleted lines 138-142:




#$XMLEncodingFmt = 'utf-8';
15 March 2007 at 07:07 AM by Adrian Schmid -
Changed lines 102-139 from:
->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 mkpdf.inc file.
to:
->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 mkpdf.inc file.

-----

I installed wikipublisher version 2101 and wikibook 0.9.4 on a 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 (notably for german language: -> Umlaute), I get an error and no pdf is created. The relevant error parts of the debug output are (identified by comparing a document created without and one with umlaute):

**** XSLTPROC
tbcommon.xsl: Couldn't determine source path; no Saxon 6.5.x?
warning: failed to load external entity "/home/admispconfig/ispconfig/web/doc/wikibook/xml/tbook-temp-file-bib.xml"


l.65 \section{Fremdw\replacechar hrungen}

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

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

***** ERROR: no PDF returned

Is this due to a library on my system not converting the characters to ISO Code?
Any help in this would be very useful.

If I find an answer, I will post it here.






#$XMLEncodingFmt = 'utf-8';
30 November 2006 at 10:43 AM by John Rankin - comment on mkpdf.pl path problems
Added line 102:
->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 mkpdf.inc file.
Changed lines 97-101 from:
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 mkpdf.pl with a confixx perl debug tool and it gave green light. But when i trie to run the mkpdf.pl from a browser an internal server error occures. (By the way i have doublechecked all dependencies) Many thancks in advance!
to:
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 mkpdf.pl with a confixx perl debug tool and it gave green light. But when i trie to run the mkpdf.pl 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 mkpdf.pl 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
Creative Commons License
Edit · History · Print · Recent Changes · Search · Links
Page last modified on 21 November 2016 at 02:57 PM