So you’re saying the whole frame, including the title block is displaced? Works fine here so it may be something in your situation. not something inherent in Kicad. What about other applications, e.g. OpenOffice, etc? Post details of your software version, OS, etc. Can you also upload a PDF generated on your system so we can view?
Can confirm, solution was given to me by Rene in this post which is to plot to PDF instead of print to PDF. Even though earlier version of KiCad in post just tried in 5.1.6 and still same offset. Linux 20.04.
Looks like print to PDF function in eeschema hasn’t got the hang of correct output when going through the system’s PDF generator. In the case of print, the producer is Cairographics, and for plot the producer is eeschema. The other difference seen in the properties panel is that the print output shows a custom size somewhat different from A4, whereas the plot output shows the correct A4 size.
Here’s a screenshot of the properties panel when viewing the output of print to PDF with okular.
The crazy thing is that it sometimes changes if I change the orientation, and sometimes it comes right. It looks like eeschema is not passing on some dimensions, perhaps via the intermediate format (Postscript?). This is just a surmise though. Other apps can generate correct output via the system print dialogue so eeschema is failing to do something.
Then again evince seems to get the dimensions right so maybe okular is not getting all the info it needs.
BTW, I’m just a user like you so there’s probably a bug report over this that you can give a thumbs up to.
No, Cairo is not used for the printing in Eeschema, only in Pcbnew. This problem would be fixed by using Cairo for printing though, but that is a large change that probably won’t happen in this dev cycle.
So how come the PDF file has the attribute produced by Cairo? See screenshot of the Properties panel above.
Edit: I think you overinterpreted what I wrote. What I wrote was that the producer of the output file was Cairo, not that eeschema uses Cairo. In fact I’m guessing that it’s because eeschema generates another intermediate format which is then converted to PDF by the system’s Cairo, that the problem arises and the fix would be to cut out the extra conversion as you say.
At least I’m not crazy and it really seems to be a bug.
I can live with it, the complete schematic is still on the page, it’s more of an aesthetic problem.
Based on kenyapcomau’s screenshot of the properties panel, I suspect that someone entered the wrong paper size just before going to lunch. As KiCAD unfortunately has the bad habit of hard coding this kind of data, there’s probably not a lot one can do.
I’ll use the PDF Print function for intermediate prints, and Plot for final artwork.
Ah no. I don’t take long liquid lunches. It was entered as A4. Even yours showed a custom size now and then. My surmise is that okular did not find something in the PDF, maybe bounding box, but had to fall back to measuring it from the entities on the page. Evince somehow managed to get it right, perhaps it rounded it to the nearest official size. But evince took an awfully long time to render the page, so who knows what it was doing. I could decode the PDF streams (it’s compressed) to see what the PDF looks like, but there are more interesting things to spend time on.