Ok, so I'm new to KiCAD but not to PCBs

I’ve added a number of IC symbols in a schematic, most contain 2 or more elements, such as a dual-timer, a quad op-amp.

I’ve been searching the forum for answers to how to change the documentation type from http: to a folder location containing a PDF file in a Win10 Pro external USB drive. When I change the documentation in one of the dual timer elements it also modifies two of the op-amp elements for no apparent reason.

I prefer pointing to my IC datasheet PDFs stored on my local USB drive rather than using a web link that may or may not be around tomorrow. I’ve read where the documentation field supports different MIME types and understood this to mean DOS drive:\directory\file locations.

What gives?

Edit: I’ve discovered that, at least in part, it is related to not having generated a Netlist. After doing so, updating the documentation field on one op-amp element in the quad, it appears to update all of the op-amp elements, ditto for the dual-timer element documentation directory link.

But there is inconsistency in other symbol component such as a hex CMOS inverter. Of the six, four of the a,b,c,d,e,f elements were changed to LM556 along with documentation pointing to the LM556.PDF, but two were not. After creating the Netlist, changing the name of one changed only 3 more, but not the last two elements.

I need to better understand whether or not there is any “linking” between each quad op-amp, hex inverter, dual-timer section to the other elements within their given package, because at the moment it seems a bit erratic.

Thanks for any help.

I have set a custom variable named KIDATASHEET to: /home/paul/electronics/datasheets/

And then in Eeschema use that path to point to local datasheets. In this case a TPS54331 buck IC from TI:


Now that worked like a charm. Thanks paulvdh!

Strictly speaking a local file URI should start with file:// So paulvdh’s example should declare KIDATASHEET to be file:///home/paul/electronics/datasheets (note the resulting three /'s). This is in case you encounter a strict, unforgiving browser some day.


“http://” and “https://” are common prefixes for web browsers. Some time ago it became customary to hide this part of the URI, but thankfully it’s back and the show the full adress by default in the adress bar these day’s. I can also use “sftp://” to reach my NAS-wannabe.

I did not give the creation of my custom variable much thought. I just duplicated what was already present in KiCad

Some browsers like Chrome still hide the scheme, but you will notice that when you copy the contents of the location bar, the scheme comes along.

So how does “file:///” denote a Windows 10 non-system drive letter?

Note, it’s not file:///, but file://. You append what you would normally use after that. So file://C:\Users\joe\Desktop…

But, but…three /'s, no two /'s - this is confusing. I’m guessing paulvdh’s is a Linux platform.

Okay, I’ll change my references to “file://g:\my documents\electronics\IC datasheets”

That’s because the file path on paulvdh’s Linux machine starts as /home/paul/… The third / is not part of the scheme indicator but the beginning of the Linux pathname.

So, for Windows 10 Pro, the “file://” prefix to a normal DOS file path worked for some symbol documentation PDFs but others resulted in “File not found” even though the file was there.

Edit: Restarting KiCAD had no effect.

Changing the KIDATASHEETS variable back to a normal DOS file path (drive:\folder\folder), made all symbol documentation references open properly.

It depends on the browser used to view the documentation. If it’s say a PDF viewer rather than a web browser it may not know about general URI schemes and in this case you have to defer to the local situation.

Adobe Acrobat Reader is not a web browser, and what I use by default for PDFs. I’ve no idea what is involved to use a web browser PDF viewer instead of a PDF app.

But you’ve explained what was happening to me, thanks.

It seems that to use generalised URIs you have to specify UNC paths in Windows, e.g. here: https://projectinsight.com/support/kb/hyperlinks-and-references-to-local-windows-files-using-internet-explorer

So it would be something like (get this!) file://///machinename/folder/etcetc

Ah so much that resulted from the choice of \ for separator all the way back in DOS.

And it’s not even possible to reliably change the pdf viewer for KiCad and use URI. Here on Linux (Kubuntu) I can change the PDF viewer to e.g. firefox in KiCad’s Preferences. However, then I can use only the normal file path starting with / to open it with firefox. If I use file:// it probably goes to directly to the system, bypassing KiCad’s choice, and it’s opened with Okular which is the default PDF viewer of my system.

Works for me. Note that the path has to be absolute, hence the third /, and firefox has a built-in PDF viewer.

Also firefox can delegate handling of MIME types so some installations may handle application/pdf with an external program.

Anyway it’s probably moot in the OP’s situation since a local directory isn’t portable to other systems, but it may matter for say a distributed package that uses a local library of PDFs in which case somehow the path has to be adapted to the end user situation.

But your Linux, right?

As you can see, yes.

I was familiar with Suse Linux desktop and server many decades ago. I’ve slept since then, :wink: