attributes appear to be downcased, causing validation errors

[asylumcs]

Attributes, like viewBox for an <svg>, appear to be downcased by ebookmaker, causing validation errors in the output.txt file such as this:

CRITICAL:root:ERROR(RSC-005): /htdocs/ebookmaker/cache/20221017003112/10001-epub.epub/10001/3163743445882447785_two-0.html.html(43,75): Error while parsing file: attribute "viewbox" not allowed here; expected attribute "alignment-baseline", "baseProfile", "baseline-shift", "class", "clip...

Notice it is complaining about "viewbox" when the uploaded file correctly used "viewBox", which is on the "expected attribute list" in the error message.

[eshellman]

on this and #136, are you using html5 or xhtml5 as the source? if the latter, are you providing the svg namespace?

Thanks for submitting these!

[asylumcs]

The source is HTML5. I understand our only choices for source are HTML5 or HTML4 (usually with XHTML 1.0 Strict or XHTML 1.1 serialization). If you want me to try something specific that isn't one of those, just ask. Appreciate you trying to make <svg> work because right now we have submitters who are being told to take back their projects and to remove their svg markup.

[eshellman]

OK great. If it worked in HTML5 I would be worried. It might work in XHTML5 (using <svg:svg>), and I was curious. What should work (and has worked) is a linked svg file. I'll keep these open until as such time as there's need for inline svg.

[eshellman]

same with MathML

[asylumcs]

I'm confused. (1) it is HTML5 and it works in a browser and in an EPUB3 if I make my own epub with Sigil. That is, I don't use ebookmaker because ebookmaker downcases viewBox to viewbox and that's not right. (2) There are users trying to use <svg> inline and they are being told "no." So the time to fix ebookmaker seems to be now, not someday. But you set priorities on such things.

[eshellman]

internally, Ebookmaker uses namespaced xml. so incoming html5 undergoes a conversion process, which doesn't handle non-xhtml namespaces. but incoming xhtml should preserve them.

[asylumcs]

I need clarification: You say HTML5 undergoes a conversion process which doesn't handle non-xhtml namespaces. Is that "does not now" or "does not yet" or "will not ever" handle things like <svg>. If it's any of those, then that's bad news for DP and I believe PG. If it's "does not but will soon handle (<svg>)" then that's a better answer. Is there a plan for <svg> in HTML5?

Also you mention "incoming xhtml." Right now all we allow is HTML5 or HTML4 (usually with XHTML1.0 Strict or XHTML 1.1 serialization). Both of those come with the HTML4 extension of .html. Are you saying if a user wants to use <svg> that they cannot use HTML5? And are you asking for them to provide files, like the ones inside your EPUBs, that have the .xhtml extension and start with an XML declaration line? Please define "incoming xhtml." Thank you.

[asylumcs]

And, back to the issue: do you consider ebookmaker's processing that downcases tags to be an error given that some tags are case sensitive? If so, will that be fixed and this issue closed?

[gbnewby]

@eshellman I am weighing in to confirm that (1) downcasing case-sensitive tags is an error that needs to be addressed and (2) inlining SVGs should be supported. Thanks for your consideration.

[eshellman]

As of today, inline SVGs are not supported in Ebookmaker. It is currently an error for submitters to use them. It is not an error for Ebookmaker to mangle unsupported elements. inline SVG is not supported in EPUB2 so we'd want to downconvert them to referenced png files. For right now, it's much better to flag inline svg as an error in submitted files.

I suppose we could start working on a v0.13 priority list, so we'd have a place to put enhancements expected in 2023.

[gbnewby]

If inline SVG with HTML5 is not supported in ebm, it should be added to the blocklist maintained on the DP wiki.

Analysis has shown that in fact inline SVG is supported in EPUB2 (the spec is silent on inline SVG, I believe). An HTML5 with inline SVG compiled by ebookmaker displayed the SVG correctly whether it was packaged in an EPUB3 or an EPUB2 and whether it was displayed on an EPUB3 reader (Kobo) or EPUB2 reader (Nook). Roger or I could package up some test cases, if that might be helpful.

Indications are that the only issue preventing full use of inline SVG with HTML5 is the mangled elements. There seems to be demand for inline SVG with HTML5 from DPers.

[eshellman]

inline svg is an html5-only element; it's on the DP wiki blocklist.
Ebookmaker supports svg files as an image format alongside png, gif, and jpeg.
EPUB2 files containing inline svg might render successfully, but they won't be valid, as far as I understand