Tags:
pdf1Add my vote for this tag create new tag
, view all tags

GenPDFAddOnDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on GenPDFAddOn contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the GenPDFAddOn bug database.

Feedback on GenPDFAddOn

-- BrianSpinar - 02 Feb 2005

Thanks for contributing this Add-on. I made a minor change at the top to exclude the first header in the TOC.

-- PeterThoeny - 02 Feb 2005

This is excellent. Speaking of TOC the

tag is often the exact part that you DON'T want in your generated document. We use the TOC functionality a lot, and it's great for online reading - but it is in the way for generated PDF content.

So in the same way that there is a start/stop for the generation, would it be possible to have (multiple) "exclusion" (or ignore) tags? Something like

<!-- PDFIGNORESTART -->
<!-- PDFIGNORESTOP -->

or similar (in our case we would put the TOC tag in the between)?

Thanks a bunch for your contribution!

-- SteffenPoulsen - 04 Feb 2005

Thanks. I've gotten the same request inside my company to have multiple start/stop sections. I just haven't gotten around to adding it yet (but likely will fairly soon). In house, we tend to use it in one specific way, so I welcome suggestions, issues, bugs, etc.

-- BrianSpinar - 04 Feb 2005

I'm having trouble with the title page capabilities. I've created a title topic with one <img src/> tag enclosed in <!-- PDFSTART/STOP --> tags and set the PDFTITLETOPIC variable in the actual document topic but the title page isn't showing in the generated document. What am I missing here?

-- BillGunter - 24 Feb 2005

One thing about the title page capability is that the title page topic needs to be expressed in pure html (not TWiki mark-up). This means including the html head and body tags, etc. My advice is to copy the example title topic that comes with the add-on installation and just re-format the "body" section to be what you want it to be. If you've already tried this, you're welcome to send me an email (use the address in BrianSpinar) and attach your title topic. Maybe I'll see something obvious as to why it doesn't work.

-- BrianSpinar - 27 Feb 2005

Hmmm, I can't get this to run (I don't much perl...). I've set the HTMLDOC TWiki preference variable, but when I try to load a topic using 'gendef' as part of the URL, I get an error:

[Fri Mar 11 09:17:30 2005] [error] [client XXXXXXXXXXX] Premature end of script headers: genpdf

Is this something obvious? This is with TWiki20041030beta under Apache 2, RedHat 9. Thanks!

-- SteveWampler - 11 Mar 2005

Installed this on my 2 Sep 2004 version running on Fedora Core 3/Apache 2. It works great.

I would see it a very interesting improvement to be able to generate a complete Web as a single PDF file, from a link in the WebHome page. Goal would be off-line reading of content as a single PDF file with links. I am able to do this at the moment by manually saving each topic as a PDF file and combining them into a single file with pdftk (http://www.accesspdf.com/pdftk/), but

  • Result is not too good with contents pages spread across
  • Links to other topics are not active.
How difficult would it be to generate a complete Web ?

-- JeanNoelSimonnet - 23 Mar 2005

I've uploaded a new version of this plugin/addon. You can see all the details (and get the latest zip file) on the GenPDFAddOn page. The main changes are some fixes to the toc and title page generation as well as now allowing multiple PDFSTART/PDFSTOP sections in a single page. It also works with the latest htmldoc (1.8.24). The source code is also in CVS now.

For Steve's script problem above, if you haven't gotten it working yet, my best guess based on what you posted is that you have a bad path to perl in the genpdf script. Make sure the script points to your version of perl (ours is /usr/local/bin/perl and is the value suppliede in the script--you may need to change this to /usr/bin/perl or something else).

For Jean-Noel, as far as generating a complete web as a single PDF file, we've discussed this at my company also, it just turns out to be a fair amount of work at several different levels (that I honestly don't have time for at this point). If you want to do this, you might consider looking at the output of the PublishAddOn and running that through htmldoc. I've never tried this, so I'm not sure how well (if at all) it would work.

-- BrianSpinar - 25 Mar 2005

This Add-on is a great addition to the TWiki-System. I've installed this on 24 Mar 2005. In using multiple PDFSTART / PDFSTOP it works not as described in version 0.2 of GenPDFAddOn. My TWiki-Page looks as follows:

TwikiPage
%INCLUDE{Page1}%
%INCLUDE{Page2}%
%INCLUDE{Page3}%

<!-- PDFSTOP -->

--mySignatur
In each include-page there is a PDFSTART and a PDFSTOP statement to suppress the TOC and the signature. The generated PDF brakes after the first PDFSTOP. It appears to me that the changes for version 0.2 are not implemented. What can I do?

-- RudiRose - 26 Mar 2005

Rudi, I checked the version of the perl module that I uploaded and it appears to the be the latest version (I uploaded another one as I did notice that the one I uploaded yesterday had an extra unnecessary file in it, but I don't think this should be a problem). I also tried something similar to what you tried, and it seemed to work OK for me. I did notice a couple things to be aware of when including pages as you did (and I should probably make the script smarter at some point to help things out, but, anyway...).

First, make sure that the PDFSTART and PDFSTOP comments are within the STARTINCLUDE/STOPINCLUDE variables in the included page. For example (in the included topic),

%STARTINCLUDE%
<!-- PDFSTART -->
...
<!-- PDFSTOP -->
%STOPINCLUDE%

Second, make sure that the net result of the included page has PDFSTART/PDFSTOP in pairs as expected. For example, when I first tried your experiment, my root page looked like:

<!-- PDFSTART -->
...
%INCLUDE{p1}%
%INCDLUE{p2}%

comments
<!-- PDFSTOP -->

The problem with the above is that the "net" page has two PDFSTART's before the first PDFSTOP (one from the root page and one from the first included page). This caused the PDF document to not look as expected. To fix this, I had to make the root page look like:

<!-- PDFSTART -->
...
<!-- PDFSTOP -->
%INCLUDE{p1}%
%INCDLUE{p2}%
<!-- PDFSTART -->

comments
<!-- PDFSTOP -->

I'm not sure if either of these are your problem, but it did seem to work OK on our site if I accounted for both of these issues. At some point, I should probably make the script ignore a second PDFSTART before the first PDFSTOP, etc., but that's a project for another day. Hope this helps.

-- BrianSpinar - 26 Mar 2005

this addon is great, but i have (maybe) the same troubles as rudi.

a simple topic like this causes the script to abort (no browser output):

<!-- PDFSTART -->
pdf text here
<!-- PDFSTOP -->

i tried it on some other topics but this didn't work also. normal pdf output works great.

environment:

apache2 2.0.53-5, perl 5.8.4-6, htmldoc 1.8.23-1.2, debian/sarge

apache-ssl 1.3.33-4, perl 5.8.4-6, htmldoc 1.8.23-1.2, debian/sarge

brian, please let me know if i can help you tracking this problem down (server logs, traces, patches, config changes etc.).

-- MartinStahn - 27 Mar 2005

Hi Brian, now it works fine. The last upload of the zip-file containing GenPDFAddOn is the right one. The genpdf.pm in the lib-directory is the version 0.2 . Look at the $VERSION = 0.2 variable in the genpdf.pm file. The previous uploads contain always the genpdf.pm version 0.1. Thanks for all.

-- RudiRose - 27 Mar 2005

Martin, try the latest zip file. It fixed Rudi's problem (I seemed to have uploaded a bad one on the 25th). If it still doesn't work, by "normal pdf output," are you saying that it works fine if you leave out the PDFSTART/PDFSTOP tags? Or do you mean it doesn't work at all within TWiki? FYI, I'm gone for the next few days, so I probably won't respond until later in the week.

-- BrianSpinar - 28 Mar 2005

brian, my downloaded/installed version was from 02 feb 2005, so i upgraded now (to 0.2). the problem with the PDFSTART/PDFSTOP tags persists (now confirmend on a third machine - fresh installation).

"normal" pdf generation works pretty well, crazy ... no errors in the apache log file.

how can i help you fixing this "bug"? this addon is great!

btw: feature requests smile

  • some variable to force a page break on pdf generation (better printable output)
  • cover page (optional)
maybe others?

-- MartinStahn - 29 Mar 2005

Martin, help me understand one thing before we get farther into debugging this. If you have a twiki page with no PDFSTART/PDFSTOP tags in it and you run the genpdf script on it, do you get PDF output that shows up in the browser? Assuming the previous scenario works, are you saying that if you add PDFSTART/PDFSTOP tags to the same twiki topic you get nothing in the browser? If this is the case, send me (via email) a copy of a twiki topic without the PDFSTART/STOP tags that "works" for you (just the raw text as you would see it in the edit window). Also send me the version of the same twiki topic with the START/STOP tags added that cause it to no longer work. Thanks.

By the way, there is already support for cover pages. I call them title pages in the GenPDFAddOn documentation. As far as I know, they work fine. The page break idea is an interesting one. I don't think it is hard to do, but the amount of time I have to devote to twiki right now is pretty limited.

-- BrianSpinar - 04 Apr 2005

I would like to embedd the revision information as a footer or in the title page of my PDFs. Since the title, header, footer topics are not rendered I cannot simply put %REVINFO% in my footer topic. I am not too familiar with Perl but would like some help/instructions to "hack" this in to the PDF script unless there is another way. I do not want to put %REVINFO% on every page that needs to be converted to PDF. I want the PDF translation to have that built in. Any suggestions?

-- MichaelRosett - 04 Apr 2005

Martin, regarding the pagebreaks, you can use the standard HTMLDOC comments - there's lots to choose from smile (I.e. if you want to break to a new page, insert this comment in your topic text: <!-- NEW PAGE -->).

-- SteffenPoulsen - 05 Apr 2005

Michael, it's actually fairly easy to get rendered versions of the title pages and header/footer pages. In the perl module (GenPDF.pm), you simply need to change the TWiki::Func::readTopicText() function call in the _getHeaderFooterData and _createTitleFile functions to _getRenderedView(). You do give up something in doing this (read the comments above the _createTitleFile function for details), but you may not care.

After thinking about it a bit more, it really wouldn't be that hard to have both the feature I wanted originally and the rendered view. If you don't mind waiting another week or so, I'll probably have a little time later in the week (or early next) to try what I'm thinking. If it works, I'll post an update. Otherwise, feel free to hack away.

-- BrianSpinar - 05 Apr 2005

I've uploaded a new version of the plugin (0.3) that adds full TWiki rendering to the title topic page. It also adds full TWiki common variable expansion to the header/footer topic page (e.g. you can now embed things like %REVINFO% in headers and footers). It doesn't seem to be possible to do full TWiki rendering to the header/footer due to the issues with how full rendering interacts with the HTMLDOC header/footer HTML comments (at least as far as I could tell with some limited attempts). Read the updated documentation for more details. As always, comments, etc. are welcome.

-- BrianSpinar - 12 Apr 2005

brian, sorry for my late answer. i'm very busy at work. first i upgraded to the new version and tried without success. after looking at the logfiles i found the following error:

Calling htmldoc: /usr/bin/htmldoc --book --links --linkstyle plain -t pdf14 --portrait --toclevels 5 --firstpage toc --size a4 --browserwidth 860 --tocheader ... --tocfooter ..i --titlefile /tmp/fileXnq2qsZ6KZ.html /tmp/filevNNUBCAH7Y.html

ERR002: Error: no pages generated! (did you remember to use webpage mode?)

in lib/TWiki/Contrib/GenPDF.pm on line 375 i've added "--webpage" as option and now it works!

i played with some other topics (with and without the "patch" in GenPDF.pm), without the --webpage option the pdfstart/stop tags do not work here.

maybe it's debian specific. for me this great addon now works, for new versions i'll patch manually or check if it's possible to set it as an environment variable/option.

if i can help you doing some testing on new versions, please let me know.

steffen, thanks for your tip with the newpage, it works great! exactly what i searched wink

-- MartinStahn - 18 Apr 2005

Martin, I know the feeling about being busy. I intentionally did not include the --webpage option as it prevents the table of contents (and supposedly title page) from being generated (see the description of what it does here). Out of curiosity, I tried adding the --webpage on my site. It did not prevent the title page from showing up, but it did prevent the table of contents. You seem to have a couple unique problems, and I'm not sure what the source of them are. I don't think it makes sense right now to add the --webpage flag to the official version because of the table of contents problem, but I'm glad patching the code with --wbpage fixes your problems.

At some point if you're bored smile and if you have a page from your site with nothing sensitive on it that has the pdfstart/stop problem, etc. without the --webpage switch, I'd be interested in seeing how it behaves on my installation. Feel free to email me the raw text or (even better) the file itself.

-- BrianSpinar - 21 Apr 2005

Brian, it seems to me to make sense if we integrate this better with the PublishAddOn. That thing currently fixes up links and such like, and generates a zip of HTML pages. Do you think it would be possible? It need not be a full integration, just an agreement to use common terms for marking published sections, and some agreement on the interface.

-- CrawfordCurrie - 22 Apr 2005

Crawford, I'm certainly open to the idea. I'm not quite sure what the end goal of the integration should be? Since GenPDFAddOn works on individual pages, would you like to see PDF versions of each page in the PublishAddOn output or would you like to see a unified PDF document of the entire "published" site? Or did you have something else in mind? Just adding PDF versions of individual publiished pages strikes me as reasonably easy to support (since that's pretty much what the genpdf stuff does now so it's just tying the two add-ons together). Let me know what you think.

-- BrianSpinar - 23 Apr 2005

Just a small remark: You could remove the CVS/ directory entries from the zipfile.

-- ChristopherHuhn - 02 May 2005

Thanks. I thought I had removed them when I uploaded it the first time, but I guess not. Anyway, I uploaded a new zip file with the CVS directories removed (no other changes).

-- BrianSpinar - 02 May 2005

Hi Brian, during the past days I tried your GenPDFAddOn which works nicely for our purposes. However, in order to make 'Set PDFORIENTATION = landscape' and alike work, I had to change quite a few statements in GenPDF.pm like

    $prefs{'orientation'} = "portrait" if ($prefs{'orientation'} =~ /\s*/);

into

    $prefs{'orientation'} = "portrait" if ($prefs{'orientation'} =~ /^\s*$/);

Please note the ^ and $ in the /^\s*$/ part. Would it be possible to include this in the released version?

-- WolfgangWalkowiak - 02 May 2005

Wolfgang, thanks and I can certainly include the fixes with the next version. I had fixed a similar problem with the toclevels variable in a previous release. I don't know why I didn't change all of them then.

-- BrianSpinar - 04 May 2005

It would be nice if html symbols in the header or footer would expand. For example, putting the html for the copyright symbol into GenPDFExampleHeaderFooterTopic doesn't work, it just renders as normal text characters in the PDF output.

-- MarcusLeonard - 10 May 2005

I've done a fairly major rewrite of lots of this plugin. Some of the features are:

  • better security (now calls system($TWiki::htmldocCmd, @htmldocArgs) )
  • checks return code of htmldoc and returns an error on failure
  • validation of preferences
  • better HTML3.2 compatibility for htmldoc 1.8.24
  • full integration of PDF META tags (depends on 2 FORMFIELDs):
    • %FORMFIELD{"HeadLine"}% for PDF Subject field
    • %FORMFIELD{"KeyWords"}% for PDF Keywords field
    • all other PDF fields use topic info
  • more htmldoc options (margins, permissions, numbered TOC, logoimage, headfootfont, ...) using preferences
  • removed %TOC% fields
  • title topic and header/footer topics are now fully rendered
  • fixed the header shifting function
Before I upload a new zip, can someone answer these questions?
  1. Shouldn't it be package TWiki::Plugins::GenPDFAddOn instead of package TWiki::Contrib::GenPDFAddOn ?
    1. And for that matter, shouldn't it be GenPDFPlugin?
  2. Shouldn't the variables start with GENPDFADDON_ instead of just PDF ?
  3. I removed the htmldoc command from preferences and placed it in TWiki.cfg. Does that mean it's a plugin not an addon now?
    1. And is there anything special that needs to be done to help during an upgrade?
  4. Shouldn't $html =~ s|<p style=\"page-break-before:always\"\/>||g; be replacing the CSS page break with <!-- PAGE BREAK --> for htmldoc?
This plugin is way cool! I will dummy up a sample PDF doc to attach to the main page so people can see just how cool it is smile

-- WadeTurland - 11 Jun 2005

Actually, I just noticed this plugin is in CVS which answered question 1. I'll get a CVS login and do this The Right Way™

-- WadeTurland - 11 Jun 2005

On TWiki::Contrib::* vs TWiki::Plugins::* question: If the TWikiExtension is a standalone script that has some additional modules then it is better to package the additional modules as a ContribPackage. If the extension is a Plugin, e.g. implements TWiki::Plugins::MyOwnPlugin::initPlugin, then package it as a Plugin. There may be border cases, but this distinction shoild give you some guidelines.

-- PeterThoeny - 12 Jun 2005

I just did a CVS commit for version 0.4 with above stated fixes. Please be sure to read the instructions carefully, especially the GENPDFADDON_ preferences and the $htmldocCmd in lib/TWiki.cfg

-- WadeTurland - 15 Jun 2005

By the way Marcus, I'm not sure what you mean by "the html for the copyright symbol", but I used © successfully in the headers with htmldoc-1.8.24. Normal html tags using <tag> syntax do not work however.

-- WadeTurland - 15 Jun 2005

Wade, there's a hex on me or something, this isn't the first time this sort of thing has happened: I messed around with © and got the ascii characters ©. Now I put it in and it works (on the title page). Anyway, it's working now. Grr, argh.

-- MarcusLeonard - 18 Jun 2005

Cool Marcus.

Version 0.5 zip which redirects to 'oops' pages for errors is available on the GenPDFAddOn page. Unfortunately it includes my vim swap file of the GenPDF.pm module so you can delete the file lib/TWiki/Contrib/.GenPDF.pm.swp

As a reminder to myself and anyone packaging the add-on, the command to use is

twikiplugins/GenPDFAddOn$ cvs -d:ext:username@cvs.sf.net:/cvsroot/twikiplugins commit
twikiplugins/GenPDFAddOn$ zip GenPDFAddOn.zip `find . -type f | egrep -v 'CVS|.swp$|.zip$' `

-- WadeTurland - 18 Jun 2005

Wade, thanks for the updates. I wish I had more time to work on this myself, but my paying job is taking most of my time right now. I'm glad someone is picking this up and running with it.

A while back, I was sent an interesting update from someone via email that added the capability to output a single PDF document for an entire web (as opposed to just a single twiki page). I haven't had a chance to even play with it or fold it in, so I don't know how well it works. Anyway, I'll send it to you (since you seem to have more time for this than I do smile ), and you can incorporate it if you think it makes sense.

Anyway, thanks again for taking this over and keeping it going.

-- BrianSpinar - 23 Jun 2005

I didn't see much point in creating a PDF of everything in the web - surely you don't want to include User pages and things like TopicClassification topics. Also his patch simply duplicated the functionality of viewPDF() and genpdf.

Instead, I made it build a tree of descendents of the base topic, thereby including only those topics relevant to the base. This is not an easy thing to do and I don't know how well it will work with webs that have thousands of topics as it is quite an expensive operation. I tried to make it as efficient as possible by following the same methodology as TWiki::Search using $TWiki::fgrepCmd. Anyway, enjoy version 0.6 from the main plugin page.

-- WadeTurland - 28 Jun 2005

Based on feedback from the guys at work, I have implemented internal linking for topics that are included inside a PDF. This makes the document more portable; rather than going out to the twiki server all the time, you can jump through hyperlinks to other topics in the same document (common sense, really!).

Enjoy version 0.8 with internal linking. Version 0.7 was just a reorg of some code with minor bugfixes.

-- WadeTurland - 30 Jun 2005

I just upgraded to the 30 Jun, 2005 version and noticed a couple of small problems:

  • the ../lib/TWiki/Contrib/GenPDF.pm script defines the local variable text as undefined in the function createTitleFile, but then tries to append to it on line 214. I changed line 205 from:
          my $text = undef;
       
    to
          my $text = '';
       
    which fixed the problem.
  • there's now a header on each page (after the first) that is impossibly long. With the previous version I had, there was no header at all, which was just fine. How do I disable this header?
Thanks!

-- SteveWampler - 01 Jul 2005

Thanks, Steve. Duly noted and updated to CVS for the next release. My logs don't have any complaints about it so I'm not sure it warrants a new release. Perl will just spit a warning IIRC.

Headers are configured in the topic you chose in your HEADERTOPIC preference. I'm guessing you are seeing the effect of full rendering after the expanding common variables. Full rendering of headers/footers was introduced in v0.4. You may need to revisit the included GenPDFExampleHeaderFooter topic to find the right variable.

-- WadeTurland - 02 Jul 2005

Had a few problems getting this running on my Windows Dev box with Cygwin. Had to change the output locations on lines 246, 557 and 570 of GenPDF.pm to be windows pathnames (c:/tmp) as it wasn't liking the /tmp. Now it won't pick up my topics that have parents. In the log I get "0 files have parent topics" however if I view my topics (raw=debug) I have %META:TOPICPARENT{name="SOMETOPIC"}%

Can anyone think why these aren't being picked up?

Thanks,

Damian. -- DamianHarvey - 20 Jul 2005

The use of some config variables are not updated to use CVS code of twiki, right? I had to add these:

$TWiki::dataDir = '/my/path/to/twiki/data';

$TWiki::fgrepCmd = '/bin/fgrep';

even thou both fgrep and dataDir is defined in $cfg{}

Then I added a "sort" to the loop over including sub-topics at GenPDF.pm:

547: for $topic (sort @topics) {

What would be a better way of beeing able to order the topics included, a GGENPDFADDON_TOPICORDER in every topic?

And then I have not been able to make the TOC appear after the titlepage, I've tried both c1, p1 and toc as arg to --firstpage but no change thou, TOC is always first, htmldoc problem?

-- HenrikAndreasson - 22 Jul 2005

Damian, I'll look tomorrow. At first glance it looks like a Cygwin setup problem.

Henrik, if there is a TOC, then yes - your PDF viewer should always display the TOC as the first page. We push the arguments "--firstpage", "toc" onto @htmldocArgs when there is a TOC. If there is no TOC, then the first page displayed should be the first page of topic text. The titlepage should always be the first page in the PDF doc though, otherwise blame htmldoc.

The descendant topics are already sorted alphabetically. At each parent, we sort the children first before pushing them onto the @$topics reference at line 532. Sorting them again later will just break any logical connection between the ideas of a child topic and the ideas of its grandchildren etc. Believe me, when you have a tree of 150 topics 6 levels deep where the first level are completely unrelated topics, you want the ideas to be "collected" by topic content rather than sorted by topic name.

-- WadeTurland - 27 Jul 2005

Oh, and I haven't even looked at TWiki (Dakar) in CVS yet.

-- WadeTurland - 27 Jul 2005

Using htmldoc 1.8.24 we are getting the following errors. ERR011: Unable to parse HTML element on line X This means that no images are displayed in pdf generated pages. Has abyone else seen this? We are using Version 0.2 because of the File::Temp incompatibility.

-- PeterJones - 10 Aug 2005

With version 1.8.23 of htmldoc the error is not there. However all images (gif,jpeg etc) are not rendered by htmldoc. I dont think that this is a problem with this Addon as I cant even get the images to render when running htmldoc from the command line. Can anyone suggest how to make the images visible.

-- PeterJones - 10 Aug 2005

This is an awesome plugin it makes so much sense in collaborative documentation... I think I've got something that might help others and a couple of questions... Sorry for the length of the posting

I'm starting to use the GenPDFAddOn as a documentation tool at my company. I found the way it searched the hierarchy and pulled back referenced pages in alphabetical order as counterintuitive. I was expecting the hierarchical search to actually observe the order in which I'd added documents to a "book" document and not use an alphabetical sort instead. I see some sense in this design, but rather than constraining the users, I think I've developed a workaround.

Basically you have one book page with bullet points of each of the subdocuments in the order that you want them in the final document. You then use a macro to "self-include" these files. With the PDFSTART/PDFSTOP tags surrounding only the included documents you only print what you want. You also have quick access to each of the subdocuments by using the bullet list at the top. Sorry for the length of the example here, but I think this helps get the point across (Note: I'm using the GluePlugin syntax to the format).

---+ Example Specification

The following bullets are links to pages which are included automatically.
   * ExampleSpecIntro
   * ExampleSpecOverview
   * ExampleSpecDigital
   * ExampleSpecAnalog

%TOC%

<!-- PDFSTART -->
%SEARCH{ ".*   \* ExampleSpec.*" topic="%TOPIC%" scope="text" type="regex" multiple="on"
~~~ nototal="on" nosearch="on" noheader="on" 
~~~ format="$percntINCLUDE{\"$pattern(.*   \* (ExampleSpec[A-Za-z0-9]*).*)\"}$nop%" }%
<!-- PDFSTOP -->

BTW, this is the first SEARCH macro I've done, so I don't pretend that it is optimum, or completely correct!!!

Finally, I'm getting resistance to TWiki as a documentation tool on two fronts. Does anybody have any additional thoughts on these?

  1. Support for VISIO or any other Vector Image Format (i.e. SVG) into PDF (and ultimately a printed copy)
    • This (I know) is a limitation of htmldoc, and not directly this plugin.
    • I can see that a higher resolution raster scan might be a workaround for this, but I haven't investigated this yet.
    • Another option might be to use XML-FO and FOP to get me there, but this doesn't look pretty.
      (e.g. WikiML -> HTML -> XML-FO -> PDF?)
  2. Change Bars in a new revision of a document.
    • On a new release of a document only highlight the changes.
    • My include method above means that I do not have a single page within TWiki to run the diff program on (or a mechanism to get this to PDF)
-- SteveHobbs - 18 Aug 2005

Cool, Steve - that should solve HenrikAndreasson's problem too.

-- WadeTurland - 11 Nov 2005

Brian, I want to commend you on a great addition to TWiki. It works great and I can see a lot of possibilities but I have an issue than I hope you can help me with.

I have a TWiki application that uses includes that reference form fields in topics, and based on the formfields, dynamically displays information in the topic. I use the

%BASETOPIC%

variable to accomplish this, along with the FormQueryPlugin module to do the searches.

When I'm in a topic like I described above, I have absolutely no problem generating the PDF. It renders beautifully, and all the info the formfields and searches reference are properly displayed.

The issue is when I try to use the pdfrecursive=on option. The parent topic is fine, but all the children that have these includes don't render properly because the formfield data does not seem to be in topic when it gets read. I tried picking through the code to see how you do recursive PDFs and I suspect it may have to do with how the _getRenderView function is constructed.

Please let me know if there is something I can do to fix this problem.

-- CharlesJohnson - 19 Aug 2005

Never mind about the above issue. I found that if I use %#INCLUDINGTOPIC% instead of %#BASETOPIC% in my included topic, everything renders as it should.

-- CharlesJohnson - 23 Aug 2005

Concerning image problems (no images rendered in PDF file) with htmldoc. I found that my webserver runs over SSL and that my htmldoc version was not compiled using SSL. My problem was fixed after recompiling with openssl enabled

-- PeterJones - 25 Aug 2005

Interesting script. It took a while to get running on my twiki, in part because I ran into authentication problems for attached images. So, here is a patch for those interested.

With use strict;, perl will complain (many times) about adding strings to an undefined variable. This change removes that error:

205c205
<    my $text = undef;
---
>    my $text = "";

Here was the source of my 'images not being included' problem. The GenPDFAddOn requalifies all img tags to the full URL. I think using the hard disk path is better.

239,240c239,241
<    # fully qualify any unqualified URLs (to make it portable to another host)
<    my $url = TWiki::Func::getUrlHost();
---
>    my $url;
>    $url = TWiki::Func::getPubDir();
>    $url =~ s/$TWiki::pubUrlPath//;
241a243,245
>
>    # and fully qualify any unqualified URLs (to make it portable to another h ost)
>    $url = TWiki::Func::getUrlHost();
348c352,355
<    my $url = TWiki::Func::getUrlHost();
---
>
>    my $url;
>    $url = TWiki::Func::getPubDir();
>    $url =~ s/$TWiki::pubUrlPath//;
349a357,358
>
>    $url = TWiki::Func::getUrlHost();

Finally, with these two changes the served file will have a reasonable extension (as opposed to no extension now).

629c638
<       print $query->header( -TYPE => "application/pdf" );
---
>       print $query->header( -TYPE => "application/pdf", -attachment=>"$topic.pdf" );
632c641
<       print $query->header( -TYPE => "application/postscript" );
---
>       print $query->header( -TYPE => "application/postscript", -attachment=>"$topic.ps" );

-- ScottHoge - 31 Aug 2005

Yay - thanks Scott for those fixes, that image thing has been causing trouble.

For GenPDFAddOn topic: I had trouble with bin/view because of a typo issue in the installation instructions. Maybe change the page text from
ALERT! Add the variable $htmldocCmd = /path/to/htmldoc; to your lib/TWiki.cfg file so TWiki can find the location of the htmldoc executable. Look for $fgrepCmd.
to
ALERT! Add the variable $htmldocCmd = "/path/to/htmldoc"; to your lib/TWiki.cfg file so TWiki can find the location of the htmldoc executable. Look for $fgrepCmd.

-- MarcusLeonard - 04 Sep 2005

Absolutely brill ... excellent idea, and solid implementation! One minor issue I encountered with version 0.8: when generating a PDF document without a title topic, I noticed lots and lots of Perl warning messages in my Apache error logs, along the lines of:

genpdf: Use of uninitialized value in pattern match (m//) at ... 
genpdf: Use of uninitialized value in substitution (s///) at ... 

Eventhough this wasn't causing any noticable problems (ie. the PDF document was generated without a hitch), I didn't want these error messages to fill up my disk - approx. 400 of these messages for a single PDF document!

It looks like the offending code was in:

    GenPDF.pm::_createTitleFile()

And the following patch seems to fix the issue (caveat emptor, as usual)


212a213,216
>
>    # Main.PeterVandenberk - only process if we have $text...
>    if ($text) {
>
243a248,249
>    }
>
248c254
<    print $fh $text;
---
>    print $fh $text if $text;

(in hindsight, I should probably have tried this patch first)

-- PeterVandenberk - 08 Sep 2005

This is a great utility, which is proving useful in formal reviews of topics.

I would like to link the script to the revision of a topic so that I could produce PDFs for previous revisions. If anyone could give me some pointers that would be much appreciated.

So far in my investigations, I've noticed that on line 96 of GenPDF.pm the function readTopictext is used with the web and topic passed as arguments. Would it be sufficient to also pass the revision to this function? How would I go about doing that?

-- ChrisSBrown - 14 Sep 2005

I've noticed that htmldoc 1.8.24 is buggy. When it tries to render tables, such as the SiteMap, it often coredumps or fails to generate pdf. It seems to be something to do with table widths and page breaks -- but I haven't investigated hugely. See http://htmldoc.org/str.php?L33+P0+S0+C0+I0+E0+Qsegmentation

Is this the crash mentioned in Known Bugs on the GenPDFAddOn page?

Anyway, htmldoc 1.8.23 seems to behave properly. For now.

-- MagnusLewisSmith - 23 Sep 2005

htmldoc 1.9 doesn't work at all. It coredumps on htmldoc --help

-- MagnusLewisSmith - 23 Sep 2005

I'm not getting images in my PDF, either. I have SSL on my server. I confirmed that my HTMLDOC was compiled with SSL enabled (I'm using Gentoo and that flag was set). I even went back to HTMLDOC 1.8.23 instead of 1.8.24 -- both versions still do not produce images.

I went and looked at the temporary HTML file that's generated by GenPDF and the tags have proper src values. I punched them into my browser, and it pulled up the image, complete with the "https."

I don't know why I'm not getting images.

-- LukeLackrone - 04 Oct 2005

OK. I tried the Scott patch before and it didn't change anything, but now it's working. I'll attribute that to my error :).

So, thanks, Scott!

-- LukeLackrone - 04 Oct 2005

PDF INCOMPLETE

I have installed the last versions of HTMLDOC and GENPDFADDOn. Works fine from Windows and Linux browser.... BUT the end of the long documents are missing. e.g. http://acpp.in2p3.fr/cgi-bin/twiki/bin/view/TWiki/TWikiPreferences

I had to put a warning on the PDF button: please ckeck the PDF.. the last lines are missing .... I have tried many heuristics ... I have forced "PDF START" and "PDF STOP", but got no improvment....

This ADDon is quite important for developing common projects .... !!! I am looking forward for the development of MS-Word or/and Latex converters ... very important for scientific paper writing ...

-- DenisPerretGallix - 28 Oct 2005

Denis,

in regards to the latex converter, take a look at GenPDFLatexAddOn. It is a bit incomplete, but feedback is welcome.

-- ScottHoge - 31 Oct 2005

Scott,

Yes I waiting for the system manager to install the latex suite...

DenisPerretGallix - 03 Nov 2005

Wow, it has been a while since I looked at this page. Nice to see some positive response, thankyou. GenPDFLatexAddOn also looks promising.

ScottHoge posted 3 patches a few months ago.

  1. Changing the undef was already in CVS but I didn't think it worthy of a new zip file - looks like I was wrong.
  2. Unqualified URLs - The reason I made it a URL instead of a file path was so that if people have a livery(3) in a different <Location> or through rewritten, redirected or CGI generated links, htmldoc should still be able to find the images. I think that should be left open for discussion.
  3. Attachment names - brilliant idea. It's going straight into CVS (after I work out if it's CVS or subversion now)
I also need to do a demo PDF showing what it's capable of.

-- WadeTurland - 11 Nov 2005

Please ReadmeFirst, we switched from CVS to SVN.

-- PeterThoeny - 12 Nov 2005

problem with the PDF

I am having a strange issue, I attach an example... Basically it seems like starting on page 3 of every document I generate the header is messed up . If the document has only two pages everything is fine. Starting on page 3 then the header get cloberred with what look like the start of the topic on a single line...

  • GenPDFAddOn-10: example of a messed-up header pdf (starting on page 3)
Also this problem seens to appear only when the pdf is generated from a linux client, the pdf is normal when genrated from a Windows client (IE)...

-- IgorCastang - 22 Nov 2005

I have an issue where documents that are rolled up with pdfrecursive=on are not rendered in a tree fashion. The main page states that subdocuments, children, grandchildren, great grandchildren, will be displayed in a tree fashion in the table of contents. This does not occur in my installation. All topics are generated but they are all at the same level.

-- CharlesJohnson - 02 Dec 2005

What I mean is if you create the topics hierarchically, then GenPDFAddOn will pull a sub-tree of topics into the PDF. It won't build a hierarchical TOC because each TWiki topic becomes a new chapter in the PDF.

-- WadeTurland - 12 Jan 2006

Anyone got the plugin working on the Dakar beta? Wondering what and where you put the $htmlDocCmd

-- NathanReeves - 08 Dec 2005

I'm having the same problem as DenisPerretGallix. Is this happening to anyone else? I find that if I turn off the unlinking of the temp files and run the htmldoc command myself, it works! What could be causing htmldoc to bail out before processing the entire HTML? We're using 20040901 with Perl 5.6.1 and Apache 2 on Solaris 8.

-- StevenLumos - 22 Dec 2005

Very strange. I spent days trying to work it out but never got anywhere. The best I could come up with is that it may be a Solaris-specific problem. Have you tried compiling your own htmldoc package without any shared libs?

-- WadeTurland - 12 Jan 2006

Wade, just installed this addon and a couple of comments:

  1. Yes, the perl warnings regarding undefined/uninit'd variables is a big thing as they will fill up the error log. Interestingly, just adding the preference variables to TWikiPreferences eliminated most. I would suggest supplying default values for all options - or perhaps the patch to set $text to " " is enough?
  2. After fixing the above, genpdf returns uninitialized value in TWiki.pm starting at line 2995 (Cairo, 02 Sep 2004 Rev 1742). Strangely, this is the area where internal tags are handled in $_[0] (ie., $text).
  3. Using the -T option on the Perl commandline, the line 516 - chdir($cwd); is considered to be "insecure" (sic) {when will the tech industry realize that the correct term is "unsecure" as aweful as that sounds?}. I suppose this needs to be untainted somehow.
Other than these, GenPDFAddOn is working well under Solaris 2.9 and Perl 5.8.7. BTW, your perl switches as defined are wI and 5.8.7 does not like "I".

-- SteveRJones - 25 Jan 2006

Definitely changing:

sub _createTitleFile {    my ($webName) = @_;  #   Perl chokes on undefined vars when using 'strict'; #   my $text = undef; # Init the var to the empty string;    my $text = " "; 

. . has removed all complaints.

-- SteveRJones - 26 Jan 2006

I am very impressed with this plugin, it works beautifully. One thing I did notice was the unreasonably large size of the PDF files (200-300KB, even for very small pages). This is due to htmldoc defaulting to embedding fonts, which is pointless, since the fonts concerned are Times and Helvetica which never need to be embedded. The following change at line 606 of GenPDF.pm changes the default to not embed, reducing PDF sizes to the 5-10KB I would have expected:

   push @htmldocArgs, "--no-embedfonts" unless $prefs{'embedfonts'}; 

-- TobyThain - 28 Jan 2006

I was wondering if there was a way to insert text above the "Table of Contents" that is auto generated? I read through the doc and FAQs but dont see anything there that jumps out at me and says this is the option... Of course I also have not figured out how to use the TwikiPreferences yet... Anyone got something I can look at to figure the whole thing out or.... ?

-- PatRiehecky - 28 Jan 2006

Instead of making perm changes to the code for the embedded fonts, why not make this configurable through "preferences"? this addon is labeled "feel free to modify".

-- SteveRJones - 29 Jan 2006

I'm having problems getting the GenPDFAddOn to work with the TocPlugin. I have each section of a large document in a separate topic, each of which is listed in a WebOrder special topic (to make TocPlugin work), and each of which is a child topic (to make GenPDFAddOn work with the recursive option). When I browse the document directly from TWiki, all the section numbering is perfect. However, when I generate the PDF version, the numbering of each 0-level (%SECTION0%) section gets reset, so that every section in the document is numbered 1.x.x.

Is this a documented incompatibility? Is there any workaround?

-- DomLayfield - 06 Feb 2006

The "pdfrecursive" option doesn't work under Dakar. Are there any plans to fix this to work under Dakar?

-- CharlesJohnson - 06 Feb 2006

Had some problems with images, and tried the patches suggested on this page, but without success. Finally tracked the problem down to the fact that I access our Wiki through a SSH tunnel. So, instead of using a URL like http://myserver/twiki, I use http://localhost:8080/twiki, which tunnels the traffic from port 8080 on my local machine, to pop out on port 80 on the server.

When the GenPDFAddOn dumps a local, temporary html version of the topic, it uses the same URL used to access the Wiki page remotely. i.e. all the images are referenced with <img src="http://localhost:8080/path/to/image">. Of course, this URL is totally broken from inside the server, so none of my images appear.

Fixed the problem by adding some lines to GenPDF.pm to chop out the portnumber. However, this is not a pretty solution. Seems like it would be much nicer to convert the URLs into a direct path to the image.

-- DomLayfield - 07 Feb 2006

More bugs... It seems that Wiki (or perhaps the LatexModePlugin specifies table widths as e.g. width="%100", which htmldoc doesn't understand and ignores. As a consequence, figure captions have the same width as the figure itself, which looks very silly with a narrow figure.

Workaround is to switch the % to the end in GenPDF.pm. I added the following at line 357 (in sub _fixHtml)

   # Workaround for bug in htmldoc, which doesn't understand width="%100".
   # Convert this to "100%" instead.
   $html =~ s/width="%([0-9]*)"/width="\1%"/sgi;

  • Sigh. The width="%100" field is/was a bug in the LatexModePlugin. (at some point, the code switched from printf("...width=%d...",...) to printf("...width=%100", ... ). Sorry for the inconvenience, the fix will carry through after R2.4. -- SH
-- DomLayfield - 07 Feb 2006

Question about the 'pdfrecursive' feature. I love this! It means I can generate a single document from a hierarchy of topics without having to refactor them all into a single megatopic.

Expressing this connection between topics using the TWiki parent/child relationship seems much more natural than the TocPlugin approach of having a separate WebOrder topic.

However, one of the problems that I'm experiencing is that there doesn't seem to be any way to explictly set the ordering of the children. For example, in my document, I have a Title/TOC page that has three child topics (effectively chapters 1, 2 , 3). But because of the names of my topics,in the PDF version I get parent->chap1->chap3->chap2. It appears that the order is an alphabetic sorting of the topic names, so in order to get 3rd chapter last, I renamed the topic with a 'Z' in front. But now chapter 3 looks silly because that page has a "Zchap3name" title and footer. I assume that I can set some option to suppress or override the title, but it seems that I really shouldn't have to do so.

Is there another way to control the ordering of sub-topics?

-- DomLayfield - 08 Feb 2006

Great great addon!

In our TWiki, many topics have PDF attachments. Is it possible to modify this addon so that the PDF attachments get added to the topic PDF?

-- NicholasSushkin - 23 Feb 2006

Installed and tested successfully on TWiki 4.0.1 Dakar (RH ES 3.0 Linux/Apache 1.3.34/mod_perl 1.29), using htmldoc 1.8.25.

The one manual change I made to get TWiki to locate htmldoc was in GenPDF.pm, instead of TWiki.cfg as the Install instructions specify since that was probably for pre-Dakar installs.

375 # $TWiki::htmldocCmd must be set in TWiki.cfg
377   $TWiki::htmldocCmd = '/usr/bin/htmldoc';

I suppose I could have set this in LocalSite.cfg, but did not try (risk) that ;-).

-- KalDe - 24 Mar 2006

Was anybody able to get recursive reature working in Dakar?

-- StefanFritz - 27 Mar 2006

-- StefanFritz - 28 Mar 2006

Got a patch from WadeTurland.(GenPDF _pm-twiki-dakar.patch) Now recursive feature work sagain in Dakar!

-- StefanFritz - 28 Mar 2006

I just uploaded a fresh patched release, suitable for use with TWiki-4 (and should still work on Cairo, though I didn't test).

-- CrawfordCurrie - 05 Apr 2006

Thanks for trying to keep this useful Plugin compatible with Cairo, is very much appreciated on behalf of all the wikis at the workplace still using Cairo! smile

Minor details / small suggestion on Change History: It is my understanding that this is generated from SVN. It would be helpful to get a timestamp, e.g. to see when each item was introduced.

-- PeterThoeny - 06 Apr 2006

Hello,

this plugin is really wonderful, nevertheless I have a problem with configuring it. All PDF´s are generated correctly, but the script seems to ignore any preferences I set. I put all preferences variables in the right topics and even tried to set the preferences in the URL. It´s always the same, the PDF is generated, any preferences are ignored. When I adjust the source code in the GenPDF.pm (for example to always set toclevels=0) it works correctly. I´m not what you´d call a perl expert, but it seems that the script doesn´t fill the $prefs variable correctly. Has anyone had the same problem or got an idea how to fix this problem?

-- SaschaHinlang - 19 Apr 2006

Hi there,

I just installed the GenPDFAddOn, on TWiki 4.0.2, with htmldoc 1.8.26, all on a RH Enterprise... Works fine, except I can not get the images to get included. I tried applying the GenPDF _pm-twiki-dakar.patch, but it seems it is allready applied in the script version I just got. Any ideas ? thanks

-- IgorNikolic - 08 May 2006

Ok, so it seem there is a problem with htmldoc. : http://htmldoc.org/str.php?L117+P0+S0+C0+I0+E0+Qimages

Any ideas how to circumvent this problem ?

-- IgorNikolic - 08 May 2006

Just a point-out regarding an installation issue I ran into. I was getting a Browser error - premature end of headers. With no apparent errors logged. It turns out that bin/genpdf is installed by default as group writable. Apache su_exec functionality will not run anything that is writable by any other userid. chmod 755 bin/genpdf resolved the issue.

-- GeorgeClark - 13 May 2006

Hi Wade, Crawford, et al.,

I would have to agree with PeterVandenberk that this add-on is brill. Like IgorNikolic, my only issue was with including images. ScottHoge provided a decent solution--convert all img src URLs to file-system paths. Wade had a very good reason to leave this approach for debate--that essentially a URL is a more flexible means of locating the resource. However, if the resource is on a highly secured (authenticated) server, then htmldoc cannot access the URL. So I thought I would build on Scott's idea, but make it configurable so that the decision is up to the TWiki admin. Here are my code diffs with comments. Note that I added some other preferences such as pdfpath and pdfheadfootsize, which improved the usability of this:

diff -r GenPDFAddOn.20060406/lib/TWiki/Contrib/GenPDF.pm GenPDFAddOn.rjw-20060518/lib/TWiki/Contrib/GenPDF.pm

The first two changes here implement a new preference, pdflocalimgsonly, that if set to true, replaces the relative URL of an img tag with an absolute path in the file system.

251d250
<    $text =~ s/<img(.*?) src="\//<img$1 src="$url\//sgi;
252a252,260
>    if ($prefs{localimgsonly})
>    {
>        my $path = TWiki::Func::getPubDir();
>        $text =~ s/<img(.*?) src="(https?:\/)?.*?\/pub\//<img$1 src="$path\//sgi;
>    }
>    else
>    {
>        $text =~ s/<img(.*?) src="\//<img$1 src="$url\//sgi;
>    }
359d367
<    $html =~ s/<img(.*?) src="\//<img$1 src="$url\//sgi;
360a369,377
>    if ($prefs{localimgsonly})
>    {
>        my $path = TWiki::Func::getPubDir();
>        $html =~ s/<img(.*?) src="(https?:\/)?.*?\/pub\//<img$1 src="$path\//sgi;
>    }
>    else
>    {
>        $html =~ s/<img(.*?) src="\//<img$1 src="$url\//sgi;
>    }

The following changes add the pdflocalimgsonly preference (last) as well as the other two additional preferences that I found useful, pdfpath and pdfheadfootsize

393a411,413
>    $prefs{'path'} = $query->param('pdfpath') || TWiki::Func::getPreferencesValue("GENPDFADDON_PATH");
>    $prefs{'path'} = '' unless defined $prefs{'path'};
>    $prefs{'path'} =~ s/,/;/go;
422a443,444
>    $prefs{'headfootsize'} = $query->param('pdfheadfootsize') || TWiki::Func::getPreferencesValue("GENPDFADDON_HEADFOOTSIZE") || '';
>    $prefs{'headfootsize'} = undef unless ($prefs{'headfootsize'} =~ /^\d+$/);
435a458
>    $prefs{'localimgsonly'} = $query->param('pdflocalimgsonly') || TWiki::Func::getPreferencesValue("GENPDFADDON_LOCALIMGSONLY") || '';
624a648
>    push @htmldocArgs, "--path", "\"$prefs{'path'}\"" if $prefs{'path'};
627a652
>    push @htmldocArgs, "--headfootsize", "$prefs{'headfootsize'}" if $prefs{'headfootsize'};

One other thing I thought I would contribute here, is a change to the view.pattern.tmpl template that adds a PDF button to the page tools.

Create the following template definition:

%TMPL:DEF{"genpdf"}%<a href="%SCRIPTURLPATH%/script/genpdf%SCRIPTSUFFIX%/%WEB%/%TOPIC%?pdfpath=/usr/local/apache/twiki%ATTACHURLPATH%%REVARG%" title="%MAKETEXT{"PDF version of this topic"}%" rel="nofollow">%MAKETEXT{"PDF"}%</a>%TMPL:END%

Then add the following to the toolbar_buttons template definition:

<span class="patternButton">%TMPL:P{"genpdf"}%</span>

Thanks again for the useful add-on!

-- RobertWhelton - 19 May 2006

Hey, thanks RobertWhelton, I will try your patches, and report on the results here !

Note on the Button ( BTW, thanks a LOT for that, I was wondering how to do that for a while...)

If you are not Perl hacker, like me, note that you cant copy-paste the template deffinition as it is. It introduces line breaks that mess up the button. Make sure it is a continuous line in the view.pattern.tmpl file.

Also note that the url href="/cgi-bin/script/genpdf/Plugins/% in my case needed to be href="/cgi-bin/genpdf/Plugins/% My stock install of TWiki 4.02 does not need the /script/ directory.

First patch. Applies wthout problem. Added

    • Set GENPDFADDON_LOCALIMGSONLY = TRUE
to TWikiPreferences. Still no images.

Second patch. Applies wthout problem. Try to make pdf, addon dies a horrible death :

[Fri May 19 12:46:08 2006] [error] [client x ][Fri May 19 12:46:08 2006] GenPDF.pm: Useless use of a constant in void context at /home/httpd/twiki/lib/TWiki/Contrib/GenPDF.pm line 632.
[Fri May 19 12:46:08 2006] [error] [client x ][Fri May 19 12:46:08 2006] GenPDF.pm: Useless use of string in void context at /home/httpd/twiki/lib/TWiki/Contrib/GenPDF.pm ]line 632.
[Fri May 19 12:46:08 2006] [error] [client x ][Fri May 19 12:46:08 2006] GenPDF.pm: Useless use of a constant in void context at /home/httpd/twiki/lib/TWiki/Contrib/GenPDF.pm ]line 632.
[Fri May 19 12:46:08 2006] [error] [client x ][Fri May 19 12:46:08 2006] GenPDF.pm: Useless use of string in void context at /home/httpd/twiki/lib/TWiki/Contrib/GenPDF.pm line 632.
[Fri May 19 12:46:08 2006] [error] [client x ][Fri May 19 12:46:08 2006] GenPDF.pm: Useless use of a constant in void context at /home/httpd/twiki/lib/TWiki/Contrib/GenPDF.pm line 632.
[Fri May 19 12:46:08 2006] [error] [client x ][Fri May 19 12:46:08 2006] GenPDF.pm: Useless use of string in void context at /home/httpd/twiki/lib/TWiki/Contrib/GenPDF.pm line 632.
[Fri May 19 12:46:08 2006] [error] [client x ]Calling htmldoc with args: --toclevels 5 --tocheader ... --tocfooter ..i --firstpage toc /tmp/GenPDFAddOnD4CrL3v9iC.html
[Fri May 19 12:46:08 2006] [error] [client x] malformed header from script. Bad header=<HTML>: genpdf

Any ideas what is going on ? I backed the second patch out, and things work ok, but still no images.

I also tried adapting the PDF url to :

%TMPL:DEF{"genpdf"}%<a href="%SCRIPTURLPATH%/genpdf%SCRIPTSUFFIX%/%WEB%/%TOPIC%?pdfpath=%GENPDFADDON_PATH%%REVARG%?pdflocalimgsonly=%GENPDFADDON_LOCALIMGSONLY%" title="%MAKETEXT{"Make a PDF frm this toppic"}%" rel="nofollow">%MAKETEXT{"PDF"}%</a>%TMPL:END%

But it does not seem to work. All of this without the second patch.

-- IgorNikolic - 19 May 2006

Hi Igor,

Thanks for the feeback on my feedback. In response...

I changed my previous entry so that the template definition does not contain line breaks.

I created the script subdirectory so that I could define a .htaccess that did not use mod_perl, as I was having problems the with mod_perl.

I have my setting the same as you for the GENPDFADDON_LOCALIMGSONLY, but I have no problems. I am attaching my complete diff from the GenPDFAddOn.tgz 20060406 version so that this can be applied in it's entirity without confusion.

There are some things that I have added since yesterday's post:
  1. I added a pdfdebug (GENPDFADDON_DEBUG) preference that causes the temp files to persist after the script runs for inspection.
  2. I made the topic as it is placed in the H1 header "pretty" (I separated the BumpyWord).
-- RobertWhelton - 19 May 2006

P.S. I am not using the pdfpath preference. I could not get it to work for htmldoc, so my code inserts the absolute path (from the filesystem "/" directory). Make sure your filesystem absolute path matches up correctly and that your configuration has the correct PubUrlPath and PubDir.

-- RobertWhelton - 19 May 2006

Fantastic ! This solved the problem. I guess that I had a slightly older version of the Add on, that messed up a few things. Thank you so very much !

-- IgorNikolic - 19 May 2006

Hi again!

One more thing that I found was that IE needs to know that the Content-Disposition is "attachement". Also, the slashes in hierarchical web names need to be converted to something like dashes for this heading.

I have updated my diff to include these fixes.

-- RobertWhelton - 19 May 2006

What a nice AddOn! Super.

I'm wondering if there's a possibility of pretty-fying TWiki tables. The tables produced by ActionTrackerPlugin are nog so readable when one of the cells has a lot of content.

Also, i'm wondering if it's possible to render the table cells borders?

-- JosMaccabiani - 21 May 2006

I find this in my error.log, perhaps it'll be of use for further deelopment (the plugin works fine):

genpdf: Use of uninitialized value in string ne at (eval 103) line 31.

-- JosMaccabiani - 24 May 2006

I have problems using this addon together with SpeedyCGI: Without SpeedyCGI, everything works fine. With SpeedyCGI, I always get the same PDF document (the first one I created), no matter which PDF I want to generate.

Not sure if this is somehow related, but I find the following error in the Apache error.log (with and without SpeedyCGI):

[Tue Jul 18 11:04:16 2006] [error] [client x.x.x.x] Calling htmldoc with args: --book --quiet --links --linkstyle plain --outfile /tmp/GenPDFAddOn0hdMaPypbz.pdf --format pdf14 --portrait --size a4 --browserwidth 860 --titlefile /tmp/GenPDFAddOnjtxiD00C6A.html --toclevels 5 --tocheader ... --tocfooter ..i --firstpage toc /tmp/GenPDFAddOnfKeWrzG97L.html

This is htmldoc 1.8.26 on Red Hat Enterprise Linux 4, SpeedyCGI 2.22, Apache 2.0.52.

-- MichaelRedinger - 18 Jul 2006

(only answering here because I'm dealing with similar issues on other extensions)

A quick look at GenPDF.pm shows that the CGI query is declared as a global. So, it probably never gets re-initialized on subsequent calls.

If you are running TWiki 4.x.x, the fix is likely simple. The fix for earlier versions of TWiki may be more complicated.

-- ScottHoge - 18 Jul 2006

I noticed something strange after I installed, wasn't sure if this was a common experience. The GendPDFAddOn doesn't show up in TWiki/TWikiPlugins or TWiki/InsalledPlugins.

I am using TWiki 4 and don't even see it when I goto configure to enable it. Thanks for any info.

-- EricHanson - 08 Aug 2006

Only Plugins show up in the installed Plugins list, not add-ons.

-- PeterThoeny - 08 Aug 2006

TWiki in combination with the GenPDFAddOn is an amazing tool! Our company is using TWiki as an internal documentation platform. Now that we have GenPDFAddOn installed and configured, we are seriously considering moving our entire software users manual from RoboHelp (a Win app) to TWiki and then generate a PDF file.

I have configured genPDF to use a header topic and title topic. This works great, except for the REVINFO variable. It shows the revision info of the footer/title topic, while I want to see the revision info of the topic that I'm generating a pdf of.

Is this a bug? Or have I done something wrong?

-- GerhardZielinski - 20 Sep 2006

I have the April 2006 version of the plugin installed. If I set the GENPDFADDON_TOCLEVELS to 0 to disable the TOC, it has no effect and the TOC appears with the default levels. If I set GENPDFADDON_TOCLEVELS to 1 or 2, the variable is used and it limits the TOC to the appropriate level. I am running this on TWiki-4.0.4-3, Wed, 06 Jul 2006, build 10807 on the server. Thoughts as to what is wrong? Thanks!

-- RickMach - 20 Sep 2006

I have found the problem with TOCLEVELS and will post a patch shortly.

-- RickMach - 28 Sep 2006

Gerhard, the trick is to use the more complex

<!-- FOOTER LEFT "%REVINFO{"r1.$rev ­ $date ­ $wikiusername" web="%WEB%" topic="%BASETOPIC%"}%" -->

instead of simply %REVINFO% which only works for the topic which is currently being rendered or "focussed" in the render engine.

Also, there are some things you should be aware of before making the decision to ditch RoboHelp, mainly htmldoc's limitations. Eg.

  • HTML 4.x is not supported, therefore limited character set
  • images and tables sometimes overflow page boundaries
  • things look much nicer with the SpacedWikiWordPlugin
-- WadeTurland - 05 Oct 2006

I added a SHORTDESCRIPTION to the "Add-On Info" section so that this add-on is represented properly in the AddOnPackage topic and query topics. Please feel free to take this into the next release.

-- PeterThoeny - 07 Oct 2006

I just tried installing this on my host, which involved building htmldoc from scratch, which appeared to work. I get an error on the pdf generation as follows:

Constant name 'HASH(0x86bc7a8)' has invalid characters at /<mywebroot>/twiki/lib/TWiki/Contrib/GenPDF.pm line 388
BEGIN failed--compilation aborted at /<mywebroot>/twiki/lib/TWiki/Contrib/GenPDF.pm line 413.
Compilation failed in require at /<mywebroot>/twiki/bin/genpdf.pl line 41.
BEGIN failed--compilation aborted at /<mywebroot>/twiki/bin/genpdf.pl line 41.

-- BryceSchober - 09 Oct 2006

BTW, I suggest adding a

%SCRIPTSUFFIX%

to your "Try loading this page" link in your instructions.

-- BryceSchober - 09 Oct 2006

I just installed GenPDFAddOn, and I'm happy with it, in general. Two small comments, however:

  1. In the section Usage, the two points: "To make ..." and "You may also ..." are not clear to me. Assuming a generic installation, where exactly should I put the Printable line?
  2. in " Add-On Installation Instructions" section, the link to the test page returns 404 error even though the AddOn is working fine.
Lastly, how can I get the links to be underlined, or blue, in the PDF?

-- YuvalAviel - 07 Dec 2006

Any idea if it is possible to use the GenPDFAddOn along with some other Plugin or Addon to email the resulting PDF file to an address that is input on the page?

-- DuncanKinnear - 07 Dec 2006

FYI, If you need to add a "PDF" button to the menu in TWiki4+ you can do make the following edits to your templates:

viewtopicactionbuttons.pattern.tmpl, add the following:

%TMPL:DEF{"genpdf"}%<a href="%SCRIPTURLPATH{"genpdf"}%/%WEB%/%TOPIC%" title="%MAKETEXT{"PDF version of this topic"}%" accesskey="P" rel="nofollow">%MAKETEXT{"PD&F"}%</a>%TMPL:END%

viewtoolbar.pattern.tmpl, change the following:

%TMPL:P{"activatable_raw_edit"}%%TMPL:P{context="WysiwygPluginEnabled" then="activatable_edit_wysiwyg"}%<span class="patternButton">%TMPL:P{"activatable_attach"}%</span><span class="patternButton">%TMPL:P{"printable"}%</span>  

to:

%TMPL:P{"activatable_raw_edit"}%%TMPL:P{context="WysiwygPluginEnabled" then="activatable_edit_wysiwyg"}%<span class="patternButton">%TMPL:P{"activatable_attach"}%</span><span class="patternButton">%TMPL:P{"genpdf"}%</span><span class="patternButton">%TMPL:P{"printable"}%</span>

view.pattern.tmpl, change the following:

%TMPL:DEF{"topicactionbuttons"}%%TMPL:P{"activatable_raw_edit"}%%TMPL:P{"sep"}%%TMPL:P{context="WysiwygPluginEnabled" then="activatable_edit_wysiwyg"}%%TMPL:P{context="WysiwygPluginEnabled" then="sep"}%%TMPL:P{"activatable_attach"}%%TMPL:P{"sep"}%%TMPL:P{"printable"}%%TMPL:P{"sep"}%%TMPL:P{"raw"}%%TMPL:P{"sep"}%%TMPL:P{"backlinks"}%%TMPL:P{"sep"}%%TMPL:P{"revisions"}%%TMPL:P{"sep"}%%TMPL:P{"activatable_more"}%%TMPL:END%

to:

%TMPL:DEF{"topicactionbuttons"}%%TMPL:P{"activatable_raw_edit"}%%TMPL:P{"sep"}%%TMPL:P{context="WysiwygPluginEnabled" then="activatable_edit_wysiwyg"}%%TMPL:P{context="WysiwygPluginEnabled" then="sep"}%%TMPL:P{"activatable_attach"}%%TMPL:P{"sep"}%%TMPL:P{"genpdf"}%%TMPL:P{"sep"}%%TMPL:P{"printable"}%%TMPL:P{"sep"}%%TMPL:P{"raw"}%%TMPL:P{"sep"}%%TMPL:P{"backlinks"}%%TMPL:P{"sep"}%%TMPL:P{"revisions"}%%TMPL:P{"sep"}%%TMPL:P{"activatable_more"}%%TMPL:END%

-- CharlesJohnson - 10 Jan 2007

I just migrated to Dakar and the current version of GenPDFAddOn and I've noticed a problem with how lists are rendered.

When you have a numbered list or bulleted list, its fine, but when you use letters, even though they render in the topic as A,B,C, etc., once you run it through genpdf, they all become a numbered list. Has anyone else had this problem? I didn't have it under Cairo and GenPDFAddOn

-- CharlesJohnson - 11 Jan 2007

I think I know why the plugin is not able to render lettered lists under TWiki 4. It has to do with the html that is generated and htmldoc's ability to convert it. Here are examples of html generated from Cairo and Dakar and as you can see the formatting is different. Htmldoc can handle the html from Cairo properly, but not the one from Dakar. I even upgraded to htmldoc 1.8.27 (latest stable release) but I have the same results (i.e. lettered lists are rendered as numbered lists):

HTML - Dakar printview rendering:

<OL>
<LI type="A"> Request the media</LI>
<LI type="A"> Assemble at the Recovery Site</LI>
<LI type="A"> Verify server hardware configuration</LI>
<LI type="A"> Verify media availability</LI>
<LI type="A"> Verify network connectivity of the servers</LI>
<LI type="A"> Verify network equipment hardware configuration</LI>
<LI type="A"> Recover server systems from system images</LI>
<LI type="A"> Recover networks from stored configurations</LI>
<LI type="A"> Recover firewall from stored configuration</LI>
<LI type="A"> Recover the TSM server</LI>
<LI type="A"> Build filesystems on recovered systems</LI>
<LI type="A"> Restore filesystems and databases from the TSM server</LI>
<LI type="A"> Test applications</LI>
<LI type="A"> Release systems</LI>
</OL>

HTML - Cairo printview rendering:

<OL type="A">
<LI> Request the media</LI>
<LI> Assemble at the Recovery Site</LI>
<LI> Verify server hardware configuration</LI>
<LI> Verify media availability</LI>
<LI> Verify network connectivity of the servers</LI>
<LI> Verify network equipment hardware configuration</LI>
<LI> Recover server systems from system images</LI>
<LI> Recover networks from stored configurations</LI>
<LI> Recover firewall from stored configuration</LI>
<LI> Recover the TSM server</LI>
<LI> Build filesystems on recovered systems</LI>
<LI> Restore filesystems and databases from the TSM server</LI>
<LI> Test applications</LI>
<LI> Release systems</LI>
</OL>

-- CharlesJohnson - 20 Jan 2007

IDEA! Suggestion: Instead of using HTML comments (not very TWiki-like) to indicate sections to convert to PDF, why don't you rely on the TWiki SECTION / ENDSECTION tag to indicate sections? Doing so would mean less commands to learn for a user, and would be more consistent with the rest of the TWiki markup.

You might want to add an type pdf to these tags to make sure that only those are interpreted by GenPDFAddOn.

-- ThomasWeigert - 21 Jan 2007

Thanks Thomas, but you misunderstand what I mean to say. The html code above is not what I see literally when I do a printview, it is what I see when I do a "view source" within the browser or when I run genpdf at the command line for that web page and grab the html source. The lettered lists render fine under the browser. I just wanted to make the point that the html code for lettered lists that Dakar generates is different from Cairo.

With gendpdf and Dakar:

  1. one
  2. two
  3. three
Is rendered in the generated pdf as:

   1. one
   2. two
   3. three

-- CharlesJohnson - 23 Jan 2007

Charles, I am running into this same bug. It looks to be a problem with htmldoc. It seems they only support the HTML 2.0 version of the OL tag, and the type attribute was only introduced in HTML 3.2. See: http://htmldoc.org/htmldoc.html#7_2

Let me tell you, this is driving the documentation people at my company batty.

-- MosheHyzon - 29 Jan 2007

Here's something a few folk might find useful. I needed a simple effective way to expose the pdf generation options to anyone who clicks on a "PDF View" button. The problem was that using a few of the options e.g. pdforienation=landscape was essential for some pages but hidden for casual twiki users. So instead of directly linking to genpdf I send them to a page which lists alls the options available and then does the genpdf step.

I have attached a file containing the twiki text for a genpdf options page. To use it you need to copy the text into a twiki page then setup a link to that page nstead of calling genpdf directly. i.e. instead of

 "%SCRIPTURLPATH{"genpdf"}%/%WEB%/%TOPIC%" 

use

 "%SCRIPTURLPATH{"view"}%/TWiki/[TheTwikiPageName]?pdf_web=%WEB&pdf_topic=%TOPIC" 

-- PatrickDiamond - 22 Feb 2007

I am experiencing a significant issue between the previous revision, 9716, and the current revision, 11673. My PDF's no longer have pictures in them. I diff'ed the two versions of GenPDF.pm and there is considerably MORE that has changed than just, "updated MIME type to pdf from x-pdf, fixed bug preventing disabling the TOC"!

-- RobertWhelton - 08 Mar 2007

Hi

This is my error : Conversion failed: 'Inappropriate ioctl for device' at /var/www/docs/twiki/---/lib/TWiki/Contrib/GenPDF.pm line 694. when I want to generate PDF version.

So, problem is about IMG TAG.. if I delete all image in my topic : Apercu_interface.png

I haven't problem after..

Can you help me please ?

thank you

-- YannickPavard - 13 Mar 2007

I need to find a copy of version 0.8 of GenPDFAddOn, in order to perform a diff and find out exactly what local changes have been made. Where might I locate this?

-- RichMorin - 16 Mar 2007

Click on the "manage" link of the package. You will see a table of all previous revisions.

-- PeterThoeny - 17 Mar 2007

GenPDF.pm (on my system) is able to pick up values such as TWiki::Func::getPreferencesValue("GENPDFADDON_RECURSIVE", but not $query->param('pdfrecursive'). Any suggestions?

-- RichMorin - 20 Mar 2007

YannickPavard, I have had this problem occationally with some image as well. I have fixed the problem by loading the image file into another image editing program and saving the file. For example we had some problem images generated in Gimp. I opened and saved them in Photoshop or Canvas and then replaced the images and the PDF generated correctly. This appears to be some bug in htmldoc causing this problem with certain image files.

-- RickMach - 20 Mar 2007

RobertWhelton - I just did a svn diff -r 9716:11673 and it showed the changes I made during that revision are the ones documented and one other code cleanup issue. Here is the additional code cleanup issue: Previously all the defaults were scattered through a bunch of $prefs{...} = statements. I consolidated all of these defaults to a single constant block to make it much easier in case someone needed to update the defaults. We are using 11673 on TWiki 4.05 without any problems. I'll email you the results of the svn checkin to see if that matches your diffs or if you have some other version.

-- RickMach - 20 Mar 2007

Thank You RickMach.. I use Gimp exactly wink

-- YannickPavard - 25 Mar 2007

I have another question about TOC variable. It's possible to remove all this variable in pdf ? Because I have TOC variable in INCLUDE TOPIC.. and I can see them in PDF ;-( The first don't appear, but another YES !

thank you and sorry for my bad english wink

-- YannickPavard - 25 Mar 2007

I've just installed the latest version of this Addon (13196) and I cannot get any images (png) to appear in the PDFs.

I see there have been a lot of issues over the life of this Addon regarding images, but I'm a bit confused about what the recommended course of action is with the latest Addon code.

What do I need to do to get images?

-- DuncanKinnear - 28 Mar 2007

Hi!, Great Plugin. Im using the 'pdfrecursive' feature and want to control the order in which child topics are displayed. This quetion was also asked by DomLayfield -- - 08 Feb 2006 above. Any have any idea's on how to do this ?. Thanks

-- IanClancy - 29 Mar 2007

Update on my issue with images.

I traced the problem down to the fact that the Addon regex for finding images is assuming that the src value is enclosed in single quotes, but the ImgPlugin that we use inserts img tags with the values in double-quotes.

I tried changing the regex in the GenPDF code to accept both types of quotes, but could get it to work, so ended up changing the ImgPlugin to output values in single quotes.

I believe the GenPDF code should be able to handle both types of quotes, so it would be good if one of the authors/contributors could fix this in a future release.

-- DuncanKinnear - 10 Apr 2007

IanClancy, I have looked for control or order of child topics and haven't found it yet. It just seems to do it in alphabetical order.

-- RickMach - 10 Apr 2007

This is a wonderful addon - I've been using it with an earlier version of TWiki for some time. Recently I added it on to 4.1.2. It works quite well, but has some problems with TWISTY text. I don't know if it's possible, but it would be nice if it could be applied after TWISTY so it shows the current state of the displayed page, instead of always showing the TWISTY text and both TWISTY show and hide links.

-- SteveWampler - 16 Apr 2007

I have installed this addon to our TWiki-installation (latest version installed on Windows 2003 with Apache 2 and IndigoPerl) and I am using HTMLDoc 1.8.27 (evaluation).

My only problem is the fact that images are not rendered in the PDF-file. I tried several solutions provided in this topic, but i still have no images. I think that there is problem with authentication, but can't pinpoint it...

The error-messages in the apache-logs are: [Mon Apr 23 12:31:16 2007] [error] [client 192.168.1.3] [Mon Apr 23 12:31:15 2007] GenPDF.pm: \1 better written as $1 at C:/twiki/lib/TWiki/Contrib/GenPDF.pm line 377. [Mon Apr 23 12:31:17 2007] [error] [client 192.168.1.3] [Mon Apr 23 12:31:15 2007] GenPDF.pm: \1 better written as $1 at C:/twiki/lib/TWiki/Contrib/GenPDF.pm line 377. [Mon Apr 23 12:31:17 2007] [error] [client 192.168.1.3] Calling htmldoc with args: --book --quiet --links --linkstyle plain --outfile C:\temp\GenPDFAddOnZBgK34LFda.pdf --format pdf14 --portrait --size a4 --browserwidth 860 --titlefile C:\temp\GenPDFAddOn3L5fBMReMg.html --toclevels 5 --tocheader ... --tocfooter ..i --firstpage toc C:\temp\GenPDFAddOnNRnMIWLvwU.html [Mon Apr 23 12:31:17 2007] [error] [client 192.168.1.3] INFO: You have only 16 day(s) remaining on your demo license. [Mon Apr 23 12:31:41 2007] [error] [client 192.168.1.3] (OS 87)The parameter is incorrect. : authentication failure for "/twiki/bin/view/TWiki/TWikiRegistration": user unknown, reason: cannot generate context

I am using the mod_auth_sspi-module for using windows authentication on Apache.

The temporary HTML-files do contain the images, but the PDF-file is not... Generating a PDF using the HTMLDoc-application and a temporary HTML-file also works fine (including the images...)

Maybe some one can give me some tips to solve this problem.

Thanks

-- PaulMaessen - 23 Apr 2007

Fixed the problem. I used the solution from ScottHoge, but at the end was the problem caused by the fact that the urlhost was already part of the url for the image, so it was never replaced by the PubDir...

It works now fine for me.

-- PaulMaessen - 26 Apr 2007

I came across a minor defect in this plugin when using it with the WorkflowPlugin:

If I generate a PDF of a page that is a specified revision of the topic (i.e. not the latest, has a ?rev= argument) then the PDF is still generated from the latest revision, not the one required.

I patched the code to get around this:

Index: GenPDF.pm
===================================================================
--- GenPDF.pm   (revision 344)
+++ GenPDF.pm   (working copy)
@@ -93,7 +93,7 @@
 
 =pod
 
-=head2 _getRenderedView($webName, $topic)
+=head2 _getRenderedView($webName, $topic, $rev)
 
 Generates rendered HTML of $topic in $webName using TWiki rendering functions and
 returns it.
@@ -101,9 +101,9 @@
 =cut
 
 sub _getRenderedView {
-   my ($webName, $topic) = @_;
+   my ($webName, $topic, $rev) = @_;
 
-   my $text = TWiki::Func::readTopicText($webName, $topic);
+   my $text = TWiki::Func::readTopicText($webName, $topic, $rev);
    # FIXME - must be a better way?
    if ($text =~ /^http.*\/.*\/oops\/.*oopsaccessview$/) {
       return "Sorry, this topic is not accessible at this time."
@@ -470,6 +470,7 @@
    my $theRemoteUser = $query->remote_user();
    my $theTopic = $query->param('topic');
    my $theUrl = $query->url;
+   my $rev=undef;  # can't use a rev argument if recursive used
 
    my($topic, $webName, $scriptUrlPath, $userName) = 
       TWiki::initialize($thePathInfo, $theRemoteUser, $theTopic, $theUrl, $query);
@@ -552,6 +553,11 @@
       }
       chdir($cwd); # return to previous working dir
    }
+   else
+   {
+      # set the rev argument if recursive is not used
+      $rev=$query->param('rev');
+   }
 
    # Do a recursive depth first walk through the ancestors in the tree
    # sub is defined here for clarity
@@ -580,7 +586,7 @@
    for $topic (@topics) {
       #print STDERR "preparing $topic\n"; # DEBUG
       # Get ready to display HTML topic
-      my $htmlData = _getRenderedView($webName, $topic);
+      my $htmlData = _getRenderedView($webName, $topic, $rev);
 
       # Fix topic text (i.e. correct any problems with the HTML that htmldoc might not like
       $htmlData = _fixHtml($htmlData, $topic, $webName, \@topics);

In addition, if you have a toolbar button for it, you need to patch it to pass the REVARG thru:

Index: viewtopicactionbuttons.dmtc.tmpl
===================================================================
--- viewtopicactionbuttons.dmtc.tmpl   (revision 350)
+++ viewtopicactionbuttons.dmtc.tmpl   (working copy)
@@ -51,7 +51,7 @@
 
 %TMPL:DEF{"workflowpdf"}%%TMPL:P{context="WorkflowApproved" then="pdfpage" else="inactive_pdf"}%%TMPL:END%
 
-%TMPL:DEF{"pdfpage"}%<span class="patternButton"><a href="%SCRIPTURLPATH{"genpdf"}%/%WEB%/%TOPIC%" title="%MAKETEXT{"Generate a PDF of this topic"}%" accesskey="D">%MAKETEXT{"P&DF"}%</a></span>%TMPL:END%
+%TMPL:DEF{"pdfpage"}%<span class="patternButton"><a href="%SCRIPTURLPATH{"genpdf"}%/%WEB%/%TOPIC%?%REVARG%" title="%MAKETEXT{"Generate a PDF of this topic"}%" accesskey="D">%MAKETEXT{"P&DF"}%</a></span>%TMPL:END%
 
 %TMPL:DEF{"inactive_pdf"}%<span class="patternButton"><strike>PDF</strike></span>%TMPL:END%

I realise that button patch is not pretty, since a hanging '?' occurs on the URL if no revision is requested, but the REVARG always converts to &rev= which is not valid if there is no query

-- DarrenElkerton - 01 May 2007

Sorry, it's maybe very easy to do but i haven't found yet how to include an image as a footer. I know i'm supposed to use GENPDFADDON_LOGOIMAGE and a mysterious I as a string... I tried to put I in the variable GENPDFADDON_HEADERTOPIC but it crashed...

-- GuillaumeBardy - 14 Jun 2007

GuillaumeBardy, to include an image as a header/footer, put the following on the topic that will be used as a header :

<!-- PDFSTART -->
<!-- HEADER LEFT "Diretoria de Informática" -->
<!-- HEADER CENTER "$LOGOIMAGE l" -->
<!-- HEADER RIGHT "%DISPLAYTIME%" -->
<!-- FOOTER LEFT "%REVINFO{"revisão.$rev ­ $date ­ $wikiusername" web="%WEB%" topic="%BASETOPIC%"}%" -->
<!-- FOOTER CENTER "" -->
<!-- FOOTER RIGHT "$PAGE(1)" -->
<!-- PDFSTOP -->

At web preferences, define the image path, as bellow :

  • Settings for the GenPDFAddOn Plugin
    • Set GENPDFADDON_LOGOIMAGE = LogodoEstado.jpg
-- LucileiaVieira - 05 Jul 2007

Hi

I am unable to get my https images through in the output pdf. I dont know if this is authentication issues or not.

I have looked at the get my $url = TWiki::Func::getUrlHost() - can this be replaced with getTWikiDiskLocation? or a call like that?

i have hard coded it for now and it works for my pdfs now.

-- TerryRankine - 06 Jul 2007

Hi CharlesJohnson, I've generated the PDF with the characters list under TWiki (Dakar) , by adding the following lines at GenPDF.pm file:

$htmlData =~ s/<ol>\n<li(.*?) type="A">/<ol type="A">\n<li>/g;
$htmlData =~ s/<li(.*?) type="A">/<li>/g;
$htmlData =~ s/<ol>\n<li(.*?) type="a">/<ol type="a">\n<li>/g;
$htmlData =~ s/<li(.*?) type="a">/<li>/g;
$htmlData =~ s/<ol>\n<li(.*?) type="i">/<ol type="i">\n<li>/g;
$htmlData =~ s/<li(.*?) type="i">/<li>/g;
$htmlData =~ s/<ol>\n<li(.*?) type="I">/<ol type="I">\n<li>/g;
$htmlData =~ s/<li(.*?) type="I">/<li>/g;

-- LucileiaVieira - 11 Jul 2007

Hi!

I have also problem with images at https: locations? If I add link for image at http site there is no problem? But when link is https then there is only empty area on pdf document where image should be?

This is quite annoying.. frown Is there any change which I could do to get it work some how?

Ps. This is one of the best plugins!

-- MarkoRintamaki - 19 Jul 2007

More information....

https pages have authentication using htaccess (in same TWiki server)

I noticed that if I include user and password in web link it will work ttps://username:password@myserver/folder/someimage.jpg

If I add this link in my topic text I can create PDF with pictures included!

How to make this working as secure way??? GenPDF should take care of authentication? Or is it possible to use same user account information who is using browser

like https://!guest:currentpassword@myserver/

-- MarkoRintamaki - 19 Jul 2007

Sollution proposal: Configure apache (2.2) to allow localhost connections without authentication? ( htlmdoc can fetch data )... Is there some security holes?? (I think there is.. smile

-- MarkoRintamaki - 20 Jul 2007

Thanks for lettered list fix LucileiaVieira !

-- CharlesJohnson - 21 Jul 2007

I'm having a problem with genPDFaddon. All my twiki/pub traffic is being redirected thru the viewfile script for security reasons. When i call the genpdf script, my PDF come without any single image, but if i change the format to html, the file is rendered correct with images. Some one have a guess how is this happening?

Thank you, very much for this addon!

-- MarcioFigueira - 01 Aug 2007

GenPDF.pm had various syntax problems when attempting to run with TWiki and Perl 5.6.1. The two places that I needed changes were how constants were defined, and the handling of filehandles versus filename. I couldn't register for a new user on the bugs web (disabled), so I attached my updated GenPDF.pm here for people suffering those problems. The file will need renamed and put into /lib/TWiki/Contrib to replace the original:

-- StephenCuppett - 09 Aug 2007

I had a problem with:

Constant name 'HASH(0x86bc7a8)' has invalid characters at //twiki/lib/TWiki/Contrib/GenPDF.pm line 391 

1) Turned out to be a simple syntax problem with the way the constants were declared and the version of Perl I was using on RHEL 2.1.
2) Once I fixed that, the older Perl didn't like "new File::Temp" either. Since only one function was being used to create the temporary files, I changed that to an easy import.
3) Finally the code was working; however, I noticed the temporary files were being orphaned on the file system and added a call to unlink to remove them after sending the PDF was complete.

These fixes are all in the cuppett.patch below.

-- StephenCuppett - 10 Aug 2007

I moved the GenPDF_-_older_systems.pm to here from the GenPDFAddOn topic. Which one is now the latest patch? I suggest to file a bug report, see link at top of this page.

-- PeterThoeny - 12 Aug 2007

Sorry, the patch should be the same, the .pm is the whole updated file. Will open the bug.

-- StephenCuppett - 13 Aug 2007

Item4452 opened. I attempted to remove the

GenPDF_-_older_systems.pm

but I wasn't able. Should probably only have the patch on this page.

-- StephenCuppett - 13 Aug 2007

I'm running into a similar issue to the https: issue reported previously, but with http:// image attachments that are also blocked due to authentication requirements. I'm wondering if a solution would be to modify the current routine to change the images to a file:// reference instead of a http:// reference.

  • For each <img tag
    • use TWiki::Func::readAttachment to read the file to a string
    • use File::Temp to store as a new temporary file
    • Replace the http:// reference to file:///tmp/temp-image-file
I believe that this would resolve the http / https authentication issues and still honor the file access permissions for the current user. It could alternatively access the image directly using the attachPath, but that would bypass any access checking for the files.

-- GeorgeClark - 29 Aug 2007

One more comment - it appears that htmldoc doesn't support the file:// link type for images. But by putting the imagename in directly without any path and using the --path option on htmldoc does work. so the link <img src=mytempimage.gif> and --path /tmp will successfully load mytempimage from the /tmp directory.

-- GeorgeClark - 29 Aug 2007

Have added 3 attributes, HEADFOOTSIZE, HEADER and FOOTER (see attached)

--- /old/lib/TWiki/Contrib/GenPDF.pm   2007-08-31 20:58:41.000000000 +0200
+++ /new/lib/TWiki/Contrib/GenPDF.pm   2007-10-10 21:32:20.037219596 +0200
@@ -410,6 +410,9 @@
        TOCHEADER => "...",
        TOCFOOTER => "..i",
        HEADFOOTFONT => "",
+       HEADFOOTSIZE => undef,
+       HEADER => undef,
+       FOOTER => undef,
        BODYIMAGE => "",
        LOGOIMAGE => "",
        NUMBEREDTOC => undef,
@@ -463,6 +466,15 @@
    $prefs{'headfootfont'} = HEADFOOTFONT unless ($prefs{'headfootfont'} =~
       /^(times(-roman|-bold|-italic|bolditalic)?|(courier|helvetica)(-bold|-oblique|-boldoblique)?)$/);
 
+   $prefs{'headfootsize'} = $query->param('pdfheadfootsize') || TWiki::Func::getPreferencesValue("GENPDFADDON_HEADFOOTSIZE") || '';
+   $prefs{'headfootsize'} = HEADFOOTSIZE unless ($prefs{'headfootsize'} =~ /^\d+$/);
+
+   $prefs{'header'} = $query->param('pdfheader') || TWiki::Func::getPreferencesValue("GENPDFADDON_HEADER") || '';
+   $prefs{'header'} = HEADER unless ($prefs{'header'} =~ /^[\.\/:1aAcCdDhiIltT]{3}$/);
+
+   $prefs{'footer'} = $query->param('pdffooter') || TWiki::Func::getPreferencesValue("GENPDFADDON_FOOTER") || '';
+   $prefs{'footer'} = FOOTER unless ($prefs{'footer'} =~ /^[\.\/:1aAcCdDhiIltT]{3}$/);
+
    $prefs{'width'} = $query->param('pdfwidth') || TWiki::Func::getPreferencesValue("GENPDFADDON_WIDTH") || '';
    $prefs{'width'} = WIDTH unless ($prefs{'width'} =~ /^\d+$/);
 
@@ -677,6 +689,9 @@
    push @htmldocArgs, "--bodyimage", "$prefs{'bodyimage'}" if $prefs{'bodyimage'};
    push @htmldocArgs, "--logoimage", "$prefs{'logoimage'}" if $prefs{'logoimage'};
    push @htmldocArgs, "--headfootfont", "$prefs{'headfootfont'}" if $prefs{'headfootfont'};
+   push @htmldocArgs, "--headfootsize", "$prefs{'headfootsize'}" if $prefs{'headfootsize'};
+   push @htmldocArgs, "--header", "$prefs{'header'}" if $prefs{'header'};
+   push @htmldocArgs, "--footer", "$prefs{'footer'}" if $prefs{'footer'};
    push @htmldocArgs, "--permissions", "$prefs{'permissions'}" if $prefs{'permissions'};
    push @htmldocArgs, "--bodycolor", "$prefs{'bodycolor'}" if $prefs{'bodycolor'};
    push @htmldocArgs, "--top", "$prefs{'top'}" if $prefs{'top'};

Gives more control on what appears in header and footer. smile

-- KwangErnLiew - 10 Oct 2007

I'm running TWiki via mod_perl. I sometimes experienced a weird behavior of bin/genpdf. It sometimes generated a PDF of a different page from specified.

I looked into the code and came up with the following patch to fix it. I made this patch against the Oct 23 2007 release, but should be applicable to prior versions.

--- lib/TWiki/Contrib/GenPDF.pm 2007-10-24 05:54:42.000000000 +0900
+++ lib/TWiki/Contrib/GenPDF.pm.patched 2007-10-31 09:27:06.000000000 +0900
@@ -67,7 +67,7 @@

 $| = 1; # Autoflush buffers

-our $query = new CGI;
+our $query;
 our %tree;
 our %prefs;

@@ -519,6 +519,11 @@

 sub viewPDF {

+   # initialize module wide variables
+   $query = new CGI;
+   %tree = ();
+   %prefs = ();
+
    # Initialize TWiki
    my $thePathInfo = $query->path_info();
    my $theRemoteUser = $query->remote_user();

In the original code, $query is initialized when it's loaded. Under mod_perl and other persistency methods, viewPDF() is invoked multiple times after GenPDF.pm is loaded. So the second and onward invocations of viewPDF() keep seeing the CGI instance of the first invocation. That led to the problem I experienced.

-- HideyoImazu - 31 Oct 2007

Hideyo, it obviousely will be best that you join the development team by asking for SVN access rights.

-- FranzJosefGigler - 31 Oct 2007

Header/footer enhancements and bug fix on generating wrong page are now incorporated into the 2 Nov release

-- RickMach - 02 Nov 2007

Is this add-on compatible with Twiki 4.2? Will a manual install of the scripts permit it to function or does the code need to be revised?

-- DustyPapadopolous - 06 Feb 2008

Worked fine for me, with the latest version of the addon and htmldoc 1.8.27 on a linux box.

-- ScottHoge - 07 Feb 2008

We're still having problems rendering images from HTML to PDF. We're running the latest GenPDFAddOn and HTMLDOC 1.8.27. Was ScottHoge 's patch added into the November release?

-- AlanRubin - 12 Feb 2008

I figured it out. User error, which is probably for the best. The particular page I was using for testing was not using proper syntax to display attached images. Although it worked in the context of the wiki, either GenPDF or HTMLDoc could not parse the incorrect method.

For anyone else that might be doing the same thing, make sure you use

%ATTACHURL%/Smile.gif

or

<img src="%ATTACHURLPATH%/Smile.gif" alt="Smile.gif" width='15' height='15' />

(examples)

This may have some relation to Scott Hoge's problem of GenPDF not being able to determine the location of the image file. Improperly formatted pages were using a literal URL as a pointer to the image file.

-- AlanRubin - 12 Feb 2008

hello,

I am trying to add the PDF button to my viewtopicactionbuttos.pattern.tmpl I have added the followng like

%TMPL:DEF{"genpdf"}%<span class='patternButton'><a href='%SCRIPTURLPATH%/genpdf%SCRIPTSUFFIX%/%WEB%/%TOPIC%?pdfpagesize=a4&pdforientation=landscape' rel='nofollow' %MAKETEXT{"title='PDF' accesskey='P'>&PDF"}%</a></span>%TMPL:END%

but nothing changed. I read that something should be changed in view.pattern.tmpl under

 topicactionbutton

but I don't have this section in view.pattern.tmpl Could you please help?

Thanks

-- GrazynaGladys - 13 Feb 2008

Grazyna, you only need to modify viewtopicactionbuttons.tmpl if you change the topicactionbuttons definition there as shown in the attached patch viewtopicactionbuttons.tmpl_patch.txt which actually adds two buttons for GenPDFAddOn and GenPDFLatexAddOn.

-- MarkusUeberall - 14 Feb 2008

Thanks Markus, that worked!

-- GrazynaGladys - 15 Feb 2008

I get blank PDF document when opening the generated file with Adobe Reader (8.1.2). When opening the same with Foxit Reader, it looks fine. I assume the embedded font cannot be opened in Adobe Reader. Is there a way to change this?

-- SakkeWiik - 22 Apr 2008

Hi, great work BrianSpinar and WadeTurland!

I try to use the GenPDFAddOn_installer script but it is not working. see the last lines with te error:

(...)
Archive unpacked
Install data/TWiki/GenPDFExampleHeaderFooterTopic.txt, permissions 0774
Install data/TWiki/GenPDFExampleTitleTopic.txt, permissions 0774
Install data/TWiki/GenPDFAddOn.txt, permissions 0774
Install bin/genpdf, permissions 0774
Install lib/TWiki/Contrib/GenPDF.pm, permissions 0774
Can't locate object method "findUser" via package "TWiki::Users" at GenPDFAddOn_installer line 668.

I done the installation by hand, but will be cool if the installer did all without the human errors.

I also try by this ways:

perl -I lib GenPDFAddOn_installer
perl -I bin GenPDFAddOn_installer

-- AurelioAHeckert - 11 May 2008

New kid in town: ToPDFAddOn

-- PeterThoeny - 02 Jun 2008

HTMLDOC (who makes the engine behind GenPDF) provides the source but not free Windows binaries. They suggest using a Google search to find them, and even provide a search link on one of their pages.

I finally found a pointer to free Windows binaries for 1.8.27 at http://www.mediawiki.org/wiki/Extension:Pdf_Export

-- SeanCMorgan - 16 Jun 2008

Re: SakkeWiik (22 Apr 2008): I had the same problem, and it was the embedded font. Thank-you for that lead! I got it to work by modifying GenPDF.pm (down near the end, where all the other arguments are added) to add an extra argument like so:

push @htmldocArgs, "--no-embedfonts"; # required with Adobe 8.1.0. and 8.1.2.

That argument also makes for smaller (but less portable) PDF files.

-- SeanCMorgan - 17 Jun 2008

Similarly, can set link color: push @htmldocArgs, "--linkcolor", "0000FF"; # Otherwise they are black

But I can't get pdfrecursive to work with TWiki 4.2?

-- SeanCMorgan - 17 Jun 2008

I've just uploaded an updated version that should fix the installer errors, makes it use the TWiki::Sandbox to call the external htmldoc and fixes (or adds?) the skin urlparam.

-- SvenDowideit - 25 Jun 2008

I have a really strange problem, on TWiki 4.2. GenPDF works, but only if the topic has PDFSTART and PDFSTOP tags. If it doesn't, I get an unspecified error from the server (error running htmldoc (path to htmldoc)).

Any ideas as to why this may be happening?

-- AllenRabinovich - 30 Jun 2008

That is pretty strange, as none of my topics have those tags. It could well be a result of the change i made to how htmldoc is called :/ I'll take a peek - what version of htmldoc are you using?

-- SvenDowideit - 30 Jun 2008

Running into problems on 4.1.2. Getting the following error which seems to be 4.2 specific..

Can't locate object method "templates" via package "TWiki" at /path/to/twiki/lib/TWiki/Contrib/GenPDF.pm line 117

Is the add-on still compatible with 4.1.2?

-- PadraigLennon - 30 Jun 2008

Allen & Padraig I've just uploaded a new version of the AddOn that should resolve both your issues. Additionally, I've made it simpler to install and use - for 4.2 you can now set the htmldoc path in configure , and both 4.2 and 4.1 you can activate the genpdf using a SKIN setting.

-- SvenDowideit - 1 Jul 2008

Latest version now respects VIEW_TEMPLATES and COVER

-- MichaelDaum - 02 Jul 2008

Sven -- thanks very much, the issue was resolved. However, there seems to be another one: the recursive option is failing. When I set pdfrecursive to on (or otherwise set a web preference variable), the PDFs generated for topics with children have 0 byte size.

No error is returned. My htmldoc version is 1.9.

-- AllenRabinovich - 06 Jul 2008

To follow up on my preceding comment: when I set it as a web preference variable, even setting it to undef results in 0 file size PDFs. I had to remove it completely from the web preferences to make it generate single-topic PDFs normally.

-- AllenRabinovich - 06 Jul 2008

I'm having the same issue as MarcioFigueira was reporting on 01 Aug 2007. I'm using the 02 July 2008 version of the GenPDFAddon with TWiki 4.1.2. Has anyone else noticed this?

-- DrewStevenson - 10 Jul 2008

Building on PatrickDiamond's idea (22 Feb 2007), I have attached information that allows users to change the PDF generation options with a form rather than editing the URL. Among the enhancements to Patrick's form is that the preferences are used to preset the form with default values. Also, to keep the form simple, it only has the more frequently used options.

The installation and configuration instructions appear in the .txt file. For the curious, a screenshot is also included.

Can this be included with the next plugin update?

P.S. I've installed add-on version 02 Jul 2008, but the links to Add-on Home and Feedback don't work (they are ...Addon[Dev] instead of ...AddOn[Dev]). They are correct at GenPDFAddOn, even though it is the same version. ???

-- SeanCMorgan - 28 Jul 2008

I've noticed that GenPDF doesnt render the HTML for Forms. The other PDF makers for Twiki also don't do this as far as I'm aware.

Is anyone making any progress in displaying Forms with GenPDF?

Anyone know what needs to be done?, if it would be reletively easy to implement this functionality?

-- NeilMclean - 26 Aug 2008

I think it would be simple - without looking, i think we all intentionally leave out the forms section of the view template.

-- SvenDowideit - 26 Aug 2008

We are going to be using GenPDF to print out Procedures and Documents that we create throughout the Software Lifecycle. The ability to print out Forms on Wiki pages would be great!

Are there any plans to include PDF creation of forms for an upcoming GenPDF version?

-- NeilMclean - 09 Sep 2008

All the hooks already seem to be there to include the form table, except it doesn't seem to work:

  • The print view ( ?cover=print) shows the table in a browser. But that cover setting is ignored by GenPDF, whether it's set in a preference variable or as a URL parameter.
  • If I give the print view's URL to the HTMLDOC GUI, it generates the PDF with the form table just fine, so it's something to do with the plugin and not HTMLDOC.
  • Using pdfstruct=webpage with the print view doesn't work for me either. That should be similar to the HTMLDOC setup, in that it forces it to be treated as a raw URL, and not even be aware of covers & such.
One thing that looks weird in GenPDF.pm is that it uses an undocumented variable (GENPDFADDON_MODE), which (almost certainly) should be GENPDFADDON_STRUCT. But changing that didn't help either.

-- SeanCMorgan - 09 Sep 2008

Hello,

I have a problem with the installation. I installed htmldoc 1.9.x and unzipped the GenPDFAddOn.zip to my TWiki installation. Then the installation instruction says: "Adjust the perl path in the genpdf script to match your perl installation location." --> I couldn't find where to set the path in this script.

The next instruction says "Configure the $TWiki::cfg{Extensions}{GenPDFAddOn}{htmldocCmd} = "/path/to/htmldoc"; using configure (in the Extensions section)" --> if I run configure and click on 'Extensions', nothing is shown (i.e., TWiki doesn't know the addon yet, I assume?)

Any help would be greatly appreciated.

P.S.: Another question: why is the option "leave out the TOC" only available as URL parameter (pdftoclevels=0) and not as Preferences variable?

Best regards, Felix

-- FelixDreher - 26 Sep 2008

Felix, the preference variable for pdftoclevels is GENPDFADDON_TOCLEVELS

But since you have pointed out some places where the docs can be improved, (rather than pointing you to the support web) here goes:

  1. "Adjust the perl path" means to edit shebangs (line number 1) in both /bin/genpdf and /lib/TWiki/Contrib/GenPDF.pm
  2. I think it only shows up in configure as of TWiki 4.2.(something). Otherwise, make sure that HTMLDOC is in the path of the environment of the Apache process.
-- SeanCMorgan - 27 Sep 2008

Setting SKIN=genpdf,pattern in web preferences seems to have no effect for me. In trying to diagnose this, I'm puzzled as to how this works. The download doesn't appear to contain anything that would add or amend the pattern template as suggested. I'm clearly missing something.

Can anyone explain how this is supposed to work? Thanks,

-- DavidHaslam - 30 Sep 2008

Thank you Sean for the quick answer. After I adjusted everything, pdf creation worked via URL ( ...../twiki/bin/genpdf/XYZ), however it didn't work via customizing the SKIN variable in TWikiPreferences ( SKIN = genpdf, pattern). Therefore I added a 'pdf-template' to topicactionbuttons.pattern.tmpl with the link to the genpdf script:

<a href='%SCRIPTURLPATH{"genpdf"}%/%WEB%/%TOPIC%?pdftitle=%TOPIC%'   ...>

and added a button to the first line of viewtoolbar.pattern.tmpl

<span class="patternButton">%TMPL:P{"pdf"}%</span>

Now at the top right of the window there is a 'PDF' button, but the 'Printable' button has disappeared. So I'm wondering what I could do to have these two buttons next to each other?

Regards, Felix

P.S.: Currently I use TWiki version 4.1.2 (but will update soon).

-- FelixDreher - 01 Oct 2008

Felix, would you mind open a support question for that. I have some questions on what you've done, but we shouldn't do that here.

-- SeanCMorgan - 01 Oct 2008

I had a problem where genpdf sometimes just produced a blank page, and left an acroread process running. It seems that htmldoc can sometimes generate a zero length pdf file, which acroread doesn't like, and just hangs.

After some investigation, it seems that in the default --book mode, htmldoc will generate a zero length file if there is no H1 tag in the file. I think it may save others sometime if the documentation explicitly mentions that a structured document needs at least an H1 tag (some of my documents started at H2, don't ask me why).

Also, Ifound it useful to add a test for a zero length output file, and generate an error: After these lines, around line 791:

    if( ! -e $outputFile ) {
       die "error running htmldoc ($htmldocCmd): $Output\n";
    }

I added this:

   if ( -z $outputFile ) {
      die "error running htmldoc, empty output file ($htmldocCmd): $Output\n";
   }

Which helped my debugging.

-- DavidHaslam - 02 Oct 2008

We have a number of documents in our wiki that do not have a <h1> tag in the source. Trying to run the plugin on these documents produces a zero length pdf and acroread throws an error. This appears due to the latest version of htmldoc that we are running, 1.8.27, not liking the missing <h1> tag inserted before the body tag, as the current GenPDF.pm code does.

I modified these lines and it seems to work:

    386    if ($html !~ /<h1>/is) {
    387         my $html_top = "";
    388         my $body_tag = "";
    389         my $html_bottom = "";
    390         ($html_top, $body_tag, $html_bottom) = split(/(<body.*?>)/, $html); 
    391         $html = $html_top . $body_tag . "<h1>$topic</h1><a name=\"$topic\"> </a>\n" . $html_bottom;
    392    } else {

-- MarkParker - 07 Oct 2008

This fix worked for me also! Centos 5.2/Twiki 4.2.3 htmldoc 1.8.27

-- MarkoRintamaki - 14 Oct 2008

Mark Parker's fix still leaves two head and body tags in the document. I use this patch instead:

--- GenPDF.pm.orig      2008-07-02 12:20:06.000000000 +0200
+++ GenPDF.pm   2008-10-21 15:07:45.000000000 +0200
@@ -348,6 +348,10 @@
    $title =~ s/<.*?>//gs;
    #print STDERR "title: '$title'\n"; # DEBUG
 
+   # Keep the body only.  A new header will be added later.
+   $html =~ s%.*<body[^>]*>%%is;
+   $html =~ s%</body>.*%%is;
+
    # Extract the content between the PDFSTART and PDFSTOP comment markers
    $html = _extractPdfSections($html);
 
@@ -389,7 +393,7 @@
       $html = "<a name=\"$topic\"> </a>$html";
    }
    # htmldoc reads <title> for PDF Title meta-info
-   $html = "<head><title>$title</title>\n$meta</head>\n<body>$html</body>";
+   $html = "<html><head><title>$title</title>\n$meta</head>\n<body>$html</body></html>";
 
    # As of HtmlDoc 1.8.24, it only handles HTML3.2 elements so
    # convert some common HTML4.x elements to similar HTML3.2 elements

-- AndreasVoegele - 21 Oct 2008

In my opinion it would be more useful if the variables in the title and header/footer were replaced with values from the topic the PDF is created from. Currently, the values of variables like %TOPIC%, %REVINFO% etc. are taken from the title and header/footer topics. If the values were taken from the source topic I could, for example, set GENPDFADDON_TITLE to %TOPIC%. I could also place variables like %REVINFO% directly into the title and header/footer topic.

As far as I can see the following patch should change _getHeaderFooterData() and _createTitleFile() accordingly. If the topic and the web aren't passed to TWiki::Func::expandCommonVariables() the values are taken from the session, which seems to be okay. Or should I pass these values to getHeaderFooterData() and _createTitleFile() as arguments?

--- GenPDF.pm.orig   2008-07-02 12:20:06.000000000 +0200
+++ GenPDF.pm   2008-10-24 09:30:14.000000000 +0200
@@ -221,7 +221,7 @@
          my $end = $3;
          # Expand common variables and render
          #print STDERR "var = '$var'\n"; #DEBUG
-         $var = TWiki::Func::expandCommonVariables($var, $topic, $webName);
+         $var = TWiki::Func::expandCommonVariables($var);
          $var = TWiki::Func::renderText($var);
          $var =~ s/<.*?>|\n|\r//gs; # htmldoc can't use HTML tags in headers/footers
          #print STDERR "var = '$var'\n"; #DEBUG
@@ -267,7 +267,7 @@
    $text = _fixTags($text);
 
    # Now render the rest of the topic
-   $text = TWiki::Func::expandCommonVariables($text, $topic, $webName);
+   $text = TWiki::Func::expandCommonVariables($text);
    $text = TWiki::Func::renderText($text);
 
    # FIXME - send to _fixHtml

-- AndreasVoegele - 24 Oct 2008

Thank you Timothe for adding FIRSTPAGE, DESTINATION, TITLEDOC, PAGELAYOUT & PAGEMODE. Even with limited testing I recommend to check-in the changes into the SVN repository and to update the package. We can fix it if something goes wrong.

-- PeterThoeny - 02 Jan 2009

I had the same problem as David, with GenPDF hanging on documents without an h1 / ---+ tag. I imagine this to be a very common problem, since I doubt I'm the only one to use includes to separate out subsections. I tried both solutions above (Mark's and Andreas') and they seemed to fix the problem. I'd suggest using one of these in the next release.

-- BrandonLynge - 24 Feb 2009

I found that this otherwise excellent addon does not expand FORMFIELD tags.

I then studied the code and found that this plugin takes the folllowing shortcuts in rendering:

  • Does not consider meta data
  • Does not treat headers, footers, and text part of the body within different context
As a consequence, a number of tags do not get expanded properly.

I am not sure whether this is by design, but it certainly does not produce the PDF I would like to see from my topics (unexpanded tags and missing content). It is easy to fix, so I will generate a new version, also integrating the fix when h1 headers are missing. I will then look at the other patches to see whether they should be integrated.

-- ThomasWeigert - 2010-09-15

I think most people would like to get a PDF output that looks similar to the print version of the page, e.g. with TWiki form and attachment table (if any). Please feel free to enhance the add-on as you see appropriate.

-- PeterThoeny - 2010-09-20

Add-on security issue: This ad-on is not aware of TWiki sessions. That may impose a security hole where template login is used and pages are selectively access controlled. In this scenario it is possible to get at the page content simply by replacing /view/ with /genpdf/ in the URL.

-- PeterThoeny - 2010-09-20

I have rewritten the genpdf script to use the normal invocation via run. The plugin does actually check whether the topic is allowed to be read, as it uses the Func::readTopicText API. So I am not sure whether your concern is correct.

-- ThomasWeigert - 2010-09-20

Hmm, there must be a bug somewhere. In one installation I put genpdf in the {AuthScripts} list and it was possible to grab an access restricted page with the genpdf script from a browser without login! If you do that with the view or rdiff script it prompts you to login as expected.

-- PeterThoeny - 2010-09-20

My version is not uploaded yet. But even the original version did check the access controls. I just tested my version for this problem and it pops an oops dialog.

-- ThomasWeigert - 2010-09-20

Thomas, can you checkin the updated code into SVN trunk? I can build and upload if you wish.

-- PeterThoeny - 2010-09-28

I have tried to install the Addon on Twiki Version 5.0 (Once on CentOS and once in OpenSuse 11.3). In both cases I get an error message:

Software error:

Undefined subroutine CGI::remoteAddress
 at /srv/www/twiki/lib/TWiki/LoginManager/Session.pm line 45
 at /usr/lib/perl5/5.12.1/CGI.pm line 893
   CGI::_compile called at /usr/lib/perl5/5.12.1/CGI.pm line 857
   CGI::AUTOLOAD('CGI=HASH(0x8cab50)') called at /srv/www/twiki/lib/TWiki/LoginManager/Session.pm line 45
   TWiki::LoginManager::Session::load('TWiki::LoginManager::Session', undef, 'CGI=HASH(0x8cab50)', 'HASH(0x14d6e70)') called at /usr/lib/perl5/vendor_perl/5.12.1/CGI/Session.pm line 64
   CGI::Session::new('TWiki::LoginManager::Session', undef, 'CGI=HASH(0x8cab50)', 'HASH(0x14d6e70)') called at /srv/www/twiki/lib/TWiki/LoginManager.pm line 321
   TWiki::LoginManager::loadSession('TWiki::LoginManager::TemplateLogin=HASH(0x142a940)', undef) called at /srv/www/twiki/lib/TWiki/Users.pm line 115
   TWiki::Users::new('TWiki::Users', 'TWiki=HASH(0x120c168)') called at /srv/www/twiki/lib/TWiki.pm line 1552
   TWiki::new('TWiki', undef, 'CGI=HASH(0x8cab50)') called at /srv/www/twiki/lib/TWiki.pm line 3342
   TWiki::initialize('/TWiki/GenPDFAddOn', undef, undef, 'http://localhost/twiki/bin/genpdf', 'CGI=HASH(0x8cab50)') called at /srv/www/twiki/lib/TWiki/Contrib/GenPDF.pm line 595
   TWiki::Contrib::GenPDF::viewPDF() called at /srv/www/twiki/bin/genpdf line 43

On our 4.3 instances the addon works fine and HTMLDOC itself is working on both system without problems.

-- MichaelGulitz - 2010-10-01

Yes, known issue. This add-on needs to be updated for 5.0.

-- PeterThoeny - 2010-10-01

By invoking the Addon I get a warning "genpdf: Can't call method "run" on an undefined value at .../twiki/bin/genpdf line 50", means: "engine->run". I don't think that it's a problem of the Addon, but one of the perl environment (running perl 5.8.8., apache2 with mod_perl, twiki 4.1.2, SuSE 10.2).

This is preceded by a warning "genpdf: Name "TWiki::engine" used only once: possible typo at .../twiki/bin/genpdf line 50", which has been mentioned several times before in this topic.

Someone can give me a hint?

-- EricSeubert - 2011-03-14

Problem solved. Installing the SuSE package did the trick.

https://build.opensuse.org/package/files?package=twiki-genpdf&project=home%3Agerritbeine

-- EricSeubert - 2011-04-08

Thanks Eric for reporting back to the benefit of the community! It would be nice to port this back upstream to twiki.org!

-- PeterThoeny - 2011-04-08

I have uploaded a 'patch' that adds new Generate PDF toolbar buttons for TWikiNetSkin and PatternSkin to make it blend in a bit better when using those skins. A screenshot is included.

To install, unpack the file GenPDFAddOn_toolbar_buttons.tgz in your twiki directory. It will add one image and overwrite the templates/view.genpdf.tmpl and data/TWiki/GenPDFAddOn.txt files, so if you like to keep them you have to make a copy before unpacking this. Don't forget to set the owner and permissions appropriately.
Set the SKIN variable like this Set SKIN=genpdf,twikinet,pattern and it should just work.

My first thought was to create a new version of the GenPDFAddOn but I add the 'patch' here instead. If someone thinks this is a good 'patch', please feel free to add it to the main release or modify it.

-- AlexanderAhman - 2011-05-14

When running the addon with 'pdfrecursive=on' an internal error occurs:

Log Entries: Insecure dependency in exec while running with -T switch at /srv/www/twiki/lib/TWiki/Contrib/GenPDFAddOn.pm line 657

Insecure dependency in chdir while running with -T switch at /srv/www/twiki/lib/TWiki/Contrib/GenPDFAddOn.pm line 671

I'm currently running TWiki Version TWiki-5.1.0, Sat, 20 Aug 2011, build 22128 on SLES10

For single topics the addon works fine.

Can somebody check?

-- MichaelGulitz - 2012-04-16

I second that.If you add the switch -U in bin/genpdf, which will allow perl to use unsafe operations, genpdf will run. However, then I get only corrupted 2bytes-sized pdf files.

-- ChristophSchaefer - 2012-07-05

It looks like this plugin needs some TLC. TWiki is a community driven project. I invite you to get involved with the TWiki community. As a contributor you can actively make a difference and help shape the product. If you are not a developer and need a timely response I recommend to hire a TWiki consultant to enhance TWiki based on your needs.

-- PeterThoeny - 2012-07-05

Just a minor trick. I didn't want to have a first page in my PDF, but just couldn't get rid of it, even using the "--no-title" option in the command line (configure/). I finally found by chance that no first page is generated if you put

<h1> </h1>
on top of the page.

-- Thomas Fozzi - 2013-06-14

Hi!

I always get a 404...

  • unpacked it in twiki dir
  • I set "Set SKIN = genpdf,onlinekommentar,twikinet,pattern" in Main/TWikiPreferences
  • htmldoc path is set in configure correctly (showing green)

When I substitute view with genpdf in the URL -> 404. And I see nothing in the apache logs or twiki/data/*

The 404 page show this text:

Not Found

The requested URL /twiki/bin/genpdf/Main/OR-701?skin=;pdftoclevels=0 was not found on this server.

-- Karsten Priegnitz - 2014-06-06

more info:

  • i did not run GenPDFAddOn_installer
  • access rights for bin/genpdf are the same as for bin/view
  • if I use skin=genpdf (/twiki/bin/view/Main/OR-701?skin=genpdf;pdftoclevels=0) then I get a resulting HTML page

-- Karsten Priegnitz - 2014-06-06

Ok, found out this:

  • if I copy what's in lib/TWiki/Contrib/GenPDFAddOn/Config.spec to lib/TWiki/UI.pm then it works

But why is Config.spec not loaded?

-- Karsten Priegnitz - 2014-06-10

FYI, once you run configure it will copy the Config.spec settings to LocalSite.cfg.

-- Peter Thoeny - 2014-06-10

Thanks Peter (again!).

Running /twiki/bin/configure did not do that. I did it manually now. PDF generation works, but all my custom css is ignored. The styles are totally different. Please compare:

For Example "Art. 22 ZPO" is in a div with class ok_artikelname. It translates to font-size 155%. This is ignored when printing.

If I explicitly set ?skin=onlinekommentar (which is my custom skin) then my Plugin - which generates everything from "Zivilprozessordnung" to "vorheriger Artikel | Inhaltsverzeichnis | nächster Artikel" by reading and displaying a database entry - isn't even called ... (http://www.onlinekommentar.ch/twiki/bin/genpdf/Main/ZPO-22?skin=onlinekommentar;pdftoclevels=0)

-- Karsten Priegnitz - 2014-06-19

Is there any way to change the body font (i.e. any TWiki parameter mapped to HTMLDOC "bodyfont" parameter) ? I also tried with embedded CSS but no luck

Thanks

-- Thomas Fozzi - 2015-03-09

Ok, I made it by using a workaround, which seems to work.

In the configuration of TWiki, section Extensions >> GenPDFAddOn I changed the path to htmldoc executable by adding --bodyfont arial at the end.

Everything is in arial now, even the TOC.

-- Thomas Fozzi - 2015-03-12

Back with a new TWiki implementation. When generating a PDF, each topic is being "printed" twice, except the WebHome topic, which only "prints" once.

Does anyone know what is causing this? And how to stop it?

Tanks

-- Patrick Townsend-Wells - 2015-04-08

Actually, GenPDF recursive generation doubles the "PDF printing" of all topics at each lower hierarchical level. The topic you start GenPDFing from is the root-level for "printing" and this topic is "printed" once in the PDF. All of its second-level children are "printed" twice. All of their third-level children are "printed" four times. All of their fourth-level children are "printed" eight times. And so on (I assume).

-- Patrick Townsend-Wells - 2015-04-10

Small error in the documentation, which took me 20 mins before finding the issue.

When specifying the document background (either with URL parameter 'pdfbodycolor' or with TWiki variable 'GENPDFADDON_BODYCOLOR' ) don't put any '#' before the hexadecimal color code, or it won't work.

-- Thomas Fozzi - 2016-07-04

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch GenPDF.pm.header-footer.patch r1 manage 2.1 K 2007-10-10 - 19:40 KwangErnLiew gives more control to header and footer
Unknown file formatdiff GenPDF.pm.rjw.diff r2 r1 manage 2.8 K 2006-05-19 - 19:10 RobertWhelton Robert Whelton's patch file
Unknown file formatEXT GenPDFAddOn-10 r1 manage 408.4 K 2005-11-22 - 20:03 IgorCastang example of a messed-up header pdf (starting on page 3)
Texttxt GenPDFAddOnMenu.txt r1 manage 5.7 K 2007-02-22 - 10:40 PatrickDiamond twiki text for a genpdf options page
Compressed Zip archivetgz GenPDFAddOn_toolbar_buttons.tgz r1 manage 49.1 K 2011-05-14 - 12:48 AlexanderAhman Adds new Generate PDF toolbar buttons for TWikiNetSkin and PatternSkin. Screenshot included.
Perl source code filepm GenPDF_-_older_systems.pm r1 manage 26.8 K 2007-08-09 - 14:33 StephenCuppett This file works with Perl 5.6.1 a little better
Unknown file formatpatch GenPDF_pm-cuppett.patch r1 manage 4.8 K 2007-08-10 - 11:26 StephenCuppett Fixes some syntax problems for older Perls (5.6.1) as well as temp file management issues (removes them after render)
Unknown file formatpatch GenPDF_pm-twiki-dakar.patch r1 manage 9.8 K 2006-03-28 - 08:03 StefanFritz GenPDFAddOn patch for Dakar
Compressed Zip archivezip GenPdfForm.zip r3 r2 r1 manage 48.9 K 2008-07-29 - 23:36 SeanCMorgan Another options form (screenshot included). May need to rename as .rar to uncompress.
Texttxt viewtopicactionbuttons.tmpl_patch.txt r1 manage 1.6 K 2008-02-14 - 12:10 MarkusUeberall Patch to add shortcuts for GenPDFAddOn and GenPDFLatexAddOn (TWiki 4.2)
Edit | Attach | Watch | Print version | History: r227 < r226 < r225 < r224 < r223 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r227 - 2016-07-04 - ThomasFozzi
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2016 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.