Hi again Lex (and sorry to disturb you :) ), Le mercredi 6 juillet 2011 16:12:15 UTC+2, Lex Trotman a écrit :
> On 6 July 2011 23:04, Lionel Orry <[email protected]> wrote: > > Well, it seems I found the problem: the <object> tag cannot be auto-closing. > > So we should replace > > > > <object data="{imagesdir=}{imagesdir?/}{target}" type="image/svg+xml" /> > > Thats a perfectly valid empty element, and to quote the XML spec > "Empty-element tags may be used for any element which has no content" I've been digging into this as well, and I know it's a valid element. The fact is asciidoc generates a file whose extension is ".html", whatever the content is HTML or XHTML (thus XML). And a local file opened by Firefox (for example) sees its mime-type set according to the file extension. To give it a try, I created a symbolic link to my faulty test_svg.html called test_svg.xhtml. The '.xhtml' link displays correctly, while the '.html' does not. The corresponding info pages show that the first one only has the correct mime-type (application/xhtml+xml). I've not found any way to force the mime-type to be different with some content in the xhtml source. It is feasible with addons that help you force the mime-type, but it's not my personal goal to do that. May those findings make the ".html" extension given by asciidoc questionable? Yes and no. For the majority of browsers to get the right mime-type, we might probably need to name these ".xhtml" or ".xml". But the .html extension is handy for other reasons (we humble users notice immediately that the file is viewable in a browser, and there's a high change that double-clicking on it or 'xdg-open' it will open the right app for this, i.e. a web browser.). The lesson to remember from this experiment is that if you open a local file generated by asciidoc and supposedly XHTML, it will be rendered as HTML by certain browsers ! > > > > by > > > > <object data="{imagesdir=}{imagesdir?/}{target}" > > type="image/svg+xml"></object> > > But I suppose to make erroneous browsers work this is ok. (After all > there is a long history of adjusting HTML so that dumb browsers work, > hi IE :-) Well in that case the browsers were not erroneous, they were rendering content as text/html, that's all. But indeed the fix is easy so that everyone is happy, so why not... > > > > or even better: > > > > <object data="{imagesdir=}{imagesdir?/}{target}" type="image/svg+xml"> > > <span class="comment"><strong>ERROR</strong>: SVG file '{target}' cannot > > be rendered</span> > > </object> > > Or even better have an attribute for user supplied alternate text. > > > > > Stuart, could you add a similar fix in graphviz-filter.conf ? > > > > Thanks a lot, > > Lionel > > > > Now if you will excuse me I have to go back to watching some minor > bicycle race in some rather pretty country. Thanks for the "pretty country" compliment :) but I already hate the day they'll go through my city when all major axes will be blocked and I'll need one hour more to get back home. :P > Cheers > Lex Lionel -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
