Category: PDF

Show subcategories objects

Name Type
PDF Generation from structures seems to have trouble with some images
Adding "Tiki Transforming" structure from:

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
tracker item
13.x dev.tiki.org wiki pages: "Unable to generate PDF"
tracker item
14.x: Export Slideshow to PDF produces Fatal Error
tracker item
tracker item
PDF Bugs with WikiLinks and Smilies
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"

Thanks to all developers Tiki is a very good CMS.

tracker item
wkhtmltopdf doesn't work without an X server
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.
tracker item
Allow replacing hardcoded call to maketoc in page with the one produced by mpdf
tracker item
Diagram not exported to PDF (mPDF)
tracker item
Display row and col borders by default when tiki spreadsheets are printed in simple mode with mpdf
tracker item
doc.t.o 12.x: Printing a structure to PDF produces a PDF with "Your access to this page has expired"
tracker item
Error when using the actions item "PDF"
tracker item
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)
tracker item
Hard to see the PDF generation remarksbox (wait...)
tracker item
improvements to the printing process of a full structure like the one in doc.tw.o/Documentation
^ 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:

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:

* 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....
tracker item
tracker item
Keep color highlighting from PluginCode at the mpdf printed version
tracker item
tracker item
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.
tracker item
mpdf 6 PluginPdfPage: Allow to override global setting to create toc in a specific page
tracker item
mpdf could include content from plugin map
tracker item
mPDF generates an empty (blank) document on the t.o forum
tracker item
mPDF produces 'Controller not found (AutoSave)' in some wiki pages
tracker item
mpdf should include content from plugin remarksbox
tracker item
mpdf: accents mangled
tracker item
mpdf: comments duplicated many times in printed tracker item with tabs and comments below
tracker item
mpdf: doesn't include graphics from privottable plugin
tracker item
mPDF: Error Controller not found (AutoSave)
tracker item
mpdf: images are not shown in printed pdf with default syntax (and never in some servers)
tracker item
mpdf: internal links to headers of the same page don't work in the created PDF
tracker item
mpdf: internal wiki links are not clickable nor converted to the absolute url counterparts
tracker item
mpdf: Print Structure -> issues with {lastmod}, {PageTitle} not shown in footer/header
tracker item
nextdoc.t.o homepage unable to generate PDF
tracker item
Printing to Adobe's PDF format (Portable Document Format)
PDF creation of articles
tracker item
PDF do not work when exporting restricted pages
tracker item
Pdf generation does not work when using browser Opera v9
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.
tracker item
pdf generation does not work for Bulgarian language
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
tracker item
PDF Generation does NOT work!
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)


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
I noticed another poster complaining about problems with Opera 9.

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

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


In the line before:


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:

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>";
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.


tracker item
PDF Generation Fails on tiki.org
tracker item
PDF generation for structures creates badly named file
In 1.9.2, the ability to create PDF files from structures is fixed (which is great). All files in the structure are now automatically added to the include list when the PDF icon is clicked while in an active structure.

However, the resulting file is badly named. For example, in a structure consisting of:

test structure [view |edit]

* 1 numbers [x] [view |edit]
o 1.1 one [x] [view |edit]
o 1.2 two [x] [view |edit]
* 2 colors [x] [view |edit]
o 2.1 blue [x] [view |edit]
o 2.2 green [x] [view |edit]


the resulting PDF file is named "green" rather than "test_structure.pdf" or "test structure.pdf". Not only is this generally confusing (naming the pdf file for the last page in the structure is pretty counter-intuitive), but the lack of the PDF extension prevents the browser from automatically opening the file. I was able to force the file to open with Acrobat Reader 5.0 for Macintosh on OSX 1.3, but only after setting the file filter to "all files." Many less experienced users would have stalled before this.

The PDF generation should default to the name of the structure plus the ".pdf" extension, and probably should also allow this file name to be manually changed before the PDF is generated.
tracker item
PDF generation of wiki pages doesn't handle tables
When you generate a PDF of a wiki page, tables extend beyond the edges of pages. Apparently, during generation the text in the tables isn't wrapped to make the table fit the width of the page.
tracker item
PDF generation of wiki pages not working on nextdoc/nextdev
tracker item
PDF print a tracker item show a white page for anonymous
tracker item
Plugin DBReport with mPDF enhancement
tracker item
print to pdf doesn't use the custom css from the L&F control panel
tracker item
tracker item
structures and printing improvements for doc.tw.o and any documentation project based on Tiki
Documentation of Tiki (doc.tw.o) needs some help, as well as any other tiki site aiming to produce structured documentatation to be exported as "printer-ready" (.pdf, .odt, ...)

!!- (1). Original idea, as posted in devel list (but improved, and made it easier, below, in (2) )
I include here a copy of the [http://sourceforge.net/mailarchive/forum.php?thread_name=467565F1.9080905%40ub.edu&forum_name=tikiwiki-devel|original post at tiki-devel list]:

[Tikiwiki-devel] New documentation file: Tiki198alpha.pdf
From: Xavier de Pedro Puente <xavier.depedro@ub...> - 2007-06-17 16:44


There are some issues that, it solved from coders, they would make
easier to produce next documents like the pdf ones:

(1) Page Title is not automatically shown on wiki pages on the server,
and thus, manual header1 was added everywhere (Almost). But when
printing to html, page title is duplicated. => if Show Page Title option
is disabled under "Admin > Wiki", Page title should not be added
automatically at print-to-html time.

(2) to produce the same structure (same level structure of headings) as
in table of contents http://doc.tikiwiki.org/Documentation , some hack
(optional) would be very welcome so that heading 1 in doc.tw.o pages is
not printed as heading 1 in through the multiprint, but as header 2, at
least. (optional).
This is, for instance, what is produced when printing a full structure
from a Workspace - AulaWiki Mod - : a coder could grab the code from
AulaWiki Mod as a reference....
In there, the description of the page is set as the Page title (header
2, I think), and the page title is included below for completeness (in
lower font, and with version number next to it)...


(3) Numbering of headings: somehow, in Workspaces this is handled
internally, and the user/documenter doesn't need to bother with manual
numbering: it's produced also at print time.

Example of print structure differences between Tiki's multi-print and
Workspaces print structure:

Print to html "Aula-Wiki Tutorial" from here:

or from here:

Well, as you could imagine, some changes to the code to make the work of
documenters a bit easier would be very wellcome also... :-)



!! (2) Update July 20th: Easier solution
Easier solution: Get levels for first heading in each wiki page of the structure not from the content of the page.

^__Example__: a page may start with a "! Title of page" (first level heading), and after that, "!! Subtitle of page" (2nd level heading), ...

Imagine that this page corresponded to "2.3.1 Module whatever" as the level in the table of contents of such structure.

The solution would be then that "!Title of page" (in that page "2.3.1 Module whatever"), when sent to (or fetched by) tiki-print_pages.php as a whole structure, was converted to "!!! Title of page"; and "!! Subtitle of page", should be converted to "!!!! Subtitle of page"..., and this way sequentially for all the title headings on each page from the structure...

The procedure below should become a 1-click from wiki (structures) to[http://doc.tikiwiki.org/Tiki19beta.pdf|PDF]. Please see:[http://doc.tikiwiki.org/Printing+the+Documentation|How to produce the .pdf out of the .odt]


Dec 13 2008. Update:
Previous problem is fixed. However, I notice that automatic numbering with heading within a page (!!#, !!!#, ...), should be also considered in the global autonumbering.

Plus width of wide images and tables would be better if not that wide when exported to html (maybe an option), for the case when you plan to import it to OpenOFfice, and they are too wide to the document. Should this be another RFE or bug report?

update on Jan. 7th, 2009:
See the other bug report: autonumbering didn't work for me with doc.tw.o/Documentation, even if it did a month ago on another site/structure

Related (and newer) bug report/RFE:
tracker item
Table of contents in the pdf produced by mpdf doesn't respect page orientation param set in plugin pdfpage.
tracker item
Tikiwiki Book
Implement something like the special page [http://en.wikipedia.org/wiki/Special:Book|Wikipedia Book] to generate some revenue from community assets
tracker item
Usability improvements for File dialog (icon in wiki page editor)
!Problem Summary
The dialog structure for uploading a file and adding a link to it in wiki page is much better than it was, thanks to the introduction of the __File__ icon in the toolbar of the wiki editor. But it is still cumbersome and error prone. Here is the process below and the usability issues that I found at various spots.

# Click on the __File__ icon
# Pick __File Gallery/Archive__ in __Type__
# Click on __Pick a file__ link
# Click on the __Upload File__
# Click on the __Browse__ button
# Click on __Upload__ button
# Browse the file system and pick the file.
# Once the file is uploaded, click on its name.
# Click on __Insert__ button

Besides the fact that this is long, there are many places where it is misleading to the user (details later). I had to try this more than a dozen times, clicking on different items, to figure out how it works. And I had help from some experts on the mailing list!

Fortunately, there are a number of very small fixes that we could implement to address those issues. See below for a discussion of the various issues and proposed fixes.

!Issue 1: __Type__ should have a reasonable default
Currently, the type is set to empty. It really should be set to either __File Gallery/Archive__ or __Attachment__ by default. Personally, I would favour __File Gallery/Archive__, because I think it's generally a bad idea to attach files to a wiki page, because it limits your ability to link to those files from other pages. But the point is: the value should default to what users most commonly use.

In some cases, the picklist only has one option in it anyways (ex: if the feature for attaching files to wiki pages is off). In those cases, then the picklist should DEFINITELY default to that single value.

^Fix: Set the __Type__ to a sensible default... I vote for _File Gallery/Archive__^

!Issue 2: __Pick a file__ link looks more like a caption than something you can click on
I never realized that I could click on it to choose the file. Someone had to actually point that out to me. Others on the mailing list have said that they need to point this out to users all the time.

^Fix: Change the link to a button^

!Issue 3: Too easy to miss the __Upload__ button
Once you click on __pick a file__ link, you are presented with the general screen for navigating and managing the File Gallery. But at this point in time, you are only intersted in uploading or choosing a file from the gallery, and seeing this complex dialog is very disorienting. In my case, I managed to miss the fac that there was an __Upload__ button on that screen, and I thought I had mad a mistake and someone pressed the wrong button or link in the previous screen. I had to go back to the previous screen several times and click on different things, and finally come back to clicking __pick a file__, and then I saw the __Upload__ button.

^Fix: Instead of having a single __Pick a file__ link (well, button, if we implement the fix to Issue 2), we should have two buttons: __Upload__ and __Choose from Server__. Or something like that (I can't think of a good workding). The __Upload__ button will take you directly to the place you currently get to after clicking on the __Upload__ button in the File Gallery screen. The __Choose from Server__ button will still take you to the __File Gallery__ navigation and management menu.^

!Issue 4: Not clear that you have to click on the file name after uploading
In Step 8, there is nothing that tells you you need to click on the file name after you uploaded it. I went through the whole process several times and it never occured to me that I had to do this until someone from the mailing list told me.

Note that there is a message to that effec that appears if you hover the mouse over the file's name. That message really should be visible at all times, not just when you hover over the file name.

^Fix 1: Make it so you don't need to click on the file name altogether.

Fix2: If that's not possible, at least put a very prominent messages saying that the user needs to click on the file name^

!Issue 5: Insert button is not clear.
In Step 9, you are back at the original pop up, and you need to click on the __Insert__ button, otherwise the link to the uploaded file does not get inserted.

Again, I had to do the process several times before realizing I had to do this. My natural tendancy was to close the popup, either by Xing it or clicking on the __Close__ button. The result is that the file does not get inserted on the page.

I think the problem is that the two buttons at the bottom say:

__Close__ __Insert__

And you naturally tend to click on the first of these two, i.e. __Close__.

^Fix: Change the order and caption of the two buttons as follows:

__Insert link__ | __Cancel__

Also, if the user clicks on the X to close the window, the link should be inserted (in other words, __Insert link__ should be the default). The reason is that it's easier to recuperate from that error (you just need to erase the link) than to recuperate from the other error (you have to start again from the beginning, to insert the link).
tracker item
ViewerJS PDF viewer instable across browsers
tracker item


The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Articles & Submissions
BigBlueButton audio/video/chat/screensharing
Browser Compatibility
Communication Center
Contacts Address book
Contact us
Content template
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Draw -superseded by Diagram
Dynamic Content
Dynamic Variable
External Authentication
Featured links
Feeds (RSS)
File Gallery
Friendship Network (Community)
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Inter-User Messages
Kaltura video management
Live Support
Logs (system & action)
Lost edit protection
Meta Tag
Missing features
Visual Mapping
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Performance Speed / Load / Compression / Cache
Revision Approval
Search engine optimization (SEO)
Semantic links
Shopping Cart
Site Identity
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Staging and Approval
Syntax Highlighter (Codemirror)
Tell a Friend
Terms and Conditions
Token Access
Toolbar (Quicktags)
User Administration
User Files
User Menu
Webmail and Groupmail
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives

Useful Tools