Re: Considering writing a proposal for the ePub filter for GSoC

Reading through the EPUB3 content document spec[0], it looks like there aren't any major changes that would drastically alter the proposal. Navigation documents are used instead of NCX in EPUB3. Navdocs just use HTML nav elements in a restricted format. I am inclined to let the user decide what EPUB version to comply to on export, in case they happen to be publishing for a particular ereader platform which mandates compliance to an older EPUB standard. But the default case should always be EPUB3. That will be the version the project supports initially, and legacy support will be added later if there's time, or in future post-GSoC patches. EPUB3 also has Media Overlays [1] based on the SMIL spec[2], which I am not sure if we need to support yet. AbiWord doesn't seem to have media embedding capabilities, which makes export easier, but any imported documents with SMIL overlays would not be fully compatible. (Please correct me if I'm wrong.) It also supports MathML, again limited to an EPUB specific subset, which AbiWord's HTML exporter will generate, so that's another win for us. Haven't tested MathML import yet. [0]http://idpf.org/epub/30/spec/epub30-contentdocs.html [1]http://idpf.org/epub/30/spec/epub30-mediaoverlays.html [2]http://www.w3.org/TR/SMIL3/ --- On Thu, 4/7/11, Leonard Rosenthol <leonardr_at_lazerware.com> wrote: From: Leonard Rosenthol <leonardr_at_lazerware.com> Subject: Re: Considering writing a proposal for the ePub filter for GSoC To: "David Wendt JR." <dcrkid_at_yahoo.com> Cc: "abiword-dev" <abiword-dev_at_abisource.com> Date: Thursday, April 7, 2011, 6:15 PM I would STRONGLY recommend that you do this based on the upcoming EPUB3 standard rather than the EPUB2.x version. Leonard On Thu, Apr 7, 2011 at 11:03 AM, David Wendt JR. <dcrkid_at_yahoo.com> wrote: I made an actual GSoC proposal for this now, available at [0]. I'll also copy-paste it here: Name: David Wendt Email: dcrkid_at_yahoo.com Project Title: ePub export/import for Abiword Synopsis: This project involves creating an Abiword export and import filter for ePub documents. ePub is a document format used for electronic publications such as e-reader books. Users will be able to create ePub documents easily using Abiword.Benefits to the AbiWord (and/or other) project(s): Deliverables: Abiword will be able to generate ePub documents, as well as edit existing ePub documents. Project Details: I will be modifying the existing HTML export and import filters to deal with ePub documents. ePub is mainly a restricted subset of HTML and CSS, compressed into an archive, along with navigation and other metadata. Project Schedule: I can begin work once the current college semester ends. The Spring 2011 semester term ends May 23rd. I currently have no scheduled absences or classes during the GSoC period. Bio: I'm David Wendt, a 3rd year college student studying computer science at Stony Brook University. I have experience with C++ and a few other languages. My previous GSoC projects were with Debian, where I (2009) modified vmbuilder to produce Debian images, and (2010) modified debbugs to allow bug submission through SOAP instead of e-mail. I have also done the necessary work to demonstrate that I can compile and modify Abiword. The relevant screenshot has been posted to an image sharing service, at this URL: http://i.imgur.com/BPwaI.png [0] http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/dwendt09/1# --- On Tue, 4/5/11, David Wendt JR. <dcrkid_at_yahoo.com> wrote: > From: David Wendt JR. <dcrkid_at_yahoo.com> > Subject: Re: Considering writing a proposal for the ePub filter for GSoC > To: abiword-dev_at_abisource.com > Date: Tuesday, April 5, 2011, 11:52 PM > Aah! At one time I thought dividing > documents into separate files was mandatory, but then I > checked and noticed we could use fragment identifiers. It > seemed conceptually easier; I would be able to get ePub > proof-of-concept exports working first and then work on > document separation later down the line. > > Separate documents have hypothetical advantages in > low-memory environments, such as the ereader tablets most > likely to be processing ePub, since it wouldn't have to keep > as big of a DOM tree in memory. I'm not sure if .zip > supports solid compression but if it doesn't then we'd lose > out a tiny bit on filesize. (I think the memory gains are > more important than a few extra Kib here or there.) > > BTW are you a student? Or are you willing to mentor? > > --- On Tue, 4/5/11, Volodymyr Rudyj <vladimir.rudoy_at_gmail.com> > wrote: > > > From: Volodymyr Rudyj <vladimir.rudoy_at_gmail.com> > > Subject: Re: Considering writing a proposal for the > ePub filter for GSoC > > To: "David Wendt JR." <dcrkid_at_yahoo.com> > > Cc: abiword-dev_at_abisource.com > > Date: Tuesday, April 5, 2011, 11:40 PM > > > > Hi! > > I`m investigating this idea too. > > > > > We are allowed to use fragment identifiers in > our > > manifest, so we wouldn't have to split documents into > > separate HTML files. > > > > It seems to me that it`s better to create separate > files > > for every > > chapter for user convenience - when  chapters are > > rather small it is > > easier to reading software to parse and load it (don`t > sure > > how much > > performance this will give, but we should`n ignore it > - at > > least we > > should give user an option that will enable or > disable > > dividing > > document into separate files). > > > > > Judging by the existence of HTML export > functionality > > (IE_Exp_HTML) it's tempting to add some options to it > and/or > > write an ePub subclass that uses the HTML > functionality to > > generate the ops files. > > > > Yes, it could be used. Though in my export filter > prototype > > I`m using > > my own export classes to better understand how > exporter > > works, it`s > > use can reduce lot`s of work with OPS, of course with > some > > modifications. Then the only thing we need is to > created > > packaging > > file (.OPF) and add some container metadata > (container.xml > > in > > META-INF). > > > > > > > > Sincerely, > > Volodymyr Rudyj > > > > > >
Received on Fri Apr 8 02:53:40 2011