MobileRead Forums - generating epub 3 with mathml?

MobileRead Forums (https://www.mobileread.com/forums/index.php)

- Conversion (https://www.mobileread.com/forums/forumdisplay.php?f=235)

- - generating epub 3 with mathml? (https://www.mobileread.com/forums/showthread.php?t=163255)

generating epub 3 with mathml?

Can calibre convert xhtml+mathml to epub 3 with mathml? Would I be able to open the resulting epub in calibre and have the math render properly? Since ebook-convert detects the desired output format using the file extension, it seems like there would be no way to say that you specifically want epub 3 output.

I guess it would also be nice to have support for epub 3's fallback mechanism for providing a bitmapped image on readers that don't support mathml. But even lacking that, I think it would be fun and cool to be the first kid on the block to be able to produce a valid epub 3 book with mathml in it. (One could always just distribute separate epub 2 and epub 3 files.)

The IDPF doesn't even seem to have included a sample with epub 3+mathml in their directory where they've made sample files available.

As far as I know neither Calibre or any reader device supports mathml.

Just for grins, I gave it a shot. It doesn't look like there is anything really major wrong, just a few minor things.

I made an xhtml5+mathml document, which I fed into ebook-convert to create an epub. Calibre generated output that kept all the mathml in there, which was the right thing to do. When I viewed the output epub, the mathml couldn't render the math, but it gracefully degraded, which is also the right thing to do. (E.g., superscripts just didn't show up as superscripts.)

As far as I can tell, there are only a few minor tweaks needed to get the converter to generate epub 3+mathml output that would be appropriate for future readers that can render mathml:

There needs to be a command-line switch to tell it you want epub 3 rather than epub 2.

When that switch is set, it needs to write xhtml5 rather than xhtml 1.1, set the mime type to application/xhtml+xml, and write output files with extension .xhtml.

The mathml property of the manifest item element should be set if there is mathml in the document. That can be done regardless of whether the user sets the switch requesting epub 3.

The mimetype is set to application/xhtml+xml (that is needed for epub 2) and I don't see why it should require the file extension to be xhtml.

Really the only thing that needs to be done is converting xhtml 1.1 to html 5 which should be fairly trivial, except in the case where the document contains namespaces other than svg/mathml.

But you still wont have any readers capable of displaying the MathML

Thanks, itimpi and Kovid, for the replies :-)

Quote:

Originally Posted by kovidgoyal (Post 1903288)

I don't see why it should require the file extension to be xhtml.

Section 2.1.1 of the spec says, "The XHTML Content Document filename should use the file extension .xhtml." But it's only a "should," not a "must." I doubt that epub 3-compatible readers would care.

Quote:

Originally Posted by kovidgoyal (Post 1903288)

The mimetype is set to application/xhtml+xml (that is needed for epub 2)

I see. What Calibre generates for me in the actual files is:

Code:

<meta content="http://www.w3.org/1999/xhtml; charset=utf-8" http-equiv="Content-Type"/>

But in the package document each item is stated to be application/xhtml+xml.

Quote:

Originally Posted by kovidgoyal (Post 1903288)

Really the only thing that needs to be done is converting xhtml 1.1 to html 5 which should be fairly trivial, except in the case where the document contains namespaces other than svg/mathml.

The spec also requires this:

Quote:

"The mathml [Publications30] property of the manifest item element indicates that an XHTML Content Document contains embedded MathML."

There is a similar requirement for SVG.

Quote:

Originally Posted by kovidgoyal (Post 1903288)

But you still wont have any readers capable of displaying the MathML

Right, but it would be fun to get ahead of the curve and be ready with a epub 3+mathml book when the first mathml-capable readers come out. I assume this will happen fairly soon. The mathml rendering code is all available under permissive licenses, and since math and science textbooks are so lucrative for publishers, I'd assume there would be a huge economic incentive for Apple and B&N to come out with mathml-capable readers. It would allow them to differentiate themselves from Kindle, which is apparently not going to support mathml in the foreseeable future. It's very different from the situation with MS and Internet Explorer, where MS suffers no competitive disadvantage from its failure to support mathml in a standard way.

In case it's of interest to anyone, here is some ruby code I wrote to patch an epub+mathml file output by calibre and make it into valid epub 3. All it does is change the doctypes and add properties="mathml" to each html item in the package document.

Code:

    unless File.exist?(infile) then fatal_error("in patch_epub3: input file #{infile} does not exist") end

    Dir.mktmpdir { |tmpdir|

      unless system("unzip -qq #{infile} -d #{tmpdir}") then fatal_error("in patch_epub3: unable to unzip file #{infile}") end

      package_document = "#{tmpdir}/content.opf"

      # EPUB 3.0 spec, section 4.3.4, says we need to declare mathml property in manifest file:

      xml = ''

      File.open(package_document,'r') { |f|

        xml = f.gets(nil) # nil means read whole file

        xml.gsub!(/(<item\s+([^\/]|"[^"]*")*\/>)/) {

          item = $1 # e.g., item=<item href="ch01_split_000.xhtml" id="html15" media-type="application/xhtml+xml"/>

          if item=~/media-type="application\/xhtml\+xml"/ then # don't do images, just html

            #$stderr.print "item=#{item}\n"

            if item=~/properties="[^"]*"/ then

              item.gsub!(/properties="([^"]*)"/) {p=$1.clone; 'properties="'+(p=~/mathml/ ? p : p+" mathml")+'"'}

            else

              item.gsub!(/<item/,'<item properties="mathml"')                                                                                                                      

            end

            #$stderr.print "changed item to #{item}\n"

          end # if html

          item

        }

      }

      File.open(package_document,'w') { |f| f.print xml }  

      Dir.entries(tmpdir).each { |x|   

        file = "#{tmpdir}/#{x}"   

        if file=~/html\Z/ then

          #$stderr.print "file #{file}\n"

          html = ''

          File.open(file,'r') { |f| html = f.gets(nil) } # nil means read whole file

          # first line output by calibre 0.7.44 looks like this: <?xml version='1.0' encoding='utf-8'?> 

          if html=~/\A<\?xml/ then

            html.gsub!(/\A[^\n]*/) {"<!DOCTYPE html>"}

          end

          File.open(file,'w') { |f| f.print html}               

        end

      }

      File.rename(infile,"before_patch_epub3.epub")

      unless system("zip -rqj #{infile} #{tmpdir}") then fatal_error("in patch_epub3: unable to rezip file #{infile}") end

Unfortunately, I have about 300 things on my plate that would be relevant now, rather than in the future :) But, patches are most welcome :)