Insert Zotero bibliographic data into a web-page by querying the Zotero API

  1. Figure out your Zotero user id. This is not the same as your Zotero username. Log into your Zotero account at www.zotero.org. Settings > Feeds/API. Copy the value given by “Your userID for use in API calls is … “.
  2. Construct an API query URL that gives you the bibliographic data you need in the format you want it. Documentation.
    • The URL starts with https://api.zotero.org/users/<userid>/.
    • For a single bibliographic item, add items/<itemkey>. To discover the item key, see the HowTo on this page.
    • Item example: https://api.zotero.org/users/160881/items/8HTNV32W/?v=3&format=bib&style=elsevier-harvard2. 160881 is my user id. 8HTNV32W is the item id in my Zotero database. v=3 selects the most recent API version number (i.e. ver. 3). format=bib requests that the data be formatted as an XHTML bibliography. style=elsevier-harvard2 sets the citation style. I like elsevier-harvard2 because 1/ it doesn’t pointlessly capitalize all title words, and 2/ it doesn’t italicize Chinese (or any) titles. See the result returned by this URL here.
    • Multiple item example: https://api.zotero.org/users/160881/items/?v=3&format=bib&style=elsevier-harvard2&itemKey=UDAKWEPD,6MPC3NRH,BETZ6T8M,2A44Q48D,9KDGT7VK,24MN76X3,IFITWC8S,5JKVSN7X,DSF26IDM,2W76QV2C,983IUQW6,5IBA73W6. Notice that the item keys are now a comma-separated list in the query string. Result is here.
    • Tag example: to return a bibliography of all items with a particular tag use tag= in the query string. E.g. https://api.zotero.org/users/160881/items/?v=3&format=bib&style=elsevier-harvard2&tag=OBI. Result is here. For more complocated tag queries, see the Documentation.
    • COinS: By changing the format=bib to format=coins, a set of <span>s containing COinS data is returned instead. https://api.zotero.org/users/160881/items/?v=3&format=coins&tag=OBI.
  3. Adding the bibliograpic data to a php/html webpage is simple:
    <?php 
    $url = 'https://api.zotero.org/users/160881/items/?v=3&format=coins&tag=OBI';
    $var = file_get_contents($url);
    echo $var;
    ?>
    

Get Zotero item key from Firefox

To read an item via the Zotero API, you need to have the item key. Oddly, the Zotero Firefox app does not provide simple access to the item keys. The following export translator will copy the item keys as a comma-separated list to the clipboard on Ctrl+Shift+c in the usual manner. The translator needs to be saved as a javascript file (.js file extension) in the Zotero translators directory. My translators directory was here ~/.mozilla/firefox/wgcm6dkk.default/zotero/translators/. The code is based on that found here: https://gist.github.com/nschneid/3134386, but pared down to give nothing apart from the list of item keys.

{
"translatorID":"0dbe4ec8-597c-4cc7-bfb5-c38321c5c689",
"translatorType":2,
"label":"Zotero Item Key",
"creator":"Adam Smith",
"target":"html",
"minVersion":"2.0",
"maxVersion":"",
"priority":200,
"inRepository":false,
"displayOptions":{"exportCharset":"UTF-8"},
"lastUpdated":"Fri 22 Aug 2014 12:24:20 PM EDT"
}

function doExport() {
   var item;
   if(item = Zotero.nextItem())
   {
      Zotero.write(item.key);
   }
   while(item = Zotero.nextItem())
   {
      Zotero.write(','+item.key);
   }
}

Fake Gelao 仡佬 writing system and manuscript.

I found a copy of this newly-published book in my mailbox last week.
Jing Tinghu 景亭湖. 2013. Pu Zu Jing: Han Yi Gelao Tianshu 濮祖經:漢譯仡佬天書. Beijing: Wenshi Chubanshe 文史出版社.

It purports to be a publication of a Gelao 仡佬 manuscript book – the Pu Zu Jing 濮祖經 or Classic of the Ancestors of the Pu People – with photographs of the original and a Chinese translation. The manuscript and the script do bear a passing resemblance to similar items produced by other groups in China’s linguistically diverse Southwest. Casual inspection reveals this one to be a transparent attempt at deception, interesting only because of the enthusiastic and credulous reception that it (and a previous discovery of the same kind) received from the Guangming Daily 光明日報. There is no sign that it is intended to be a joke. Here is an English version of the story.

A debunking of another “Gelao manuscript” – the Jiu Tian Da Pu Shi Lu 九天大濮史錄 – appears on this Chinese blog.

The following page appears as p. 165 of the 2013 publication:

fake_ms_crop
fake_ms_xiehewanbang

協和萬邦

This page, like all the others in the manuscript, is “translated” into Chinese in such a way that each “Gelao” graph corresponds to exactly one Chinese character, the same Chinese character each time (except for a few slips – see below). Word order is preserved. The end result makes sense in Chinese. This alone tells us that this is not a translation. It is also puzzling to find not a single mention of an actual Gelao word in the entire publication.

Furthermore, phrases straight out of Chinese literature emerge by this process. The 4-character phrase on the left, for instance, is translated as 協和萬邦. But notice that second Gelao character: elsewhere in the manuscript, it corresponds to 合 in the translation. And sure enough, the translators have rendered this 4-character phrase as 協合萬邦, not 協和萬邦. Clearly, the composers of the manuscript text were led astray by the homophony (in Mandarin!) of 和 and 合.

A related confusion occurs in the immediately previous 4-charater phrase: the phrase translated as 設立和王 is also written with the character elsewhere used for 合, not the one used for 和.

fake_ms_hewanggongyi

和王宮邑

Further on in the text on p. 165, we find the “normal” writing for 和 – the three prongs with circles on the top, as in the phrase 和王宮邑 (image on the right).

fake_ms_puwanggongdian

濮王宮殿

Evidently, the manuscript text is in Chinese not in Gelao. The Chinese translation isn’t a translation – it’s the text from which the manuscript was produced.

The “script” is clearly a set of symbols invented so as to be easy to remember by someone who knows the Chinese script. The character corresponding to 宮, for instance is clearly 宀 over 王. 邑 is immediately recognizable. 濮 (image on left) is just stripped down a little, and 殿 (left) is barely modified at all.

And the content?  I haven’t had the patience to go through it in detail, but it looks like Chinese dynastic history rehashed, with an extra role for the 僕人 as heroic ancestors of the Gelao. Plus some stuff about the smelting of silver, and cinnabar, and Laozi, and divination.

“Fake, fake, fake, fake.”

Custom fonts for unusual scripts.

The following is a simple method for building a font for an unusual script, using open source software. It could be used to design fonts for scripts that do not have a standard encoding (pre-Han Chinese scripts) or for distinctive varieties of scripts that do have a standard encoding (graph forms found in Chinese calligraphy). The example used here is the script of a 19th c. Nosu manuscript in the Penn Museum (96-17-2).

The method starts with a digital image of the text that provides the glyph exemplars. This needs to be converted to a black-and-white (i.e. 1-bit) image, in which the glyph exemplars are black and everything else white. The outlines of the black areas of the image can then be automatically traced, to provide the outlines for a digital font. These outlines can be imported into a font-editing program, to be modified as necessary, assigned to an encoding, and exported as a font file.

Tools

  1. Linux OS. The following walk-through was carried out on Ubuntu 12.04. All the tools below are simple to download and install under Ubuntu. It may be possible to adapt them to work on MS Windows or a Mac.
  2. GIMP, or some equivalent program for manipulating images.
  3. Glyphtracer, which automates the process of tracing glyph outlines (using potrace under the hood, which must be installed for Glyphtracer to work.)
  4. FontForge, a superb outline font editor.

Procedure

Since our goal here is illustrative, we will make a font consisting of just six glyphs, the six glyphs that appear in what I presume is a title in the top right-hand corner of this page. We will assign the glyphs to the same code points as lower case “a” through “f”. If text containing these six letters is displayed using the font, the glyphs will appear instead of these letters. (In general, this is not a good idea, but since it allows us to type our font using simple key-strokes, it is useful for illustrative purposes.)

1. Create B&W source image with GIMP.

96-17-2_6_croppedOpen up the image file in GIMP. We don’t need any of the Chinese text, so we can crop away everything except the top right-hand corner, giving something like the image on the right.

If we were doing this properly, we might want to compensate for the distortion due to the page not being flat when photographed. The GIMP’s “rotate”, “shear” and “scale” functions would probably be adequate for this. But we shan’t bother since the glyphs look good enough.

 

thresholdNow we need to convert this color image to a 1-bit black-and-white image. Use the GIMP’s “threshold” tool (tools > color tools > threshold on my machine) to separate the blackish ink of the glyphs from the various shades of brownish paper. The histogram in the threshold tool shows two peaks – one corresponds to the darker ink (smaller left peak) and the other to the lighter brown paper (larger right peak). By dragging the black slider to an appropriate position between the two peaks, we can make almost all of the paper white, and almost all of the ink black. The aim is to preserve the glyph outlines as accurately as possible. Any black mess that comes over from dark patches on the paper can be cleaned up in the next stage.

96-17-2_6Now we have a color image that only uses two colors (black and white). We need to convert it to a black and white (i.e. 1-bit) image. GIMP does this with Image > Mode > Indexed... > Use black and white (1-bit) palette. Now we can also use the usual GIMP tools to clean up any speckles or other mess that is interfering with the glyph outlines. This should give us something like the image on the left.

Save as a PNG file. We now have a image file that is acceptable as input to Glyphtracer.

 

2. Trace glyph outlines with Glyphtracer.

On running Glyphtracer, the first dialog screen allows you to choose the name for the font (anything will do – we’ll call ours nosu), and to select the file path for the input file (browse to that PNG file you saved in the previous step) and the output file (if you use the automatically generated path, it will end up in the same location as the input file).

glyphtracer1

Click Start.

The next screen should display the input image, with a bounding box around each glyph. The current glyph is indicated by the text in the button bar at the bottom: Glyph 1/26 a (a). If you click on any glyph in the image, its outline will be assigned to the code point for “a”. This also automatically increments the code point to “b”, reflected in the button bar text. Experiment with the three buttons at the lower left: these change the code point to which a clicked glyph will be assigned. As you assign each glyph in the image, it appears greyed out. (I haven’t found any way to unassign a code point.)

glyphtracer2

Code points available for assignment include Latin alphabet and its common extensions, numerals 1-10, common symbols, and Cyrillic. However, it is an easy task to modify the python code in the file gtlib.py to allow assignment to other ranges, such as CJK for Chinese, or the Private Use Areas.

When all glyphs have been assigned to code points, click Generate SFD file. Glyphtracer will automatically trace the outlines of the glyphs, representing them using Bézier curves. If your input file was nosu.png and you accepted the default options, the output file will be nosu.sfd and in the same directory. The SFD file format contains the numerical data representing the glyph outlines, and the mappings to code points. It is readable by the FontForge program which is the next tool we need to use.

3. Make font with FontForge.

Run FontForge. Open the SFD file saved in the previous step. The glyphs will appear in the appropriate positions.

fontforge1

Double click a glyph to edit its outline. (We won’t actually do any editing for the purposes of this walk-through, but the glyph edit window is shown below.)

fontforge2

Generate the font: File > Generate Fonts.... (I got the “missing points at extrema” and “non-integral coordinates” errors – but these are not lethal, so saved anyway. Alternatively, fix them in FontForge before saving.) The default is to save as a TrueType font, which will produce a file with a .ttf extension: nosu.ttf.

4. Install font, and try it out.

The font file that I produced is here: http://www.cangjie.info/blog/public_files/nosu.ttf

The font can be installed on any platform, including MS Windows, in the usual way. The screen shot below shows a document produced by typing “abcdef” etc. and then switching the font to nosu.ttf.

LibreOffice

Notes.

  • nosu.ttf is not a fixed-width font, as most East Asian fonts are expected to be. This could easily be changed using FontForge.
  • There are constraints on the arrangement of glyphs in the image to be read by Glyphtracer. I believe it is the case that individual glyphs must be separated by an orthogonal grid of whitespace. I.e. both horizontal and  vertical bands of white, running across the entire image, must separate rows and columns of black glyphs.
  • For a similar guide to the use of these tools, see James Wilkes Web Design. It also describes a technique for embedding fonts in web-pages, so content can be viewed without end users having to download and install the relevant fonts.
  • Youtube tutorial by the developer of Glyphtracer.

 

Ubuntu 12.04 dual boot with Windows 7 on HP EliteBook 8560w

This wasn’t straightforward. It is now working, but nowhere near “out of the box”.

  • The Windows installer (wubi.exe) didn’t work – it just crashed.
  • The installation from CD got stuck – froze on the “copying files” screen.
  • Followed the nomodeset workaround. This allowed the installation to complete.
  • Windows installation on the HP EliteBook had already used up 4 disk partitions. This does not leave a partition free to install Ubuntu. So I deleted the HP “recovery” partition and resized the main windows partition using “disk management” utility in Windows. Other users have recommended deleting the “HP Tools” partition instead. No idea what the consequences of these choices might be.
  • Installation successful. GRUB looks normal. Could boot to Windows, but could only boot to Ubuntu in safe (“recovery”) mode. Booting to Ubuntu in normal mode produced a screen of junk pixels and a freeze every time.
  • Installed recommended Nvidia drivers while in recovery mode, following automatic dialog prompt.
  • Everything seems to be fine.

 

See also: http://beradrian.wordpress.com/2012/06/10/install-ubuntu-12-on-8560w/

Horrible Libre Office bug

I was editing an .odt document using LO Writer, saving periodically. While I was away from the machine, the battery ran out. When I switched on again, the .odt file was still there, but contained 0 bytes of data. The entire contents of the document had been lost. I hadn’t set LO to make backups. The copy on Ubuntu One had already synced to the 0 bytes version. Yikes!

Purely by luck, I had booted to my MS Windows partition on the same machine not too long before the power outage. A previous version of the .odt file had synced to the Ubuntu One folder on the Windows partition and was still there to be retrieved. Phew! Of course, had I booted to the Windows partition after the power outage, with an internet connection, that would have synced to the 0 bytes version as well. Horrible.

This was LibreOffice 3.4.4 on Ubuntu 11.10.

The bug is well known, and has been fixed in a more recent version. But the more recent version is not in the Ubuntu repositories yet.
http://en.libreofficeforum.org/node/2052
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/817326

I am now going to do the following:

  1. get the new version of LO.
  2. review my backup procedures. LO can be set to make automatic backups: Tools > Options > Loan/Save (General) > Always create backup copy. This saves a backup file to ~/.libreoffice/3/user/backup/
  3. wonder what other unpleasant issues might be lurking in LO.

Not Arnold Schoenberg

Nine small ladies with no clothes on, balancing an enormous man with lots of clothes on and his concert grand on their heads… The entire time I was at UCLA I was under the misapprehension that this was supposed to be Arnold Schoenberg, for no better reason than that the UCLA version of the sculpture stands outside Schoenberg Hall. It never seemed very appropriate. Seeing a larger version of the same thing at the NE corner of Central Park, labeled “Duke Ellington”, I thought that this must be an act of self-plagiarism by a sculptor pressed to complete his commissions – knock off another Schoenberg, give him a moustache, call it “Duke Ellington”, and no one need ever know. Weird, but not nine-naked-dwarfettes-holding-a-piano-on-their-heads-weird. But no. I’m now forced to the conclusion that it is Duke Ellington at UCLA too.

Duke Ellington

Nine "muses" effortlessly support Duke Ellington and his piano

Comments on the work of the Old Hanzi Group towards an encoding of OBI script.

This document is a response to an invitation by Suzuki Toshiya and Deborah Anderson to comment on work by the Old Hanzi Group towards an encoding of early Chinese scripts. The comments are based on a review of documents archived on the IRG website:(http://appsrv.cse.cuhk.edu.hk/~irg/), and of the data deposited at ftp://ftp.iso10646hk.net/IRG/OldHanzi/.

Contents:

0. Introduction

1. General remarks

2. Other projects

3. Feasibility of OBI standardization and encoding

4. Why Old Hanzi shoud be encoded separately from CJK

5. Documentation

6. Intended user group, and purpose of encoding