Category: PDF

mpdf fails to print the output from PluginGanttChart
You can see it reproduced when you attempt to produce the PDF (by means of Tiki PDF option, using mpdf in the backend) from a wiki page showing the results on a sample Gantt Chart, such as the one reproduced in doc.t.o:
https://doc.tiki.org/Sample-Gantt-Chart

See what a local PDF printer (CUPS based, on linux, thorugh Firefox) produces:
{img fileId="1644" thumb="box"}

See what mpdf produces:
{img fileId="1645" thumb="box"}

Maybe this could be solved by firing casperjs in order to get at least some look & feel of the output from that gantt chart?
Clicking at the "print" icon in the toolbar from the plugin ganttchart itself seems to display something similar

Reproduced in branch 24.x here:
http://xavi-9794-7940.show2.tikiwiki.org/tiki-index.php?page=Sample-Gantt-Chart
u: admin
p: 12345

At https://tiki.org/forumthread70022-mpdf-Generates-Black-PDF-docs

Logged, I tried to check the PDF feature by going to the "Thread actions", click on the item "PDF".

It downloaded a blank document onto my computer.

Tested on Tiki24 still here.

pdf generation (using mpdf) doesn't include diagrams if only local casperjs installed (as composer package, and preference "File Galleries (control panel) > Settings for Diagrams > __Use locally CasperJS to export images__" enabled) but the other preference "__Use draw.io public services to export images __" is not enabled.

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:
{file type="gallery" fileId="1563" showicon="y"}

Export a pdf version of slides (using mpdf) from the slideshow fails to respect image sizes when within ((doc:PluginFluidgrid)), and therefore content overflows slides in some cases.

Example of code from a production site:
{CODE()}
{slideshow theme="sky" transition="slide" transitionSpeed="default" backgroundTransition="none" controls="y" controlsLayout="bottom-right" controlsBackArrows="faded" progress="y" slideNumber="y" fragments="n" fragmentClass="grow" fragmentHighlightColor="none" autoSlideStoppable="y" alignImage="n"} ^Presentació a: https://foo/bar ^
{FLUIDGRID()}~~cyan:.~~ {DIV(style="text-align:left")}
__Apartats de la xerrada d'avui__ (''Xavier''):
1. Dades crues
2. Processat de dades d'un mes
3. Processat múltipes mesos
4. Ingesta Dades Fusionades a CityOS
5. Ús de les dades
6. Pendent: Errades en agregats esbiaixats
7. Altres (per qui vulgui saber més detalls ;-)
{DIV}
{img fileId="4"}
---
{img fileId="5"}
---
{img fileId="6"}
{img fileId="7"}
{FLUIDGRID}
{CODE}

Slideshow displays images in the fluidgrid as expected:
{img fileId="1566" thumb="box"}

However, the pdf version does get the images splitted in several slides/pages.
{img fileId="1567" thumb="box"}

Similar issue reproduced here:
http://xavi-9794-6688.show2.tikiwiki.org/tiki-index.php?page=new_page
u: admin
p: 12345
In this show instance, nothing is displayed in the pdf.
Using latest 24.x branch: r79594 (Last Changed Date: 2022-01-22 14:46:09 +0100 - Sat, 22 Jan 2022)

I attempted to print thorugh mpdf the pivot tables which are shown after applying (plus table converted to heatmap-table) the profile Bug_Tracker_16 , and I got an error 500 WSOD

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/
Log in first as admin:
u: admin
p: 12345
Visit then;
http://xavi-9794-6688.show2.tikiwiki.org/tiki-print.php?page=Bug+Tracker&display=pdf

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

Similar error 500 WSOD when attempting to produce a PDF from a wiki page which includes tracker calendar displays:
Log in first as admin
Then visit:
http://xavi-9794-6688.show2.tikiwiki.org/tiki-print.php?page=Tracker_as_Calendar_19&display=pdf
---

mPDF produces 'Controller not found (AutoSave)' when attempting to print some wiki pages since site upgraded to tiki 17svn from 15.x. Using mPDF 6.x from composer in both cases.
It's an intranet, but I can provide page contents of one of them to a developer willing to debug the issue.
re: aspbsgmobils

mpdf (tested in latest 19.x svn and latest mpdf from composer - through packages control panel) doesn't seem to include content from plugin REMARKSBOX.

See it reproduced here:
https://adup.cat/181218

Some accents are mangled from wiki page headings when printed in the pdf produced by mpdf 7.x

{CODE()}
! {{page}}
!! Full de Càlcul Oficial (Mònica)
text
!! Previsió inicial GID
(...)
some convene plugin, ...
{CODE}

Produces:
{CODE()}
Table of Contents
GID -Â Vacances ..........................................................................................................................
2
Full de Cà lcul Oficial (MÃ2nica) ......................................................................................
2
PrevisiÃ3 inicial GID ...........................................................................................................
2


GID -Â Vacances
Full de Cà lcul Oficial (MÃ2nica)
text
PrevisiÃ3 inicial GID
(...)
some convene plugin, ...
{CODE}

when trackers set to show comments below tracker items, and section headings are shown as tabs: comments are shown below each one of the tabs of the tracker item printed (therefore, duplicated info many times)

doesn't include graphics from privottable plugin. Example: pivottable in bugtracker16 summary tab

using mPDF to print pdf works nicely in most cases, thanks (using 17.x svn)
We have one wiki page, though, where we get this error:
{CODE()}
Error
Controller not found (AutoSave)
{CODE}

Is that a known issue (some sort of interaction with AutoSave)?
That wiki page (it's an intranet, sorry) has this plugins:
* fluidgrid
* quote
* fancytable (with tablesorter)

Any clue?

Re: smartphones page at work

some images are printed, but some others are not, and they seem to need to have no other params params than the minimum, however, using standard syntax from a brand new tiki site embeds wiki pages with a syntax that mpdf is not able to make it just work, and images are not shown in the pdf produced.

Reproduced here:
http://seeds4c.org/Ubuntu+16.04+LTS+for+Human+Beans
(you can produce the pdf by yourself there)

Code that mpdf doesn't seem to like:
{CODE(ln="1" colors="tiki")}
{img src="display466" link="display466" width="400" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"}
{img fileId="60" thumb="box"}
{CODE}

Code that mpdf seems to like:
{CODE(ln="1" colors="tiki")}
{img src="https://www.hecticgeek.com/wp-content/uploads/2012/09/Editing-the-disable_wol-script-in-Ubuntu-12.04.jpg"}
{img src="display550" width=600}
{CODE}

(removed the examples with params like src="dl437&display" since they were written by the time when tiki accepted that oldish syntax by mistake){sign user="xavi" datetime="2018-07-24T23:05:08+00:00"}

---
Update: {sign user="xavi" datetime="2018-06-21T11:04:30+00:00"}
In a production server in our work, no images are shown in the pdf at all, with neither syntax. Is there any log file with potential information on why no images are shown in the pdf produced by mpdf?
I confirm that we have php7.0.* and php modules gd, & mbstring installed server side.

Xavier

I removed "19.x" categorization because branch 19 doesn't exist yet. The category "regression from version 18 to 19" is accurate here and already assigned. {sign user="chibaguy" datetime="2018-07-12T07:46:41+00:00"}
---
Update answering luci (Why can't standard users reply to comments, such as my user "xavi" wit no admin rights? :-/ ). Answering here instead (lacking time):{sign user="xavi" datetime="2018-07-24T23:02:41+00:00"}
* replacing that old syntax with new and valid syntax (? intead of &) still yields some broken images in the pdf produced by mpdf. I granted access to amnabilal to a server where she can reproduce. I didn't hear any more feedback from her about it, but I confirm that this issue still exists in several servers of mine, with different setups.{sign user="xavi" datetime="2018-07-24T23:02:41+00:00"}
---
Update: Default syntax with param -+thumb="box"+- keeps images away from the printed pdf (even with valid https cert and fully valid params aside of mpdf) {sign user="xavi" datetime="2018-11-26T22:16:13+00:00"}
Example:
{CODE()}
{img fileId="60" thumb="box"}
{CODE}
---
Issue with -+thumb="box"+- or -+thumb="zoombox"+- for instance, confirmed still in 21.5vcs as of today {sign user="xavi" datetime="2021-11-19T16:14:52+00:00"}

When using the ~np~[#Header|Header]~/np~ in a Wiki page and referencing to a header on the same page it works as intended but not after exporting it with mpdf to a PDF these links are blue and clickable but don't serve their purpose of jumping to their anchors.

Workarounds are using the Plugin ALINK/ANAME which only opens the browser with the given page which is not quite the intention of having it exported as PDF. Another one is using the HTML Plugin which worked for the page and to jump to the anchor in the PDF but is troublesome for further maintaining multiple bigger pages with this Syntax.

I have the assumption that tiki is referencing the ID attribute for the anchor in the A Tag rather than a name tag which mpdf actually supports.
https://github.com/mpdf/mpdf/issues/1055

internal wiki links are not clickable nor converted to the absolute url counterparts in the pdf when the option to show links at the bottom is selected in the tiki admin panel.

Reproduced here:
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) --

Upgraded today (server side) to latest 24.x branch: r79594 (Last Changed Date: 2022-01-22 14:46:09 +0100 - Sat, 22 Jan 2022)

In that page, there is an internal wiki link to HomePage:
{CODE()}
((HomePage))
{CODE}

The user would expect to have that link converted in the pdf as a link to:
http://xavi-9794-6688.show2.tikiwiki.org/tiki-index.php?page=HomePage

but it's not converted to any link, it's just shown as simple standard text (with no indication that it refers to another page in that tiki site)

See the pdf produced by mpdf for instance here:
{file type="gallery" fileId="1563" showicon="y"} (using trunk from august 2021, r78798)
{file type="gallery" fileId="1706" showicon="y"} (using branch 24.x Jan 2022, r79594)

Printing a structure with mpdf, some things are not printed properly:
* Footer (or header) {PAGETITLE}
A wiki page itself can be printed to a PDF, and {PAGETITLE} __in the footer __ will be translated correctly to the footer. But once the same page is printed as part of a structure, {PAGETITLE} in the footer will only produce a void.

* Plugin Last Modification
A wiki page itself is printed to PDF correctly showing the value for {lastmod}. If the same page is printed as part of a structure, {lastmod} will not be translated.

Working in wiki page alone:
{img fileId="1440" thumb="box"}

Bug in structure:
{img fileId="1439" thumb="box"}

This url:
https://nextdoc.tiki.org/tiki-print.php?page=Documentation&display=pdf

comes from clicking at the PDF icon of the homepage, as a non-admin user loged in (in case it matters), and it produced a white screen with this error message:

"Unable to generate PDF"

On a working Tiki 24.x (253bcbb09b2f1c2df4bced1802f4c13cc0cf32be, 253bcbb0 · [FIX] PluginManager: move source code link with other general info · 1 day ago);

If I diagnose composer from the shell I have:
{CODE()}
tsaharoniki@server001:~/public_html$ ./temp/composer.phar diagnose
Checking composer.json: WARNING
License "LGPL-2.1" is a deprecated SPDX license identifier, use "LGPL-2.1-only" or "LGPL-2.1-or-later" instead
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
__Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0 87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B 0C708369 153E328C AD90147D AFE50952__
OK
Checking composer version: OK
Composer version: 2.2.9
PHP version: 8.1.4
PHP binary path: /usr/bin/php8.1
OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
cURL version: 7.64.0 libz 1.2.11 ssl OpenSSL/1.1.1i
zip: extension present, unzip present, 7-Zip not available
{CODE}

I install the package mPDF (see the recording): {file type="gallery" fileId="1786" showicon="y"}

My Vendor folder is updated (today's date) and inside other folders have been updated or added
{CODE()}
drwxr-xr-x 8 tsaharoniki tsaharoniki 4096 Mar 27 13:25 vendor
tsaharoniki@server001:~/public_html$ cd vendor
-rw-r--r-- 1 tsaharoniki tsaharoniki 178 Mar 6 20:46 autoload.php
drwxr-xr-x 2 tsaharoniki tsaharoniki 4096 Mar 27 12:08 composer
drwxr-xr-x 3 tsaharoniki tsaharoniki 4096 Mar 27 12:08 mpdf
drwxr-xr-x 3 tsaharoniki tsaharoniki 4096 Mar 27 12:08 myclabs
drwxr-xr-x 3 tsaharoniki tsaharoniki 4096 Mar 6 20:46 npm-asset
drwxr-xr-x 3 tsaharoniki tsaharoniki 4096 Mar 27 12:08 paragonie
drwxr-xr-x 3 tsaharoniki tsaharoniki 4096 Mar 27 12:08 psr
drwxr-xr-x 3 tsaharoniki tsaharoniki 4096 Mar 27 12:08 setasign
{CODE}

In the file : vendor/composer/platform_check.php there is a check for PHP8

{CODE()}
if (!(PHP_VERSION_ID >= 80000)) {
$issues[] = 'Your Composer dependencies require a PHP version ">= 8.0.0". You are running ' . PHP_VERSION . '.';
}
{CODE}

This forbid the Tiki to run with PHP7.4.

On most of Virtual servers and Cpanel (tested on Server Debian10 running Virtualmin) you can select the PHP version that will be used for this domain. You can select a different PHP version than the one used by the server for the HTML backend.

It work usually fine.

However users don't have any option when this is about the PHP CLI. (php -v)

Developers have workaround like :
php74 console.php ...
sh setup -p /usr/...

It is usually fine for developers.

However for Admins (or power user) there is no option to select the PHP CLI version.
Like:
* tiki-check.php
* tiki-admin.php?page=packages
* ... ?

Printing to Adobe's PDF format (Portable Document Format)

As a wiki page has the option to be exported as PDF, in the same manner it would be useful to get the option for articles.

When a page is restricted by permissions, this page cannot be exported to pdf using the pdf icon.
The result is a pdf that contains the message "You do not have the permission to view that page....".
The reason for that is that the pdf export contains NO mechanism to pass the authentication of the logged-in user to the pdf tool. So the pdf tool (i.e. wkhtml2pdf) calls the page in question as an un-authenticated user.

Update:
Main issue fixed. Restricted pages require token authentication enabled to be exported to pdf.
Feature: "auth_token_access".

Note: If the page acts as a template for tracker input - access is still debied. This might be an issue with the "auth_token_access" feature itself and should be a new bug report bc it might effect other areas as well.

PDF-generation does not work at all in Opera 9. The pdf generation page is shown, but when you click "create" nothing happens. I have check this for wiki pages and articles. I don't know if pdf-generation is available for other features.

first of all excuse me for accidentaly logging with this account

version v1.9.0 -Sirius
I am working on setting up a tikiwiki in bulgarian language for internal usage.
I have made partial translation of the language to bulgaian (keeping the UTF-8 encoding)
The main encoding used in BG is windows-1251 (it sucks and is tottaly incompatible i know)
I have a very simple page which is in cyrilic (bulgarian) in the DB it is stored as UTF-8.
When trying to generate PDF the process passes just fine. The only problem is that all non english text is seen as question marks.

I have tried changing te WinAnsiEncoding to builtin in class.pdf.php, but that doesn't help. If you need i will provide a samples from WinAnsiEncoding and builtin

All suggestion's appreciated

Platform:
tikiwiki Version 1.9.4
RHFC 4 (2.6.17-1.2139_FC4smp #1 SMP)
PHP 5.0.4 (with php-xml-5.0.4-10.5)

UPDATE:

OK, it looks like the problem was due to strange characters (I had copied-and-pasted from another tikiwiki site).

So, if I create a new wiki page and try to create a PDF from that, I get further. This time, I get a pge full of the PDF codes! I've tried using both IE6 and Firefox 1.5.0.6.
I noticed another poster complaining about problems with Opera 9.

I don't think it's a browser issue.

============
Problem:
PDF Generation doesn't work. After clicking the "Create" button, the resulting page (tiki-export_pdf.php) is blank.

I added some debug statements to the code, and it appears that everything is fine up to this statement in function insert_html (source file: pdflib.php):

$this->flush($src);

In the line before:

$this->WalkParsedArray($htmlparser->content,$src,$dummy);

if I print out $src, I can see the contents fine. But the flush statement following doesn't seem to work. In fact, if you append an echo statement after that, it doesn't execute:

$this->flush($src);
echo "after flush\n"; <=== doesn't display

In the code for flush(), I added more echo statemnts.

function flush($src) {
echo "<h2>entering flush</h2>";
$this->ezText($src,$this->tiki_textheight);
echo "<h2>leaving flush</h2>";
}

I also added echo statements in ezText().

Interestingly, "entering flush" is printed followed by REPEATED calls to ezText. The "leaving flush" statement is NOT printed!!

This is very weird.

I know the PDF generation feature worked fine in version 1.7.1.

Any ideas what's going on? I can send the entire debug output if it will help.

Thanks,

paul