This procedure worked for me.  There is no guarantee that it would work for you, and you use these instructions solely at your own risk.  As always, back-up your data and remove the battery before fiddling with the insides of your computer.

The underside of the P1630, with battery removed, is shown below:

The drive bay with the cover removed is shown below. The drive is covered by a plastic sheet, and it’s the four foam-rubber pads at the edges of the sheet that holds the drive in place.

Every muscle, every sinew, every fibre of your being will scream that it isn’t so, but you just need to lever up the disk drive to be able to take it out (taking care not to damage the flat cable connecting to the drive):

After you disconnect the flat cable from the drive (another moment where you wonder exactly how much force will be “enough” force), you can take the plastic/foam-rubber combo off the old drive, put it on the new drive, and do the reverse procedure to reassemble the P1630 with the new drive.

Emacs’ “Imenu” feature puts in the menu-bar a menu whose each menu item (or sub-menu item) jumps you to a location in the current buffer. Emacs being Emacs, Imenu is highly configurable, and quite often an Emacs mode will set up the Imenu menu to point to locations in the buffer that are significant for that mode/file-type. For example, my xslide and tdtd modes each set up very different Imenu menus.

`imenu-generic-expression` is a variable that, at its simplest, contains a list of three-item lists that each specify a menu title, a regular expression, and the number corresponding to the subexpression of the regular expression to use as the resulting menu item’s name. When `imenu-generic-expression` is set and the Imenu menu bar item is enabled (using `imenu-add-to-menubar`, naturally), Emacs constructs a buffer index by searching the buffer using each of the regular expressions in turn and then builds up the menu based on the matches found.

For example, here’s the `rnc-mode-hook' that I use to add a “RNC” menu when using `rnc-mode' to edit RELAX NG compact syntax (RNC) files. The hook sets `imenu-generic-expression` with patterns that match significant declarations in a RNC file (with separate sub-menus for include, namespace, and datatypes declaration types) then enables Imenu with `imenu-add-to-menubar`. A screenshot of the resulting menu is action is shown after the code.

(require 'rnc-mode)
(add-hook 'rnc-mode-hook
 (lambda ()
   (set-variable
    'imenu-generic-expression
    (list
     (list
      nil
      "^\\([a-zA-Z][-a-zA-Z0-9._]*\\)\\s-*[&|]?=" 1)
     (list
      "include"
      "^include\\s-+['\"]\\([a-zA-Z][-a-zA-Z0-9._]*\\)['\"]" 1)
     (list
      "namespace"
      "^\\(default\\s-+\\)?namespace\\s-+\\([a-zA-Z][-a-zA-Z0-9._]*\\)\\s-*=" 2)
     (list
      "dataypes"
      "^datatypes\\s-+\\([a-zA-Z][-a-zA-Z0-9._]*\\)\\s-*=" 1)))
   (imenu-add-to-menubar "RNC")))

The only downside to using `imenu-add-to-menubar` compared to doing more of it yourself is that `imenu-add-to-menubar` doesn’t provide a way to sort the menu items, so the order of the matches in the file is the order of the items in the menu or sub-menu. I wrote both xslide and tdtd before I knew of `imenu-add-to-menubar`, but the recently revived xslide for XSLT 2.0 still uses a custom function to make the Imenu index because I also like to sort the index entries alphabetically within each menu or sub-menu.

stf (https://github.com/MenteaXML/stf) is a XProc pipeline that runs a Schematron test suite on test documents (that you create) and winnows out the expected results and report just the unexpected.  stf uses a processing instruction (PI) in each of a set of (typically, small) test documents to indicate the test’s expected asserts and reports: the expected results are ignored, and all you see is what’s extra or missing.  And when you have no more unexpected results from your test documents, you’re ready to use the Schematron on your real documents.

<?stf?> Processing Instruction

The format of the PI is:

<?stf \s+ ( '#NONE' | ROLE ':' COUNT ( \s+ ROLE ':' COUNT )* ) ?> 

where:

• stf: PI target
• #NONE: No faild assert or successful report expected. Use with ‘go’ tests that should not produce any assert or report messages. If running Schematron on the test produces any asserts or reports, they are reported as an error.
• ROLE: Token corresponding to @role value of an assert or a report in the Schematron. Schematron allows @role to be an arbitrary string, but restricting it to a single token makes it easier to deal with the PI using regular expressions rather than having to parse roles that may contain spaces.
• COUNT: Integer number of expected occurrences of failed asserts or successful reports with @role value matching ROLE. A mismatch between the expected and actual count is reported as an error. A ROLE starting with # does not have its count checked.
• \s: Whitespace character

Examples

<?stf ERROR_FOO:2 ERROR_BAR:1 ?> 

A failed assert or successful report with role="ERROR_FOO" is expected twice in the SVRL from the test document, and either with role="ERROR_BAR" is expected once.

<?stf ERROR_FOO:2 #ERROR_BAR:1 ?> 

A failed assert or successful report with role="ERROR_FOO" is expected twice in the SVRL, and no assert or report with role="ERROR_BAR" is expected since # precedes ERROR_BAR.

<?stf #NONE ?> 

No assert or report are expected for the current document.

Usage

stf requires Ant and Calabash. Calabash (as used here) requires Saxon. All three require Java.

1. Set the properties in properties.xml to match your local setup.
2. Write the tests, including a <?stf?> processing instruction in each.
   One practice is to use a tests directory containing a go subdirectory for tests that are expected to produce no Schematron assert or report messages and a nogo subdirectory for tests that are expected to have errors, but you can organise them any way you like.
3. Run Ant
   You can run the test.schematron from build.xml directly:

   ant -f /path/to/stf/build.xml test.schematron

   or you can import the stf build.xml into your local build.xml:

   <property name="stf.dir" location="/path/to/stf" />
   <import file="${stf.dir}/build.xml" />

   and run the test.schematron target, or you can import the stf build.xml and use the <test.schematron/> macro in a target in your local build.xml:

   <target name="test">
     <test.schematron />
     <xspec xspec.xml="tests.xspec" />
   </target>

Ant Properties

• ${schematron}: Schematron file to test.
• ${tests.dir}: Directory containing test files.
• ${calabash.jar}: Location of Calabash jar.
• ${saxon.jar}: Location of Saxon 9.2 (or later) jar.
• ${resolver.jar}: Location of XML catalog resolver library.
• ${resolver.class}: Class name of XML catalog resolver. Default is org.apache.xml.resolver.tools.CatalogResolver.

XProc Processor

The pipeline currently depends on Calabash extensions.

The version of Calabash used in testing depended on Saxon 9.2 or later.

Running (Not Testing) Schematron

Ant build file also includes schematron macro and run.schematron target to make it easy to run Schematron on real files once you’re sure it works on your tests.

License

Licensed under the terms of a BSD license.

• Update on the XSL-FO 2.0 work
• ‘Ignite’ lightning talks on XSL-FO
• XSL-FO tutorial

If you use Twitter, register your interest at the “XSL-FO meetup @ XML Prague 2012” page on Lanyrd.com, otherwise send me email.  If you have suggestions for the format or content, likewise add something to the Lanyrd page or send me email.

The fo:simple-page-master FO in XSL 1.1 defines the dimensions of a page. A document may have more than one fo:simple-page-master, and the same fo:simple-page-master may be used in multiple contexts. A fo:simple-page-master has up to five regions: fo:region-body, fo:region-start, fo:region-end, fo:region-start, and fo:region-end.  Only fo:region-body is required.  The adjacent figure shows one arrangement of the regions.

Effect of writing mode

The FO names for the outer regions include “-before”, “-after”, “-start”, and “-end” rather than “-top”, “-bottom”, “-left”, and “-right” since the relative position of the regions depends on the writing mode.

This figure shows the arrangement of the regions for both “lr” (short for “tb-lr’ for “top-to-bottom, right-to-left”) and “rl” (you can work it out) writing modes. As you can imagine, the arrangements would be different again for “tb-rl” and “bt-rl”, etc.

Regions have default names

Regions have names, and content is directed to the page regions based on the region’s name, not on its FO type (a.k.a. its “class”). This time, the figure shows the default, initial name for each page region FO, which just happens to look a lot like the FO’s name, such as “xsl-region-body” for fo:region-body.

Or use your own names

But you don’t have to stick with the initial names. You can define the regions with any name, such as “my-before”, “my-end”, or even “George”, provided it’s:

• A valid name. It has to be, in XML terminology, a NCName, which means, e.g., it can’t contain a colon and has to start with a letter (or other allowed character).
• Unique within the region names for the page master
• Not the initial name for a different class of region: i.e., you can’t call your fo:region-before “xsl-region-after” and expect things to work

An additional proviso that works across page masters is that you can’t use the same name on different region types on different page masters. So “George” can’t be a fo:region-before on one page master and fo:region-start on another. Sorry, George.

Reusing region names across page masters

The flip-side of the proviso above is that you can use the same region name for the same region on different page masters. This figure shows three page masters that will separately be used for:

• The first page in a page sequence;
• The odd pages; and
• The even pages.

Since (for conventional, “tb-lr” documents, anyway) the first page of the first page sequence is numbered “1″ and appears on the right-hand (recto) side of a spread and (conventionally, again) following page sequences also start on an odd-numbered, recto page, the page master for the first pages often has the same header and/or footer as other pages or other odd-numbered pages. In this case, the “First” page master and the “Odd” page master have the same names for the same regions except xsl:region-end, which is named “First-Outside” on the “First” page master and “Odd-Outside” on the “Odd” page master. (Note that repetition of “First” and “Odd” in region names is for convenience only and isn’t a requirement of XSL-FO.)

Arrange page masters into sequence

When the multiple page masters are used to make a sequence of pages (using fo:page-sequence-master, as you do), you can see the repetition of the regions across the multiple pages. When overlaid over pages from the exercises used in the course, you can see the same footer in use on the odd pages, a different footer on the even pages, the different fo:region-end content on the first and the later odd pages, and (in this case) nothing at all in the fo:region-start of any page.

Content from fo:page-sequence

The content of the page regions, including the content of the fo:region-body, comes from the fo:page-sequence: (conventionally) the content of the outer regions are defined in fo:static-content, and the content of the fo:region-body, in the fo:flow.

The correspondence between fo:static-content and an outer region is by name: put simply, when a page master for a page has a region with the same name as the “flow-name” property of a fo:static-content of the current fo:page-sequence, the areas from the formatting objects within the fo:static-content are repeated within that region on that page. (The not put simply version could see things rearranged through a XSL 1.1 fo:flow-map and multiple fo:flow with content directed to multiple regions on the page, but that’s something for another time.)

I’d like to thank my clients, past and present, who provided such positive testimonials for inclusion in the new site.

In the beginning, there was the page. And the page was without objects and void, and not a whole lot was upon the face of the page.

And XSL said, let there be text, and there was text.

And XSL saw the text, and they divided the text from the page. And XSL called the text the region-body, and the space they called the margins. And the region-body and the margins were the first formatting.

And XSL said, let there be blocks in the midst of the text, and let them divide the text from the text. And it was so. And the text with blocks was the second formatting.

And XSL said, let there be regions in the edges of the page to hold static content, and let them be for page numbers and running heads, and it was so.

And XSL made the two page sides, the recto for the right hand side and the verso for the left.

And XSL set them in the page masters to apply to all pages. And the recto and the verso were the third formatting.

And XSL said, let the blocks bring forth abundantly inline objects and properties that apply to them.

And XSL created fo:character and every inline FO after their kind, and every property after its kind, and it was good.

And the inline FOs and properties were the fourth formatting.

And XSL said, let users make graphics, and tables, and columns, and side floats and other areas. And the graphics and tables and columns and side floats were the fifth formatting.

Then XSL did errata until XSL 1.1, which added change bars, table markers, indexing FOs and much that was good.

Future development is happening on the Trac and Subversion for the xslide SourceForge project.  See https://sourceforge.net/apps/trac/xslide/wiki/WikiStart.

The net result is (a) I will be paying a lot more attention to doing my own website backups in future; (b) I’m busy scraping pages from the WayBack Machine and Google’s cache to remake the web sites; (c) the graphics don’t feature in the caches, so they’ll take longer to get back; and (d) this blog’s styles disappeared along with everything else and is now using the current default. You probably won’t miss the blog styles all that much, but losing them left WordPress in a state where it was both configured to serve RSS and not configured to have the RSS link on the pages, with the result that it threw an error on each request and didn’t serve anything. Finding and fixing that just added to the effort.

So while the websites are mostly back, it will be a while before they’re pristine again. The http://www.mentea.net/ website design is due to be revamped real soon now, anyway, but I still need the old content in order to transfer it to the new layout.