| On this Page | Filed elsewhere |
|---|---|
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.
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.
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;.
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."
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).
Source: email
Date: 8 Nov 2002
Filename: Wh2513 and Wn1048
Keywords: symbol
TWO REPLIES ABOUT ODD SYMBOLS
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.
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.
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.
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.
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 http://www.lib.umich.edu/eebo/docs/dox/rnums.html
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.
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.
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
See http://www.lib.umich.edu/eebo/docs/dox/fingers.html
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 https://listserv.indiana.edu/cgi-bin/wa-iub.exe?A2=ind0406&L=sharp-l&T=0&F=&S=&P=10387 for a discussion about names of these fingers.
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 http://www.lib.umich.edu/tcp/docs/dox/charadd.html and of course http://www.lib.umich.edu/tcp/docs/dox/Eebochar.ent.txt
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.
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">
or
(b) container elements like this:
<FRAC><NUM>6</NUM><DENOM>8</DENOM></FRAC>.
(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).
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="::">.