XML Wokflows: From XML to PDF: Part 1: Special Transformation

Rather than having to deal with XSL-FO, another XML based vocabulary to create PDF content, we’ll use XSLT to create another HTML file and process it with CSS Paged Media and the companion Generated Content for Paged Media specifications to create PDF content. I’m not against XSL-FO but the structure of document is not the easiest or most intuitive. An example of XSL-FO looks like this: <?xml version=”1.0″ encoding=”iso-8859-1″?> (1) <fo:root xmlns:fo=”http://www.w3.org/1999/XSL/Format”> (2) <fo:layout-master-set> (3) <fo:simple-page-master master-name=”my-page”> <fo:region-body margin=”1in”/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-reference=”my-page”> (4) <fo:flow flow-name=”xsl-region-body”> (5) <fo:block>Hello, world!</fo:block> (6) </fo:flow> </fo:page-sequence> </fo:root> This is an XML declaration. XSL FO

XML workflows: Converting our content to HTML

One of the biggest advantages of working with XML is that we can convert the abstract tags into other markups. For the purposes of this project we’ll convert the XML created to match the schema we just created to HTML and then use tools like PrinceXML or AntenaHouse we’ll convert the HTML/CSS files to PDF Why HTML HTML is the default format for the web and for most web/html based content such as ePub and Kindle. As such it makes a perfect candidate to explore how to generate it programmatically from a single source file. HTML will also act as

XML workflows: Introduction

One of the biggest limitations of markup languages, in my opinion, is how confining they are. Even large vocabularies like Docbook have limited functionality out of the box. HTML4 is non-extensible and HTML5 limits how you can extend it (web components are the only way to extend HTML5 I’m aware of that doesn’t need an update to the HTML specification.) By creating our own markup vocabulary we can be as expressive as we need without adding complexity for writers and users and without adding unnecessary complexity for the developers building the tools to interact with the markup. Why create our

Athena: What an ofline web reading experience may look like

With the latest set of web technologies coming down the W3C/WHATWG pipeline it is now possible to create top-of-the-line responsive experiences that can also work as ofline applications. HTML5 web is more than capable of competing with native applications. Chrome and Windows apps have shown as much capability as native apps, if we let them. What needs to happen now is the developer shift to thinking about the web in terms of application logic rather than the rules we want the web to play by. Athena is a proof of concept for such an application. It uses ServiceWorkers for caching

CSS Support and namespaces

There are two new @rules in CSS (well, they may not be new but they are new to me) that open an awesome set of possibilities for CSS development with or without a pre-processor. @namespace CSS namespaces are the CSS implementation of XML namespaces; the technology that allows elements from different XML vocabularies to live in the same document . In the case of CSS, namespaces allow us to style elements with the same name from different vocabularies differently. For example, let’s look at the a from both XHTML and SVG vocabularies @namespace url(http://www.w3.org/1999/xhtml); @namespace svg url(http://www.w3.org/2000/svg); /* This matches