Non-rectangular areas and copyfitting may seem like radical new steps for XSL FO, but they are both in the first XSL Requirements Summary published in 1998! One thing that has changed since 1998 is that now XSL can say “area shapes will be SVG”, and everybody will nod wisely and get on with implementing or using non-rectangular areas expressed in SVG. Back in 1998, there was no SVG and no other standard way of expressing shapes that could have been nearly as usable for the purposes of XSL FO.

The talks are:

• What XSL 2.0 means for implementers and users — Discusses the changes that will have to take place under the hood of any XSL formatter that supports XSL 2.0 and what those additional capabilities can bring to your stylesheets.
• Real time, all the time, ragtime XML — An update on the capabilities of Xcruciate.

• Go to http://www.jisc.go.jp/app/JPS/JPSO0020.html, enter “X4051″ in the first text input field (the one with the “JIS” prefix), then press enter.
• On the next page, select “JISX4051″.
• On the following page, there’ll be links to the PDFs of the parts of JIS X 4051. You can view them in your browser, but you can’t print them.  (If your browser launches in an external application to view PDFs,  all you might see is a bunch of blank pages.)

The XSL FO 2.0 talk covers: a quick overview of XSL 1.1 (by building up a formatted page in the manner of Genesis 1); the current uses for XSL; the W3C XSL FO subgroup; the XSL 2.0 requirements workshop and requirements document; and some examples of what will be possible with XSL 2.0.

The “Testing XSLT” talk from XML Prague 2009 covers more of the “what” and “why” of testing XSLT that previous renditions of the talk or tutorial. It consequently has fewer details about individual tools, but for that there’s now resource pages for XSLT and XSL FO tools on the Menteith Consulting website.

The other XML Prague 2009 talk is about Xcruciate, where I was the second speaker with Mark Howe of Cyberporte, and the posters were about XSL FO 2.0 requirements and using XSLT with xmlroff to generate C source code and other things.

So I would like to know how you are using XSL FO. Please reply to Tony.Graham@MenteithConsulting.com.

To make it a bit easier for you, here are some categories:

• Use
• Volume (e.g., pages per day/week/month/year/job)
• When you started using XSL FO
• Interesting aspects of job/output
• Additional comments
• Anonymous (yes/no)

I am interested in all uses of XSL FO, but if your use is particularly off-the-wall, I may come back to you asking for a sample or a scan/photo of the completed work.

I will summarise the results back to here and to the lists where I’m also asking for information.

If you want to be anonymous, I won’t mention either you or your company by name in any results.

Some version of the results may end up being linked to from the W3C XSL page: I haven’t organised anything with the XSL FO SG, but it seems like the sort of information that would be useful to have there.

Firefox could display the character, so I knew it had to be there somewhere. After a bit of hunting through /usr/share/fonts using FontForge, I found the OpenSymbol font, originally part of OpenOffice but now separately installable as the ttf-opensymbol package.

The first step in acquainting any XSL formatter with the font’s use is including the font name in a font-family value. Specifying font-family on fo:root sets the default for the document:

<fo:root font-family="Georgia, opensymbol"
 font-selection-strategy="character-by-character">

I used to have symbol, etc., in that list for use on Windows, but, sadly, I haven’t found a way to get a ✓ into PDF other than also installing the OpenSymbol font there. Specifying font-selection-strategy as character-by-character is just making sure the formatter will swap fonts if the first font doesn’t have a glyph.

How the XSL formatter finds the font is different for different formatters. The second, Antenna House-specific step is adding /usr/share/fonts/truetype/openoffice, which contains the font file, to the config file at /usr/AHFormatterV5/etc/font-config.xml:

<font-config>
 <!--otf-metrics-mode mode="typographic"/-->
 <!-- add your font folder here -->
 <!-- font-folder path="/home/user-name/fonts" -->
 <!-- /font-folder -->
 <font-folder path="/usr/AHFormatterV5_64/fonts">
 <glyph-list file="ZapfDingbats-glyphname.txt" afm="ZapfDingbats.afm"/>
 </font-folder>
 <font-folder path="/usr/share/fonts/truetype/msttcorefonts"/>
 <font-folder path="/usr/share/fonts/truetype/openoffice"/>
</font-config>

And I get a tick out of U(buntu):

The Note “describes requirements for general Japanese layout realized with technologies like CSS, SVG and XSL-FO”. It covers page design conventions as well as how to layout lines. Naturally it covers Japanese-specific details such as vertical text, mixing Japanese and Latin text, ruby (small-sized, supplementary text), warichu (inline cutting notes), tate-chu-yoko (horizontal in vertical setting), and furiwake (multiple phrases or sentences in in the middle of a line).

The article provides an overview of the Note (and was good practice for the in-depth analysis that needs to be done for one of the XSL 2.0 requirements), but if you want all the details, then you need the Note (and if you really want all the details, then you also need JIS X 4051, and possibly assistance in reading it).

To do the deed, I added some XSL attributes to the <inline-graphic> element in my well-formed XML.  I also made an entity declaration for &xmlroff; so I wouldn’t have to repeat the markup each time (and so, having got it right once, it would be right everywhere).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE poster [
<!ENTITY xmlroff '<inline-graphic src="xmlroff.svg" alignment-adjust="-22.5&#37;"
height="from-parent(&apos;font-size&apos;)"/>' >
]>
<poster>
<title>Using XSLT in &xmlroff; for C Code Generation and XSL FO Testing</title>
<body>
<intro>
<para>&xmlroff; (http://xmlroff.org) is a fast, free, high-quality,...

where:

• height="from-parent('font-size')" sets the graphic height to the current font-size
• alignment-adjust="-22.5%" (where “%” is the numeric reference for “%”) moves the bottom of the graphic down so the baseline of the logo text lines up with the baseline of the regular text. When the alignment-adjust value is a percentage, it is calculated relative to the height, so it remains correct when the font size changes.

The XSL attributes are just copied through when transforming to XSL FO:

<xsl:template match="inline-graphic">
  <fo:external-graphic
    src="url('{@src}')"
    xsl:use-attribute-sets="graphic-atts"
    content-height="scale-to-fit"
    content-width="scale-to-fit"
    scaling-method="resample-any-method">
    <xsl:copy-of select="@height | @width | @content-height | @content-width |
@scaling-method | @alignment-adjust"/>
  </fo:external-graphic>
</xsl:template>

The result is slightly more interesting text, but also more readable where sentences and paragraphs that started with the all-lowercase “xmlroff” now start with the xmlroff logo.

Two of the best ways for you to provide feedback about XSL-FO and the requirements for XSL-FO 2.0 are:

• Indicate which areas of XSL-FO are important to you by completing the survey at http://www.w3.org/2002/09/wbs/1/xslfo20requirements/
• Provide feedback on individual requirements using the W3C public Bugzilla system