Thanks for the bug report -- I'll try to fix it soon.
As to the examples, there is nothing really fancy about them at all, so it
must be your system or browser. The source for the table you mention is:
<h3>2.2 <a name="History">History</a></h3>
<pre> <history supercedes="CP501"
derivedFrom="CP500">
<modified version="2" date="1999-09-25">
Added Euro.
</modified>
<modified version="1" date="1997-01-01">
Made out of whole cloth for illustration.
</modified>
</history></pre>
<p><b>history</b> (optional) provides information about the changes to the
file
and relations to other encodings. This is an optional element.</p>
<p><b>modified</b> provides information about the changes to the file,
coordinated with the version. The latest version should be first.</p>
which is pretty vanilla.
In the technical reports, the only point where we make use of Javascript is
in the dates -- the advantage of having it there is that it provides a
double-check to make sure that the date is updated when the technical report
is updated. It's very simple stuff, so it shouldn't cause a problem for any
of the browsers -- and if Javascript is not enabled, it reverts to a
plaintext date.
Mark
Doug Ewell wrote:
> I found a problem in Technical Report 19, "UTF-32." In the Definitions
> section, the three terms UTF-32BE, UTF-32LE, and UTF-32 are defined.
> Under UTF-32, there is the following bullet point:
>
> o In UTF-32BE, <004D 0061 D800 DC00> is serialized as <00 00 FE FF
> 00 00 00 4D 00 00 00 61 00 01 00 00>, or <00 00 00 4D 00 00 00 61
> 00 01 00 00>
>
> Of course, this should read "In UTF-32"... not "In "UTF-32BE". I'm sure
> this is just a typo, but since the whole point of this section is to
> define and contrast these three terms, UTC will surely want to correct
> the error.
>
> I'm having a bigger problem with some of the more recently updated TR's,
> especially those written or co-written by Mark Davis. Not all of the
> text in the examples prints correctly or at all. For example, in TR 22,
> "Character Mapping Tables," only two lines from Section 2.2, "History,"
> print out; the rest is blank. Most of the other examples (elements and
> validity checks, for instance) are completely blank. They show up just
> fine on the screen.
>
> FYI, I am using Windows 95 (revision B), Netscape Navigator 4.06, and
> printing to an HP LaserJet 4M Plus.
>
> Could this have anything to do with the Javascript embedded within the
> TR? I also noticed that the "Last Modified" date in the header of the
> TR is generated using a Javascript call, and this creates some odd
> situations -- the versions accessible under "This Version" and "Latest
> Version" are identical but the times are different by a few minutes,
> and of course the dates no longer follow the ISO 8601 format, but revert
> to U.S. mm/dd/yy format.
>
> Can the authors (or reformatters) of Unicode Technical Reports please
> keep the use of "fancy" HTML and Javascript in TR's to a minimum?
> Tables and simple stylesheets ought to be sufficient. This is not an
> elaborate sales or marketing presentation, after all -- it's a TECHNICAL
> REPORT. Please don't tell me to update or change my browser to get the
> "full experience" of the TR. I should be able to print the thing on
> dead trees and get all the information that way if I choose.
>
> Thanks,
>
> -Doug Ewell
> Fullerton, California
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:05 EDT