[tei-council] pdf version of guidelines, fonts

[Syd Bauman]

> you need a Unicode-aware OS / email client......

I use Emacs. But IIRC, e-mail gateways are still 7-bit operations.


> 20154
> 8266
> 216

Thanks.


> if you have suggestions beyond Julia's, best to get them in now if
> you can.

OK. It would be a lot easier on those looking for formatting problems
if we waited to look at the results post-implementation of Julia &
Chris's suggestions, rather than looking at the page and trying to
imagine what the improvements will look like. But if there isn't
time, so be it.


> I am not entirely sure you are right. The relevant bit is a <vaList
> type="semi"> applying to @unit in att.measurement. Since it's only
> "semi", it is purely advisory, not normative.

Of course not, my apologies! I mis-read your e-mail and was looking
at 'data.numeric.xml' not 'att.measurement.xml'. So ignore pretty
much everything I said. 

Actually, don't ignore it, carefully consider it with respect to
data.numeric: I think deleting the range sentence is a very bad idea,
for the reasons stated. Using <num> or <formula> or, if those are too
difficult <hi> with an apologetic explanatory comment seems like the
way to go for data.numeric. If necessary we could re-word, as I said.


On to what you were talking about, att.measurement.


> Anyone who wants to know what a "kibibyte" is will go look it up.

Perhaps technically true, but I claim that many, if not most, people
using these Guidelines come from the humanities, not computer
science, and would not know that they want to know what a kibibyte
is. I bet several people on Council didn't know the difference
between a kibibyte (KiB) and a kilobyte (KB), either. 


> Describing it as "1024 bytes" doesn't tell me anything, since we
> don't define "byte" anywhere!

We don't define "meter" either, nor should we.


> The text says Wherever appropriate, a recognised SI unit name
> should be used (see further <ptr
> target="http://www.bipm.org/en/si/"/> which is fine. Personally,
> I'd leave it as is and forget the whole <valList>. 

I feel the same as when we went 'round this before. When user is
typing along in oXygen and enters a unit= attribute, a lovely list of
possible values pops up. This permits user to choose "mL" for
milliliter, thus reducing the odds that one project uses "mL",
another "ml", a third "millilitre", a fourth "milliliter", and yet a
fifth "cc" for the same thing. Why is this bad? (Note that if user
wants a value that is not on the list, she can just type it in, as it
is type=semi.)

Furthermore, in the Guidelines, there is a nice summary list of
symbols that would require digging around in the cited sources to
find. (Most Historians are not going to know whether to look in the
"base units" section or the "derived" section, etc.) Last, we provide
a mechanism for the glosses and descriptions to be in a language
other than English.


> it is unfortunate that <hi> is not allowed inside <note>, so we
> cannot do superscripts that hacky way.

Which characters were giving you problems? Were they inside <desc>
(in which case probably <formula> or <num> would do, but if necessary
we could probably write the values out longhand) or the value of
ident= (in which case we've no recourse)?