I have a python script that queries customer and order information for a database, creates a latex template based on that data with jinja2, and finally calls
subprocess.call(['/usr/texbin/pdflatex', filename], shell = False)
with filename being the latex template.
The folder of the respective filename is named after the customer. I'm operating in Germany, so some of the filenames contain 'Umlaute' such as ö.
I have a folder structure like so:
.
└── invoices
├── customer_no_umlaut
├── invoice_no_umlaut_01
└── invoice_no_umlaut_02
└── cüstömer_with_ümläüt
├── invoice_with_ümlaut_01
└── invoice_with_ümlaut_02
This all works perfectly fine on my local computer.
Since I need to share these files, however, I want to have the pdfs in a Dropbox folder.
So in my code, I plug in the path to the Dropbox folder instead of the original local folder.
What I then get is the latex template in my Dropbox-folder with this text in parenthesis after the filename:
Unicode Encoding Conflict
as in
"Rechnung_Gedöns_4-724_(Unicode-Codierungskonflikt).tex"
So it seems that Dropbox is not happy with my unicode charset.
What I find strange, though, is that this applies to the filename only. The python script is able to create folders in the Dropbox with the customer's name retrieved from the database with the same encoding.
Does someone have any thoughts on how to solve this?
I managed to resolve this by chance more or less.
In my desperation, I deleted the customer folders containing an umlaut in my Dropbox. I then reran the script described in the question again. From the respective customer data, the script creates the path of the target file folder. If the folder does not exist, it is being created.
As I had deleted the folders, they were now created anew. The latex templates where then placed inside and called with
subprocess.call(['/usr/texbin/pdflatex', filename], shell = False)
And everything works fine.
I guess the old versions of the folders must have been where the unicode conflict took place.