The fonts created in *.pdf documents using the PCBNew “Plot” feature are too large when displayed in Adobe Acrobat Reader. Has anybody else had this problem? (Running PCBNew nightly version from 30 June 2017 on Win7/64.)
I customarily make a set of *.pdf hardcopy documents for review and reference, using the “Plot” feature in PCBNew. This has worked well in the past, ever since I started using KiCAD over 2 years ago. Tonight when I plotted a *.pdf file, the character fonts displayed in the *.pdf file seem to be too large, roughly 130% (eyeball estimate) of what they should be.
Here is what I see on my display of PCBNew. Notice that the lettering in the “Notes” block fits nicely on the page. By the way, I set this up as an 11" x 17" (U.S. “B” size) page in KiCAD.
And here is what gets displayed by Adobe Acrobat Reader DC. (Version 2017.012.20095 - about two weeks old.) As you see, the text runs on over the edge of the page.
Using gsview/ghostscript under Windows I get the same oversized font.
I get a lot of these size problems when I use my companies custom font, as it has broken sizing
I can’t be very specific, but clearly KiCad used to use it’s own font (“pcbnew font”) in PDFs (and other plot formats). At some point a change was made to allow the system Helvetica font in plot outputs (maybe related to DXF). That is shown in you example.
Recently I believe JP Charras reverted this change (git commit), so the latest nightly (2017-08-21) now again uses pcbnew font in plots. I confirmed this for PDF output.
I didn’t look where m_textMode gets set, I guess there is a dialog option somewhere. In the DXF plot dialog, there is a checkbox “Use pcbnew font to plot texts”, but I don’t see that in PDF dialog. Possibly the setting from DXF dialog is used when plotting PDF.
Thanks to @marcos and @davidsrsb for confirming my observations, and helping to isolate the problem to someplace within KiCAD. Good idea from @davidsrsb - I didn’t think to open my defective *.pdf files with GSView, since I never use it to open PDF’s.
The answer from @bobc stimulates my curiosity to ask a bunch of questions, ranging from fundamental stuff related to OS’s in general, to specific questions about this particular case. I won’t pursue them now - I’m unlikely to live long enough to get it all organized in my mind.
Today I’ll be working from a machine running a KiCAD nightly version from back in February, so I suspect ( ) it will produce a usable *.pdf file from the “Plot” feature. I am reluctant to install a current nightly build - versions from just last week are reported to have serious problems for production use (see Netclass clearance resetting to zero ), and I see that the size of the installation file jumped by about 10% in the last few days. Nobody has ventured to nominate a trustworthy nightly build in the thread Recommended/non-recommended Nightlies .
Funny thing is that during my degree work I was plotting Hershey fonts on the university plotter, now 30 years later I find them being used in KiCad.
I did some digging and I think maybe this patch from April inadvertently broke PDF plots. So you might also find SVG plots have “real text” instead of line drawings. (This allows text to be searchable).
For PDF JP Charras implemented a way to have hidden real text, and visible line drawn text, which gives accurate text while also being searchable and copiable.
If I’m right, builds from April to August had this bug, so a Feb build should be ok.
Yes, the nightly from back on 10 Feb 2017 works well.
The question that leaves me fearful and trembling is, “If KiCAD can’t do a correct “Plot” output to a *.pdf file, can I trust it to correctly “Plot” to a Gerber file?” (I guess that’s why I always bring up the Gerbers in gerbv before I send them to the board fabricator. It’s very rare that I find a defect at that point, but I don’t want to take the risk of missing a defect in my final inspection if I know that the Gerbers came from a program with a defective “Plot” function.) I’ll stick with my February nightly build until I see a consensus that a more recent build is trustworthy.
That’s a very good question, however software developers are no closer to answering that sort of question reliably than we were 30 years ago. It’s a question about the “unknown unknowns”. There are quite likely bugs in the nightly builds affecting Gerbers, but they probably only happen in obscure conditions or are minor in impact…
I did attempt to write some code to monitor code changes and the rate of bugs reported, but the Launchpad API is not terribly friendly so I didn’t get far.
I have a tool which packages the gerbers into a zip and a gerbv project, so I can quite easily review the gerbers and be sure the zip file also contains the right files. But I still managed to send one design with no tracks on the PCB I was in a hurry to fill out an order…
Yeah, just a couple months ago I bought some boards that don’t have Reference Designators on the Silkscreen. Just one cantankerous little check box that evaded my notice . . . And the boards are for an initial pilot production run, that will be displayed and inspected by all kinds of people . . . .
Can you and I create a “Mutual Assistance Pact”, assuring each other that our respective supervisors and co-workers will never hear of these incidents, at least not from you or me?
It wouldn’t surprise me to find bugs or defects even in the most mature software releases. In this case I am especially wary because I know that there are problems in an area of the code that is functionally “close to” the code which creates Gerber plots. I wouldn’t be nearly as worried if there were known bugs in, say, setting the display screen colors, or even placing traces. But I am especially wary because “Plot to PDF” is only one click away from “Plot to Gerber”.
Plotting functions are likely some of the oldest and crustiest parts of the codebase.
Watching the GitHub logs, it looks like cleanups and bugfixes elsewhere have flushed out code that has been broken for a very long time
Was that change in behavior deliberate . . . or an unavoidable consequence of some other change . . . or a temporary step backwards, to be corrected in the near future . . . or an unexpected result of some change?
In MY opinion, the combination of “Drag Track” with push-and-shove is EXTREMELY beneficial, and the way things SHOULD work unless you specify otherwise.
With recent Nightlies, do you still get “Drag Track” if you press “D” before clicking on a segment?
I did try D and G.
The GitHub commit log shows a lot of attempts to sort this area out. I hope the default behaviour goes back to normal and will file a specific bug report if it doesn’t or we we will be explaining forever to beginners how to push and shove
In the current fedora nightly build it works as expected (The build is from 5 days ago version 100:r10805.6be2f29-nightlies; The version info that can be copied from the help dialog is useless for fedora it seems.).
M moves and D is the interactive drag.
) it will produce a usable *.pdf file from the “Plot” feature. I am reluctant to install a current nightly build - versions from just last week are reported to have serious problems for production use (see 