Hello Frank,
Log: misplaced a paper by ... a century
Would you mind checking the title, please? It uses both "Ueber" and "Auflösung". Same for the other one with Nåherung for the other paper.
Also the new entries use utf-8 which the old ones don't eg your name is L{"o}ffler in the ET paper.
Re my own commit with the cropping script: it crops pdf files to remove white border. All automated. Isn't it a beauty to read? :-)
Yours, Roland
"Ueber" is fine; e.g. in Swiss German, there are no upper case umlauts.
Please do not use utf-8; this is not handled well. Only ASCII and bibtex-latex-notation works.
-erik
On Fri, Apr 5, 2013 at 3:43 PM, Roland Haas roland.haas@physics.gatech.eduwrote:
Hello Frank,
Log: misplaced a paper by ... a century
Would you mind checking the title, please? It uses both "Ueber" and "Auflösung". Same for the other one with Nåherung for the other paper.
Also the new entries use utf-8 which the old ones don't eg your name is L{"o}ffler in the ET paper.
Re my own commit with the cropping script: it crops pdf files to remove white border. All automated. Isn't it a beauty to read? :-)
Yours, Roland
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Fri, Apr 05, 2013 at 04:32:20PM -0400, Erik Schnetter wrote:
Please do not use utf-8; this is not handled well. Only ASCII and bibtex-latex-notation works.
It is handled without problems here. Do you have problems with it?
Frank
On Fri, Apr 05, 2013 at 12:43:26PM -0700, Roland Haas wrote:
Hello Frank,
Log: misplaced a paper by ... a century
Would you mind checking the title, please? It uses both "Ueber" and "Auflösung". Same for the other one with Nåherung for the other paper.
I know, I noticed this myself before I committed. It is exactly like that in the original article.
Also the new entries use utf-8 which the old ones don't eg your name is L{"o}ffler in the ET paper.
utf-8 is standard nowadays, isn't it? We use utf-8 in paper for quite a while now.
Re my own commit with the cropping script: it crops pdf files to remove white border. All automated. Isn't it a beauty to read? :-)
Where do these borders come from? Given the beauty of the script I guess there is no easier option to not have them created in the first place? :)
Frank
On Fri, Apr 5, 2013 at 10:34 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Fri, Apr 05, 2013 at 12:43:26PM -0700, Roland Haas wrote:
Hello Frank,
Log: misplaced a paper by ... a century
Would you mind checking the title, please? It uses both "Ueber" and "Auflösung". Same for the other one with Nåherung for the other paper.
I know, I noticed this myself before I committed. It is exactly like that in the original article.
Also the new entries use utf-8 which the old ones don't eg your name is L{"o}ffler in the ET paper.
utf-8 is standard nowadays, isn't it? We use utf-8 in paper for quite a while now.
It works in latex, but not in bibtex. Unfortunately I don't recall what went wrong. I do recall that I switched my personal bibtex file to utf-8, and then had to backpedal and convert everything back again. Note there are a host of tools that read bibtex entries, e.g. for sorting, combining, filtering, or for converting to html etc. -- maybe some of them are broken? Or maybe there are some broken bibtex styles around; when one submits to a journal, often particular styles are required.
I've been using utf-8 in latex itself for many years without problems.
-erik
On Fri, Apr 05, 2013 at 10:45:49PM -0400, Erik Schnetter wrote:
It works in latex, but not in bibtex. Unfortunately I don't recall what went wrong. I do recall that I switched my personal bibtex file to utf-8, and then had to backpedal and convert everything back again.
It would be interesting to know what went wrong. It really does work without problems for me. However, if it doesn't for some people then the best way would indeed be to switch back to a less readable but more traditional method.
Or maybe there are some broken bibtex styles around; when one submits to a journal, often particular styles are required.
One possibility that comes to mind is that someone _not_ using utf-8 in latex might get problems when using bibtex files that do.
Frank
On Fri, Apr 5, 2013 at 11:25 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Fri, Apr 05, 2013 at 10:45:49PM -0400, Erik Schnetter wrote:
It works in latex, but not in bibtex. Unfortunately I don't recall what went wrong. I do recall that I switched my personal bibtex file to utf-8, and then had to backpedal and convert everything back again.
It would be interesting to know what went wrong. It really does work without problems for me. However, if it doesn't for some people then the best way would indeed be to switch back to a less readable but more traditional method.
Google finds this: http://wiki.lyx.org/BibTeX/Tips
-erik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Frank,
Re my own commit with the cropping script: it crops pdf files to remove white border. All automated. Isn't it a beauty to read? :-)
Where do these borders come from? Given the beauty of the script I guess there is no easier option to not have them created in the first place? :)
Matplotlibs savefig has an option to get tight bounding boxes
http://stackoverflow.com/questions/3130072/matplotlib-savefig-image-trim
though using only removes the whitespace on the right hand side.
Using pdfcrop (which is reasonably sane, it's just the bash script in a makefile using gawk which is somewhat horrible) just seemed like safer/faster way of getting rid of any white space around plots.
Yours, Roland
- -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
On Sat, Apr 06, 2013 at 12:16:06AM -0700, Roland Haas wrote:
Matplotlibs savefig has an option to get tight bounding boxes
http://stackoverflow.com/questions/3130072/matplotlib-savefig-image-trim
though using only removes the whitespace on the right hand side.
Did you try
fig.savefig("bla.pdf", bbox_inches='tight') ?
Frank
On Sat, Apr 06, 2013 at 07:36:55AM -0500, Frank Loeffler wrote:
though using only removes the whitespace on the right hand side.
Did you try
fig.savefig("bla.pdf", bbox_inches='tight') ?
Wait, that is what you said. However, in my case it seemed to work on all sides (e.g. see the ugly figure here: https://www.cct.lsu.edu/~knarf/parma/old_resolution_study/speed0.png where it even cut things on the left side.) The remaining whitespace on the plot itself is probably from subplot_adjust() with a large value of 'left').
Frank
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Roland Haas