I´ve recently discovered this site and you might be able to give me some advice working with LaTeX.

Here´s my problem:

My company is working on several user manuals. Each user manual is located in its own directory (repository for svn etc.). Basically, all user manuals have the same structure: Main .tex file (providing all \inputs to document class, \inputs, tables etc.) --> Chapter --> .tex file (optional, not always used but pretty often.) There is a lot of cross-referencing going on.

So, our structure is basically t1 -->t2-->t3. t standing for .tex. Our goal is t1-->t2-->t3(-->t4).

We are trying to outsource certain phrases. E.g., the preface is basically always the same. This way, we are able to maintain various user manuals using just one .tex file (basically 1 .tex file). The problem is: We don´t want to create a directory for common phrases and texts. Our file structure depends on individual repositories/ directories. As a consequence, there is no general relative path that we can use:

A chapter in Manual 1 (t1) requires chapter/xxx.tex (which inputs aaa.tex) as an input path. Chapters in Manual 2 and 3 require /../../manual1/chapter/xxx.tex.

The path used to input the aaa.tex file referenced in xxx.tex is based on the main .tex file (t1) from manual 1. This path won´t work for manual 2 and 3. If I adjust the path for manual 2 and 3, the path won´t work with manual 1.

Is there any way to fix or at least "avoid" this. It would be great to reference to an additional level using a path that will work for several manuals.

I hope you don´t consider this question an annoying noob question and I´ve somehow made myself clear, but I´ve been searching for quite a while now and haven´t found an appropriate solution yet. It would be great if you could help me fix this.

closed as unclear what you're asking by Joseph Wright Aug 13 '13 at 11:21

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Why don't you put the files you want to use with many manuals in a texmf tree so that they can be found (like e.g. article.cls) from everywhere? – Ulrike Fischer Apr 18 '13 at 14:32
  • In this case, I won´t thank you for your advice ;) I´ve never herad of texmf tree (I just started working with latex. Most of my epxerience is based on docbook and xml). A quick qoogle search makes me believe, that a txmf tee is not what we "want". As mentioned before, our file structure must remain untouch. Each repository is based on (if not even required by) a specific structure. So I/ we cannot change that (scripts, builds etc. depend on it) – Daniel Keyes Apr 18 '13 at 14:40
  • I must confess I have difficulties following your file structure (which I understand must remain unchanged). What I understand is that there are several hierarchical levels in the folder structure which are in many respects similar, but (almost) never identical. Is that so? Maybe an actual example structure would me more enlightening. – Count Zero Apr 18 '13 at 15:05
  • Then I don't understand your question (and your structure). Imho it doesn't make sense to keep a common file used by many projects in a directory specific to one project. In miktex I would put such common files in a folder mycommonfiles/tex/latex and then register mycommonfiles as a new root/texmf tree. – Ulrike Fischer Apr 18 '13 at 15:09
  • Our file structure is basicall always the same: repositoryxyz-->documentation (main tex. file for pdf build)-->administration_manual (referenced.tex files)-->outsourced sections folder (optional). Personally, I agree that outsourcing would be the best solution. But: We cannot change our file structure since it connected to our software build-process (software engineering). Besides, we want to remain flexible (even though it might be a bit chaotic): There is a lot of cross-referencing but only a few "real" common texts. I gues its simply too much effort due to our rather stiff file structure. – Daniel Keyes Apr 25 '13 at 9:29