The beta release of Page2Pub should be considered a "Proof of Concept." As such, there are a number of current known issues & limitations to the platform. We plan to address these in future releases.

In particular the next build should feature:

• An authoring interface for creating a cover for your book
• Improved typography
• Ability to add user generated templates
• Full Compliance with the IDPF OPF 2.0 and OPS 2.0 Standards
• Optimization for web pages beyond Wikis
  

If you are interested in assisting with the development of Page2Pub (either through funding or directly working on it with us) please contact us.

Known Limitations

As this is a "feature preview" release, it is bound to have limitations. This section identifies the issues and limitations we are aware of; if you encounter these issues, please do not report them – they are already on our TO-DO list. On the other hand, if you encounter an issue that is not listed here, please see the "Reporting Bugs" section below and let us know!

Preview Output Differs from Final Output

The PRS uses HTML (i.e. web-page format) to display a preview of what the final output will look like when it is rendered to PDF. Unfortunately, HTML does not support page breaks, headers, footers, or page numbers, so these elements may be missing or appear in strange places within the previewed content. The HTML preview also places borders around elements when such borders will not be present in the final output. In addition, the kerning and/or character spacing of content in HTML is not the same as it is in print or in a PDF, so the spacing of elements, such as the table of contents, may look strange during preview, but will look correct in the final PDF document.

In a future version of Page2Pub, we would like to move away from using HTML for rendering the preview. Unfortunately, with the current state of Adobe Flex components, such a solution may require us to write a significant amount of custom code for this to be possible.

No Editing Support

Aside from editing meta-data, neither the gathering component nor the PRS currently provide any way to edit gathered content before it is rendered to the final PDF. Editing is a large but important feature that we would like to add in future versions once we have secured proper funding.

Only One Instance of the PRS Can Be Running at a Time

Only one instance of the PRS can be running at a time, as a result of our choice to use Adobe Flex on the Adobe Air Runtime for the user interface. Adobe limits the number of instances of an Air application to one. Unfortunately, this restriction cannot be lifted unless Adobe lifts it, or we switch to a different library for the user interface.

Only One EPUB Publication Can Be Open in the PRS at a Time

Currently, only one EPUB publication can be open in the PRS at a time. Since the PRS does not provide any editing support, we do not believe this should pose much of an inconvenience. However, with additional funding, we do wish to make the PRS support opening multiple documents in multiple windows in the future, especially because only one instance of the PRS can be running at a time (see previous section).

Chapter Titles are Not Rendered

Although the gathering component associates a unique "chapter name" with each piece of content gathered (either selections or full pages), the PRS does not render these chapter names into the final document. The decision to exclude this feature was a response to the restriction the gathering component currently imposes that chapter names not contain spaces. When this restriction is lifted, we may add chapter title rendering support in the future.

"Full page" Gathering Results in Unwanted Content

The PRS has only been tuned to work well with full-page gathering from RocWiki (http://www.rocwiki.org) – the "People's Guide" to Rochester, NY – and MediaWiki sites based on the "Monobook" theme (such as Wikipedia, http://www.wikipedia.org). The PRS will do its best to render full pages of content gathered from other sites, but the result may include additional text or links that are unwanted. For example, gathering a full page from other sites might include navigational links, header and footer text, and layout images, which were intended for presentation as an on-screen web page but that look out-of-place in print.

To prevent this, we recommend selecting and gathering only the specific content you want from each page (see "Gathering a Selection" under the "Using Page2Pub" section of this document).

Metadata Are Not Used During Rendering

Although the gathering component captures metadata about each piece of gathered content, this information is currently not used by the PRS. We envision this information being accessible and useful once editing features have been added to the system.

Content Containing Nested Tables Does Not Render Correctly

Gathered content containing nested tables does not currently render properly in the PRS. This is due to a limitation in iText (http://www.lowagie.com/iText/), the PDF rendering framework that the PRS uses, that prevents a table from being nested within the cell of another table when there is additional content within the cell. The current implementation will sacrifice the content of the cell to preserve the content of the nested table, which may not be the desired behavior.

In the process of adding editing support, we intend to overhaul the way that tables are rendered to remedy this issue. Unfortunately, with the current architecture, the iText framework would need to be modified to support nested tables properly.

Limited Template Support

Although the PRS makes use of templates for page size and layout information, support for these templates is limited. Specifically, colors and borders, specified in the templates are ignored, as are any fonts specified that are not installed on the local machine. In addition, although templates define the spacing between various elements, this spacing is not respected for most elements. This is due to a limitation in the way that the PRS represents nested content (paragraphs, images, and tables in other paragraphs or table cells) to the iText PDF framework.

With the introduction of editing support in a future version, we intend to make template support much more useful and flexible.

Only Partial Compliance with the IDPF OPF 2.0 and OPS 2.0 Standards

The Page2Pub system is only partially compliant with the "EPUB" standards – the Open Publication Structure (OPS) 2.0 and the Open Packaging Format (OPF) 2.0 – as defined by the International Digital Publishing Forum (IDPF). This section notes the specific limitations in this area.

No NCX support

Version 2.0 of the OPF introduces a declarative table of contents, the Navigation Center eXtended (NCX), which must be included in an "NCX file" within an EPUB publication to define the table of contents and reading order. Currently, the Gathering component does not generate this file and relies on EPUB readers / reading systems to fall-back to the OPF version 1.0 behavior of using the spine as the table of contents. In addition, the PRS also follows the version 1.0 behavior, ignoring any NCX file that is specified in the OPF and relying entirely on the spine to define the order in which content is rendered.

Support for Chapter Content in XHTML Format Only

Although the OPS defines three acceptable formats for chapter content within an EPUB publication – XHTML, DTBook, and Out-of-Line XML Islands – the PRS will only render EPUB publications containing chapter content in XHTML format. Publications containing content in other formats will not render at all, even if such content defines fall-backs in XHTML format (see the next section).

No Support for EPUB Fallback Content

Fallback support allows an EPUB reader to use a fail-safe version of a document, in case it cannot render the specified document. This is due to the fact that XHTML pages are specified for use as fallback items. Since all of our gathered documents are in the XHTML format, fallback support has not yet been added.

No Support for SVG Images

The OPS defines four image formats that OPS-compliant Reading Systems must support – Graphics Interchange Format (GIF), Joint Photographic Experts Group (JPEG), Portable Network Graphics (PNG), and Scalable Vector Graphics (SVG). Unfortunately, SVG graphics require an entirely different image rendering system than the other three. Therefore, the PRS cannot currently render images in SVG format.

We may be able to take advantage of a framework such as Apache Batik (http://xmlgraphics.apache.org/batik/) to provide this support in the future.