The previous topic had over 50 replies which I really appreciate.
I made quite a few improvements and the button should work properly on all screens. I would really like to move on so please if you can, upgrade to the latest version (16.10.43) and test if the PDF output after pressing “PDF” button looks acceptable across all documents or reports which matter to you. Thanks!
Thanks lubos
I tried printing an invoice that uses a purchased template (from invoice themes - art nouveau) and it’s very broken - formatting is all wrong, it tells me there is a xref chink missing and here’s the top of the pdf.
Right now I’m concerned about standard printing without HTML customization. That will be separate issue.
On a sales quote, tax code that appears like this onscreen:
gets wrapped incorrectly as below in the PDF:
That column width didn’t come out right.
Journal entry has no PDF button. Don’t know if one was planned.
Fixed Asset Summary now looks worse than in 16.10.26. That version had different, but acceptable, text wrapping. This version has unacceptable wrapping and the entire report covers only about 60% of the page width:
Reports which previously had vertical compression (probably a padding issue) and misalignment of totals still do.
The latest version (16.10.49) fixes all issues reported above.
-PDF button not working in Google chrome i get blank screen.
-Now if i print on Foxit PhantomPDF printer the file saved is corrupted. (Saturday was working fine)
I tried Microsoft edge all worked fine but the PDF Button when generate the PDF can’t support custom field with HTML code.
Using the PDF Button
Printing file as PDF
Ubuntu Server, PDF Button does not generate the headings in Bold on any report. The PDF generated by the email button produces the PDF correctly.
Everything is working fine with mine.
Windows 8.1 Desktop Edition.
I will continue to see if there is anything else and report
Continued progress. 
It is difficult to check everything on all reports, because account name lengths, descriptions, and other aspects of available data may not stress the PDF engine. But here is an example where what’s onscreen doesn’t match the PDF, even though the PDF looks somewhat acceptable. In this case, account names that are on single lines onscreen are wrapped onto as many as three lines in the PDF, and general horizontal spacing is quite a bit different. But at least the text wrapping does not break words:
Here is another example where the PDF looks fine by itself, but column spacing differs quite a bit from screen. In this case, the PDF probably looks better, with more obvious separation of headings, as though the font is a little smaller or a more compressed style:
Many reports now exhibit this behavior of different column spacing and text wrapping, but overall acceptable or even better appearance (as opposed to those mentioned separately that generate unacceptable text wrapping):
Inventory Value Movement report cuts off the both the left-hand name and part of the right-hand closing balance columns:
Inventory Quantity Movement report wraps the item code and name column at far left very awkwardly, even breaking words apart:
Capital Accounts Summary PDF omits account owner’s name and cuts off right-hand column, the same as the Inventory Value Movement report:
Pdf Printer works very fast now. Takes about 3 seconds to create the pdf. Very good thank you. The layout looks right apart from one strange thing. Any text I have in bold is on one line and the rest of the text is on the next line. See attached picture. However this is not how it looks in Manager and I think it should look the same in Manager and on the PDF. I would prefer that the text continue on the same line as the bold text as its wasting space to the right of the bold text.
Secondly, I am still getting the Xref error using PDF Xchange Editor. This is a standard Manager invoice, not an html customised one. Thanks
@Tut, translating what you see on screen to PDF will never be 100% accurate because there is a mismatch between screen and print media. And that’s OK. The most important thing is to make output both on screen and on PDF good enough. Anyway, I re-calibrated a few things in the latest version so reports with many (long) columns should fit on PDF better.
@dalacor, not sure what is that error about but it seems like you can re-save PDF in that program which will fix the error so I’ll leave it at that for now. I fixed the issue with bold text though.
@compuit, what web-browser are you using to access server edition?
@aymanjou, if you are using custom HTML in custom fields, there is going to be limited set of tags supported. You can show what HTML markup you are entering in your custom field and I’ll have a look what can be done about that.
I can definitely understand this. Assuming that nothing you’ve done introduces other errors to forms that were previously fixed (and my spot checking says these look good), I don’t find any more problems. Small differences in layouts, yes. A few text-wrapping differences, yes. But everything I have tested looks professional and no errors are generated.
One thing I want to strongly encourage is to keep the Print button along with the PDF button so those who wish, for whatever reason, can still print through the operating system and take advantage of features available there, such as paper size, orientation, number of copies, collation, double-sided printing, and so forth.
Paper size and orientation will be configurable from within Manager and PDF button will support it too.
Number of copies, double-sided printing etc. can be still facilitated when printing PDF itself.
Web browser version used to access Manager.
Just to be clear … the bold that is missing on the reports is in the PDF preview when viewed on the computer’s screen. Should the PDF be printed, it does print the bold text correctly even though it is not shown in the rendered on screen PDF.
Yes, it appears to be a FireFox thing by the look of it. By using the Chromium web browser the bold type face issue on screen is resolved.
Firefox is using pdf.js component internally to render PDF within the browser. Based on what you are saying, it is an issue in pdf.js rather than in PDFs Manager is producing so I’ll leave it at that.
I set FireFox to use the Document viewer in place of rendering within the browser itself. This for me gives the desired result beautifully, you do not have click the browser back button to get on with work.
