I don't know, only John MacFarlane can have the answer to that question Le dimanche 13 août 2023 à 07:38:44 UTC+2, nopria a écrit : > I see, can such behaviour be fixed? Should I report it as a bug? > > Il giorno sabato 12 agosto 2023 alle 20:01:25 UTC+2 Christophe Demko ha > scritto: > >> >> $ pandoc -t native ![SVG Image](data:image/svg+xml;charset=utf-8,> version="1.0"?>> width="100" height="100" viewBox="-150 -150 >> 300 300">> style="fill:#CCCCFF;stroke:#000099"/>) [ Figure ( "" , [] , [] ) >> (Caption Nothing [ Plain [ Str "SVG" , Space , Str "Image" ] ]) [ Plain [ >> Image ( "" , [] , [] ) [ Str "SVG" , Space , Str "Image" ] ( >> "data:image/svg+xml;charset=utf-8,%3C?xml%20version=%221.0%22?%3E%3Csvg%20xmlns=%22http://www.w3.org/2000/svg%22%20width=%22100%22%20height=%22100%22%20viewBox=%22-150%20-150%20300%20300%22%3E%3Crect%20x=%22-100%22%20y=%22-100%22%20rx=%228%22%20ry=%228%22%20width=%22200%22%20height=%22200%22%20style=%22fill:#CCCCFF;stroke:#000099%22/%3E%3C/svg%3E" >> , "" ) ] ] ] >> >> Le samedi 12 août 2023 à 19:59:59 UTC+2, Christophe Demko a écrit : >> >>> It's because pandoc converts the URL of an image using HTML encoding and >>> does not the reverse job while producing output. >>> >>> Le samedi 12 août 2023 à 19:42:38 UTC+2, nopria a écrit : >>> >>>> Yes it's an option, but I would like to understand why using plain text >>>> does not work. >>>> >>>> Il giorno venerdì 11 agosto 2023 alle 12:23:32 UTC+2 Christophe Demko >>>> ha scritto: >>>> >>>>> You could write a filter that convert a Inline SVG image defined by >>>>> plain text into a Inline SVG image defined by BASE64 >>>>> >>>>> Le jeudi 10 août 2023 à 15:39:40 UTC+2, nopria a écrit : >>>>> >>>>>> Following other tentatives >>>>>> >>>>>> of markdown to DOCX conversion containing external SVG, I tried to convert >>>>>> to ODT a markdown containing **inline** SVG, such as the one below: >>>>>> >>>>>> # Example document >>>>>> >>>>>> This is an example of Markdown document with inline embedded SVG >>>>>> images. >>>>>> >>>>>> Inline SVG image defined by plain text: >>>>>> >>>>>> ![SVG Image](data:image/svg+xml;charset=utf-8,>>>>> version="1.0"?>>>>>> height="100" viewBox="-150 -150 300 300">>>>>> ry="8" width="200" height="200" style="fill:#CCCCFF;stroke:#000099"/>) >>>>>> >>>>>> Inline SVG image defined by BASE64 converted text: >>>>>> >>>>>> ![SVG >>>>>> Image](data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxMDAiIGhlaWdodD0iMTAwIiB2aWV3Qm94PSItMTUwIC0xNTAgMzAwIDMwMCI+PHJlY3QgeD0iLTEwMCIgeT0iLTEwMCIgcng9IjgiIHJ5PSI4IiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjIwMCIgc3R5bGU9ImZpbGw6I0NDQ0NGRjtzdHJva2U6IzAwMDA5OSIvPjwvc3ZnPg==) >>>>>> >>>>>> Some math to check if it works; >>>>>> >>>>>> $$A_c = 23 r^2 - v$$ >>>>>> >>>>>> using command >>>>>> >>>>>> pandoc example.md -o example.odt >>>>>> >>>>>> with Pandoc 3.1.6.1. As you may confirm yourself, the BASE64 inline >>>>>> SVG is correctly converted, while the textual inline SVG is not displayed >>>>>> in the resulting ODT and the following warning appears at conversion: >>>>>> >>>>>> [WARNING] Could not fetch resource data:image/svg+xml;charset=utf-8 >>>>>> ... >>>>>> >>>>>> Given that a BASE64 inline SVG is enough to do the job, I would >>>>>> prefer to avoid the BASE64 conversion and go with the plain text inline SVG. >>>>>> >>>>>> I already tried html encoding of SVG text and uppercase "utf8" >>>>>> without success. >>>>>> >>>>>> I choose ODT because it's open and because it seems to display SVG >>>>>> natively without needing PNG conversion (I hope it works with more complex >>>>>> SVG too), which is a great feature. >>>>>> >>>>>> Thank in advance for your time. >>>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/56d7ca33-74ad-4499-8cb1-49e8ea240187n%40googlegroups.com.