| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 8.1 | We have no answer but similar questions | REORG::SEARLE | | Thu Sep 29 1988 09:08 | 18 |
| I don't have an answer, but we (will soon) face the same problem
with SQL documentation. We haven't figured out how to show extensions
in hardcopy books, let alone online. We thought an <EXTENSION>...
<ENDEXTENSION> tag that caused bracketed text to be screened would
be a nice way to do it, both in hardcopy and online.
To my knowledge, nothing of the sort exists or is planned. Can
you tell me a little bit about the ADA doctype and the set of tags
it uses to handle extensions? Do you think that it would be a workable
solution for you if those tags screened text instead of somehow
denoting second color?
Thanks!
Kirk Searle
SQL documentation
|
| 8.2 | ADA doctype and screened text | TLE::BBISHOP | | Thu Sep 29 1988 14:14 | 43 |
| >>Can you tell me a little bit about the ADA doctype and the set of tags
>>it uses to handle extensions?
The ADA doctype is layered on LPAHAND and contains mostly
tag definitions for special tags that format the Language
Reference Manual (LRM). We need special tags because we include
the ANSI standard as part of the LRM and need to match the
ANSI-standard format.
Way back when we had DSR and .MEM files as DOCUMENT output,
and when writers could easily write their own tag
definitions, etc. we added <EXTENSION> and <END_EXTENSION>
to the doctype so that I could mark the DEC additions to the
ANSI standard using different kinds of change bars in review
drafts (that way, we could have both change bars and extension
markers. Since we can't do different kinds of change bars or define tags
easily anymore, the tags are currently no-ops. But my files are coded
with them and it would be easy to reactivate them -- or
even make them global. It would also be easy for me to change
their spellings if need be (e.g. if other languages writers
wanted different spellings...<ENDEXTENSION> is definitely
better with respect to DOCUMENT V1.n than <END_EXTENSION>).
>>Do you think that it would be a workable solution for you if
>>those tags screened text instead of somehow denoting second color?
For the online bookreader, I think that screened text (change in
background shade of gray or color) would make more sense than
font changes. Some of my extensions are many pages long. I think
font changes take enough eye adjustment that they would interfere
with readability, etc. -- in addition to interfering with conventions
like bolded keywords, etc.
For hardcopy, I think second color is preferable to screened text.
I'm sure on-demand printing and the possibility of giving users
printable files on CDROM will have some affect on second color.
I hate to open that issue up here -- or give up second color while
it's still an option. I think second color is optimal for readers,
even though screened text may be optimal for documentation
production.
Barbara
|
| 8.3 | sounds like we agree | REORG::SEARLE | | Fri Sep 30 1988 10:13 | 13 |
| Thanks for the information!
Sounds like our projects have the same problem. It also sounds
like we agree that <EXTENSION> <ENDEXTENSION> tags to bracket text
the ONLINE doctype will screen is a reasonable solution.
How <EXTENSION> tags might work for hardcopy is off the subject of this
conference, but the standard hardcopy doctypes must make some
accommodation if such a tag works for the ONLINE doctype. Screening
makes sense to me for hardcopy because it's something we can produce
on any PostScript printer.
Kirk
|
| 8.4 | Screens and text don't mix well | OROGEN::BODGE | Andy Bodge | Fri Sep 30 1988 17:30 | 8 |
| I have a feeling that almost any screening you might do with online
text would savage the readability. Either that or the screen would be
so light that it would hardly show up. Try laying screens over text in
your favorite graphics editor -- the letter shapes fall apart quickly.
With a color system, no problem; but how to support monochrome?
Andy
|
| 8.5 | Still unclear: what plans if any to flag extensions in online books? | REORG::SEARLE | | Fri Oct 14 1988 09:22 | 13 |
| I don't yet understand the answer to the original question in .0:
VAX languages often present language extensions in a
second color in their hardcopy form. How is this going to
be handled for the bookreader? Is a set of tags going to
be added so that writers can code second-color extensions?
Can someone edify us on how manuals that flag extensions will be
accommodated by the ONLINE doctype and the bookreader? If there
are no plans to accommodate such manuals, I'm not sure it makes
sense to put those books online.
Kirk
|
| 8.6 | | VAXUUM::UTT | | Sat Oct 15 1988 16:59 | 20 |
| Kirk-
I agree that a set of <extension> tags are a good way to handle
this problem. They can be ignored for hardcopy, if that's
appropriate, but when we have 2-color printers they'll be
neededn then, too.
I also agree that screening the text is a bad idea -- the text
will probably become unreadable.
Font changes also present a problem -- we had a hard enough time
finding *one* readable text font! But it's not out of the question:
It might be possible to find a font that would work. Certainly as
the font selection and monitor resolution increase, this will become
a more viable option.
I don't have any answers for you. I think that it's something we'll
have to think about as we get experience with the bookreader.
Mary
|