Shareware Overload

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Overload / ShartewareOverload.cdr / wp / pc_wread.zip / COLORS.DOC next >

Wrap

Text File | 1990-02-06 | 45KB | 737 lines

COLORS COLORS COLORS: COLORS COLORS A brief essay COLORS on COLORS the use of color COLORS in PC-Write screen displays . . . COLORS COLORS COLORS COLORS from -- COLORS COLORS High Boskage House COLORS COLORS Software COLORS COLORS COLORS COLORS COLORS COLORS ABOUT SCREEN-DISPLAY OPTIONS IN PC-WRITE PC-Write is a very powerful tool. Every tool represents a series of trade- offs between power and simplicity, and PC-Write is no exception. The price that must be paid for its power is an innate complexity--a need for the user to be able to understand and profitably harness all those powers. While no powerful tool can be without complexity, the better ones are designed with that complexity systematized as well as can be, so as to make learning and using it no more difficult than it inherently must be. Every cue and clue that can ease the way for the user is important. Without a good set of such cues and clues, the most powerful of tools can be nearly valueless, for an inoperable tool is a useless tool, regardless of its capabilities; a tractor beats a mule, but not if you don't know how to drive. To move from the philosophically vague to the pragmatically specific, PC- Write offers its user a substantial variety of ways to transform simple text into printed characters on a page. Although some printers will be limited in their abilities to make use of all of PC-Write's capabilities, most newer ones can use most of the available options. In full, PC-Write offers users some 20 different ways to output printed text; 18 of these are specifically defined (although redefinable), and another two are user-definable. The full panoply of available effects, with their nominal definitions, is: ∙ Boldface (significantly darker than normal type) ∙ Compressed type (pitch varies with printer, but usually circa 17 cpi) ∙ Double-width type (halves pitch of prevailing type) ∙ Elite (12 cpi, draft quality) ∙ "Fast" (10 cpi, pica draft quality) ∙ "Higher" (superscripts, as in algebraic equations) ∙ Italics ∙ "Lower" (subscripts, as in chemical formulae) ∙ "Marine Blue" (for printers that can do color printing) ∙ Overstrike (everything overstruck, usually with /, for legal usages) ∙ Pica, (10 cpi, "near-letter quality") ∙ "Quality" (12 cpi, elite "near-letter quality") ∙ Red (for printers that can do color printing) ∙ Second-Strike (slightly darker than normal type) ∙ Underlining (all characters, including spaces, underlined) ∙ "Variable" (proportionally spaced type--each character a different width) ∙ "W" [Double-U] (double underlining) ∙ "X" [user #1] (available for user definition) ∙ Yellow (for printers that can do color printing) ∙ "Z" [user #2] (available for user definition) Considering that even the nominally specified effects can be redefined by the user, that is quite an assortment of styles. Specifying these effects within a document is extraordinarily simple. One need only press a two-key combination--the Alt key and an ordinary letter key--to toggle any one of these effects. And, as long as they are not incompatible, any number of them can be made to be "on" simultaneously via "nested" commands (Red and italics are compatible, but subscripting and superscripting simultaneously is manifestly impossible). The Quicksoft folks have even managed to make virtually all of the letter keys used reasonably mnemonic for their effects (as the previous Table showed). So far, so good. Now, however, comes the problem: keeping the user (that's you) clearly informed as to what text is "scheduled" to be printed in what form. If all your "enhancements" (anything in the Table above) are invisible (to you) in your text, editing is almost as impossible as it would be if the text itself were invisible. Manifestly, text affected by an enhancement must be displayed on the screen in a way different from "plain" or "normal" text. Moreover, the user would ideally like to know a lot more than just "enhanced/not-enhanced" about her or his text, especially when there are nearly two dozen possibilities to consider. In the best of worlds, monitors would show text exactly as it would appear on the printed page. A few dedicated word-processing machines have come close to this ideal, but even the jazziest new video hardware cannot do the trick for PCs. It is therefore necessary to use what amounts to a symbolic information system to give the user as much information as possible in a useful form--that is, without overwhelming him or her. Monochrome monitors offer a limited but useful set of symbols. In addition to "normal" text, they can show text as underlined, boldfaced, boldfaced and underlined, or "reversed" (dark on light). Clearly, it is essential to group all enhancements into no more than four categories, or "families," for monochrome displays. Color obviously offers far more possibilities. Although today's jazzy hardware has lots of potential, one is best advised to stick with the old CGA standard "palette" of colors. A video card that offers "256 colors" is offering tints and hues that differ from one another in subtle degrees of more interest to an artist than a word processor seeking visual cues. Judging just by the color tables, a CGA-standard color system offers 16 foreground colors on 8 backgrounds, 128 different possible combinations. But this is a simplistic calculation, and its results useless. First of all, any color on itself is invisible. Second, the 16 foreground colors are really 8 colors in two groups: "normal" and "intense." The differences can be seen, of course, but few users can readily detect them outside of a side-by-side, or "A-B" comparison mode. Blue on red versus bright-blue on red is definitely not a wise way to distinguish different enhancements. These obvious considerations alone reduce the useful palette to 56 combinations (8 times 8, minus the 8 same-on-same pairs). Beyond this is the fact that many nominally visible and distinguishable combinations are, in practice, nearly unreadable. This latter point is, to some extent, a judgement call, and in any event a matter for trial-and-error on-screen examination, not color theory. At all odds, the useful palette is smaller than 56 combinations. One might initially reason that with only "normal" and a maximum of 22 enhancements to portray, the palette must surely suffice, even if a few pairings are impractical. Well, yes and no. Yes, in that there are assuredly well over 23 viable color combinations available. No (or at least "Whoa, let's look at this"), in that merely making assignments that are unique but arbitrary is not a terribly good approach. It is here, in the matter of "patterns," that things get tricky. Most users, given time, would probably learn to live with any arbitrary assignment of color combinations to enhancements; sheer repetition would drill it in, given enough time. But the adjustment process would be slow, tedious, painful, and--rightly so--aggravating. What is needed is for the assignments to follow some reasonable system, so that each of the enhancement/color-combination pairings is informative not only in itself (that is, by pure memorization) but as part of a logical system of cues and clues--so that even if not immediately specifically remembered its general significance can be grasped. It is when we attempt to construct such logical groupings of color combination to signify specific enhancements that we find--even with a nearly two-to-one ratio of available color-pairs to enhancements--we are feeling the pinch. This verbose document could easily be trebled in length by an attempt to outline how High Boskage House Software came to the color sets it uses; instead, we will present our results and merely (?!?) offer some after- the-fact thoughts on that set. Incidentally, we tried to extend the same principles to the mono displays, and will comment on that set as well. Note that there are Appendices that discuss the mechanics of coding the "attributes" (color combinations or mono displays) into PC-Write, and the derivation of the arbitrary-looking "attribute" codes (for the curious). The High Boskage House set of PC-Write enhancement displays is this. (Each line is actually shown in YOUR current display of that mode.) ∙ Pica, draft∙∙∙∙∙∙∙∙∙∙∙∙∙∙white on blue∙∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ Pica, NLQ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙red on blue∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ Elite, draft∙∙∙∙∙∙∙∙∙∙∙∙∙white on green∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ Elite, NLQ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙red on green∙∙∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ Compressed∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙white on brown∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ Double-width∙∙∙∙∙∙∙∙∙∙∙∙∙white on red∙∙∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ Proportionally spaced∙∙∙∙white on cyan∙∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ Boldface∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙red on black∙∙∙∙∙∙∙∙∙∙∙∙∙∙bright ∙ Second-Strike∙∙∙∙∙∙∙∙∙∙∙∙yellow on black∙∙∙∙∙∙∙∙∙∙∙bright ∙ Superscripts∙∙∙∙∙∙∙∙∙∙∙∙∙green on black∙∙∙∙∙∙∙∙∙∙∙∙bright ∙ Subscripts∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙cyan on black∙∙∙∙∙∙∙∙∙∙∙∙∙bright ∙ Overstrike∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙blue on black∙∙∙∙∙∙∙∙∙∙∙∙∙bright ∙ Italics∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙green on grey∙∙∙∙∙∙∙∙∙∙∙∙∙underline ∙ Underlining∙∙∙∙∙∙∙∙∙∙∙∙∙∙cyan on grey∙∙∙∙∙∙∙∙∙∙∙∙∙∙underline ∙ Double underlining∙∙∙∙∙∙∙black on grey∙∙∙∙∙∙∙∙∙∙∙∙∙underline ∙ "Blue"∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙blue on grey∙∙∙∙∙∙∙∙∙∙∙∙∙∙bright underline ∙ "Red"∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙red on grey∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙bright underline ∙ "Yellow"∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙yellow on grey∙∙∙∙∙∙∙∙∙∙∙∙bright underline ∙ USER #1 (Alt-X)∙∙∙∙∙∙∙∙∙∙brown on black∙∙∙∙∙∙∙∙∙∙∙∙bright ∙ USER #2 (Alt-Z)∙∙∙∙∙∙∙∙∙∙magenta on grey∙∙∙∙∙∙∙∙∙∙∙reverse Before we dilate on these, we need to consider another aspect of screen display as yet unmentioned: "areas." We need more visual information than just the enhancements in effect on our text. There are nonprinting formatting devices that we use in PC- Write--things like Ruler Lines, Help screens, and Guide Lines (Help screens are not actually a "formatting device," but we do need to see them on screen too). Moreover, our text itself has characteristics associated with its screen display but not--not necessarily anyway--its printout: whether it runs beyond the current left or right screen edge, where the actual text (including spaces) ends and blank screen begins, and so on and so forth. For all of this (PC-Write defines 16 separate "areas" of screen display), we need distinctive visual cues and clues, and they need, urgently need, to fit into our overall pattern of display-characteristic assignments. It should be painfully clear that what is "obviously" a good system to one observer may be equally "obviously" terrible to another--there's no accounting for tastes, as the old lady who kissed the goat remarked. But any system, to even be considered, must have some overall logic, even granted that tradeoffs are impossible to avoid. Listed next are the 16 PC-Write screen "areas" and what we color them as part of the pattern that includes the attribute display listed earlier. ∙ screen border∙∙∙∙∙∙∙∙∙∙∙∙black on black∙∙∙∙∙∙∙∙∙∙∙∙normal ∙ "normal" text∙∙∙∙∙∙∙∙∙∙∙∙grey on black∙∙∙∙∙∙∙∙∙∙∙∙∙normal ∙ lines below text end∙∙∙∙∙grey on black∙∙∙∙∙∙∙∙∙∙∙∙∙normal ∙ area after text line∙∙∙∙∙white on black∙∙∙∙∙∙∙∙∙∙∙∙bright ∙ beyond-screen marker∙∙∙∙∙grey on red∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ marking/boxing text∙∙∙∙∙∙light magenta on black∙∙∙∙reverse ∙ marked/boxed text∙∙∙∙∙∙∙∙magenta on black∙∙∙∙∙∙∙∙∙∙bright ∙ rulers, outside margins∙∙light magenta on grey∙∙∙∙∙bright ∙ rulers, within margins∙∙∙magenta on grey∙∙∙∙∙∙∙∙∙∙∙reverse ∙ status line∙∙∙∙∙∙∙∙∙∙∙∙∙∙grey on magenta∙∙∙∙∙∙∙∙∙∙∙underline ∙ top-area prompts∙∙∙∙∙∙∙∙∙white on magenta∙∙∙∙∙∙∙∙∙∙bright underline ∙ menus∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙white on magenta∙∙∙∙∙∙∙∙∙∙bright ∙ selected menu item∙∙∙∙∙∙∙magenta on grey∙∙∙∙∙∙∙∙∙∙∙reverse ∙ help topic list∙∙∙∙∙∙∙∙∙∙white on red∙∙∙∙∙∙∙∙∙∙∙∙∙∙reverse ∙ selected help topic∙∙∙∙∙∙red on grey∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙bright ∙ help text∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙grey on blue∙∙∙∙∙∙∙∙∙∙∙∙∙∙normal If you're not sure to what some of these "area" descriptions refer, consult your PC-Write manual index under Screen, areas of. The first critical distinction we felt necessary was that between enhancements that change the pitch of the text and those that do not. There can, we feel, hardly be a more basic division: pitch changers affect the very fit of the words onto the page, and have to be carefully considered in formatting. As you will see, all pitch-effect enhancements are reverse-video in mono, and something-on-color in color modes. Non- pitch enhancements in color are all on either black or grey backgrounds. This set up our first major trade-off. Everyone with a color monitor likes color; using plain black as the "normal" background may seem a bit boring to users who like vivid displays. Several points affected our decision. One, the display is to convey information, not impress your friends and neighbors with your wonderful new video card's abilities. Two, black is a useful background to more foreground colors than most or all of the other possible backgrounds. Three, text on black may not produce as much candlepower as text on a jazzy colored background, but over the long haul is probably both more readable and easier on the eyes (which is why most serious text-only users still stick to mono monitors). Four, keeping the whole screen illuminated constantly will eventually wear out the screen phosphors more quickly than just illuminating letters (yes, monitor screens do eventually wear out, at least if you log 100 hours weekly on them, as we typically do). So, in our pattern, a colored background for text always signals that that text is going to (or, considering draft-versus-NLQ, is probably going to) affect the fit of that area on the page, and will require close scrutiny to ensure a properly formatted printout. There are two notable apparent exceptions to this rule: magenta backgrounds and the help-topic displays, with their red and blue backgrounds. Magenta in our system has a key role--it signals "special" information: as a background, it is reserved for non-document "top-line" text, while when appearing, light or normal, on grey (or white) it signals non- document lines (such as Rulers or Guide Lines) appearing in the area normally reserved for true text. And "Marking" and "Marked," both transient states of true text, are conveyed by variations of magenta on black. The reservation of magenta-on-grey for the Alt-Z code may seem like an exception to this rule, but we haven't yet discussed the "phantom lines": Guide Lines and Page-Break Lines. While Alt-Z could be used as a real printer code, fracturing the rule, we will see why this is unlikely. The use of red as a background for the Help topic-selection area, and of blue for Help text, is also not a true violation of the rule, because those areas simply take over the whole screen when they appear, and could not possibly be mistaken for document text or vice-versa. Just as a colored background distinctively cues a pitch-change, the lack of color in the background signifies fixed-pitch text. And while the use of plain grey-on-black for "normal" text is easy on the eyes, it also makes it possible for the use of foreground color to distinctively signal a fixed-pitch text enhancement. Since there are 13 such enhancements possible and only about half that number of colors, it is clearly impossible to signal all fixed-pitch enhancements by colors on black; by including colors on grey, we reach the requisite total without actually infringing the rule about colored backgrounds. Most of the fixed-pitch enhancements can be readily grouped into two "families," and these are especially clearly reflected in the mono-mode displays used: things that alter the appearance of the printed characters themselves, and things that emphasize those characters without actually altering them. (The prototypical examples of these families are boldfacing and underlining.) Italics, which might logically belong to the first group, are universally signified by underlining ordinary text--so in practice they naturally fall into the second group. The first group was signified with--we hope--good logic by changing the color of the affected characters, just as the enhancement changes their printed appearance; for the second group, the grey background signifies an "external" augmentation (like underlining in print) of their effect. The only open questions were the "color" commands (Blue, Red, Yellow) and the undefined (but user-definable) enhancements. Manifestly, an enhancement intimately associated with a color should have that color in its screen display; and since the "on-black" colors are all used for far more common enhancements, the color commands were included in the second group and display as their named colors on grey. The Alt-X "undefined" enhancement was included in the "on-black" family rather by Hobson's choice, because--as we will see--the Alt-Z "user" enhancement is not really a viable "user" option, and its "on-grey" status is essentially mandated by other concerns (but, as you can read in your PC-Write manual, Alt-X isn't really much of an "option" either). Within these three major groupings--pitch-changers, character modifiers, and character emphasizers--the assignment of specific colors to specific enhancements was made to some extent intuitively. The factor most often in play was the "feel" of the color versus the effect (red should be something dramatic or important). For instance, boldfacing cries out for red, given the black background, while double-wide is the "on-red" pitch modifier because it's the most "dangerous" one (it can easily run right off the printed page.) And the criterion for a given foreground color in "bright" versus "normal" intensity was thoroughly empirical--visibility. In the "area" displays, the key-cue color magenta is a bit restricting, but not as much so as it might seem. Most of these displays are in little or no danger of being mistaken one for another, or for text, so some duplication of color combinations is tolerable. As previously noted, for example, the Help facility completely takes over the whole screen, while a Ruler line is not likely to be mistaken for anything else at all. Using magenta for "marking" and "marked" text, while a minor compromise, was acceptable to us because it is denoting a "special" kind of material: a transitory, unusual state. And with the Marking/MARKED notices in the Status Line, we felt that "bright/normal" were workable distinctions. The Ruler Lines are virtually the only other place where we allowed the difference between "normal" and "bright" to signify. While we earlier remarked that such distinctions are not readily noticeable to a user, a Ruler Line is a clear exception: a true side-by-side, "A-B" situation. (We do actually also make the cursor white, not grey, when it's past the true end of a line, but that is a nicety, not a critical distinction.) Note that our "area" assignments in mono/single-color are mostly the PC- Write defaults (we took the Status line from bright to normal after noticing that it was literally burned into our amber--not green--screen). Last, but not least, our scheme needs to deal with the "phantom lines": Guide Lines and Page-Break Lines. Guide Lines always begin with an Alt-G character in column 1 of the line--this is a PC-Write absolute requirement (in versions 3.xx). In the "hide" screen mode of PC-Write--which is what PC-WREAD emulates--Guide Lines are totally invisible. But while PC-WREAD needn't concern itself with them, you and we, as overall PC-Write users do. The PC-Write default values for Guide-Line coloration are grey-on- black for all monitor types. We instead, working them into our pattern, have adopted magenta-on-grey; the non-black, non-color grey emphasizes their critical nature, while the magenta shows them as non-text items. Page-Break lines do display, even in "hide" mode. We have colored them magenta-on-grey in our scheme, for two reasons. First, there is no real chance of confusing them with a Ruler, a Guide Line, or any other special non-text line; second, this coordinates with coloring Alt-Z the same. A Page Break may be "Hard" or "Soft." Soft Breaks are marked by a Code-12 character, Hard Breaks by a Code-12 followed by a Code-15. But Code-15 is just the Alt-Z character! So, if we want Page-Break lines to be colored the same no matter whether Hard or Soft, Alt-Z has to be colored in a nontext manner--the same way as Alt-T (the Code-12, not the character- pair). This is why "User 2" (Alt-Z) some ways back appears to be--but really is not--an infraction of the "magenta-for-nontext-only" rule. Always keep clearly in mind the schizophrenic nature of Page-Break Lines: the code-number characteristics discussed above control the appearance of such lines in the "show" mode; in "hide" mode, their appearance is controlled by the "Area 10" attributes. The hide-mode display has a life of its own; the previous paragraph refers to the "show" mode display. That's a few notes on the main thrust of our reasoning in designing the specific set of display attributes we associate in our customized PC-Write with the various enhancements and areas. It is not exhaustive--we didn't go into the white-for-draft/red-for-NLQ mirroring in the Pica and Elite modes--but it covers the general outline of our thinking, and points out most of the complexities and trade-offs faced in creating such a set. If you are using just the default attributes of PC-Write--especially on a color display--we feel you are missing a lot of available help. This is not a criticism of Quicksoft; they built a reasonable set of "quiet" defaults, presumably because "quiet" (muted-tone) displays offend no one. But they included tremendous customization power in PC-Write, and it is our own fault if we do not take full advantage of that power. Notice how much more jazzy the main documentation file (what you saw with SEEDOC) is than this file; that's what you can accomplish by customization. If you like the idea of a spectrum of screen effects for the PC-Write spectrum of enhancements and information but don't like our specific choices, design your own. We like these, and built them into the PC-WREAD documentation reader so you could see them in action for yourself; but the actual PC-WREAD program uses--in the shareware demonstration version--only the original PC-Write default values. It's what you're reading this with. The full-license distribution version will read your PR.DEF and ED.DEF files, and display accordingly. But whether or not you ultimately register PC-WREAD, we recommend your customizing those .DEF files, either with our pattern or with one of your own designing. This discussion has been dual-purpose: to show you the underlying logic of our choices, and to thereby equip you with a better sense of the problems to be met and trade-offs to be made in evolving such a system should you undertake the task yourself. In the Appendices that follow, we will first show you how to implement PC- Write customization, then explain a bit about how the screen displays are coded inside your computer. Your PC-Write manual remains your primary information source--it is an outstanding example of what program documentation should be (but so rarely is)--but you may find the elaborated instructions here easier to use for this specific task. Also, if you are trying to follow all this out with your PC-Write manual in hand, literally or figuratively, you should be aware of a few critical typographical errors therein concerning these topics. These errors appear in the full PC-Write User's Guide manual, Version 3.0, dated September 1988, and are not picked up in the October 1988 Addenda. On page 335 of the manual, there is a Table of enhancements, showing the corresponding font letter and character code for the 20 normal PR.DEF font variations. The middle column shows incorrect code values. There is a correct, and more complete, Table on page 339. On page 354 of the manual, the monochrome default attribute for Area 10, "normal" Ruler-line text, is shown as 9 (underline); it is actually implemented as 15 (bright), which makes much more sense anyway. In conclusion, if we may be excused our self-interest, once again-- ╔═════════════════════════════════════════════════════╗ ║ DON'T FORGET TO REGISTER YOUR COPY OF PC-WREAD! ║ ╟─────────────────────────────────────────────────────╢ ║ It's the honorable thing to do, and it's cheap! ║ ╚═════════════════════════════════════════════════════╝ ╔═════════════════════════════════════╗ ║ APPENDIX 1: ║ ╟─────────────────────────────────────╢ ║ Implementing The Color Scheme ║ ╚═════════════════════════════════════╝ Let us assume, for the sake of discussion, that you have elected to implement the display formats discussed above exactly as shown there. (If you want to implement different changes, the same methods will apply, but the actual numbers to enter will be different; nevertheless, the information here should be very useful to you.) To implement the font-effect (Alt-plus-letter) characteristics, you need to edit your Printer Definition file, PR.DEF; to implement the "area" characteristics, you need to edit your Edit Control file, ED.DEF. In both cases, you edit these files with PC-Write, just like any file. ╔══════════════════════╗ ║ ┌──────────────────┐ ║ ║ │ ╔══════════════╗ │ ║ ║ │ ║ WARNING!!! ║ │ ║ ║ │ ╚══════════════╝ │ ║ ║ └──────────────────┘ ║ ╚══════════════════════╝ NEVER EDIT ANY CRITICAL FILE WITHOUT MAKING A BACKUP COPY FIRST!! If, like most PC-Write users, your primary control files are indeed named ED.DEF and PR.DEF, we suggest backup copies named EDDEF.OLD and PRDEF.OLD; but the exact names you use aren't as important as the fact that you have backups, clearly labelled and readily identified. Be sure to make such copies before modifying your files; that way, if you do make a mistake, you haven't done critical damage. Let's start with PR.DEF. While there may be many curious lines in the file, you will always find a block where each line begins with a # sign followed immediately by a letter of the alphabet. These are the font lines, and it is them that you need to edit. We will be inserting three new lines, but in most cases, the form of the change (and we will show you the exact specifics too) will be to take a line that starts this way: #B=02 ∙∙∙∙∙∙∙∙∙∙∙∙ and change it, by inserting three codes, to one that starts like this: #B:15.15.12=02 ∙∙∙∙∙∙∙∙∙∙∙∙ Please note that the actual PR.DEF lines are not in boldface! That's just a device we use in this document to highlight what we're talking about. Also please note that the string of dots is not literally what you'll find there; they just stand for some text not relevant to what we're doing now. When you inspect this area of your PR.DEF file, you will see that the fonts (the #B shown above is Boldface, the Alt-B font) are alphabetical but that six--A,G,J,K,N and T--are "missing." Don't worry about them; most we'll leave alone, while for two (G and T) we'll insert new lines. #B:15.15.12=02 ∙∙∙∙∙∙∙∙∙ #C:112.112.111=06 ∙∙∙∙∙∙∙∙ ╔════════════════════════════════════╗ #D:112.112.79=16 ∙∙∙∙∙∙∙∙ ║ This is the relevant portion of a ║ #E:112.112.47=03 ∙∙∙∙∙∙∙∙ ║ PR.DEF file customized to display ║ #F:112.112.31=28 ∙∙∙∙∙∙∙∙ ║ the exact color scheme described. ║ #G:112.112.125=11 ╚════════════════════════════════════╝ #H:15.15.10=24 ∙∙∙∙∙∙∙∙ #I:1.15.122=21 ∙∙∙∙∙∙∙∙ ┌──────────────────────────────────┐ #L:15.15.11=25 ∙∙∙∙∙∙∙∙ │ CRITICAL NOTE: If you do add a │ #M:9.15.113=07 ∙∙∙∙∙∙∙∙ │ new #T line, as was done here, │ #O:15.15.9=19 ∙∙∙∙∙∙∙∙ │ you MUST also add the numbered │ #P:112.112.18=05 ∙∙∙∙∙∙∙∙ │ line (276:708,015) shown, just │ #Q:112.112.44=22 ∙∙∙∙∙∙∙∙ │ AFTER the #-letter list. This │ #R:9.15.116=30 ∙∙∙∙∙∙∙∙ │ retains Alt-T as a Hard Break. │ #S:15.15.14=01 ∙∙∙∙∙∙∙∙ └──────────────────────────────────┘ #T:112.112.117=12 #U:1.15.123=23 ∙∙∙∙∙∙∙∙ Comments: #V:112.112.63=04 ∙∙∙∙∙∙∙∙∙ #W:1.15.112=18 ∙∙∙∙∙∙∙∙∙ 1. The #G, #T, and 276: lines are new. #X:15.15.6=13 #Y:9.15.126=31 ∙∙∙∙∙∙∙∙∙ 2. Do NOT add or change any text after #Z:112.112.117=15 the =xx entry of each line. 276:708,015 If you insert a definition line for #T in PR.DEF, you MUST add a third line in PR.DEF if you want Alt-T to work properly! That line is: 276=708,015 (Enter it flush left right AFTER the # lines. Again: all that is involved with each of the 20 changed lines is to insert between the letter and the = sign a set of three numbers preceded by a : and separated by periods. From #B= we go to #B:15.15.12= and that's all you have to do; leave the rest of each line unchanged. And the three new PR.DEF lines need only be inserted exactly as shown above. Just so you know what you're doing and why (our old habit): ∙ The colon : tells PC-Write that the character's effect on affected text has been customized and that the custom values follow. ∙ The three numbers are the "attributes" (discussed more in Appendix 2 of this file) that specify the associated screen-enhancement values for, respectively: monochrome monitors, so-called "single-color" monitors, and color monitors. ∙ The two periods . just tell PC-Write where one attribute ends and another begins. In the ED.DEF file, we will not be changing any existing lines. Instead, we will simply insert some brand-new lines, which will redefine the appearance of the "areas" discussed above, in the ways discussed above. You can put these lines anywhere in ED.DEF, but try to place them at a logical-looking point; it's nice to be tidy. These are the 14 needed new ED.DEF lines: &1:7.7.7 &2:15.15.15 &3:112.112.71 NOTE: &5:15.15.5 &6:112.112.13 Enter all these lines FLUSH LEFT! &7:7.7.23 &8:1.15.87 DO NOT indent any of them. &9:9.15.95 &10:15.15.117 &11:112.112.125 &12:112.112.79 &13:15.15.124 &14:15.15.95 &15:112.112.125 As always, let's tell you what you're doing here. The ampersand & tells PC-Write that this line is a redefinition command. The number right after that defines the specific screen "area" to be dealt with by this line (see your PC-Write manual for the specific meanings that correspond to each number). The colon : marks the start of the attribute list to be used. The periods . separate the attribute codes. And, as in the PR.DEF codings, the three numbers are, in turn, the attributes to be used with monochrome monitors, "single-color" monitors, and color monitors. We have left areas 0 and 4 in entirely their default states by simply not redefining them. The codes we use in our redefinitions for single-color monitors are all the same as the default codes. The mono codes are all the same as the default codes except for the normal Status Line display, which is now ordinary underline rather than bright underline; that line, in a nearly unchanging form, is always on the screen when you work in PC- Write, and if you do as much of that as we do (unlikely, we grant), you really can burn it into the screen, even on a modern amber monitor. Remember that--as mentioned before--the "Area 10" (Ruler Lines outside the margins) attribute also controls "hide" mode Page-Break-Line display. ╔═════════════════════════════════════╗ ║ APPENDIX 2: ║ ╟─────────────────────────────────────╢ ║ Display-Character "Attributes" ║ ╚═════════════════════════════════════╝ Note 1: This discussion pertains only to text-mode displays. The display of text in any graphics mode is a decidedly more complex process. Note 2: You DO NOT need to know this stuff! It's here for the curious. Your display monitor screen shows text at up to 80 characters a line, and up to 25 lines a screen. The total number of text-character positions on your screen is thus simply 80 x 25, or 2000. Glossing over a lot of complications, exceptions, and differences between various specific pieces of video hardware, we may say that somewhere in your computer there is a bank of memory with 2000 bytes each of which corresponds to a specific character spot on your monitor screen. The byte in a given memory cell is the character that will be displayed at the corresponding screen location. All possible bytes--all the values from 0 to 255--will display on the screen if you can get them into video memory (actually two, the zero byte and the "space" byte, will show as blanks on the screen, but that's their "display"). Bytes with codes under 32 cannot always be put into video memory--it depends on the specific software that you ask to do the putting. BASIC, for example, treats 11 of those 32 low-order codes as instructions to do something (such as beep the speaker) rather than as characters to display. But your video hardware will show them all if you can get them into that video memory. If the terms "value" and "code" as used here are not clear to you, refer to the Appendix in the main PC-WREAD documentation file via SEEDOC. But, as you should be well aware by now, what to display is only half of the matter; how to display that "what" is the other half. Sure enough, video memory has another 2000 memory bytes, each uniquely associated with one of the first 2000, and thus also uniquely associated with a specific character position on your screen. It is in this second bank of memory that we store the "attribute"--or display instructions--for each character position of the screen. A byte comprises eight bits. Each of the bits in an attribute byte controls some specific aspect of the display your screen will show at the associated location. Here is how an attribute byte breaks down: 128 64 32 16 ║ 8 4 2 1 ╔═══════╤═══════╤═══════╤═══════╬═══════╤═══════╤═══════╤═══════╗ ║ blink │ Red │ Green │ Blue ║ bright│ Red │ Green │ Blue ║ ╚═══════╧═══════╧═══════╧═══════╬═══════╧═══════╧═══════╧═══════╝ 8 4 2 1 ║ 8 4 2 1 Background control bits ║ Foreground control bits Let's demystify this picture a bit. First, the numbers: every bit in a byte is a digit in a binary--base 2--number (the word bit is derived from "binary digit"), and is thus a power of 2 (just like every place in a familiar decimal--base 10--number is a power of ten). The numbers across the top are the values of every place in the byte expressed in "normal" decimal representation. As you see, the byte divides into two areas of control; since in some situations (such as the BASIC programming language's COLOR statement) we think of these separately, we have also shown bit coding for each half as if it were a distinct entity (which it is not; we just sometimes think of it that way). Next, the color names: color monitors, like color TV sets, use three separate color-presentation tools (we'll skip the electronics involved), one each in the three so-called "primary colors" of Red, Green, and Blue, to produce the full spectrum of visible colors. On a TV, the relative intensities of each primary can be varied in almost infinitesimal increments; on a PC monitor, at least one compatible with the old CGA cards, the primary colors have only two or three possible values: on, off, and--sometimes--high-intensity on. There are three bits in the "background" area and another three in the "foreground" area which control the primary-color display for the byte's screen position; if a given bit is 1, that primary in that area is on, and if it's 0, that primary in that area is off--very simple. In the foreground area, there is a fourth bit called the "intensity bit, or the "brightness" bit. If it is on, each foreground primary is on--if at all--at a "bright" level; otherwise each is on--if at all--at a "moderate" level of intensity. Finally, there is the so-called "blink bit"; this, just as you think, enables blinking at the associated screen spot. (But, although this bit is in the "background" area of the byte, only the foreground blinks!) On many monitors, appropriate software can change the function of the "blink bit" to that of an intensity bit for the background; but, since not every monitor can do this, our display scheme made no attempt to utilize this feature. By using the three primary colors one at a time, we rather obviously get only three different colors: red, green, and blue. But we can mix the primaries to get secondary colors. With both Green and Blue turned on, we get the curious result quaintly referred to as "Cyan" in computerspeak; by mixing Red and Green, we get a sort of Brown; Red and Blue give us a passable Magenta; and with all three primaries on, we get--as Isaac Newton discovered long ago--white (actually, a sort of grey). These seven combinations, plus Black (the absence of any color) are the full set of background colors normally available. In the foreground, we have these same eight, plus a set of intensified shades of much the same description (the intensified Brown becomes Yellow, but the others don't change that much in character). Curiously, the brighter "intensified" versions of these colors all look to the human eye as paler and more washed-out than their plain versions. By now, you have probably deduced from whence comes the unique "attribute" number associated with a specific color pattern in PC-Write's PR.DEF and ED.DEF customization entries: it is just the numeric value of the screen- attribute control byte that produces the desired effect. The easiest way to see this is with an example. Assume that we want to have a given character display as Blue on a Brown background. The bits we need to turn on are Blue in the foreground area and Red and Green in the background area. The bit values of these three bits are, respectively, 1, 64, and 32 (check the byte shown earlier). When we add those up, we get 97, which is the correct attribute number to specify to PC-Write "Blue on a Brown background." Monochrome specifications work a little differently, because mono has so few (five) possible states. The "blink" and "intensity" bits control the same features--blinking and intensified-foreground. What would be a Blue foreground in color--just the "blue" bit on--enables underlining; if any other foreground bits are also on, underlining is disabled and the display is "normal" text (or "bright" if the intensity bit is on). The background is always black unless all three background bits are on and no foreground bits are on; this produces black on white (or whatever color your monochrome monitor displays, probably amber), or "reverse video." You cannot underline in reverse, since all foreground bits must be off. As we said, you do not need to know all this stuff. You can get all the attribute codes from the table in the PC-Write manual. It's just our old instinct to provide knowledge along with the step-by-steps. ─────────────────────THAT'S ALL, FOLKS!───────────────────────────