3.912 WP/NB; NotaBene's Ibid (180)
Willard McCarty (MCCARTY@vm.epas.utoronto.ca)
Mon, 8 Jan 90 20:28:08 EST
Humanist Discussion Group, Vol. 3, No. 912. Monday, 8 Jan 1990.
(1) Date: Sat, 6 Jan 90 13:49:28 EST (22 lines)
From: iTAMAR <B10@TAUNIVM>
Subject: Re: 3.902 ScriptureFonts: Greek & Hebrew for WP5 (144)
(2) Date: Mon, 08 Jan 90 18:36:15 CST (138 lines)
From: "Robin C. Cover" <ZRCC1001@SMUVM1>
Subject: NOTABENE (DRAGONFLY) IBID. PROGRAM
(1) --------------------------------------------------------------------
Date: Sat, 6 Jan 90 13:49:28 EST
From: iTAMAR <B10@TAUNIVM>
Subject: Re: 3.902 ScriptureFonts: Greek & Hebrew for WP5 (144)
Great news for WordPerfect users. But I was referring to
normal and easy writing, as part of NB, with all the normal
NB features, including the text-base, the data-base and all
utilities, not just typing and printing. And a-propos typing
and printing, I was referring to the fact that one and a single
keyboard easily handles 3-4 languages, like Roman, Greek, Slavic
and Hebrew, not different keyboards. And, of course, with one single
keystroke, or 2 keys stroke per character. All of the above not
as a smart add-on, some extra product, but an integral part
of NB.
Itamar Even-Zohar.
(I have forgotten to add: Sanskrit, full diacritics, Semitic
and other languages full scientific transliteration, and more.
And again: not in a typewriter manner, but as a full-fledged
wordprocessor with all the unrivalled features a *researcher*
needs.)
(2) --------------------------------------------------------------143---
Date: Mon, 08 Jan 90 18:36:15 CST
From: "Robin C. Cover" <ZRCC1001@SMUVM1>
Subject: NOTABENE (DRAGONFLY) IBID. PROGRAM
Dragonfly Software's IBID. (Bibliographic) Program and
Multilingual Text Processing
I have been using the new bibliographic package called
"IBID." from Dragonfly Software, which runs under the regular
version of NotaBene and under the SLS (Special Languages
Supplement) version. In reviewing IBID's case-conversion rules
(for academic styles that capitalize non-function-words in English
titles), I am struck once again with the necessity of having
"language" as a fundamental concept within academic software -- if
not within the operating system.
Since my comments might appear to reflect negatively on IBID.
(and they should not), let me offer some appropriate praise for
the IBID. bibliographic program. The fact that IBID. shares with
NotaBene a concept of "language" at *some* levels is just one way
it seems conceptually superior to other bibliographic programs I
have seen. Being able to use IBID. from within the current edit
window (accessed with one keystroke) and having the bibliographic
data fully integrated with the wordprocessor file is vastly
superior to using a standalone reference management program. One
inserts a bibliographic reference from the reference database into
the current document with a single keystroke after selecting it
from a list of matches (selected from author and/or title and/or
date). Thus, IBID. stands within the NotaBene tradition by
focusing on the user as an *academic* writer for whom economy of
time is important. Even in this first release, IBID. provides
several functions not even attempted by some mature standalone
products. ProCite, for example (in my version at least) attempts
no case conversion at all. The Papyrus program (which does have
an enviable regular-expression-like formatting language, allowing
for conditionals and field inter-dependencies), just punts on case
conversion. The Papyrus manual reads: "...Of course, non-English
titles follow entirely different rules [for capitalization in
titles]. German nouns are always capitalized, French titles
generally use sentence style, etc. You're on your own for these!"
BibTeX is also very powerful, but most interfaces I have seen are
primitive by comparison to IBID.; I think it allows one to bracket
characters which should never be forcibly downcased. But
personally, I do not believe the academic writer (using TeX/LaTeX)
should be pressed into the role of a typesetter anyway. Other
good reference management systems I know about are tailored to
sub-specialty fields (medicine, natural science, engineering) such
that they are not broadly applicable to humanities fields. The
trajectory for development of IBID. set in version 1 is very high,
and eventually (even immediately) I would expect to see the
product attract new users to NotaBene for the bibliographic
function alone.
Having said that, let me indicate that Dragonfly is tidying
up things a bit on the formatting of bibliographic records which
contain French, German and other languages in title fields. Does
anyone else share the suspicion (or studied conviction) that
bibliographic software poses one of the more difficult
computational challenges for academic software? The matter of
case conversion, simple version, is this: suppose we have a
Festschrift or journal with a French or German title, and an
essay/article in English; for several popular academic styles
which use uppercase "title style" in titles, we expect the
software to use an English stop list and perform case conversion
on the English article title but not to touch the German
Festschrift/journal title. The situation gets really messy when
you throw in programmatic control over "titles within titles," or
"quotations within quotations," or "quotations within titles,"
where different languages employ different rules for quoting and
citation using italic and/or left and right guillemet (the
'European quotation marks' consisting of double angle brackets =
ascii 174 and ascii 175). Someone might say that I am lazy --
can't I defer a few minor details like this to "hand re-
formatting" at print time? Maybe (read NO!) -- but details of
"foreign" language spelling, punctuation and citation are
sometimes the most frustrating to unravel anyway (for a given
style). I don't want the LEAST obvious information details missing
from the bibliographic database, or deferred until some later time
when I must deal with them again: I want them HANDLED by the
program so I don't have to think about them.
It appears that "bibliography" is another instance powerfully
vindicating the general observation that has been made by early
proponents of descriptive markup (e.g., members of the Brown
Harvard CHUG group), and more recently within the Text Encoding
Initiative. It is a fundamental linguistic observation about
text, and implies that using an "internationalized alphabet,"
however rich the character set, is no solution to academic
computing at all. We must insist in software development that
"text" is not just a stream of characters, but that "text" occurs
"in" some language. Being "in" a language determines many things:
a certain sort sequence, hyphenation rules, keyboarding
conventions, spell-checking dictionaries, thesaurus, stop lists
(for function words), fonts, scripts, directionality of writing,
handling of dates and other numeric & determinative characters, --
and (in bibliographies) use of case-conversion rules, punctuation
rules, (embedded) quotation markers, and so forth. Since SGML
allows "language" to be predicated as an attribute of text at any
level (character/graph, word, phrase, sentence, paragraph), this
standard for descriptive markup would be one obvious way to
implement multi-lingualism in bibliographic or other programs.
In this connection, I am happy to repeat here a word of praise
for Dragonfly Software: I think Dragonfly (with XyQuest) has
developed the best conceptual tools for dealing with "multi
lingualism" of any commercial DOS-based wordprocessing platform.
Though NotaBene currently lacks the concept of text structure
(document hierarchy, as supported in validating (SGML) structure
editors), the fundamental concepts for descriptive markup and
multi-lingualism are there. Apple's Script Manager (with some
improvements promised under System 7) tries to achieve some of
these effects at system level, but has not been successfully
promoted in Mac applications (NISUS being a noteworthy exception
in being Script Manager compatible). Academic writers generally
know what language they are dealing with in their research (or
they certainly should), so manually shifting to "new_language"
would be a small price to pay for getting intelligent control over
the language-related text features noted above. NotaBene has gone
a certain distance in exploiting its language-specific features,
but still uses a modeless switch between several Indo-European
languages so that the conception of an "internationalized"
character set still stands in the way. I do not imply that
computational solutions to these problems are easy: I am sure they
are incredibly hard, especially working within segmented memory
and primitive graphics of (native) MS-DOS. I suggest that getting
control over bibliographic data is another case proving the
general claim that we will not have adequate multi-lingual text
processing software until our programs know that "languages" are,
and that "text" is always "in" some language. Comments?
Robin Cover
zrcc1001@smuvm1.bitnet
attctc!utafll!robin.UUCP
attctc!cdword!cover.UUCP
3909 Swiss Avenue
Dallas, TX 75204
(214) 296-1783