Category: Print

At the bottom of each wiki page, when the print option is selected, a <HR> appears. I have checked the code, and it appears because the brackets have been escaped.

~np~</div>
&lt;HR&gt;
<p>
</p>~/np~


{img fileId="758"}
{img fileId="759"}


I would expect that the HR be absent, or that it was not escaped, so that it can display properly.

On the bottom of each Wiki page, in the Print view, a <HR> appears.

{img fileId="760"}
{img fileId="761"}
{img fileId="762"}

I would expect that it would ether not escape the brackets, rendering it in the browser, or for it to be removed entirely.

13.x dev.t.o: Print version for tracker item almost empty

Untested in trunk yet.
To reproduce, see a tracker item, such as:
http://dev.tiki.org/item5294

And see the printer-ready version of that item:
http://dev.tiki.org/item5294?print=y

Only this is shown:
{CODE()}
12.x & 13.x: Comments can't be posted (12.x) nor edited (12.x, 13.x) when codemirror is switched on (or 'disabled but switchable')


The original document is available at http://dev.tiki.org/item5294
{CODE}

13.x dev.t.o: Print version for tracker item almost empty

Untested in trunk yet.
To reproduce, see a tracker item, such as:
http://dev.tiki.org/item5294

And see the printer-ready version of that item:
http://dev.tiki.org/item5294?print=y

Only this is shown:
{CODE()}
12.x & 13.x: Comments can't be posted (12.x) nor edited (12.x, 13.x) when codemirror is switched on (or 'disabled but switchable')


The original document is available at http://dev.tiki.org/item5294
{CODE}

To reproduce, visit: http://dev.tiki.org/tiki-view_tracker_item.php?itemId=5317

Click the print icon:
http://dev.tiki.org/item5317?print=y

Only the title appears, along with 2 "add comments" buttons. These are relevant in print mode (printing comments is OK, but not a button to add more)

{img fileId="818"}

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

Click "Print": https://dev.tiki.org/tiki-print.php?page=Tiki12

{CODE(caption="Current link")}The original document is available at https://dev.tiki.org//tiki-index.php {CODE}

The double // is wrong, and it should send to the page name, not the home page

1- Visit http://doc.tiki.org/tiki-index.php?page_ref_id=3714

2- Click the print icon and you get content of front page:
http://doc.tiki.org/tiki-print.php?page_ref_id=3714

Compare these 2:
http://doc.tiki.org/LDAP+authentication
http://doc.tiki.org/tiki-print.php?page=LDAP+authentication

{img fileId="833"}

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 12.x if not risky, else in trunk
The canonical relation for https://themes.tiki.org/tiki-print.php?page=CSS should be:

{CODE()}<link rel="canonical" href="https://themes.tiki.org/CSS">{CODE}

On Tiki24 we have an admin "Print Setting" page : tiki-admin.php?page=print

If I want the generate a PDF from the action menu (first preferences on the admin page) this is what I see:
{img fileId="1714" thumb="box"}

Wiki print, the main feature to enable everything print, is somewhere at the bottom ? and PDF generation is at the top, preferences that rely on it are place above it... frankly it really look bad for Tiki to release such mess for users. We should use tab and reorder things.

Another example, the preference "Show Page title" is placed under "PDF settings" however it is applied to both (common preference)

Please see:
http://www.seomoz.org/blog/canonical-url-tag-the-most-important-advancement-in-seo-practices-since-sitemaps

tiki-print.php -> tiki-index.php

In trackers, if you find a tracker item following a search, you have some parameters in the URL for item 6 of 70. The canonical format should be just the tracker item.

In blogs,
tiki-send_blog_post.php?postId=xyz
and
tiki-print_blog_post.php?postId=6079
should be:
tiki-view_blog_post.php?postId=xyz

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

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: print structure ("Tiki Reference Guide") stops after a two pages only or so.

Structure toc is something like this:
{CODE()}
Admin Home
General Admin
General Preferences
General Settings
...
...
{CODE}

and page General Preferences is the last one shown.
Url was like [https://doc.tiki.org/tiki-print_multi_pages.php?printstructures=%255B%25223610%2522%255D&find=&print=Print|this one]

In addition, tabs in the shown pages do not work. Maybe because js comes loaded at the end, and page didn't finish loading?

In any case, the best option for tabs in multiprint is that the __notabs__ option should be automagically implied when doing a multiprint.

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"}

To reproduce, visit:
https://doc.tiki.org/tiki-index.php?page_ref_id=4565#Translation_through_Tiki_interface_database_

Then, click "print", and you will be at:
https://doc.tiki.org/tiki-print.php?page_ref_id=4565

But showing HomePage instead of
https://doc.tiki.org/tiki-print.php?page=Interface+translation

When a page which calls the FADE plugin is printed via tiki-print.php, the call's body is not printed by default. To print the content in my Tiki 18 and 19 installs, once I am in tiki-print.php or tiki-print_article.php, I must cancel the automatic printing, click on the label, and then have the browser print. Having revealed from tiki-index.php does not suffice.

It is arguable how much of a bug this constitutes, but the fact the hidden content is quietly hidden when printing is in my opinion already a problem. I believe if the content is not printed, there should at least be a warning displayed, and ideally an offer to reveal hidden zones ("This page contains hidden zones. Should the content of these zones be printed?").

The current way to reveal the zones - to click in tiki-print.php - is very strange, since one would not expect tiki-print.php to be interactive.

We link to files in our tiki as follows

{CODE()}* {FILE(type="gallery" fileId="877" showicon="y")} foofile {FILE} {CODE}

Renders as (live example):
* {FILE(type="gallery" fileId="877" showicon="y")} foofile {FILE}

The -+showicon+- parameter results in having a nice little icon displayed closed to the linked file which is nice.

Problem:
--
Using the print function in Chrome shows those icons several times bigger then they are shown in the actual / normal article view. For me it looks like the print preview in chrome shows the icons in original filesize of the icon, while in the normal article view the icon is displayed in a way smaller size.

In Firefox it behaves slightly different: Print preview looks fine (small icons) but the actual print is using bigger icons as well.


Possible solution/fix:
--
The print css should use the same fileicon-size as in the normal article view

When a structure is printed using multiple print, then the page aliases are ignored.
The TOC shows numbering and aliases correctly.
But the page within the print output shows numbering and page name instead of alias.

This is not only inconsistent, but a major problem:

All pages in TikiWiki must have a unique name. So, in case you need to create similar structures multiple times, you'd need to define some prefix for the page names to keep them unique.
This results in rather ugly page names.

Example:
A section "Client Overview" is mandatory in the structure.

The structure is created for some module "Module A" and some module "Module B".
You'd now prefix the pages, resulting in page names "ModA_client_overview" and "ModB_client_overview". That works okay, no problem, you can simple create aliases "Client Overview" for the pages.

The TOC then prints "1.1 Client Overview". That's correct.

But why does "1.1 ModA_client_overview" appear in the printout of the page instead?!

print mode doesn't seem to know that :_: is for a name space, and just puts a question mark to create a new page

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"

Steps to reproduce:
# go to ((Make a Wish)) on this site
# click the print icon
# scroll down and try to return to this page by clicking on the link: The original document is available at http://dev.tiki.org//Make+a+wish

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.

When using tiki-print.php the page's real name is displayed instead of its alias. This is probably caused by the same regression which caused real names to be displayed as the page title instead of the alias as was addressed in [https://dev.tiki.org/item4722?from=user|this] bug report that has been completed.

I believe that the fix implimented in the bug report linked above does not remedy this, as I applied that fix to one of my local installs and the problem was still there.

I think the reason this happens is because the code that sets the page title as an alias gets that information from the structure_path object that is somehow tied to the breadcrumbs module, and the breadcrumbs module is absent when viewing the page content through tiki-print.php.

Possible solutions would include getting access to alias information through another way (generating a structure_path object on the fly if one does not exist), or perhaps simply generating breadcrumbs on the tiki-print.php page to have access to the object and setting their visibility to hidden.