• View
• Edit
• History
• Attach
• Print
• Backlinks

PmWiki2PDF-Talk

09/22/2006 Alain

FDPF errors under PHP 5.xx

Warning : the embedded version of FPDF isn't PHP5 ready. The pdf appears as garbage on the navigator window instead of being sent to acrobat.

FDPF uses $HTTP_VARS_SERVER which does not exist anymore on PHP5, instead of $_SERVER. Changing all occurences (and suppressing accordingly "Global" declarations) in fpdf.php solves the issue.

20.Juni.2006 hh ( hh(at)11h.de ) I also cant get the images. It is possible to convert normal pages. With images this error appears:

Result from loading pmwiki-32.gif renamed as bildtest.gif

FPDF error: GIF parser: unable to open file http://137.22.221.134/wiki/pmwiki/uploads/bildtest.gif(approve links)

But it is possible to open the image, the file header is converted wright way. The real reason is there: from gif.php: do {

			if(!$this->m_img->load($this->m_lpData, $imgLen = 0)) {
			$this->m_HHData.="zzz".$this->m_img->m_data."http666";  #########################
				return false;
			}
			$this->m_lpData = substr($this->m_lpData, $imgLen);
		}
		while($iIndex-- > 0);

What can be the reason?? With .png there are other Errors.

There is a new script from 2006-05-28 Valentin Schmidt supporting Alpha channel see http://fpdf.org and there scripts At the site of http://html2fpdf.sourceforge.net/ there is no example with images and probably my not working images are containing alpha channels. Maybe this new script can be integreted and will solve the problem!

• the_CName Please :
  • I'm not practice usually this language 'english', write me as soon as possible the more simply... thanks to your understanding.
  • see this page to view bad or not supported element HTML : http://devht.stephane-huc.net/Test/Index

• 16/03/06 Contact at:Tom
  • Noticed that this script cannot work with text indents. (<div class='indent'>, which is translated to text-indent html code) Is there a way to solve this easaly because we have used it alot and now want to print out our documents.

• 8/18/05 - JasonGreen
  • I noticed that any markup that creates a <span> tag in your HTML will create a screwed up PDF file. For example, if you used %color=green%, you would get overlapping text in your PDF. Or, if you used [-This is some smaller text-], Adobe would say the font couldn't be found and make that text ridiculously huge. I'm using PmWiki 2.0beta30, though, so it may be something that's already fixed.
  • To get around it, I added the following line to cookbook/pmwiki2pdf/pmwiki2pdf.php:

 // Right after $pdf = new HTML2FPDF(); on line 53:
 $pdf->DisableTags('<span>');

=> the_CName : okay, thanks ... I've seen this problem ... Iv'e create a new archive with this implement in my code ! Is egual with this report bug in HTML2FPDF ? I believe it ...

Ok, I'm having to change my opinion because this recipe breaks the break-page one. Also, inline styles son't appear to come over too well.PB
the_CName the recipe breakpage is now understanding ! - 2005-08-20 !

• No, the script pmwiki2pdf.php no redefine your Schlaefer markup.
• In principle, the script pmwiki2pdf translate the wikitext by functions PmWiki ( ReadPage() and MarkupToHTML() ) .
• In the version, before 2005-08-20, the script no transform your markup in tag necessary and comprenhensive

for translate to PDF.

• Since the version, i've search your markup (defined in your differente version : "====/(:breakpage:)/____" break_page.php and break-page.php scripts) and it transform this markup in tags comprehensive for the class PDF.
• and the pdf action (as you write : $HandleActions['pdf'] = 'HandlePDF';) exists since the first version !\\ It's Pm that turn me...

The problem PB mentions is that you write in pmwiki2pdf.php

 $HandleActions = array(
  'browse' => 'HandleBrowse',
  'edit' => 'HandleEdit', 'source' => 'HandleSource', 
  'attr'=>'HandleAttr', 'postattr' => 'HandlePostAttr',
  'pdf' => 'HandlePDF',
 );

So you overwrite the $HandleActions in pmwiki.php and any other definition in any other cookbook (break page for example) that was included in config.php before pmwiki2pdf.php. But this is not necessary. You need only append your pdf action to the $HandleActions array by replacing the code above with

 $HandleActions['pdf'] = 'HandlePDF';

Schlaefer August 21, 2005, at 10:22 AM

add in function HandlePDF() this :

[after] //read wikipage
$page = ReadPage($pagename);
//this line :
$licence = ReadPage('PaganWiki.PaganWikiOpenContentLicense');

[before] //transform text to html
//this line :
$xyz['licence'] = mv_breakpage($licence['text']);

[after]] $html = change_code(MarkupToHTML($pagename, $xyz['text']);
//this lines :
$html .= "<page_break>";
$html .= change_code(MarkupToHTML('PaganWiki.PaganWikiOpenContentLicense', $xyz['licence']));

Save this modification, and upload you script modified in your ftp user ... run ?

If you have a pb, contact me ;-)

PS : For your question, i believe that necessary -1- to parse it in code (x)HTML, -2- to return this code HTML in variable PHP, and -3- to transform the pmwiki2pdf.php script by others modifications...

Vincent Voois August 27, 2005, at 12:04 PM
I like the module. Just one of the problems is that Adobe 7.0 doesn't embed itself into the browser anymore (i don't know why, but i have to download the documents since i updated from 6.x to 7.x) so this creates pdfs being saved local and all URL paths are related to the file rather than the site (file:///c:/Documents and settings/....). This also causes that none of the images are embedded into the PDF. It might be better to add a comment where it is possible to a link to a static URL path rather than a dynamic one inside the PDF document.

If all does work well, the images span across pages and through the footers and page-numbers and this is one of the most irritating factors most html2pdf utilities have, since there are no calculations done on the image size properties and calculate if the lower edges would fall within the range of the bottom and side page borders. There is no scaling whatsoever.

Also it would be wise to state that you modified the source rather than "hacked" it as "hacking" is generally associated with the idea that something illegal has been done to make things possible while all used tools and sources in this scenario here, are available free for use.

Stephane Smets 14 sep 2005 - 08h20 I have a strange things : the generated filename for the pdf doesn't contains the extension, so the browser ask for download instead of showing the pdf. I try to look into the code, and.. find a line where the extension is added. So, ... bug?
I have also try the pdf option on http://doc.linucie.net and there is the same problem.
->the_CName 27 sept 2005 : Please, update your Adobe Reader client to his ultimate version ... it's a security bug with Internet Explorer (search it, at "Adobe Acrobat Control Activex")
With others browsers web, it's run correctly ! ... egual on linux station !!!

Other thing, as mentioned by Vincent Voois, no picture is added in the pdf. IS there plans to change this?

Thks for the help

Christophe David 2005/09/18

The generated pdf files do not include the images from the HTML page due to the fact that an incorrect path is supplied to fopen() in html2fpdf.php.

This can be corrected by replacing line 218

by

How to generate the PDF file with the title (eg. PmWiki2PDF)? currently it only has the contain but without the title (or the path of the wiki) -rhiino 9/21/2005

Stephane Smets 28 sep 2005 - 08h40

You can easily change in pmwiki2pdf.php the line : $xyz['name']['pdf']= ... to have a title in your format. By eg : $xyz['name']['pdf']= $GroupName.'_'.$xyz['name']['page'].".pdf";

RussFink 2005/09/24 There is a conflict with this and NumberedHeaders. Just by including the NumberedHeaders php script without actually using it, the ! headers will not appear at all in the PDF output. This is a showstopper of sorts, if you need numbered tables of content.

this script NumberedHeaders run differently that PageTableOfContents... 'n it "break" the output pdf !

I then tried with PageTableOfContents, and the PDF generates the following output. Headers do appear, and it does a nice job of automatically linking the sections and providing bookmarks in the output; however, it includes some funny "&ensp" markups in the output :

On this page...
1. Wiki Content
1. 1.1  Academic
2. 1.2  Practical (non-Academic?)
3. 1.3  General Content
2. Outside Content
1. 2.1  Humor

4. Oktober 2005: I noticed a security hole... the script deliveres PDF files of documents the user has no right to see. e.g. I passwort-protect a document, when viewing it it tells me to enter a password. But if I add ?action=pdf a PDF file is being generated and displayed. I double-checked with installing a naked fresh system with the latest version of both pmwiki and pmWiki2PDF and I get the same effect. Uli

4 Octobre 2005 : It's not necessary to write me in red ... 'n cause afraid all people. -- Yes, i've just test your explication, and i've seen the problem. I don't know how it's possible to include a password verification. I will try to join Pm... to explain me how can i implement this.

  $page = ReadPage($pagename);

  $page = RetrieveAuthPage($pagename, 'read', true, READPAGE_CURRENT);

10. October 20005 Please explaine me the differen methods

1. setBasePath ( to return a good path to include img)
2. UsePre
3. UseCSS

What is there meaning? How do I use them? --fraz

• changed pmwiki2pdf.phpΔ by Daniel Scheibler on 2005-11-17
  • add HandleAuth['pdf']
  • change ReadPage(...) into RetrieveAuthPage(...)

december 10, 2005 - hfwang

For some reason the PDF document created with this recipe do not contain any images. I treid the above solution, even the hardcoded part in the main script, but no luck. Can somebody please take another look at this 'issue' please? TIA

verify the variable $xyz['path'] as egual : $xyz['path'] = $_SERVER["DOCUMENT_ROOT"];
if that's ok, test to replace $pdf->setBasePath($xyz['path']); by $pdf->setBasePath($xyz['url']); ...

december 12, 2005 - hfwang

Hi the_CName, thanks for the swift response, much appreciated. Unfortunately it does not function yet. I tried setting both variables in any combination (and ofcourse with the correct path), but no luck so far.

Variables tried:

$xyz['path'] = $_SERVER["DOCUMENT_ROOT"];

$pdf->setBasePath($xyz['http:/www.mydomain.com(approve links)']); this could'nt run, because not exists... try : $pdf->setBasePath("http:/www.mydomain.com(approve links)");