Re: Bug in TR 19, and fancy HTML in TR's
Am 2000-07-11 um 00:05 h UCT hat Erik van der Poel geschrieben: Or the document.write can be removed from TR22, but I don't know whether that workaround is acceptable to the authors. Or, the construct prelt;?xml version=quot;1.0quot; ...?gt; lt;!DOCTYPE characterMapping SYSTEMÂ quot;http://...quot;gt;/pre could be replaced with blockquotecodelt;?xmlnbsp;version=quot;1.0quot; ...?gt; brlt;!DOCTYPE characterMapping brnbsp;nbsp;SYSTEMnbsp;quot;http://...quot;gt;/code/blockquote (beware: I had to abbreviate the exapmle, so you cannot just paste it into the HTML source). The recipe is: - between pre and /pre, - replace line-breaks with br, - replace spaces with nbsp; - then - replace pre with blockquotecode - replace /pre with /code/blockquote Best wishes, Otto Stolz
Re: Bug in TR 19, and fancy HTML in TR's
Thanks to Netscapers Katsuhiko Momoi and Erik van der Poel for helping untangle this for me. It turns out that there is a bug in Navigator 4.06 that operates as Erik described. So the problem is Netscape's, but OTOH it *is* related to the use of Javascript in TR's which I originally questioned. Katsuhiko's workaround was the ticket: clearing the disk cache *immediately* before printing allows everything to be printed successfully. BTW, I upgraded to Navigator 4.7 yesterday and the bug is still there. (Not surprising, since it had not been reported before.) So obviously this is no longer a question of upgrading to the newest version. -Doug Ewell Fullerton, California
Re: Bug in TR 19, and fancy HTML in TR's
FYI, I am using Windows 95 (revision B), Netscape Navigator 4.06, and printing to an HP LaserJet 4M Plus. snip 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. Well, some people might actually prefer you upgrade your browser to something that supports Unicode a bit more effectively, at the very least. :-) NN 4.0x has tons of problems with bidi and other complex scripts, with Asian characters, and more. Its not entirely unreasonable for the online resources of the Unicode Consortium to make use of technologies that support Unicode and not be obliged to test everything on older browsers that do not. I think its likely that they did not even know that such an issue would exist, since they have upgraded to browsers and technologies that support the very standard they are writing for. As a side note, I do not test code on my Osborne 1 or my Epson PX-8, either. :-) Just my 2 cents. michka
Re: Bug in TR 19, and fancy HTML in TR's
Doug's point is well taken. It's been the editorial committee's policy to make sure that TR's can be accessed from a wide variety of browsers. If limiting the range of formatting that is to be used in TR's makes a real difference to people in the implementers community, then that is something the Ed. Committee ought to look at in my opinion -- at least as long as those features aren't strictly required to express the contents of the TR. Some people working on real products may be prevented from updating their machines during some stages of their project. I know I kept a real stable setup during the two years it took to publish Unicode 3.0 and was forced to use IE 3.21 for the longest time. A./ At 09:36 AM 7/8/00 -0800, Michael \(michka\) Kaplan wrote: If you were a person who regular had to deal with such issues, as I imagine Mark has to be (heck, I am, and I am not nearly as busy as he is!), then it is likely that you have a certain level of technology... and it is also likely that you do not test everything you do on every version of every browser. Thus even if a particular report does not have such a requirement, the other 12 you worked on over the preceeding months might. And maybe you do not want to waste time installing multiple browsers and such. For the UTF-8 thing, Mark did explicitly say that all new content is being done with UTF-8 encoding in a message last night.
