Drafting a paper I've just got stuck trying to fit some lengthy equations into a two column document. For some I've gotten away with splitting lines using \begin{split} or \begin{align} environments, but for some it starts to look ridiculous. I also started to run into issues where my \left( and \right) bracket commands didn't like to be split over lines. So I decided that there was no option except spreading the equation over the full page width.
This is actually not particularly straightforward in LaTeX. A reasonable forum discussion on options gives a few suggestions. It seems that it needs to be floated within a figure environment. This is also suggested in a very comprehensive document (p35) on typesetting equations. Unfortunately both of these require manual fiddling with equation numbers and quite a lot of extra code in the document. I've therefore modified their code to define my own environment for a floated equation and used counters to automate the equation numbering.
Preamble:
% for floated 2 column equations
\newcounter{tempEquationCounter}
\newcounter{thisEquationNumber}
\newenvironment{floatEq}
{\setcounter{thisEquationNumber}{\value{equation}}\addtocounter{equation}{1}% record equation as happened and remember number
\begin{figure*}[!t]% float following equation across columns
\normalsize\setcounter{tempEquationCounter}{\value{equation}}% record current equation number in floated location
\setcounter{equation}{\value{thisEquationNumber}}% use previous equation number
}
{\setcounter{equation}{\value{tempEquationCounter}}% set back to equation number in floated location
\hrulefill\vspace*{4pt}% add a horizontal rule separator
\end{figure*}% end float environment
}
In the text simply wrap the standard equation environment in the new environment:
\begin{floatEq}
\begin{equation}
a = b + c
\label{equ:floatedEquation}
\end{equation}
\end{floatEq}
This should float the equation across the whole page and allow LaTeX to fit it in the right place whilst still numbering it as if it appeared where it is defined in the text. Or at least that's what it's achieving for me at the moment!
Showing posts with label Latex. Show all posts
Showing posts with label Latex. Show all posts
30/05/2013
More thoughts on thesis documentation...
It's over a year since I put together some thoughts about how documents (PhD theses in particular) get written up. Having just started on the third year of my PhD I need to start compiling all the little bits I've written in the last two years together into something resembling a final thesis format. I can then build this up into a body of work that I can present at the end. This raises the question - how to best go about this process?
First a few conflicting thoughts about the final document I need to produce:
What I would prefer to write is a document that I could upload to the web and could be referenced and useful to anyone. I've spent some time thinking about how I might be able to cleverly combine the two, but I don't think I'll be able to write just one document to satisfy both aims. So my plan now is to write the thesis in a fairly conventional manner in order to satisfy the requirements for a PhD, then to later revise this into a format that I prefer. Obviously this second part will be easier if I know what I'm planning during the first part, so here is my initial outline...
First a few conflicting thoughts about the final document I need to produce:
- I'd like to write in short concise sections that will either stand on their own, or can be built up into a larger document. I'm concerned that this will not produce a coherent final document though.
- I'd like to setup the individual sections in a hierarchy that reflects the hierarchy of the systems they are describing. Unfortunately this is likely to produce far too many levels in the document (when I drew up a draft layout I got to 12 levels!).
- I'd like to describe the work down to a level that anyone (even a schoolchild) could understand, however this would probably end up being a massive document that would be too basic for most readers.
What I would prefer to write is a document that I could upload to the web and could be referenced and useful to anyone. I've spent some time thinking about how I might be able to cleverly combine the two, but I don't think I'll be able to write just one document to satisfy both aims. So my plan now is to write the thesis in a fairly conventional manner in order to satisfy the requirements for a PhD, then to later revise this into a format that I prefer. Obviously this second part will be easier if I know what I'm planning during the first part, so here is my initial outline...
Thesis mark I
I'll be using LaTeX for the writing, in whatever document template I'm given (or have to make to fulfill my departments guidelines). I'll try to keep it split into relatively small chunks, but without going to too many levels of subheading (4 max). I plan to keep each chapter in its own subdirectory and include it using the \include command. Within chapters I will break things down again using \input commands to allow me to keep sections and subsections in their own individual tex files.
I'll try to use hyperlinks where possible using \usepackage{hyperref}, using the colorlinks option to avoid the default ugly boxes. By using a subtle colour for the links they shouldn't be too jarring in a printed report (where they will be no use) but obvious enough when read on a computer.
As previously discussed in this blog, I'll try to include figures from matlab and simulink as vector images, stored wherever they are generated. I'll also use a single bibtex reference file for all my references.
As with other work, ongoing revision of the thesis will be controlled using Bazaar. I can include the version used to produce output files within them using vc.tex, which is pretty neat. That way when I have multiple versions printed out and sent to people for comments I hopefully shouldn't lose track of which version they're commenting on!
As previously discussed in this blog, I'll try to include figures from matlab and simulink as vector images, stored wherever they are generated. I'll also use a single bibtex reference file for all my references.
As with other work, ongoing revision of the thesis will be controlled using Bazaar. I can include the version used to produce output files within them using vc.tex, which is pretty neat. That way when I have multiple versions printed out and sent to people for comments I hopefully shouldn't lose track of which version they're commenting on!
Latex to Kindle?
Thesis mark II
Latex to html?
html to chd?
I never really finished writing this post, but it gives a flavour of what I was thinking a little while ago when I started writing in earnest!
I never really finished writing this post, but it gives a flavour of what I was thinking a little while ago when I started writing in earnest!
20/08/2012
TeXworks shortcuts
I use TeXworks as my LaTeX editor currently and I recently discovered a few shortcuts that I'm finding really handy in the preview window:
Shift + click = Zoom in
Alt + click = Zoom out
Ctrl + click = Find paragraph in source code
Hope those few are helpful to someone. Let me know if there are any others that I might find useful!
Shift + click = Zoom in
Alt + click = Zoom out
Ctrl + click = Find paragraph in source code
Hope those few are helpful to someone. Let me know if there are any others that I might find useful!
31/07/2012
My referencing process
I suspect everyone has a subtly different way of doing this, depending on the tools they prefer and the way they like to work. I thought I would document my process as I think it's pretty efficient and has some real advantages, I'm sure there is still plenty of room for improvement though.
Overall aim
As an academic I often need to refer to work done by others, this normally done by noting their published work as a list of references or bibliography at the end of my documents. The most basic way of achieving this would be to have a stack of published books and papers in my drawer that I can refer to and then type in the reference details at the end of the each document I want to write. I'm sure that plenty of people do work this way, but from my point of view I see it as pretty inefficient (lots of printing, lots of sorting, lots of typing, not very portable, an awful pain to change reference styles, etc).
I manage my references entirely in software using a few specific tools. I've mentioned most of them in other posts but I'll go into a bit more detail here on the actual process I use.
I'm going to split referencing into two separate processes. Firstly, as I'm researching a topic, I tend to gather references to get an idea what I'm doing. Secondly, when I come to document my work I need to search and cite the references I've found.
Tools
Google Scholar is generally my primary resource for finding papers and documents. I also rely on standard Google searches a massive amount and I have a Google alert set up to email me when a few key phrases appear in new articles added to the web.
IEEExplore generally has most of the published work (in terms of papers, Journal articles, etc) that I need to refer to. The University has a subscription to this that allows me to download what I need (otherwise I'd have to pay!).
Pdf format is generally how almost all papers are delivered and the format that I keep them in. I use Foxit reader to read pdf documents. I keep all my reference documents in one big folder rather than worrying about any kind of complex filing system.
I use Bazaar to version control my folder of pdf documents. I've previously discussed how this works and how it allows me to work between different computers, even without installing any software on them.
I use a tool called cb2bib to maintain a list of references in bibtex format. I started off just using this to add references to my bibtex file, but I've found it to also be really good for browsing references and citing whilst writing a document. I changed some of the default setup to help it retrieve data from the net.
I use Latex to typeset most of my work. Within this I can simply point it at the bibtex file for all the details of the references. I have previously mentioned how to use a bibtex file that is not in the same place as the rest latex document.
Gathering references
- Search for the document that I need to find using Google, Google Scholar or general web browsing.
- Open and read the document to see if it looks relevant and useful. Assuming that it does...
- Download the document to my big folder of "third party" references. I tend to use the full title of the work as the save name of the document - this can lead to quite long file names, but it makes it a lot easier to find things!
- Add the saved file to my bazaar version control system. This only takes a couple of clicks through tortoiseBzr menus in windows explorer.
- Add the document to my bibtex file using cb2bib. This is a pretty straightforward process:
- Open cb2bib, I have a keyboard shortcut setup for this (it should also remember what bibtex file is being used)
- Click "import from pdf file"
- Click "select files"
- Select pdf files saved previously (hold ctrl to select a bunch at once)
- Click "process"
- The software will try to extract as much info as possible from the pdf file, this probably won't be enough so...
- Click Network query to retrieve all the info about the file from the web (this usually works fine, but it's worth checking the results, you may need to give it the right title to start it off)
- Click save to add the reference to the bibtex file
- The changed bibtex file and added references will need to be "commited" to the version control repository.
Citing references
- With a Latex document that has a pointer to the bibtex file within it.
- Open cb2bib citer (I use a keyboard shortcut) and select the reference(s) required:
- [optional] Select the way I want my reference list displayed by pressing "a" (author), "j" (journal), "t" (title) or "y" (year). I find author is usually best.
- [optional] Filter the reference list by pressing "f" and then typing what you want to search for ("d" clears the search)
- Click on a chosen reference
- [optional] Press "o" to open the reference and read it
- Press "enter" to cite the reference, a small pen marker will appear next to it (in author view it will appear next to each author for the same paper). Multiple references may be cited by selecting them and pressing "enter". "delete" clears all the selected references.
- Press "c" once all the references for citing are selected, this will close the citer window and copy the latex text for the references to the clipboard.
- Paste the text into the latex file to include the references at that point in the document.
13/02/2012
IET conference paper reference style
I've recently prepared a paper for a forthcoming IET conference in which I cited references.
Whilst the template for the paper provided an example of the format it would like references to journals to be included in, it gave no further advice.
Assuming that there would be a standard format for all IET conference papers I went a-googling - with very little success. My next option was to ask on the IET forums here. Unfortunately this didn't turn up any standard formats either. Therefore my conclusion is that a "standard" doesn't exit.
This isn't a major issue as I think you'd have to work quite hard to contrive an example where a reader wouldn't be able to decipher a reference due to the use of an obtuse format. However I think it would be good practice to document the format I've used here...
The conference template suggests (for a journal article):
[1] A. B. Author, C. D. Author. “Title of the article”, The Journal, volume, pp. 110-120, (2000).
Surprisingly this differs from the IET advice for research journal citations and the two documents on IEEE reference formats.
Therefore the style I decided to use is:
Journal article
Whilst the template for the paper provided an example of the format it would like references to journals to be included in, it gave no further advice.
Assuming that there would be a standard format for all IET conference papers I went a-googling - with very little success. My next option was to ask on the IET forums here. Unfortunately this didn't turn up any standard formats either. Therefore my conclusion is that a "standard" doesn't exit.
This isn't a major issue as I think you'd have to work quite hard to contrive an example where a reader wouldn't be able to decipher a reference due to the use of an obtuse format. However I think it would be good practice to document the format I've used here...
The conference template suggests (for a journal article):
[1] A. B. Author, C. D. Author. “Title of the article”, The Journal, volume, pp. 110-120, (2000).
Surprisingly this differs from the IET advice for research journal citations and the two documents on IEEE reference formats.
Therefore the style I decided to use is:
Journal article
- A. B. Author, C. D. Author. “Title of the article”, The Journal, volume, pp. 110 – 120, (year).
- A. B. Author, C. D. Author. “The title of the conference paper”, The Conference, Location City, Location Country, pp. 1-7, (Month year).
- A. B. Author, C. D. Author. “The title of the book chapter”, in D. Editor (Ed.), The title of the book (Publisher, year, 1st edn.), pp. 1 – 7.
A. B. Author, C. D. Author. The title of the book (Publisher, year, 2nd edn. 2006).
Patent
As I prepared the paper using LaTeX, all my referencing was done using BibTeX. I therefore needed to create a custom bibliography style file. I did this using the custom-bib package. This a fairly straightforward process once it's figured out, roughly consisting of:
Now I wouldn't recommend this if it can be avoided as the language used is pretty obscure, however I eventually got something that looked about right.
If you want to use my style file it's here. Obviously it comes with no warranty and no official backing from the IET. It looked ok for the paper I submitted but I'd recommend thorough checking of the output if you do use it.
Please let me know if this is of use to you, or if you have any comments on my chosen style, using custom-bib or any other part of my process.
- A. B. Author. “The title of the patent”, British Patent 123456, (Month year).
- A. B. Author, C. D. Author. British Patent Application 98765, (Month year).
- A. B. Author. “The title of the thesis”, PhD thesis, XYZ University, year.
- BS1234: “The title of the standard”, year.
- http://www.theiet.org, accessed Month year.
As I prepared the paper using LaTeX, all my referencing was done using BibTeX. I therefore needed to create a custom bibliography style file. I did this using the custom-bib package. This a fairly straightforward process once it's figured out, roughly consisting of:
- run latex on "username"\Application Data\MikTeX\2.8\tex\latex\custom-bib\makebst.tex
- answer questions appearing in the output window
- get *.dbj file produced at the end
- run latex on that file to produce *.bst file (I found that the full path to the file was required at this step, so it needed to be run from the command line rather than through an editor)
Now I wouldn't recommend this if it can be avoided as the language used is pretty obscure, however I eventually got something that looked about right.
If you want to use my style file it's here. Obviously it comes with no warranty and no official backing from the IET. It looked ok for the paper I submitted but I'd recommend thorough checking of the output if you do use it.
Please let me know if this is of use to you, or if you have any comments on my chosen style, using custom-bib or any other part of my process.
16/08/2011
Using a remote Bibtex file
As mentioned previously:
There are plenty of questions about this out there in internetland, mostly with the following suggestions:
- I am using version control software to backup my work
- I'm using LaTeX
- I don't like duplicating files around my system
- I'm working between both Windows and Linux
There are plenty of questions about this out there in internetland, mostly with the following suggestions:
- Move your bibtex file to within the tex installation root - I can't really do this because of 1. above.
- Use symbolic links to the original in the local folder - I can't do this becuase of 4. (windows doesn't support them)
- Give a relative filename reference e.g. '\bibiography{../literatureReview/references}'
- Adding the location as an environment variable as described here.
27/07/2011
Making a bibtex file from a folder of pdf files
The issue
As I'm going to be writing some big documents with lots of references I'd be a fool to try to manage these manually, I therefore needed to pick a reference management piece of software. After some browsing I settled on JabRef because: it's free, it's open source, it's lightweight, it's cross-platform and it handles bibtex format natively (which is what I need for it to integrate with latex). It should also link nicely into the Sciplore mind mapping software which I'm using (more about that some other time).
JabRef is basically a database management tool for references that stores its database in bibtex format. It looks like it will work rather well, but unfortunately my first stumbling block is that I already have a folder full of my references in pdf format (~200). This means that I'm immediately faced with the big task of going through and adding the details of each pdf individually. There must be a better way...
Someone else asked the same question here. The answer seemed to be that there was no easy way in JabRef, but it could be done in some other reference management software - such as Mendeley. So I could install that as well and export from there to use JabRef, that seemed like a pain though, especially as you need log in details and all sorts for Mendeley.
The solution
Somewhere else cb2Bib was suggested. This looks like an awesome piece of software, almost to the point that I could use it instead of JabRef, although I don't think it does quite the same job. It's designed as a bibtex database manager, however it is more tailored towards reference entry than editing or final use (e.g. citations) - although it can do this. Its method of adding a new reference is based on what's currently in the clipboard - thats whatever you most recently 'cut' or 'copied' in your operating system. This can either be a piece of text or a pdf file.
Files from the system can also be queued up to be added to the clipboard for addition to the bibtex database - in this manner a folders worth of pdf files can be added. Once the file is in the clipboard the software interrogates it to try to extract the right details for the bibtex reference entry. It is also able to do some other clever things like search the web and find a web reference for it that matches only one of the pieces of data it has extracted. There is also the option to manually edit the fields or to set off a whole run of files to add automatically.
My implementation
In practice the software took a little while to get used to; the buttons aren't in quite the locations I'd expect, there seem to be about 3 different windows that are independent but interrelated and the method of specifying a bibtex file and then successively saving additions to it felt a little odd (rather than running through to create a file and then saving it all at once). But once I was used to it at that level it all worked.
When I came to actually try to add all of my pre-saved pdfs however, I hit problems. Whilst automatic extraction usually managed to pull out a few nuggets of useful data, it rarely found enough for a complete entry. Hitting the button to search the web didn't seem to give much assistance. So it was time to dig a little deeper.
Probing through the website there is quite a lot of useful information on how to configure the software to do what you want. What I needed to do was look into where was being searched on the web for my articles. This is all setup in a configuration file located at:
C:\Program Files\cb2bib\data\netqinf.txt (windows)
or
/usr/share/cb2bib/data/netqinf.txt (linux) (you'll need permissions or to be root to edit)
Wading into there you can find out where is being searched and in what order. What would have been ideal for me would have been a search of the IEEE Xplore site, as that would have turned up most of my papers. Unfortunately it was not in there. Second best was google scholar, sitting at the bottom of the list of options. The documentation in the file wasn't brilliant, but with a bit of trial and error I was able to work out what was going on.
The major change I made to the file was to add this at the top of the queries list:
# QUERY INFO FOR Google Scholar
journal=
query=http://scholar.google.com/scholar?hl=en&lr=&ie=UTF-8&q=<<title>>&btnG=Search
capture_from_query=info:(.+):scholar
referenceurl_prefix=http://scholar.google.com/scholar.bib?hl=en&lr=&ie=UTF-8&q=info:
referenceurl_sufix=:scholar.google.com/&output=citation&oe=ASCII&oi=citation
pdfurl_prefix=
pdfurl_sufix=
action=
journal=
query=http://scholar.google.com/scholar?hl=en&lr=&ie=UTF-8&q=<<excerpt>>&btnG=Search
capture_from_query=info:(.+):scholar
referenceurl_prefix=http://scholar.google.com/scholar.bib?hl=en&lr=&ie=UTF-8&q=info:
referenceurl_sufix=:scholar.google.com/&output=citation&oe=ASCII&oi=citation
pdfurl_prefix=
pdfurl_sufix=
action=
The important changes here are the <<title>> and <<excerpt>> search strings, and the change from capture_from_query=info:(\w+):scholar in the existing scholar searches to capture_from_query=info:(.+):scholar in my search. I'm not too sure what the latter change did, but its effect was that it found the details - where previously it was often missing them!
As I'm going to be writing some big documents with lots of references I'd be a fool to try to manage these manually, I therefore needed to pick a reference management piece of software. After some browsing I settled on JabRef because: it's free, it's open source, it's lightweight, it's cross-platform and it handles bibtex format natively (which is what I need for it to integrate with latex). It should also link nicely into the Sciplore mind mapping software which I'm using (more about that some other time).
JabRef is basically a database management tool for references that stores its database in bibtex format. It looks like it will work rather well, but unfortunately my first stumbling block is that I already have a folder full of my references in pdf format (~200). This means that I'm immediately faced with the big task of going through and adding the details of each pdf individually. There must be a better way...
Someone else asked the same question here. The answer seemed to be that there was no easy way in JabRef, but it could be done in some other reference management software - such as Mendeley. So I could install that as well and export from there to use JabRef, that seemed like a pain though, especially as you need log in details and all sorts for Mendeley.
The solution
Somewhere else cb2Bib was suggested. This looks like an awesome piece of software, almost to the point that I could use it instead of JabRef, although I don't think it does quite the same job. It's designed as a bibtex database manager, however it is more tailored towards reference entry than editing or final use (e.g. citations) - although it can do this. Its method of adding a new reference is based on what's currently in the clipboard - thats whatever you most recently 'cut' or 'copied' in your operating system. This can either be a piece of text or a pdf file.
Files from the system can also be queued up to be added to the clipboard for addition to the bibtex database - in this manner a folders worth of pdf files can be added. Once the file is in the clipboard the software interrogates it to try to extract the right details for the bibtex reference entry. It is also able to do some other clever things like search the web and find a web reference for it that matches only one of the pieces of data it has extracted. There is also the option to manually edit the fields or to set off a whole run of files to add automatically.
My implementation
In practice the software took a little while to get used to; the buttons aren't in quite the locations I'd expect, there seem to be about 3 different windows that are independent but interrelated and the method of specifying a bibtex file and then successively saving additions to it felt a little odd (rather than running through to create a file and then saving it all at once). But once I was used to it at that level it all worked.
When I came to actually try to add all of my pre-saved pdfs however, I hit problems. Whilst automatic extraction usually managed to pull out a few nuggets of useful data, it rarely found enough for a complete entry. Hitting the button to search the web didn't seem to give much assistance. So it was time to dig a little deeper.
Probing through the website there is quite a lot of useful information on how to configure the software to do what you want. What I needed to do was look into where was being searched on the web for my articles. This is all setup in a configuration file located at:
C:\Program Files\cb2bib\data\netqinf.txt (windows)
or
/usr/share/cb2bib/data/netqinf.txt (linux) (you'll need permissions or to be root to edit)
Wading into there you can find out where is being searched and in what order. What would have been ideal for me would have been a search of the IEEE Xplore site, as that would have turned up most of my papers. Unfortunately it was not in there. Second best was google scholar, sitting at the bottom of the list of options. The documentation in the file wasn't brilliant, but with a bit of trial and error I was able to work out what was going on.
The major change I made to the file was to add this at the top of the queries list:
# QUERY INFO FOR Google Scholar
journal=
query=http://scholar.google.com/scholar?hl=en&lr=&ie=UTF-8&q=<<title>>&btnG=Search
capture_from_query=info:(.+):scholar
referenceurl_prefix=http://scholar.google.com/scholar.bib?hl=en&lr=&ie=UTF-8&q=info:
referenceurl_sufix=:scholar.google.com/&output=citation&oe=ASCII&oi=citation
pdfurl_prefix=
pdfurl_sufix=
action=
journal=
query=http://scholar.google.com/scholar?hl=en&lr=&ie=UTF-8&q=<<excerpt>>&btnG=Search
capture_from_query=info:(.+):scholar
referenceurl_prefix=http://scholar.google.com/scholar.bib?hl=en&lr=&ie=UTF-8&q=info:
referenceurl_sufix=:scholar.google.com/&output=citation&oe=ASCII&oi=citation
pdfurl_prefix=
pdfurl_sufix=
action=
The important changes here are the <<title>> and <<excerpt>> search strings, and the change from capture_from_query=info:(\w+):scholar in the existing scholar searches to capture_from_query=info:(.+):scholar in my search. I'm not too sure what the latter change did, but its effect was that it found the details - where previously it was often missing them!
The other change I made was to untick the option "Set 'title' in double braces" box in the configuration window. After I'd made these changes it worked a lot more consistently.
Some of the time it still pulled out the wrong details if it mis-extracted the article title, however I'd named all my pdfs with the title of the paper, therefore it was simply a case of copying and pasting the filename into the title field and rerunning. It would have been really nice to be able to use the title of my pdf as part of the search but unfortunately I couldn't find a way of doing that.
The only other issue I'm having is that although cb2bib adds in the link to the pdf file, JabRef wont understand it as it uses a very slightly different bibtex format for it. The cb2bib format seems to be:
file = {location}
whereas the JabRef format seems to be:
file = {description:location:type}
There is a comment here by a Mendeley admin that suggests that there is no prescribed format for this aspect of a bibtex file, so I guess it's to be expected. I should be able to work around it with a bit of clever find/replace, but it's an annoyance.
ACTUALLY - this seems to be working under windows! It looks like a different version of JabRef has gotten around this issue.
UPDATE: After a couple of months of getting used to cb2bib and using it to produce a document I'm not really finding the need to use JabRef at all! The 'citer' facility of cb2bib is actually really good.
UPDATE: I hadn't previously gotten round to extracting from IEEE Xplore, as almost everything is on Google Scholar. However I've just tried to set it up and found that the IEEE pages use javascript buttons to produce the citation. This makes it difficult to fully automate.
If you add the following to netqinf.txt then it should search IEEE Xplore for the title, you can then manually click the "download citation" button, select BibTeX format and then copy the BibTeX citation into cb2bib:
# QUERY INFO FOR IEEEXplore
journal=
query=http://ieeexplore.ieee.org/search/searchresult.jsp?newsearch=true&queryText=<<title>>&x=35&y=7
capture_from_query=arnumber=(\d+)&contentType
referenceurl_prefix=http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=
referenceurl_sufix=
pdfurl_prefix=
pdfurl_sufix=
action=browse_referenceurl
ACTUALLY - this seems to be working under windows! It looks like a different version of JabRef has gotten around this issue.
UPDATE: After a couple of months of getting used to cb2bib and using it to produce a document I'm not really finding the need to use JabRef at all! The 'citer' facility of cb2bib is actually really good.
UPDATE: I hadn't previously gotten round to extracting from IEEE Xplore, as almost everything is on Google Scholar. However I've just tried to set it up and found that the IEEE pages use javascript buttons to produce the citation. This makes it difficult to fully automate.
journal=
query=http://ieeexplore.ieee.org/search/searchresult.jsp?newsearch=true&queryText=<<title>>&x=35&y=7
capture_from_query=arnumber=(\d+)&contentType
referenceurl_prefix=http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=
referenceurl_sufix=
pdfurl_prefix=
pdfurl_sufix=
action=browse_referenceurl
14/07/2011
Latex \psfragfig of figures in other folders
What I've spent part of today wrestling with...
I've detailed previously how I'm exporting Matlab plots and including them in Latex documents. This works very well for figure files in the same directory - which is kind of the way Latex is set up. Unfortunately I'd like to maintain my folder structure in a different manner, for example, I have a "results" folder and a "thesis" folder both at the same level. Within "results" I have my Matlab plotting scripts and the images that are automatically saved by them. In my "thesis" folder I have my Latex files, in which I would like to include my results images.
Ideally I would be able to simply reference the image in my Latex document but that's not quite how it worked out. Let me explain what I tried...
Using \graphicspath
This is the most obvious way of doing things as noted here, and it works fine for graphics inserted with the \includegraphics command. I was also able to reference relatively like this: \graphicspath{{../results/}} and apparently it would also look in all the subdirectories if I put a double slash on the end: \graphicspath{{../results//}}.
This would be a great solution if I were using the \includegraphics command - but I'm not. I'm using \psfragfig and it doesn't work with this command, I guess because it's not set up to?
There is also a suggestion here that this method shouldn't be used, in favour of adding the images directory within your Latex compiler setup - although I'm not sure this would be appropriate for what I was trying to do.
Using \input, \include or \import
These all do similar things, in that they allow you to bring in latex documents from elsewhere in a folder structure. Only some of them will allow relative linking via higher level directories (rather than just subdirectories). \import seemed to be what I needed (or rather the \subimport variant of it did), so I set up a .tex file containing only my \psfragfig command within the "results" folder and imported that into my document. This got the figure into the document, but it didn't do all the nice text replacement that it was supposed to. In this respect it was no better than the previous technique.
After some experimentation it seems that \psfragfig only looks locally to the master document for the .tex files that it uses to include text with the figures.
Using \write18
So it appeared that the only way I was going to get the \psfragfig command to work properly was by having both the "figure.eps" file and the "figure.tex" file local to the master document. I'm not keen on the unnecessary duplication involved in this, so at the very least I decided to make it automatic. I therefore set it up so that these two files are automatically copied to the local directory during compile. This means that I always have the most up to date version of them in my document, and everything stays nice and automatic.
I think the only way to copy a file around between directories from within a Latex document is by issuing a system level command using \write18. This is usually disabled by default in Latex as it has the possibility of really mucking things up in your system if you were compiling 3rd party code. Therefore I had to compile my code with the extra argument '--shell-escape' as detailed here.
So I want to use the Latex \write18 command to execute a DOS copy command, that's fine; but there is also the tricky issue of needing to use backslashes for the path in the DOS copy command - these are obviously reserved in Latex. Therefore I had to use the technique outlined here to get around this.
So finally I managed to put together a Latex command that works, and it looks like this:
\def\psfragfigremote{\begingroup\catcode 92 12 \execB}
\def\execB#1#2%
So after including that in my header I can reference figures in other directories in my document like so:
\psfragfigremote{..\results\}{figure}
This copies both figure.eps and figure.tex (generated from Matlab with the matlabfrag command) from the results folder into the current folder and then includes them in the document.
It works fairly well, but not the first time it is run. I'm not sure why this is, possibly it hasn't finished copying the .tex file before starting to execute the next command. Therefore two compiles may be necessary to get all the labels sorted out.
I'm sure there must be a better way of doing this, possibly modifying the \graphicspath and \psfragfig commands so that they play well together would be a neater solution, but this works ok for now.
I hope this is of use to someone. Any improvements or suggestions then please comment.
UPDATE: Replacing the \write18 commands with:
\write18{robocopy #1 . #2.tex #2.eps}%
and removing the star after \psfragfig will only copy the files if they have changed, speeding up processing significantly.
I've detailed previously how I'm exporting Matlab plots and including them in Latex documents. This works very well for figure files in the same directory - which is kind of the way Latex is set up. Unfortunately I'd like to maintain my folder structure in a different manner, for example, I have a "results" folder and a "thesis" folder both at the same level. Within "results" I have my Matlab plotting scripts and the images that are automatically saved by them. In my "thesis" folder I have my Latex files, in which I would like to include my results images.
Ideally I would be able to simply reference the image in my Latex document but that's not quite how it worked out. Let me explain what I tried...
Using \graphicspath
This is the most obvious way of doing things as noted here, and it works fine for graphics inserted with the \includegraphics command. I was also able to reference relatively like this: \graphicspath{{../results/}} and apparently it would also look in all the subdirectories if I put a double slash on the end: \graphicspath{{../results//}}.
This would be a great solution if I were using the \includegraphics command - but I'm not. I'm using \psfragfig and it doesn't work with this command, I guess because it's not set up to?
There is also a suggestion here that this method shouldn't be used, in favour of adding the images directory within your Latex compiler setup - although I'm not sure this would be appropriate for what I was trying to do.
Using \input, \include or \import
These all do similar things, in that they allow you to bring in latex documents from elsewhere in a folder structure. Only some of them will allow relative linking via higher level directories (rather than just subdirectories). \import seemed to be what I needed (or rather the \subimport variant of it did), so I set up a .tex file containing only my \psfragfig command within the "results" folder and imported that into my document. This got the figure into the document, but it didn't do all the nice text replacement that it was supposed to. In this respect it was no better than the previous technique.
After some experimentation it seems that \psfragfig only looks locally to the master document for the .tex files that it uses to include text with the figures.
Using \write18
So it appeared that the only way I was going to get the \psfragfig command to work properly was by having both the "figure.eps" file and the "figure.tex" file local to the master document. I'm not keen on the unnecessary duplication involved in this, so at the very least I decided to make it automatic. I therefore set it up so that these two files are automatically copied to the local directory during compile. This means that I always have the most up to date version of them in my document, and everything stays nice and automatic.
I think the only way to copy a file around between directories from within a Latex document is by issuing a system level command using \write18. This is usually disabled by default in Latex as it has the possibility of really mucking things up in your system if you were compiling 3rd party code. Therefore I had to compile my code with the extra argument '--shell-escape' as detailed here.
So I want to use the Latex \write18 command to execute a DOS copy command, that's fine; but there is also the tricky issue of needing to use backslashes for the path in the DOS copy command - these are obviously reserved in Latex. Therefore I had to use the technique outlined here to get around this.
So finally I managed to put together a Latex command that works, and it looks like this:
\def\psfragfigremote{\begingroup\catcode 92 12 \execB}
\def\execB#1#2%
{\immediate
\write18{copy #1#2.eps}%
\write18{copy #1#2.tex}%
\psfragfig*{#2}
\endgroup
}
So after including that in my header I can reference figures in other directories in my document like so:
\psfragfigremote{..\results\}{figure}
This copies both figure.eps and figure.tex (generated from Matlab with the matlabfrag command) from the results folder into the current folder and then includes them in the document.
It works fairly well, but not the first time it is run. I'm not sure why this is, possibly it hasn't finished copying the .tex file before starting to execute the next command. Therefore two compiles may be necessary to get all the labels sorted out.
I'm sure there must be a better way of doing this, possibly modifying the \graphicspath and \psfragfig commands so that they play well together would be a neater solution, but this works ok for now.
I hope this is of use to someone. Any improvements or suggestions then please comment.
UPDATE: Replacing the \write18 commands with:
\write18{robocopy #1 . #2.tex #2.eps}%
and removing the star after \psfragfig will only copy the files if they have changed, speeding up processing significantly.
03/06/2011
Simulink to eps
I've mentioned previously that I've developed a process to export plots from Matlab and include them as (eps format) figures in a Latex document. Well today I spent a load of time trying to get a similar method working for exporting Simulink model diagrams from Matlab. This hasn't proved quite as easy, but I think I'm there now.
My main issue was that Simulink doesn't allow you to print in the same way as a normal Matlab figure does. The "print" command can be used, but it works in a very specific way. It is fairly easy to use this command to print in eps format (see my previous posting for why this is a good thing); however it doesn't allow you the same freedom to setup the page. More specifically it will only allow you to use a pre-defined page size (A4, US legal, etc). It rescales and centres the figure to fill the page, but, unless the model is the exact same aspect ratio as a pre-set paper type, you end up with white borders at either the top/bottom or left/right.
EDIT: This seems to have been corrected in newer versions of Matlab now!
I've tried all sorts to get round this, including calling Ghostscript from within matlab to post-process the eps file. This should work as it ought to be able to find the right "bounding-box" for the figure and resize the page accordingly. However I had no luck with this - it would either not trim it down at all, or over-trim it removing some of the image.
I also tried exporting in a few other formats (namely normal postscript and pdf) and then converting with Ghostscript. This worked a little better and I was able to get the right bounding box through a process of:
So an alternative process I finally came up with is:
There's nothing very clever in the code, but if anyone wants a copy of my function I'll happily forward it to them. Hope this helps somebody!
EDIT: Code for my function is available here.
My main issue was that Simulink doesn't allow you to print in the same way as a normal Matlab figure does. The "print" command can be used, but it works in a very specific way. It is fairly easy to use this command to print in eps format (see my previous posting for why this is a good thing); however it doesn't allow you the same freedom to setup the page. More specifically it will only allow you to use a pre-defined page size (A4, US legal, etc). It rescales and centres the figure to fill the page, but, unless the model is the exact same aspect ratio as a pre-set paper type, you end up with white borders at either the top/bottom or left/right.
EDIT: This seems to have been corrected in newer versions of Matlab now!
I've tried all sorts to get round this, including calling Ghostscript from within matlab to post-process the eps file. This should work as it ought to be able to find the right "bounding-box" for the figure and resize the page accordingly. However I had no luck with this - it would either not trim it down at all, or over-trim it removing some of the image.
I also tried exporting in a few other formats (namely normal postscript and pdf) and then converting with Ghostscript. This worked a little better and I was able to get the right bounding box through a process of:
- Simulink export to pdf,
- Ghostscript convert pdf-to-eps,
- Ghostscript convert eps-to-eps.
So an alternative process I finally came up with is:
- Find out the ratio of the figure (I did this by exporting as a raster image and then reading back in - I'm not very happy with this technique as it's pretty dirty, but at least it works)
- Simulink export to eps, with the model at the very bottom of the page
- Automatically edit the resulting eps file to adjust its bounding box information
There's nothing very clever in the code, but if anyone wants a copy of my function I'll happily forward it to them. Hope this helps somebody!
EDIT: Code for my function is available here.
19/05/2011
Professional plotting
I've written and read plenty of technical reports in my time, and one major feature that almost all technical reports have in common is the inclusion of figures. Pick up any ten technical documents and I reckon you'll find at least 5 different ways of including figures; and of these 5 only one will actually look any good. So as I start to produce figures for my PhD I've been starting to look into the best way of managing this initially simple sounding task.
When I say "figure" I'm generally thinking of some kind of plot, or set of plots, usually in 2D; however what I'm going to discuss should apply to most other "technical" "pictures", but probably won't extend to photo-type images (for reasons that will hopefully become obvious).
The Issues
I won't bother going into all the different ways a figure and a report might come together, except to say that at the very bottom of the scale would be a 'picture'/screenshot pasted into a word document - this just looks awful. What I'll work up to will hopefully be the top of the scale.
What I will list is what I see as some major stumbling blocks in figure/report preparation:
Background Details
One of the first important distinctions is the difference between types of image. Most images that one would typically come across on a computer are raster images, these are stored as a set of pixels - imagine a piece of squared paper with each square filled in a different colour. From a distance, or if all the squares are very small, then this looks great; however if we zoom in (e.g. make each square larger) then we start to see the joins between edges and everything starts looking "blocky". Most programs usually handle this by blurring the pixels together slightly, which can help up to a point, but often we just end up with a blurred mess - not what we want in a precise technical report.
The alternative is vector graphics. These are saved more as a description of what needs to be drawn, rather than point-for-point what is on the screen. This means that zooming is purely a mathematical operation, and all the lines will still appear as prefect lines. The same also works for text, which is stored within a vector graphic as actual text, rather than as a picture of it.
There are plenty of graphics explaining this along with a good description in the Wiki pages linked above. But if you're still not sure then try this simple experiment: type a word into a paint program (e.g. Microsoft Paint) and zoom in, and then do the same in a word processing program (e.g. Microsoft Word) - the difference should be pretty obvious.
In summary, unless what your are working with is an actual picture (in which case converting it to vector graphics would be impossible) then you will get best quality out of maintaining it in a vector format. There are plenty of these formats to choose from; however I find them to be surprisingly unsupported in a lot of applications. As my final target format is pdf (as mentioned elsewhere in this blog) I'm going to be working with eps and pdf formats. These both rely on postscript as an underlying process and are therefore fairly compatible.
My process (overview)
With all of the above as my aims I've worked out a basic process for generating figures. It seems to be working fairly well so far, so I'll outline it here:
1) Write a script to produce the figure and save is as an eps file. This means that I can always go back and see how each figure was produced (what the original data was, how it was scaled, etc, etc). If the data changes then I can simply rerun the script and a new figure will be produced. If I need the figure in a different ratio or with different colours (or a different label, etc, etc) then I can make some minor changes to the script and rerun it. I keep the script under version control, but not the eps file it produces (as I can always reproduce this if necessary). I use Matlab for this process as it is what I am most familiar with (although I often store the raw data in an excel or csv file and read this into Matlab). I suspect I could use Gnuplot or something similar instead.
2) Include the eps file in my LaTeX script. This means that when I regenerate the pdf output from my LaTeX it always includes the most recent version of the figure. As it remains as vector graphics throughout the process I get nice clean professional results.
This process solves all of the problems outlined above, except point 4. It is still possible to produce an eps figure from Matlab with "Courier" font and then include it in a Latex document using "Times" font. I find that this looks out of place. I get around this by using a function called matlabfrag, in combination with pstool package for LaTeX. This means that the final figure picks up the font used in the rest of the document. It also allows me to use full LaTeX expressions in my figures.
My process (in detail)
This may get more refined as time goes by, but currently this is the detailed version of how I would produce a figure:
1a) Write a Matlab script to plot the figure as normal. Using standard matlab command to plot and label axes, etc.
1b) Within the script include a call to 'saveFigure.m'. This is a function I have created which accepts a file name and optionally a figure size (otherwise some default values are used), resizes the figure and then calls matlabfrag to save it as an eps file (and an associated tex file including all the labels).
2a) In the LaTeX preamble include '\usepackage{pstool}'. This allows the use of the psfragfig command.
2b) Within my LaTeX include the figure in the normal way. However, instead of using the latex '\includegraphics' command, I replace it with the '\psfragfig' command.
Notes
I can make my 'saveFigure.m' function available to anyone interested, but it doesn't do much more than I have described above!
I have created a slightly revised process for including Simulink models in documents which is a little different that I can discuss if anyone is interested?
I spent a little time trying to get psfrag to play well with eps files produced from other packages - e.g. Google Sketchup, however I don't think I've quite got to the bottom of it yet.
When I say "figure" I'm generally thinking of some kind of plot, or set of plots, usually in 2D; however what I'm going to discuss should apply to most other "technical" "pictures", but probably won't extend to photo-type images (for reasons that will hopefully become obvious).
The Issues
I won't bother going into all the different ways a figure and a report might come together, except to say that at the very bottom of the scale would be a 'picture'/screenshot pasted into a word document - this just looks awful. What I'll work up to will hopefully be the top of the scale.
What I will list is what I see as some major stumbling blocks in figure/report preparation:
- Difficulty updating the figure.
- Inability to resize the figure to suit the report.
- Images (+ text) looking crappy when zoomed in.
- Disconnect between the figure labels and the report text.
- Difficulty regenerating the figure at a later date.
Background Details
One of the first important distinctions is the difference between types of image. Most images that one would typically come across on a computer are raster images, these are stored as a set of pixels - imagine a piece of squared paper with each square filled in a different colour. From a distance, or if all the squares are very small, then this looks great; however if we zoom in (e.g. make each square larger) then we start to see the joins between edges and everything starts looking "blocky". Most programs usually handle this by blurring the pixels together slightly, which can help up to a point, but often we just end up with a blurred mess - not what we want in a precise technical report.
The alternative is vector graphics. These are saved more as a description of what needs to be drawn, rather than point-for-point what is on the screen. This means that zooming is purely a mathematical operation, and all the lines will still appear as prefect lines. The same also works for text, which is stored within a vector graphic as actual text, rather than as a picture of it.
There are plenty of graphics explaining this along with a good description in the Wiki pages linked above. But if you're still not sure then try this simple experiment: type a word into a paint program (e.g. Microsoft Paint) and zoom in, and then do the same in a word processing program (e.g. Microsoft Word) - the difference should be pretty obvious.
In summary, unless what your are working with is an actual picture (in which case converting it to vector graphics would be impossible) then you will get best quality out of maintaining it in a vector format. There are plenty of these formats to choose from; however I find them to be surprisingly unsupported in a lot of applications. As my final target format is pdf (as mentioned elsewhere in this blog) I'm going to be working with eps and pdf formats. These both rely on postscript as an underlying process and are therefore fairly compatible.
My process (overview)
With all of the above as my aims I've worked out a basic process for generating figures. It seems to be working fairly well so far, so I'll outline it here:
1) Write a script to produce the figure and save is as an eps file. This means that I can always go back and see how each figure was produced (what the original data was, how it was scaled, etc, etc). If the data changes then I can simply rerun the script and a new figure will be produced. If I need the figure in a different ratio or with different colours (or a different label, etc, etc) then I can make some minor changes to the script and rerun it. I keep the script under version control, but not the eps file it produces (as I can always reproduce this if necessary). I use Matlab for this process as it is what I am most familiar with (although I often store the raw data in an excel or csv file and read this into Matlab). I suspect I could use Gnuplot or something similar instead.
2) Include the eps file in my LaTeX script. This means that when I regenerate the pdf output from my LaTeX it always includes the most recent version of the figure. As it remains as vector graphics throughout the process I get nice clean professional results.
This process solves all of the problems outlined above, except point 4. It is still possible to produce an eps figure from Matlab with "Courier" font and then include it in a Latex document using "Times" font. I find that this looks out of place. I get around this by using a function called matlabfrag, in combination with pstool package for LaTeX. This means that the final figure picks up the font used in the rest of the document. It also allows me to use full LaTeX expressions in my figures.
My process (in detail)
This may get more refined as time goes by, but currently this is the detailed version of how I would produce a figure:
1a) Write a Matlab script to plot the figure as normal. Using standard matlab command to plot and label axes, etc.
1b) Within the script include a call to 'saveFigure.m'. This is a function I have created which accepts a file name and optionally a figure size (otherwise some default values are used), resizes the figure and then calls matlabfrag to save it as an eps file (and an associated tex file including all the labels).
2a) In the LaTeX preamble include '\usepackage{pstool}'. This allows the use of the psfragfig command.
2b) Within my LaTeX include the figure in the normal way. However, instead of using the latex '\includegraphics' command, I replace it with the '\psfragfig' command.
Notes
I can make my 'saveFigure.m' function available to anyone interested, but it doesn't do much more than I have described above!
I have created a slightly revised process for including Simulink models in documents which is a little different that I can discuss if anyone is interested?
I spent a little time trying to get psfrag to play well with eps files produced from other packages - e.g. Google Sketchup, however I don't think I've quite got to the bottom of it yet.
26/04/2011
Documentation
Within my work, as with many (most?) other professions, I have considerable need to produce documents. For me these usually take the form of:
As I've mentioned before, I'm very much a believer in using the right tool for the job; to this end I thought I would note down what I'm using and try to justify my choices.
Plain text - I'm trying to use for emails, this can get difficult if I need to include equations or images, in these cases I will generally try to include them as an attachment.
Open Office Writer - I'm using to produce short reports. I have chosen not to use Latex (see below) for these as I am producing them as quick, short documents for dissemination to my supervisors; hence I find the WYSIWYG interface easier than going through Latex. I have considered setting up a Latex template but I don't think the extra hassle will be worth it in the end.
These documents I export to pdf format prior to dissemination (see a forthcoming post for reasoning). I also maintain these documents within my version control system (again see a forthcoming separate post).
Handwritten Notes - I keep a log book for scribbling down results and doing rough sketches, however I'm trying to digitise the important points from these as soon as possible as I can never find the page I wanted (no search facility!), or when I do find it that I can't read my own writing (yes it is that bad!).
Latex - (pronounced "lay-tec") I'm trying to use for most other work. My main reasons for use being:
Do you think the way I'm doing things is sensible? Any questions, comments or arguments then please add them below!
- Ongoing notes - for my own use and occasionally for discussion with my supervisors
- Communication - invariably via email
- Recording results - as they are produced from experiments
- Reporting on progress - monthly/yearly formal reports
- Papers - Eventually for publication in journals or similar
- Thesis - Finally for submission for my PhD
As I've mentioned before, I'm very much a believer in using the right tool for the job; to this end I thought I would note down what I'm using and try to justify my choices.
Plain text - I'm trying to use for emails, this can get difficult if I need to include equations or images, in these cases I will generally try to include them as an attachment.
Open Office Writer - I'm using to produce short reports. I have chosen not to use Latex (see below) for these as I am producing them as quick, short documents for dissemination to my supervisors; hence I find the WYSIWYG interface easier than going through Latex. I have considered setting up a Latex template but I don't think the extra hassle will be worth it in the end.
These documents I export to pdf format prior to dissemination (see a forthcoming post for reasoning). I also maintain these documents within my version control system (again see a forthcoming separate post).
Handwritten Notes - I keep a log book for scribbling down results and doing rough sketches, however I'm trying to digitise the important points from these as soon as possible as I can never find the page I wanted (no search facility!), or when I do find it that I can't read my own writing (yes it is that bad!).
Latex - (pronounced "lay-tec") I'm trying to use for most other work. My main reasons for use being:
- The source is stored as plain text - this means it can be easily version controlled and differenced. (see a forthcoming separate post on this...).
- It can compile directly to pdf with lots of nice extras included (menu's, interactive contents, hyperlinks, etc).
- It separates the content from the formatting - allowing me to concentrate on one or the other, rather than worrying about items jumping between pages or links not working.
- It is very flexible and can produce beautiful documents (especially where equations or complex formatting is involved).
I'll probably be posting more on Latex, as I have played with it to produce some interesting documents in the past.
Subscribe to:
Posts (Atom)