@kal u can install a third party pdf generator. for windows we have PrimoPDF which can generate PDFs when the Print button is clicked,
there must be something similar for Mac.
Hi spandan888. OS X (macOS) has always had native PDF export built-in to the OS. That’s what Lubus was referring to when he said I could use it as a workaround. But for some reason, Manager appears to be using its own internal PDF generator, even when selecting ‘Print’, which means that I have no way of actually printing the unadulterated HTML.
Manager itself must be previewing themes using WebKit. That feature is partly broken (or more likely, overridden by Manager’s use of HTML tables and CSS to generate its own user interface), but it mostly works. I assumed if I could get it to look right in Manager, I could expect it to look the same when printing the PDF. Lubos’ own comment seemed to confirm this. So it has come as quite a surprise to see what is now happening. I’m sure Lubos will know a way to fix this (without resorting to pixelated screenshots).
When generating a PDF with the macOS built-in PDF generator, Manager definitely does not override the operating system’s generator. Generating a PDF using the PDF button and Print button (by then selecting Save as PDF…) yield distinctly different results, neither of which is an exact reproduction of what is on screen.
Here is a direct screen shot of a sample invoice:
Here is the same invoice converted to a PDF using the PDF button:
Notice the fonts are different. (The internal generator uses Google’s Noto fonts to avoid problems with various international character sets. The capital letter “I” in the title is the giveaway.) Also notice column widths are different.
Now here is the same invoice converted to PDF with the Print button and the macOS internal PDF generator:
The font is back to matching the screen, but margins are wider than on screen and thus column layout is also different, although in another way from the internally generated PDF.
The more you tinker with a theme, the more possibilities there are for any PDF generator to produce a variation. Some variations may be acceptable to you, some may not. But generating a PDF from Manager is not a WYSIWYG situation.
1 Like
I have no idea what Manager is sending to Apple’s print engine, but it definitely isn’t the raw HTML/CSS. My point is, it’s doing something to it first.
Your screenshots, using the standard table-based theme, all look pretty good Tut, no matter which way you print. My story isn’t so happy.
Here is a direct screen shot of a sample invoice, displayed in Manager:
Here is the same invoice converted to PDF with the Print button:
And here’s what the PDF button gives me:
Maybe not, but Tut, this used to work just fine in older versions. When you create a HTML based templating system, some people will want to ‘tinker’, but others will want to create their own templates from scratch, and that is what I did. I have heard Lubos explain why he felt he needed to change it, but what I can’t accept is that I just spent uncountable hours working around all the odd behaviour in the new Liquid-based themes, working around all the CSS limitations, until it looks just right in Manager (it looks just right in Safari too when I replace the Liquid code with standard HTML, because it is all standard HTML/CSS) only to have it look like a steaming pile of something else when I go to print. Please understand my frustration here. We had something that works, and now it doesn’t.
I understand your frustration, @Kal. I share some of it. For example, I have questioned why, if Manager needs to use the Noto fonts to get all the right unicode for various languages, symbols, etc., in PDFs it doesn’t just use them everywhere. A lot of discussion on the forum has its origins in the lack of WYSIWYG behavior. And of course, we Mac users (especially long-time ones like me) are more sensitive to this than others might be.
So my point was to assert that Manager is not overriding things. But how everything interacts, and therefore why some things go awry when others don’t, is beyond my knowledge and understanding. All I know is that the completely unmodified, default theme looks different on screen versus PDF versus Print. And that’s what I was trying to convey.
As a relatively long-time user, I have a pretty good feel about what the program is supposed to do from an accounting perspective. But how it does whatever it does I know nothing about.
If you think I could be of any help in order to find out where and why things are going wrong, you could send me your underlying code and your workflow.
Besides Windows10, I am also an up to date Mac user, and I do have knowledge of HTML/CSS, but I am not an expert.
I always find it interesting to see how standard code may well be mis-interpreted by divers software like Internet Explorer, Safari, Firefox, Opera and then one has to deal with the many pdf printers.
Thanks Tut. I spent such a long time battling with the CSS and Liquid code to make that beautiful looking invoice you see in the first screenshot, not anticipating that the whole thing would break again when I tried to print. Your understanding of my frustration doesn’t help fix the problem, but sometime it’s just nice to be heard. 
I’m an ‘especially long-time’ Mac user too—started around 91 or 92, before HTML and PDF were even invented. Was using an Apple II before that, and a Commodore 64 at home. (Somehow managed to avoid Microsoft OSs all that time!)
Thanks ries, I appreciate the offer. I’ve been coding HTML and CSS for a long time, and normally I wouldn’t have too many problems bending it to my will. The main problems I faced initially were (1) getting the data out using Manager’s implementation of Liquid, which is far from straight-forward, and (2) trying to style tables with CSS, when certain CSS selectors simply won’t stick to table elements (unless you apply them inline). It took a lot of work, but the result was something which finally looked right in Manager—displaying the data where I wanted it, and styling it correctly. The code also renders beautifully in Safari, Firefox and Chrome.
However, I don’t understand what’s happening when I press print. Even printing out of Safari, is screwing things up which means that the problem isn’t limited to Manager. I should have tried that before taking wild guesses at what Manager was doing behind the scenes. I’ll have a bit more of a play and see what I can find out…
@lubos, @Tut, @ries, @spandan888, thanks for all taking the time to respond. I solved the printing issue, and it didn’t have anything to do with Manager. My <style> tag had the media set to “screen” so it wasn’t being used when going to print. Removing that fixed the problem. An embarrassing mistake, but I’m just relieved that it’s finally working!
Good of you to share your “embarrassing mistake”, which is in my opinion quite a normal mistake. Added your solution to my checklist. Have a nice weekend!
1 Like
It changed. I did not use it. Can you help me? thank you
What are you talking about, @Van_Hoan_Vu?
I can not use {{fields [1] .text | date_to_string}} {{ fields[“Due Date”].text | date_to_string }} to get the date
I now use:
{{ fields[0].text | convert: "date" | date: "%-d %B %Y" }}
And for due date:
{% for field in fields %} {% if field.label == 'Due date' %} Payment due by: {{ field.text }} {% endif %} {% endfor %}
It ain’t pretty but it gets the job done.