I came accross the same problem you did when i compiled my first multi-file document using the subfiles package.
Since I am not a long term latex user i do not fully understand the mechanics of the problem but I suspect the problem is that when you compile the "slave" file (in your case 'subpiece1.tex') your compiler searches for the custom package in the same directory as 'subpiece1.tex' and the other default tex directories.
I managed to solve the problem by changing the \usepackage{} command to also include a relative path that will be common for both the "master" and the "slave" .tex files.
What you need to do:
- Add a folder in your home directory for the master document. i.e.
your home directory should have folders: master folder (containing
main.tex), tex folder, images folder.
- Edit your main.tex folder so that the \usepackage{} command includes the relative path to 'styling.sty' (it should read
\usepackage{../styling} with no file extension)
- If you did step one correctly 'styling.sty' will have the same relative path from 'main.tex' and 'subpiece1.tex' (the relative path
for both is one folder up. This is achieved by '../' in the
\usepackage{} command)
- Update all the other relative file paths so they read as required.
main.tex now reads
\documentclass[11pt,letterpaper]{article}
\usepackage{../styling} %includes \usepackage{subfiles}
\begin{document}
%\maketitle (I just removed these because for the demonstartion i didnt actually need them)
%\tableofcontents
\subfile{../tex/subpiece1}
\end{document}
subpiece1 now reads
\documentclass[../master/main.tex]{subfiles}
% again I just removed the graphics path because I have no need for it
\begin{document}
\section{sectiontitle}
%Images and text
\end{document}
I personally prefer to group my preamble.sty into the same folder as my main.tex but the basic idea is the same. I believe any path would be fine as long as the relative paths are the same for both the 'main.tex' and 'subpiece1.tex' files.
I also suspect there are better/more elegant ways of getting around this problem but this worked for me so far.
Forgive the family analogy but it may help
you grasp how your relatives are structured and how they are referenced
So you are a folder lets call you Thomas and you have a parent lets call them blindhardt
you are placed in a system as /blindhardt/thomas but for self reference you can use the alias "."
you have children /blindhardt/thomas/janet and /blindhardt/thomas/john
they may have nicknames such as preface and chap1
to indicate your childs relation to yourself you can say ./preface or ./chap1
for your father you can say .. and for siblings they may be ../older or ../younger
your family tree can now be
/blindhardt/older
/thomas/
/thomas/preface
/thomas/chap1
/younger
Ok thats the basic theory of your relative paths now to your answer
One part of you Thomas the custodian (of the family bible) is known as main.tex
markellos shows neatly that if that part of you (main.tex) identifies as
\providecommand{\main}{.}
then any ../child/story.tex can refer to you as their provider
\providecommand{\main}{..} i.e their own parent
also their additional statement
\documentclass[\main/main.tex]{subfiles}
confirms they are of the same subgroup (class) as yourself
as a family you agree to keep all your pictorial assets in
/blindhart/somewhere/vault however as custodian you wish to call it
/blindhart/thomas/images
% here is the vault path for you ./images and the next generation {\main\images/}
\graphicspath{{images/}{\main/images/}}
OK nothing new so far, lets say you keep a folder (ABC) in that vault
both you and your children will now both need to have some cross index.
\graphicspath{{images/}{\main/images/}{images/ABC/}{\main/images/ABC/}}
So now it does not matter if pic1.png or fig1.pdf is in either main/images or /images/ABC
all of your imediate family of files can find it with
\includegraphics[width=4cm]{pic1}
Main.tex (just one line changed)
\providecommand{\main}{.}
\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[english]{babel}
\usepackage{graphicx}
%here is the NEW path
\graphicspath{{images/}{\main/images/}{images/ABC/}{\main/images/ABC/}}
\usepackage{subfiles}
\usepackage{blindtext}
\begin{document}
\subfile{\main/chap1/chap1}
\end{document}
chap1.tex (no change, except a wider acceptance)
\providecommand{\main}{..}
\documentclass[\main/main.tex]{subfiles}
\begin{document}
\begin{figure}[bh]
\centering
% f1 can be any accepted image (png pdf etc.) beware if there are two in different locations then the order WILL become important.
% it can be in ./f1.png it may be in ../images/f1.pdf or even ../images/ABC/f1.eps
\includegraphics[width=4cm]{f1}
\label{fig:img1}
\caption{ShareLaTeX learn logo}
\end{figure}
Hello, here is some text...
\end{document}
Obviously /older and its /children can follow the same pattern but if you all want to access the family crest in /blindhardt/images then you start adding many more nested relative layers and it may be easier to include an absolute address for such master images thus you and your siblings could add
\graphicspath{{c:\familydocs\blindhardt\images/}{images/}{\main/images/}{images/ABC/}{\main/images/ABC/}}
There are ways to include spaces in the above but for fullest compatibility I suggest we don't include any
All of the above is based on the wording of your question, however every tex file can visit the public library by itself.
There is a default library at your ${TEXMFHOME}/tex/generic/images
You can also nominate a sequence of project collectives via the TEXINPUTS=".:.//:c:\road\to\nowhere: " variable which you could if you know what your doing re-define differently prior to each project run.
NOTE the special token .// which means ALL subdirectories
See Automatically Locate Included Images and Renaming chapter folder and referring to images efficiently
Best Answer
I approach this type of problem in this way. I have a command defined in the preamble that (re)sets the graphics path ...
I call the command at the start of each chapter ...
My understanding is, one should keep the list of folders in graphics path as short as possible to minimize the time to parse through the search paths. Also, I have had no issues (re)setting the graphics path at intermediate points within the document body.
I am curious why this approach is not an obvious or otherwise viable one.