Name | Type |
---|---|
PDF Generation from structures seems to have trouble with some images | 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 |
Humphrey
Contributors |
tracker item |
PDF Bugs with WikiLinks and Smilies
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 |
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: 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.... |
tracker item |
Mikael.Franzen
Contributors |
tracker item |
Keep color highlighting from PluginCode at the mpdf printed version | tracker item |
kerrnel22
Contributors |
tracker item |
make mpdf of diagrams work also when behind a firewall using proxy | tracker item |
make mpdf of images also work also when using https cert with issues | 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 | wiki |
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 doesn't include images in many cases including zoombox fluidgrid and others | tracker item |
mpdf fails to print PluginGanttChart | tracker item |
mPDF generates an empty (blank) document on the t.o forum | tracker item |
mpdf generation doesn't include diagrams if only local casperjs installed but service to export images from draw.io not enabled | tracker item |
mpdf generation from slideshow fails to respect image sizes and therefore content overflow slides | tracker item |
mpdf of pivot tables from the default setup as in profile Bug_Tracker_16 produces error 500 WSOD | 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 |
natokpe | tracker item |
nextdoc.t.o homepage unable to generate PDF | tracker item |
Package, mPDF, Print; Installing the mPDF package on Tiki24 update composer and it now require PHP8 (brick the Tiki) | tracker item |
Installing package is hardly possible on shared hosting without an option to select the PHP CLI to use | tracker item |
PDF
Printing to Adobe's PDF format (Portable Document Format) |
wiki |
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!
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 |
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] (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. |
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 |
PhantomJS | wiki |
Plugin DBReport with mPDF enhancement | tracker item |
PluginPDF | wiki |
print to pdf doesn't use the custom css from the L&F control panel | tracker item |
Print, PDF; Big design changes between Tiki24 and Tiki25 when printing or saving as PDF | tracker item |
ShowCaseSupport@projectashenfire.org | tracker item |
Structure TOC with bullets and numbers | 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]: {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] |
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)
{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). ^ |
tracker item |
ViewerJS PDF viewer instable across browsers | tracker item |
wkhtmltopdf | wiki |
xavi
Contributors |
tracker item |
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}