To the extent that it allows MPs to frustrate the will of the people, I am not happy that the Supreme Court has decided that Parliament is not prorogued. On the other hand, I must congratulate the court on their well-argued decision and, in particular, Lady Hale for the excellent summary which she presented. This is British justice at its best, even if it makes Brexit even more difficult. It is clearly right that there must be some mechanism to hold the executive to account. Sadly there doesn’t seem to be any way to force MPs to make good their promises!
I'm getting so fed up with the BBC. It is running an endless stream of anti-Brexit propaganda at the moment. I think BBC reporters and editors really believe they are being balanced but they are too stupid to see that they are being used by the Project Fear rabble.
This morning they had a doctor campaigning against a no-deal Brexit because it threatened drug suppliers to the NHS. Nobody at the BBC questioned how this could be. Does anyone really believe that a no-deal Brexit could cause drug shortages in the UK? If so, I’d like them to explain why to me. Even Yellowhammer, based on a ‘reasonable worst case scenario’ assumed that there was ‘a low risk of significant sustained queues at ports outside Kent’, while the authorities in France have ridiculed the idea that there would be any delays at the Channel ports. In addition, Dover only accounts for 5% of the UK’s overall tonnage while other ports have plenty of spare capacity. Unfortunately, Project Fear has been so effective that there have already been shortages attributed to Brexit before we have left the EU, with or without a deal!
Here's a shot of my desktop running ConTeXt. Before I try processing an XML document in ConTeXt, I have to learn the rudiments of that typesetting language. Although I have used TeX, LaTeX and XeTeX in the past, I am finding ConTeXt quite a challenge – mind you, all the TeX-derived systems are. I expect to be able to define font size and body size or leading in a single statement. Instead, I have to specify the font size and then the linespace in terms of height, depth, top, bottom and line. I'm not very sure what some of these are.
The ConTeXt manual recommends using a line break instead of the command \par. The odd thing is that the line breaks within the paragraph change when one goes from a \par to a line break. I haven't yet learnt how to change the relative size of the footnotes. Talking of footnotes, I noticed that the footnote numbers are not lined up with the body text but intrude into the backspace. Very odd. There is certainly a lot to grapple with.
I've spent about a week trying to get ConTeXt to find the fonts in the Mac's /Library/Fonts directory (and search recursively as well). The ConTeXt support documents are rather fragmented, sometimes out of date and often contradictory. This is not to criticise those behind the project. I think that the number of people working (unpaid and in their own time) on ConTeXt is very small compared to those working on TeX and LaTeX and, at the same time, those are mature technologies with little changing and, therefore, not much demand for updated documentation. Anyway, I finally found a solution on Stack Exchange which did the trick.
The great secret to getting tech to work, even something as apparently simple as getting ConTeXt to recognise the path to the fonts, is persistence. That probably applies to getting anything to work. Whether I'll ever have the patience to see through a complete XML workflow remains to be seen! And then there is the question as to whether it will repay the effort.
For years I have typeset books for Tiger of the Stripe using Adobe's desktop publishing program (DTP), InDesign. Its great strength is the level and subtlety of typographical control it offers. Its greatest weaknesses are: (1) the poor support of all DTP systems when it comes to structured input and consequent lack of consistent output; and (2) Adobe's subscription model. It would be bad enough if one had to pay a hefty subscription for InDesign and that meant that the program was really stable and getting better all the time. However, the opposite seems to have happened; Adobe sits on its cash pile and does little to improve the program or even fix bugs. Its XML support is useless, probably because Adobe wants to sell you a subscription to FrameMaker. The unstructured nature of input means that InDesign files are full of garbage. If your final product is a printed book, you probably won't notice this, but what if you want to produce an ePub or Kindle edition? To be fair, InDesign makes quite a good stab at making ePub3s – at least fixed-layout ones. But reflowable ones require quite a lot of extra work in an XML editor to make them work properly, and, as I said, they're full of garbage, making the file sizes bigger than they need to be and making editing them that bit more difficult. The rebellion against the subscription model has seen a renewed Quark XPress and the emergence of Serif Publisher. However, neither of these offers the more structured approach i would like.
When I worked in scientific publishing, I used various flavours of TeX and LaTeX. LaTeX is a very good program for setting mathematics (and text) and offers automatic page makeup and automated tools for indexes, cross-references and bibliographies. However, LaTeX doesn't offer such a structured approach as XML, and controlling the typography and layout is quite hard.
Later I worked briefly for a company specialising in XML-based typesetting. Frankly, I wasn't very impressed with the software – it was hard to learn and seemed rather difficult to bend to one's will. Needless to say, it was also very expensive. Nonetheless, the idea of using XML as the input file is immensely appealing. Using XML forces you to define the structure of the document precisely, something I wish I had been able to do when typesetting Kennedy's New Latin Primer. It also separates the structure and content of the text from presentational elements (in fact, the XML text file itself doesn't deal with presentation), just as HTML and CSS are separated in web pages (at least, that is best practice).
The trouble with XML is that it is completely flexible. That doesn't sound like a problem but it is because it means that there are many different flavours of XML, and that means there is no standard way to transform it into a printed book, an ebook, a website, or whatever. Also, because the presentational elements of the document are separate from the XML text file, you have to have a way to transform the file. You can do this with eXtensible Stylesheet Language Transformations (XSLT – don't you hate the jargon?). These aren't too bad for producing HTML (which is, after all, a subset of XML). However, if you want to create a PDF file for a printed book, it gets really complicated. If you look at most of the PDF documents produced from XML this way, they're really not up to publishing standards.
For many years, I've been looking with interest at something called the Text Encoding Initiative (TEI). It has come up with a set of incredibly thorough guidelines for coding books and articles – so thorough, in fact that their guidelines in PDF form take up 1870 pages. Fortunately, there is also a 'Lite' version. Even so, this doesn't solve the problem of transforming your text into print.
I've looked at various solutions for transforming XML (probably TEI Lite) to print and none of them is perfect. However, the best seems to be ConTeXt, a derivative of TeX. This is freeware, it understands XML and it has very good typographical controls. Now, I've just got to learn the TEI coding and the typographical and layout commands for ConTeXt. Will I live long enough to produce a book this way?