Anyone else having issues, as of 1.0.165 with printing to PDF? I have tried both export to PDF file and what I usually do because of page margins and such, using CTRL-P (OS-driven print).
OS: Fedora Linux 29
Joplin version: 1.0.165 (my build; note I have been building Joplin for Fedora since… 1.0.140 without issues)
What happens: document is truncated at some point on the first page. If I alter things… the truncation point changes. I can’t see a rhyme nor reason for it at this time. Occurs with all documents.
I’ll try downgrading when I am back home in a couple hours. UPDATE (OUCH!!!): Don’t try downgrading. Joplin doesn’t like that.
Win10 Pro x64 1903 - Joplin 1.0.165 Linux Mint 19.2 x64 - Joplin 1.0.165
For me printing or exporting to PDF seems to cut off about 2/3 of the way down the first page and then stops. If the document should be several pages long I only get part of the first page.
When printing Joplin ignores any custom css settings and uses its internal print settings. You can see the page re-render before printing / exporting to PDF. The cut-off appears (*) to coincide with how much can be seen in the Joplin rendered note window when Joplin “resizes” the page. It looks like Joplin is just printing what is in the rendered note window and not the whole note. This is possibly also why exporting to PDF now includes the vertical scroll bar in as it appears in the rendered note.
EDIT: (*) I say “appears” as it happens too fast to be certain. However this is what I am getting with PDFs.
This is just a coincidence. I've run some tests and in my case, it just stops printing after about 77% of the first page. If you use print and not export, you see the rendered "print" pane until you click on Print or Cancel. In my case the cut-off neither matches the "normal" rendered preview pane nor the "print" rendered preview pane.
Thanks for pointing out it was just a coincidence. I did try to make it clear it was just a guess I was making
I'm sorry for being a bit dense but what do you mean by "upstream issue"? I understood "upstream" would mean something that "fed into" the project. Joplin 1.0.161 prints / exports to PDF multi-page notes and does not include the vertical scroll-bar. So does this mean that Joplin 1.0.165 uses a broken print / export pdf component?
Joplin uses Electron to create "native" react-native apps on macOS, Linux, and Windows.
For PDF generation we use the Electron function printToPDF.
Joplin depends on many other npm packages (which you can see in the appropriate package.json files in the code), which are all considered upstream. So, if there's a bug in a dependency, there's nothing that we can do. Sometimes there's a chance to write a workaround in the Joplin code, but most of the time there isn't.
We have to investigate, whether it is an upstream issue, but when looking at the code changes between 161 and 165, nothing would suggest that we screwed something up. Thus I assume we might have updated dependencies (upstream) which now results in this error.
I suppose it all depends on how vital folks think that functionality is. It may be an upstream issue, but the PDF issue percolates to the application.
I exported the .md, opened it in atom and then generated PDF using one of their extensions. I had to remove ‘[[toc]]’ from the file, but i got a PDF in the end.
Not ideal, but better than nothing. And, of course, it demonstrates the power of markdown.
I have the same problem on MacOs The Export to PDF, as well as the print function, will only print a part of the document A downgrading resulted in an ERROR because of a newer profile. I expect a new version of Joplin will appear soon with a solution of this problem
Not quite the right analogy. Printing in every single application works fine on my computer. But not with Joplin.
A more apt analogy would be a browser that ceased to talk to the network (but other browsers and networking applications were not affected), not because networking ceased to function, but because the upstream networking library the browser choose to use was broken.
Now, I can live with this for now (not as vital as my networking analogy) but, yes, if an upstream library breaks, and an application still uses it, then indeed the bug is now manifest in both.
If the bug hasn’t been filed yet upstream, I can do so, but proper protocol would be to file it there and to file it with Joplin.
A much bigger issue seems to be that data loss issue a few people are reporting. Ugh. I feel for them. Hence I do a periodic export. I’m terrified of the “one instance of your data” model. I digress.
I reverted all packages that were updated between 161 and 165. Nothing. Ok, so maybe not an upstream issue after all. So now I will have to figure out which commit screwed up the PDF export.
I'm working on it. But as you an imagine this is time consuming.
But I'm confident that it will be fixed at one point. Ok, I have to grab some food. Will work on it later this afternoon.
@tessus I did a bit of snooping using git bisect and tracked the issue down to a specific commit, actually one line in particular. Removing this line fixes the issue, but since this was a bug fix commit, I’m sure it introduces another. I think we’ll nee @laurent to take a look since he has a better handle on this stuff.
@CalebJohn removing the line fixes the problem, but breaks something else. The preview pane is no longer scrollable, nor does it scroll when you scroll in the edit pane. very weird.
Thanks for finding it. Look forward to when it comes cleared. Using Joplin for product support notes where I work since MS changed OneNote. Basic is better.
The Export to PDF, as well as the print function, will only print a part of the document 
Ok, I have to grab some food. Will work on it later this afternoon.