Closed gordol closed 7 years ago
Hello! Thanks for reporting this.
Yes, I believe unescaping href's values will do the trick.
Interesting fix...
Would it not work to just check for jinja tags in the href, instead of using a custom URL protocol?
What is the advantage?
If you do not explicitly use an URL protocol (http, ftp, secretrary) LibreOffice will insert file:
plus the URL to current document path.
So, if we don't use secretary:
scheme, your above template logic ({{ photo.full_size_url }}) will be saved as file:///path/to/current/document/{{photo.full_size_url}}
My first idea was to use a custom filter to solved that problem, but it will be complicated to implement. So the scheme solution is like using a filter but with an easier implementation and cleaner templates.
I see, thanks for the explanation!
I always have to manually edit content.xml in the odt archive to fix this... it's a problem for all HREF type inputs, not just "document" type. I only chose the document type for the example above because it shows the escaping. ;)
Both OpenOffice and LibreOffice refuse to add a feature to allow disabling of certain auto-escape sequences, which is understandable...
So, do we think it's a good idea to try to unescape these before passing into Jinja?