Category: PDF

Database error on [https://tiki.org/tiki-print.php?page=Community&display=pdf]

Seem the auth token isn't getting generated maybe?

I tried to update mPDF there via admin/packages and it said it failed because:
{CODE()}Problem 1
- Conclusion: don't install mpdf/mpdf v8.0.7
- Conclusion: don't install mpdf/mpdf v8.0.6
- Conclusion: don't install mpdf/mpdf v8.0.5
- Conclusion: don't install mpdf/mpdf v8.0.4
- Conclusion: don't install mpdf/mpdf v8.0.3
- Conclusion: don't install mpdf/mpdf v8.0.2
- Conclusion: don't install mpdf/mpdf v8.0.1
- Conclusion: don't install mpdf/mpdf v8.0.0
- Conclusion: don't install mpdf/mpdf v8.0.7
- Conclusion: don't install mpdf/mpdf v8.0.6
- Conclusion: don't install mpdf/mpdf v8.0.5
- Conclusion: don't install mpdf/mpdf v8.0.4
- Conclusion: don't install mpdf/mpdf v8.0.3
- Conclusion: don't install mpdf/mpdf v8.0.2
- Conclusion: don't install mpdf/mpdf v8.0.1
- Installation request for mpdf/mpdf ^8.0.0 -> satisfiable by mpdf/mpdf[v8.0.0, v8.0.1, v8.0.2, v8.0.3, v8.0.4, v8.0.5, v8.0.6, v8.0.7].
- Conclusion: remove setasign/fpdi 1.6.2
- mpdf/mpdf v8.0.0 requires setasign/fpdi ^2.1 -> satisfiable by setasign/fpdi[v2.1.0, v2.3.4, v2.1.1, v2.2.0, v2.3.0, v2.3.1, v2.3.2, v2.3.3].
- Can only install one of: setasign/fpdi[v2.1.0, 1.6.2].
- Can only install one of: setasign/fpdi[v2.1.1, 1.6.2].
- Can only install one of: setasign/fpdi[v2.2.0, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.0, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.1, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.2, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.3, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.4, 1.6.2].
- Can only install one of: setasign/fpdi[1.6.2, v2.1.0].
- Can only install one of: setasign/fpdi[1.6.2, v2.3.4].
- Installation request for setasign/fpdi (installed at 1.6.2) -> satisfiable by setasign/fpdi[1.6.2].
{CODE}

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]

(http://gaeacoop.org/tiki/tiki-index.php?page_ref_id=1)

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.

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.

Should be a server issue. assigned to amette to install lib.

Reopening because it looks like it is

duplicate of [item5325]

On a Tiki20 using mPDF with the PDF print option enabled Admins or Registered can successfully generate a PDF from the tracker item action menu.

If anonymous do the same he have a white page.
(I checked that all fields display data anonymous can see).

It can be seen [https://tsaharoniki.com/item89-%D7%99%D7%95%D7%9D-%D7%94%D7%9B%D7%99%D7%A4%D7%95%D7%A8%D7%99%D7%9D|here]

Hi Devs!

My setup:

Tiki: 18.0
PHP: 7.0.32
Linux: CentOS 7
mPDF: v7.0.3

One feature that bothered me was the lack of repetition of the header in PLUGIN DBReport when generated in PDF (usually via PLUGIN LISTEXECUTE) in tables that were divided into more than one page.

Reading the mPDF [https://mpdf.github.io/tables/tables.html#repeating-table-header-row-on-new-page|documentation] I discovered that the header line that was wrapped around the < thead> TAG is repeated on each page that the table is split.

!!Repeating Table Header row on new page
''If a table is split onto more than one page, the first row of the table will be repeated at the top of the new page if < thead> or < tfoot> is defined''


I changed the code in /lib/wiki-plugins/wikiplugin_dbreport.php file as the snippet below:

{CODE()}
615 public function header_row_html($data)
616 {
617 $html = '';
618 // generate a new table
619 if (isset($this->style)) {
620 $html .= '<table' . $this->style->attributes() . '>' . "\n" . '<thead>' . "\n";
621 } else {
622 $html .= '<table>' . "\n" . '<thead>' . "\n";
623 }
624 // write headers
625 $style_index = 0;
626 if (isset($this->headers)) {
627 $html .= $this->line_row_html($this->headers, $data, true);
628 }
629 $html .= '</thead>';
NEW return $html;
630 }
{CODE}

After this change, all tables generated by PLUGIN DBReport that split on more than one page in the PDF file automatically repeats the header.

I believe that other PLUGINS that generate tables (like PLUGIN LIST, for example) can benefit from this functionality (thead TAG involving the header line).

I have helped in something.

Salutes from Brazil!

print to pdf doesn't use the custom css from the L&F control panel

{img fileId="1943" thumb="box"}

Preferences:
feature_wiki_print = 'y' ('n')
print_original_url_tracker = 'n' ('y')
print_original_url_wiki = 'n' ('y')
print_pdf_from_url = 'mpdf' ('none')

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

This is demonstrated here:
http://user-11990-7501.show2.tikiwiki.org

With a wiki page this code
{CODE(theme="default")}Table of contents:{toc structId="1" shownum="1"} {CODE}
will produce this with a PDF generated:
{img fileId="1444" thumb="box"}

It does not matter if the wiki page is part of the structure or not.
On screen there are only numbers shown:
{img fileId="1445" thumb="box"}

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

{QUOTE()}
[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)...

edutwo_ws_print_structure4.png

(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.
[http://edu.tikiwiki.org/tiki-workspaces_view_structure.php?print=4]

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

Print to html "Aula-Wiki Tutorial" from here:
[http://edu.tikiwiki.org/tiki-print_pages.php]

or from here:
[http://edu.tikiwiki.org/tiki-workspaces_view_structure.php?print=4]

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

(...)

{QUOTE}

!! (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?

---
REOPENING BUG
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:
[http://dev.tikiwiki.org/bug2255]

Table of contents in the pdf produced by mpdf doesn't respect page orientation param set in plugin pdfpage.

Implement something like the special page [http://en.wikipedia.org/wiki/Special:Book|Wikipedia Book] to generate some revenue from community assets

{syntax type="tiki" editor="plain"}
{maketoc}
!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).
^

Hello,
thanks for all the hard work, Tiki is working great on our internal site.
I have a problem with ViewerJS.
- everything works fine for me (Linux, Firefox, latest version)
- I cannot get it to work for a user, using same browser as I do (Win, Firefox)
- the ViewerJS loads but displays a gray page
- same problem in full page and in embedded iFrame.
I got no response from the github ViewerJS part.
I could do debug of ViewerJS, but never done that in javascript, can someone provide some hints? Should I look at a specific function in the code, as I am wondering if the download of the file is hanging, or if it the display.
Thank for any help,
Hubert J.

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