On this Page Filed elsewhere

Handwritten Symbols

Source: email
Date: 2 Feb 2004
Filename: Wc717
Vid: 56700
Keywords: symbol, handwritten

Query This text is William Cartwright's book on "Semography", which contains 480 of his own shorthand symbols, which the vendors have captured as hash. I have for the moment changed these to GAP SYMBOLS, but they must, I think, be handwritten, so I'm not sure that they should be captured at all. However, the book is pretty pointless without them. Are the symbol gaps ok, do you think?

Answer I think the symbol gaps are ok. If there are any extended passages in shorthand, you might even want to think about <GAP DESC="foreign">-- since it is, in fact, a passage in a non-Latin alphabet.

I'm not sure that it matters whether the symbols are written in by hand, or printed as type, or even printed as little cuts, for that matter. What matters is that the book was intended to appear with that material in it. Our ban on handwritten material is really just a shortcut to banning material that is not really part of the book as it was intended to appear. Handwritten material that was part of the plan from the beginning, and was not printed simply because no type was available, should be included.

Back to Top

Jupiter v. Recipe

Source: email
Date: 29 Apr 2003
Filename: Wm2381
Vid: 30814
Page ref: 53
Keywords: symbol

Query I'm confused by the use of the symbol for Jupiter in this book. Could it be being used to mean recipe? It doesn't seem to mean tin.

jupiter being used to signify recipe

Answer (By Jove,) I think you've got it. It looks to me as though the printer, lacking the usual "Rx" symbol for "Recipe", instead used the nearest thing available, which is probably really (as you say) the "Jupiter" symbol but has the virtue of looking rather like a 2-shaped "r" with a stroke across it -- the "-rum" symbol -- and therefore at least reminiscent of the "Rx" symbol (i.e. "R" with a stroke across it).

Should I just capture with the entity reference for Jupiter?

We've tried to treat characters as much as we can as semantic, rather than purely formal, units. And "Jupiter" makes no sense. Neither does "abrum" for that matter. I suggest we simply use &Rx; despite appearances. The alternatives would be (1) a new entity--to be avoided if possible for a nonce use; (2) leaving it as <GAP>, which is not helpful; and (3) <ABBR>r</ABBR>, which is forced and not really any truer than &Rx; would be. So I'd go with &Rx;, and assume that what we see is some kind of allograph of &Rx;.

Back to Top

Date symbols

Source: email
Date: 28 May 2002
Vid: 113895
Page ref: 40,55
Keywords: symbol

The date that appears at the *end* of several of the treatises is confusing: it appears in an edition note like this: "This Treatise was revised, @ 12 m. 1648."

First confusing date symbol

The thing that I have indicated by "@" looks like the sign for "sun", and the thing that I have indicated by "m." is probably rather a symbol of some kind. Unless you know what, if anyhing, it is, I guess I'd leave it as "m". It doesn't look like a Scorpio. And the fact that it contrasts with Virgo on pages where they are used together suggests that it is not Virgo either (see, e.g., img 55).

second confusing date symbol

Back to Top

Stand-alone symbols

Source: email
Date: 8 Nov 2002
Filename: Wh2513 and Wn1048
Keywords: symbol


These two questions are both about symbols standing alone. The first is about musical notes and other musical signs occurring in ordinary continuous text, *not* as part of a piece of music. The second is about Greek letters used as mathematical signs, *not* as part of a piece of Greek.

The answer in both cases is that these should not be captured with GAP tags (either GAP DESC="music" or GAP DESC="foreign") as if they were passages of music or words in Greek. Instead they should be treated as individual symbols. That means that if they are recognized, and are part of either our own set of character entities or the standard ISO character sets, they should be recorded using the appropriate character entity. If unrecognized, or if neither we nor the ISO have supplied a character entity to use, capture such a symbol simply as "#".

Here's the rule:

"Symbols ... should be recorded ... with the hash character (#) if the symbol is clear enough but is not listed here or in the ISO sets."

The only exception to this occurs when you find a symbol occurring repeatedly in a book. In that case, we appreciate being asked about it, so that we can if possible supply an entity for it, rather than having to search through hundreds of examples of "#" and replace them later.

Back to Top

X as denarius

Source: email
Date: 21 Sep 2004
Vid: 65445
Page ref: 26, 28
Keywords: symbol

Query On this page there is what looks like a X and also an X with a horizontal line through it, both symbolising a denarius.

X symbolising denarius

The author specifically berates people for getting it mixed up with the roman numeral X or with *. How do you think we should capture it?

And on ref 28 there are two symbols that look like how numbers are shown on dice, only with dashes rather than dots. configurations of dashes

Answer We'll probably never see these things again, so let's not spend *too* much time thinking about them (I'm talking to myself here). How about this:

Of these, &Xbar; and &fivedash; are new additions.

Back to Top

Infinity symbol

Source: notes file
Date: 3 Dec or 12 Mar 2003
File name: Wb6185
Keywords: Symbol

On PB REFs="16," "56," "57," "82," "118," "140" Ns=""5," "85," "86," "137," "209," "253" replaced # with ∞ entity. (Symbol seems to represent 1000 in these examples.)

PFS: a use of the infinity sign we have seen before, in Randle Holme's Academy of Armoury: see example near the bottom of the page at

Back to Top

Squares and Quadrines

Source: notes file
Date: 19 Apr 2004
File name: Wb5040
Keywords: symbol

□ was used to represent a hollow square (ref 83 and 106). I changed this to &quadrine; but I wasn't sure what it was being used to represent.

PFS: at one point the square occurs along with sextile and trine and is best captured (I think) as &quadrine;; but on these other two pages (imgs 83 and 106), it seems to mean something like 'square' in the measurement sense ('2 square inches') (?). In that, case, maybe Apex's □ (from the ISOPub set) is the better choice, in that it does not specify the meaning of the symbol, but simply records its shape, = U+25A1.

Back to Top

Use of generic and specific cross entity references

Source: notes file
Date: 24 Nov 2003
File name: Ws2541a
Keywords: symbol, cross

On ref 59, the book describes a mark in the form of a "+" -- using a symbol that looks like a 'long' or 'latin' cross. This was captured as illegible, but is not--it's just an unrecognized symbol. Since the book seems to make a point of its exact form, and since there is a unicode character for this form of cross, I've decided not to use our generic ✗ entity but to add a &latcross; entity (= unicode #271D). We should continue to use the generic ✗ entity in contexts where some specific shape of cross is not at issue.

Back to Top

Rotated index fingers

Source: notes file
Date: 21 Jun 2004
File name: Wa4136.take2
Keywords: symbol

There is a version of &rindx; used three times in this text where the little finger is pointing rather than the index. I can't find this in our docs. It looks like it is being used as a subsidiary marker to the &rindx; in this case. PDCC had captured them as &lindx; and I've changed them to the unimaginative &rlittlefinger; but I suppose you may want to change them all to &rindx; and say we don't distinguish.

PFS: These are not little fingers: they are index fingers of left hands, turned upsidedown (note location of thumb). I think the most likely explanation is simply that the printer ran out of right hands pointing right (or didn't care to distinguish), and instead used a left hand, and rotated it 180 degrees so that it pointed right too. We could in theory distinguish as many as 8 characters (2 hands x 4 directions), or as few as 2 (2 hands) or 4 (4 directions). I suggest that we mark direction, not handedness, leaving us with 4 entities, all of which have Unicode equivalents:

&uindx; = index finger pointing up = U+261D
&lindx; = index finger pointing left = U+261C
&rindx; = index finger pointing right = U+261E
&dindx; = index finger pointing down = U+261F

So yes, until I'm persuaded that 'handedness' was ever significant in the use of manicules*, I'd capture these right-pointing left hands as &rindx;

* see for a discussion about names of these fingers.

Back to Top

Reversed section symbol

Source: notes file
Date: 14 Dec 2004
File name: S22172-3
Keywords: symbol

PFS: noticed an odd reversed 'section' sign, that the book *seems* to use (I only looked at a few examples) to reference the sections of its own chapters, while using the regular section sign elsewhere. In case it later proves useful, I've created a new entity for this (&rsect;), but it does not at all seem worth checking the §s in this book and replacing some of them! see and of course

Back to Top

Rx symbol

Source: notes file
Date: 14 Nov 2003
File name: Wb5931
Keywords: symbol

℞ was used as the symbol to indication refutation sections.

PFS: hard to tell if this is really (physically) the Rx (recipe) symbol, or the similar R/ (responsus) symbol which is used in antiphons paired with v/ (versus). In any case, the *meaning* is clearly not that of recipe. In such cases in the past I believe that we ignored the physical appearance (much as we do when q; doesn't mean "-que"), and instead captured as <ABBR>R</ABBR>. Since this symbol appears only in the italian section, I've changed them to
<ABBR EXPAN="responso">R</ABBR>
--and did the same to the "R." that seems to mean the same thing.

Back to Top


Source: notes file
Date: 2005-01-25
File name: apex/Wh2261
Keywords: Maths

I have gone through the <GAP DESC="math"> tags and converted several to fraction entity references, or captured the f ractions using / eg. 6/8. Is there any reason why there aren't more fraction entity references?

pfs: I think the only reason is that these ISO entity references originate in the 'vulgar fractions' used in modern printing, and ultimately in the printer's sorts available with different fonts, which include as pre-constructed characters only the most common fractions, out of an infinite number of possible ones. We should probably have avoided this half-way solution (of using charents where we had them and / where we didn't), and used one solution or the other exclusively, or perhaps some kind of markup solution different from either. I can think of four ways to change what we do:

(1) Use / exclusively and no frac entities.
(2) Make up new frac entities whenever we meet a new fraction.
(3) Create fraction elements, either
(a) empty elements like this

<FRAC NUM="6" DENOM="8">


(b) container elements like this:


(I rather like that last idea. We could even record the form of the divider mark as an attribute:

<FRAC DIVIDER="horizontal line"><NUM>6</NUM><DENOM>8</DENOM></FRAC>)

(4) Create an entity for the 'fraction slash' which would be a functionally defined character rather than a formally defined one. I.e., regardless of whether it looked like _ or / it would be captured as &fracslash; and define the numbers on either side as constituting a fraction. This is more or less the Unicode approach (fraction slash=U+2044), though even Unicode includes code points for the common vulgar fractions as well, out of its usual concern for backwards compatibility with legacy character sets.

Of these I would opt for this order of preference: (4)-(1)-(3b) and would reject (2) and (3a) as untenable. But is any of them worth doing? Note that my favorite (4) requires that keyers be able to distinguish between 'fraction slashes' and things that *look like* fraction slashes, e.g. date alternatives (1645/46) and punctuation virgules (he came / to the sea).

Back to Top


Source: email
Date: 11 Mar 2002
Keywords: note, symbol

Query. I am unsure how to capture a note-marker which looks like (::).

Answer. Before looking at the book, I was worried that we might have to deal with a "ratio" sign, but I think this is simply a pair of colons (::) used as a note marker. The printers were apt to use any odd bit of type as a note marker, including quotation marks (in which case the thing to do is use the entity reference for the appropriate quotation mark, e.g. N="&ldquot;"). In this case I would simply use a pair of colons <NOTE N="::">.

Back to Top