I believe the need to use quotation marks around the style file name was removed at some point, and the manual is out of date. Instead of
#+ODT_STYLES_FILE: "template.ott" the manual ought now to read: #+ODT_STYLES_FILE: template.ott Yours, Christian L.C. Karssen writes: > Hi list, > > Not sure if this is related (or fixed with the aforementioned patch) > because I'm not using a list for the ODT style file. > > Today, after upgrading from Org 9.1.13 (actually installed from melpa on > 20180625) to melpa version 20181105 exporting to ODT stopped working. In > my org file the style file name was enclosed in double quotes (as > specified in the manual [1]): > > #+ODT_STYLES_FILE: "template.ott" > > The error message is: > > OpenDocument export failed: Invalid specification of styles.xml file: > "\"template.ott\"" > > Removing the quotes fixes the export to ODT. > > > Best regards, > > Lennart. > > [1] https://orgmode.org/org.html#Applying-custom-styles > > > On 05-11-18 09:49, Christian Moe wrote: >> >> Thanks, Nicolas! >> >> I'll test on my end when it shows up in ELPA. >> >> Yours, >> Christian >> >> Nicolas Goaziou writes: >> >>> Hello, >>> >>> Christian Moe <m...@christianmoe.com> writes: >>> >>>> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE >>>> option as a list, as in this example from the manual >>>> ([[info:org#Applying custom styles]]): >>>> >>>> #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png")) >>>> >>>> This is needed if you want a complex style with e.g. an image in the >>>> header. >>>> >>>> Exporting this causes an "Invalid specification of styles.xml file" >>>> error on my recent ELPA version. The problem seems to be that the option >>>> is treated as a string and never tested to see if it contains a list. >>>> >>>> To reproduce the problem, place the attached documents >>>> odt-styles-test.org and odt-test-styles.odt in the same directory, then >>>> export odt-styles-test.org to ODT. The result should have a unicorn in >>>> the letterhead. >>>> >>>> The below quick-and-dirty patch seems to fix it, but I'm sure there's a >>>> better approach. >>> >>> Thank you. I applied your patch with an additional check: the value should >>> be enclosed within round brackets. >>> >>> Regards, >> >>
