Category: PDF

Adding "Tiki Transforming" structure from:
http://themes.tikiwiki.org/tiki-print_pages.php

I get and error (no PDF) and the following in my error log:

{img src=images/code.png}%%% {CODE(wrap=>1)}
[18-Jul-2007 13:16:46] PHP Warning: imagecreatefromstring() [<a href='function.imagecreatefromstring'>function.imagecreatefromstring</a>]: Passed data is not in 'JPEG' format in /home/themetw/public_html/lib/pdflib/pdflib.php on line 393
[18-Jul-2007 13:16:46] PHP Warning: imagecreatefromstring() [<a href='function.imagecreatefromstring'>function.imagecreatefromstring</a>]: Couldn't create GD Image Stream out of Data in /home/themetw/public_html/lib/pdflib/pdflib.php on line 393
[18-Jul-2007 13:16:46] PHP Warning: imagesx(): supplied argument is not a valid Image resource in /home/themetw/public_html/lib/pdflib/pdflib.php on line 394
[18-Jul-2007 13:16:46] PHP Warning: imagesy(): supplied argument is not a valid Image resource in /home/themetw/public_html/lib/pdflib/pdflib.php on line 395
[18-Jul-2007 13:16:46] PHP Warning: imagesx(): supplied argument is not a valid Image resource in /home/themetw/public_html/lib/pdflib/class.pdf.php on line 2887
[18-Jul-2007 13:16:46] PHP Warning: imagesy(): supplied argument is not a valid Image resource in /home/themetw/public_html/lib/pdflib/class.pdf.php on line 2888
[18-Jul-2007 13:16:46] PHP Warning: imagecreatefromstring() [<a href='function.imagecreatefromstring'>function.imagecreatefromstring</a>]: Passed data is not in 'JPEG' format in /home/themetw/public_html/lib/pdflib/pdflib.php on line 393
[18-Jul-2007 13:16:46] PHP Warning: imagecreatefromstring() [<a href='function.imagecreatefromstring'>function.imagecreatefromstring</a>]: Couldn't create GD Image Stream out of Data in /home/themetw/public_html/lib/pdflib/pdflib.php on line 393
[18-Jul-2007 13:16:46] PHP Warning: imagesx(): supplied argument is not a valid Image resource in /home/themetw/public_html/lib/pdflib/pdflib.php on line 394
[18-Jul-2007 13:16:46] PHP Warning: imagesy(): supplied argument is not a valid Image resource in /home/themetw/public_html/lib/pdflib/pdflib.php on line 395
[18-Jul-2007 13:16:46] PHP Warning: imagesx(): supplied argument is not a valid Image resource in /home/themetw/public_html/lib/pdflib/class.pdf.php on line 2887
[18-Jul-2007 13:16:46] PHP Warning: imagesy(): supplied argument is not a valid Image resource in /home/themetw/public_html/lib/pdflib/class.pdf.php on line 2888
{CODE}

To reproduce, visit https://dev.tiki.org/Tiki12

Click PDF link:
https://dev.tiki.org/tiki-print.php?page=Tiki12&display=pdf

{img fileId="820"}

14.x: Export Slideshow to PDF is broken
Feature:
http://doc.tiki.org/Slideshow#PDF_Export

See it reproduce here:
http://xavi-9794-5645.show.tikiwiki.org/tiki-slideshow.php?page=Tiki+Wiki+CMS+Groupware#
After cliking at the button at the bottom, to create the pdf out of the slideshow, and allowing popups from the site, this url is produced in the popup:
http://xavi-9794-5645.show.tikiwiki.org/tiki-slideshow.php?page=Tiki%20Wiki%20CMS%20Groupware&pdf&landscape&fontsize=large
u: admin
p: 12345

And the Error shown is:
{CODE()}
Fatal error: Call to a member function get_current_line_box() on a non-object in /var/www/xavi-9794-5645/vendor/dompdf/dompdf/include/absolute_positioner.cls.php on line 92
{CODE}

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

Hello,
i'm using the pdf extraction utility. It is really great. But there are some mistakes.
- WikiLinks are not shown properly as they are in the WikiPage.
- Smilies are placed as URL can not be upload. Even if the servername is set correct and the imgs are in that place

I tried using the existing BugReport at http://tikiwiki.org/tiki-index.php?page=PdfGenerationDev but what does
>>MOre to be add under #876666 on SF search "PDF"
mean?

Thanks to all developers Tiki is a very good CMS.

Moritz

When I tried using wkhtmltopdf for PDF export, all I got was 0 byte files. I turns out this is because the system running wkhtmltopdf must have an X server installed to work. This is not the case with my headless server, and I imagine that most web servers do not run X.

In 18.x (and probably earlier) you can print the table of contents on the fly in the pdf produced by mpdf (at pdf generation time), regardless of using hardcoded maketoc calls, o hardcoded title calls with wiki argument variable -+{ { page } }+- (no space intended between angle brackets).

^ Preference: Control Panels > Print > mPDF > __Table of contents__ ^

This feature is nice, but if would deserve another minor level of integration, for those cases in which:
# the Wiki page title is hidden by default, and placed by hand in the wiki page where needed (or replaced by human-(more-)readable text), usually at the top with a heading 1 level style.
** current behavior: mpdf places the table of contents at the top, and page title is shown below the table of contents, which is counter intuitive
# A wiki page has the AutoTOC setting disabled at wiki page level, and a hardcoded call to __~np~{maketoc}~/np~__ is placed below the page title (or wherever, with whichever maketoc params for the users like, such as levels="2,3", my favourite, btw).
** current behavior: mpdf keeps the table of contents produced by itself, plus the table of contents that was previously generated in the rendered html page by the wiki markup). therefore, 2 table of contents are shown, which is not what most users would expect.

Potential solution to both issues: (2 birdies in one shot)
__Allow replacing hardcoded call to maketoc in page with the one produced by mpdf__

How? Brainstorm mode on:
* add a new param -+inpdf+- in maketoc plugin, with several values:
** __replace__: -+~np~{maketoc inpdf=replace}~/np~+- Replace that maketoc call in the wiki textarea with the output of the table of contents from mpdf
** __keep__: -+~np~{maketoc inpdf=keep}~/np~+- keep same behavior as nowadays, for those edge cases in which user has custom maketoc for partial sections of the page (or whatever), which want printed also besides the full table of contents at the beginning, etc.
** __ignore__: -+~np~{maketoc inpdf=ignore}~/np~+- ignore the maketoc call when creating the pdf, so that the only maketoc is the one produced by mpdf at the beginning (for cases with wiki page created by Tiki itself, etc, so that placement of the maketoc from mpdf is the expected one, etc)

Opinions?

When generating a PDF from a wiki page diagrams are not shown in the PDF.

I printed in 20.x a tiki spreadsheet to pdf through mpdf (installed through the packages control panel), with the spreadsheet param -+simple=y+-

The printed sheet in the pdf page didn't display borders of rows and cols by default, which makes it difficult to distinguish rows or cols in some cases.
When choosing the print version of the wiki page, the cell borders where shown, and when printed locally through a locally installed pdf printer in the desktop computer, the borders where included in the pdf.

Is it difficult to add by default when making the pdf from mpdf directly? Or document somehow how to hack the code to add some custom css in the pdf files generated through mpdf?

Reproduced here:
http://xavi-9794-7140.show2.tikiwiki.org/tiki-index.php?page=Spreadsheet-demo-instructions
u: admin
p: 12345

See pdf generated here:
http://xavi-9794-7140.show2.tikiwiki.org/tiki-download_file.php?fileId=1

First sheet has simple=y, and borders are not shown.
Second sheet in the same page has simple=n, and borders are shown

doc.t.o 12.x: Printing a structure to PDF produces a PDF with "Your access to this page has expired"

Example:
"Tiki Reference Guide" at https://doc.tiki.org/tiki-print_pages.php

{img fileId="583"}

On doc.t.o (homepage) I tried to use the PDF item from the action menu.

{CODE()}PDF generation failed. The package mPDF is not installed. You can install it using packages. This is set by the administrator (search for "print" in the control panels to locate the setting).{CODE}

Find an easy way to help tiki users convert their slideshows made with tiki slideshow feature into a pdf of slides (for backup and life-saver when internet issues at presentation time)

Every now and then, we prepare presentations with the nice Tiki ((doc:Slideshow)) feature (jquery.s5)
But the day of the presentation, some issues might happen: internet connectivity issues, or others, like in the demo scheduled for the Tiki Roundtable Meeting for April 2015 from teh tekadvocates, etc.

The dompdf lib seemed to help with that, but it was never brought to a production level. See:
http://doc.tiki.org/Slideshow#PDF_Export

Some workaround is to make the slideshow by hand through screenshots of all slides, one by one, and then, convert them all into a pdf with external tools, such as gscan2pdf or similar.
http://gscan2pdf.sourceforge.net/

When you create PDF using Tiki (mPDF) using the wikitopline it take a little time and page is not staying on position but moving top.

If the wikitopline is not on the top of the page (and usually it is moved it down or remove it with bootstrap and mobile) the user won’t see the feedback unless he scroll to find it.

The problem is that from the user point of view it is like nothing is happening and he will likely think the feature is not working.

It could be a modal over the screen so all case (mobile) are covered.

^ Related to http://dev.tikiwiki.org/bug1184 . Opened a new one since those comments below are updated of a new trial I made today - Jan. 7th, 2009^
Issues detected while dogfooding "__minimum-clicks for pdf from doc.tw.o/Documentation structure__". An opportunity to improve the current features for production.
Related links:
http://doc.tikiwiki.org/Documentation
and
http://doc.tikiwiki.org/tiki-print_pages.php

Printed to html using SeaMonkey browser 1.1.12 and to pdf CUPS/pdf printer, both under Ubuntu 8.04 GNU/Linux
page numbers refer to a pdf produced today out of there:
[ftp://ftp.ourproject.org/pub/edutiki/090107_doc_tw_o___Tikiwiki_Documentation_SeaMonkey.pdf]
(25Mb)
-----------------------------------------------------------------------------

* Autonumbering of headings is shown on the table of contents, but not on the pages themselves (using the default theme in doc.tw.o, based on thenews.css I guess). I would say that this worked for me a month ago on a 2.1 site using feb12.css with another (shorter) structure of wiki pages ( http://www.iesbarcelona.org/ESSO350/tikiwiki-2.1/tiki-index.php?page=2008+Fall+-+Final+Paper ).

* page 39: .htaccess from dynamic content is not shown in the full page. Can this be modified at printing time so that the full content is shown on the page?

* page 41: a CODE block longer than a single sheet of paper is cut at the end of the page, not showing the rest of the content. Can this be modified at printing time so that the full content is shown on the page?

* Some pages didn't have the title manually displayed. Those ones doesn't show the title of the page (as section of the full pdf)... Maybe the best workaround is to add a setting for the user to select whether he/she wants adding all page names as titles to the pages, or not. For our case, maybe it's easier to remove extra title (easy to identify when you have too title too similar one after the other) than having to figure out where a new page starts... (see plugins pages...). Example: page 127: PluginJS is shown, fine, but not PluginLang, PluginListpages? Plugin Manager?, on the following pages...

* copyright license is needed at the end?

* It would be nice to allow at structure-printing time to select which version among the ones allowed by the PLUGIN VERSIONS (where applicable), had to be selected for printing. Right now, it might be useful for people looking for an updated documentation for their 1.9.x, so that all plugin versions were pre-set to display the content from 1.9.x. Moreover, after April (only some months to go for that) we will have the same issue with people looking for 3.x documentation, or just 2.x. Well, this is just to raise this point for the following months, so that, the better for us for producing our own documentation, the better for other communities producing their documentation using Tiki and coping with their versions also... (Firefox, for instance?)

* when the content is copied and pasted to OpenOffice (using OOo 2.x and 3.x), there are images or tables which are wider than the page size.

* Is it possible to have page breaks added before headings of level X (and let the user select a page break just before a heading level 1, and 2, for instance).
---
Update on Dec 7th, 2012 (Tiki9.x LTS):
* RFE still valid....

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

Keep color highlighting from PluginCode at the mpdf printed version

When you print a page with plugin code and color highlighting enabled (through codemirror), the mpdf produced page doesn't keep the colors.

Some code to easy copy & paste to any tiki 18.x install with mpdf:
https://dev.tiki.org/CodeMirror+Testing+v3

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

We can't get diagrams printed in pdf pages (generated through mpdf) in a tiki23 site behind a firewall. We have setup proxy info in tiki, and then we can use tiki profiles control panel, for instance, but we can't use composer web interface/control panel because the system is not able to connect to composer.tiki.org. It seems as if the system is not ready to use the proxy info provided in the tiki ui.

We have been able to print diagrams in tiki master (tiki23 can't be used yet in show2.t.o) in a show2.t.o instance when using __Use draw.io public services to export images__ (reported [item7802-mpdf-generation-doesn-t-include-diagrams-if-only-local-casperjs-installed-but-not-remove-service-from-draw-io|here])
However, we haven't been able to achieve the same goal in a test tiki23 site behind a firewall. So probably the proxy info needs to be added (if present) in the commands that mpdf uses or somehow?

mpdf seems to faill to include images in the generated pdf file when you use:
* some self-signed https certificate, or
* a valid one but issued from a certification agency (like from a local public administration, in our case at work) which is not recognized by your browser by default unless you import a specific authority file in the right place (and I don't know how to do that for mpdf).

I wish there was some way to tell mpdf to avoid checking https certificate validity, like the option you can have in many other programs (wget, curl, git, ...). If that is possible, then a new option should be added in Tiki UI to let the tiki site admin enable it in those known use cases in which you need that feature.

As an example, that would have allowed to use mpdf successfully in the last couple of years at work. And we still can't use it normally due to this issue.

{syntax type="tiki" editor="plain"}
This feature arrived in {mr id=5960} but wan't made optional sadly, i might get round to it one day, so this is just a reminder really

memory exhausted (even if 1Gb allocated to php processes!) after uploading big pdf (20Mb with images) to file gallery and tiki works server side with pdftotext and others.

Untested in other versions of Tiki.
It might very well be a problem with pdftotext, because the file uploads to the server fine, and the server processes the file with pdftotext after that, before showing the error message. Apache error log says memory exhausted.

Allow to override global setting to create toc in a specific page through PluginPdfPage
Otherwise, you get 2 table of contents in a wiki page ifyou have that parameter set globally in print control panel, and you also have toc in a long wiki page in production.

Example (where you can't override that setting):
http://seeds4c.org/Ubuntu+16.04+LTS+for+Human+Beans

mpdf doesn't seem to include content displayed through plugin map.
Tested using latest 19.x with mpdf (7.1) installed through control panel to install packages

See it reproduced here:
https://adup.cat/Inici#contentpestanyes_trobades-4

{syntax type="tiki" editor="plain"}
Printing with mpdf doesn't include images in many cases including params in the plugin img call such as zoombox, or when controlling the display of images from inside a ((doc:PluginFluidgrid)) , and in other cases reproduced in the show.t.o instance indicated:

Reproduced in a show2.t.o instance from another bug report (since setting up diagram generation requires some manual steps to get the composer package installed server side)
http://xavi-9794-6688.show2.tikiwiki.org/tiki-index.php?page=Tiki-Wiki-CMS-Groupware
u: admin
p: 12345

Current code used in the show instance:
SVN (24.0vcs): Tuesday August 3, 2021 17:34:21 CEST - REV 78798 (InnoDB)

See pdf produced with pdf:
{file type="gallery" fileId="1564" showicon="y"}

See the corresponding pdf produced by a local pdf printer from the print veresion of that wiki page:
{file type="gallery" fileId="1565" showicon="y"}


Code being used for the first sections about images:
{CODE()}

{FLUIDGRID()}
5: {img src="tiki-download_file.php?fileId=5&display" width="200"} 6: {img fileId="6" width=200}
---
7: {img fileId="7"} 8: {img src="tiki-download_file.php?fileId=8&display" width=400}
{FLUIDGRID}

!!# Local Image with zoombox
{img fileId="4" thumb="box"}

!!# Another local Image without zoombox

{img src="tiki-download_file.php?fileId=5&display"}

!!# A remote image with zoombox

{img src="https://doc.tiki.org/img/wiki_up/393px-Pears.jpg" thumb="box"}

!!# A remote image without zoombox

{img src="https://doc.tiki.org/dl1480?display&x=250&y=180" }

{CODE}
---

retested today upgrading the show instance to latest 24.x
"Upgraded today (server side) to latest 24.x branch: r79594 (Last Changed Date: 2022-01-22 14:46:09 +0100 - Sat, 22 Jan 2022) ", adn removed and reinstalled mpdf and diagram packages.
Same issue.{sign user="xavi" datetime="2022-01-22T23:32:38+00:00"}