Subject: RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

From: Bob Braden <[email-masked]>
Date: Mon, 19 Jun 2006 09:32:45 -0700 (PDT)

*> 
  *> Note 2: Unlike some others on the IETF list, I recognize the 
  *> importance of having illustrations in better-than-ASCII forms. 
  *> We may disagree on how often it is important, or even on whether 
  *> "important" should be a criterion or the criterion should be 
  *> closer to "convenience".  I am nonetheless very sympathetic to 
  *> the arguments that fancy illustrations often hide fuzzy thinking 
  *> while the discipline of producing ASCII line art tends to 
  *> clarify thinking and encourage simplicity in design.  Perhaps as 
  *> a result of those possible disagreement, we might disagree on 
  *> the relevance of ASCII versions of text and ASCII approximations 
  *> to the more advanced, image-type, illustrations.  But we at 
  *> least share the belief that there is a problem in this area that 
  *> should be solved.  I am not positive that even that position has 
  *> IETF community consensus.
  *> 
  *> regards,
  *>      john

John,

This discussion has seemed to overlook that fact that for the past 20
years or so the RFC Editor HAS offered a .ps/.pdf alternative output
format; it just can't be normative.  With very few exceptions, a
protocol specifications (that's what we are supposed to be documenting
here, the last time I checked) can be defined normatively quite
satisfactorily using ASCII.  But, sometimes it is helpful to add
additional explanatory (non-normative) diagrams, equations, etc., which
can be in an auxiliary .ps/.pdf version.  I believe there are roughly
50 worked examples of this approach among the 4000+ RFCs in the
archive.

The one caveat is that processing RFCs with a .ps/.pdf version does
take more time and effort, so we hope it does not happen very
often.

Bob Braden

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Mon, 19 Jun 2006 14:09:24 -0400

--On Monday, 19 June, 2006 09:32 -0700 Bob Braden
<[email-masked]> wrote:

>   *> Note 2: Unlike some others on the IETF list, I recognize
> the    *> importance of having illustrations in
> better-than-ASCII forms.    *> We may disagree on how often it
> is important, or even on whether    *> "important" should be a
> criterion or the criterion should be    *> closer to
> "convenience".  I am nonetheless very sympathetic to    *> the
> arguments that fancy illustrations often hide fuzzy thinking 
>   *> clarify thinking and encourage simplicity in design.
> Perhaps as    *> a result of those possible disagreement, we
> might disagree on    *> the relevance of ASCII versions of
> text and ASCII approximations    *> to the more advanced,
> image-type, illustrations.  But we at    *> least share the
> belief that there is a problem in this area that    *> should
> be solved.  I am not positive that even that position has 
 
> John,
> 
> This discussion has seemed to overlook that fact that for the
> past 20 years or so the RFC Editor HAS offered a .ps/.pdf
> alternative output format; it just can't be normative.  With
> very few exceptions, a protocol specifications (that's what we
> are supposed to be documenting here, the last time I checked)
> can be defined normatively quite satisfactorily using ASCII.
> But, sometimes it is helpful to add additional explanatory
> (non-normative) diagrams, equations, etc., which can be in an
> auxiliary .ps/.pdf version.  I believe there are roughly 50
> worked examples of this approach among the 4000+ RFCs in the
> archive.
> 
> The one caveat is that processing RFCs with a .ps/.pdf version
> does take more time and effort, so we hope it does not happen
> very often.

Bob,

I certainly was not ignoring that possibility, and have
commented on it several times.  However I see three major
disadvantages of it which may or may not be subsumed by "more
time and effort".  The proposers of this particular experiment
would add a third, which is precisely that the ps/pdf forms are
not normative.  Those disadvantages are, in increasing order of
importance for this discussion (but perhaps not more generally),
are:

(1) Because the ps/pdf files are not normative, we haven't spent
nearly enough time making sure that they are long-term readable.
Perhaps we should; perhaps we now assume that, since they are
not normative, we don't care.  But there have been, e.g., many
postscript files of the vintage of last 1989 that are not
readable by modern tools without at least some fussing.

(2) If I prepare an RFC draft using some mechanism which
produces a document in form X, where X might include

	* ASCII text, via emacs or vi, with a post processor for
headers, footers, or page numbers
	* xml2rfc
	* MSWord plus some templates and post processing
	* nroff with a profile different from the RFC Editor's standard
	* LaTeX or TeX
	* Obscure word processor 7b

then the RFC Editor makes changes, possibly extensive and
returns the revised document in an ASCII text format.   No
matter how good my tools are, I'm going to have to do
considerable, mostly manual, work to retrofit those changes into
my source.  The retrofit will be easiest with the fourth, but
nroff preparation is part of what some of us have never used and
others would like to get away from.  It will be second-easiest
if I prepared the input with the ASCII editors, but they won't
help me produce PS/PDF for the textual part of the document
(which we both assume will be most of it).  For the others,
based on experience with three of the four, it has considerable
costs in time and effort, costs that are high enough to act as a
considerable deterrent to ever getting around to producing the
PDF or PS forms.  

If that deterrent is what the RFC Editor is after, perhaps on a
"if we make it hard, then only those who think it is really
important will put in the time and create the extra work for
us", I wish you would be more candid about it with the
community.   But I haven't concluded, so far, that it is
intentional.

But, if it is not, then one of the discussions we should be
having, IMO, is about selecting one or two additional input
formats (xml2rfc and Word stand out as candidates to me) in
which the RFC Editor is willing to accept input documents and
return editing results to the authors for review.  Doing so
would solve a large number of problems, not only wrt easily
producing PS/PDF forms when needed, but for producing revised
versions of the relevant documents for updated standards, etc.
That suggestion has been made several times; as far as I know,
the discussion has never gotten off the ground.

(3) Finally, if one adopts the "plates in the back" model, the
PDF (or whatever) document contains the illustrations and _only_
the illustrations.  That makes it fairly insensitive to the RFC
editing process.  In that process, almost all changes are to
text. Even if the figures are changed, that usually requires
significant negotiation between authors and RFC Editor and there
is still more text.  So I suggest that, generally, we would find
that, in a "text plus figures" model, the editing process would
generally change the text only, permitting the figures/images to
remain unchanged.  That would considerably reduce the burden of
both preparation and checking relative to what is now required
to produce, retrofit changes, and publish a PS or PDF document.

As I have said in response to other notes, I'm not convinced
that "text plus figures" (or "image attachments") is a good
enough idea to be worth writing up and considering -- in terms
of either IETF needs or RFC Editor workload.  But it has enough
advantages relative to either version of the status quo
--"ASCII-only" or "of course you can produce a version in PDF if
you are motivated enough and we hope you won't get motivated
very often"-- that I think it needs a bit more consideration
than it has been getting.  

Of course, if the community approves the current "normative PDF"
proposal, that discussion would be moot.    But I don't think I
see the discussions headed in that direction (just personal
opinion, of course).
        
   john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Jun 2006 00:18:08 +0200

> returns the revised document in an ASCII text format.

Now I have never written an RFC so I don't know how all of this  
works, but I have written two books for different publishers so I  
know how this kind of thing works elsewhere. My question: does the  
RFC editor really live up to his/her name and perform extensive  
edits? And if so, what are the nature of those edits? I can't imagine  
they go to the technical content, so either it's language (copy edit)  
or formatting, right?

> No matter how good my tools are, I'm going to have to do
> my source.

Ok. If we're talking about copy edits here, then this is one for the  
problem statement. Note by the way that the formatting authors are  
normally expected to do is indicating heading levels, block quotes,  
captures, that kind of thing. This is very easy to do with styles in  
modern word processing applications, which generally make anything  
tagged with a style look different. It's also easy to do with old  
school tools such as nroff and HTML/XML, and unless I'm mistaken,  
there are tools available to convert between the two approaches.  
(Word processors generally have a document format in common that  
preserves the style tags if not their attributes.)

If there is an iterative cycle of changes between the authors and the  
RFC editor, I think it's necessary that this is done with some form  
of style tagging. In addition, more advanced word processors such as  
Word and Star/Open Office/Writer support a "track changes" feature  
where any changes made to a document are identified along with who  
made them. This makes sending different versions of a document back  
and forth infinitely easier, but it has the downside that many word  
processors and other tools don't support this, so the selection in  
tools is much smaller.

> return editing results to the authors for review.

Yes, this makes sense. Especially if the Word format is only used as  
a "lingua franca" without depending on specific details. I.e., I can  
write a text in Open Office, tag it with the right styles and export  
to .doc format. In Word or another word processor that can read those  
files, the styles will still be present even if the document looks  
slightly different from the way it did when I wrote it because some  
information is lost when saving in a non-native file format.

> Doing so

Let's see if we can do better now.

> editing process.

I'm not too happy about that. If we're going the route of using  
images for formulas and drawings, it makes sense to make those  
available as separate files in an "easy" format such as GIF or PNG,  
or, in addition or alternatively, a PDF can be produced where the  
images are present in-line with the text. Having the images separate  
from the text in a PDF has all the disadvantages of PDF: possibly  
large files, small selection in viewers, security and compatibility  
issues, but it's still inconvenient when reading the text and having  
to hunt for the images separately.

> So I suggest that, generally, we would find
> remain unchanged.

That is not my experience. Figures are very hard to get right, they  
very often require edits.

> than it has been getting.

Two prominent problems associated with the ASCII format are that it  
doesn't really support formulas and figures. I was intrigued with the  
earlier Unicode examples, so I decided to do some checking of my own  
with regard to "unicode art" for figures. Have a look at:

http://www.muada.com/drafts/utf8-art.txt
http://www.muada.com/drafts/utf16-art.txt

I think this is closer to what an RFC with Unicode line art would  
look like than trying to present an example in email. For me, the  
UTF-8 encoding isn't immediately decoded properly by my browser, but  
the UTF-16 version is. I also can't get this displayed properly on  
the command line on my Mac. Still, it's not _too_ hard to have the  
Unicode characters displayed properly. The Unicode line art looks a  
lot better than ASCII-only line art, but it shares many of the same  
limitations, such as only (reasonably) being able to display  
rectangular shapes and horizontal/vertical lines. There are some  
exceptions such as the ability to use rounded corners, but true round  
shapes or even usable diagonal lines don't seem to be supported. This  
also means that it should be generally possible to convert from  
Unicode to ASCII-only line drawings without much loss of information.

There has been some talk about specifying a font for displaying  
Unicode, but on my Mac at least, that doesn't seem to be necessary.  
An important issue with different fonts is the difference in  
character width for different characters, but the line art characters  
are mostly the same width so this isn't an issue. However, the width  
of the space character can vary, but there's probably a fixed width  
space in the table somewhere. Also, it looks like there is only a  
single glyph for these types of characters that is shared between  
fonts. I.e., whether I use Courier or Times, the line drawing  
characters look the same.

It does seem to me that looking into Unicode for better formula and  
drawing support makes a lot of sense. This allows us to make better  
looking RFCs without radically changing the way RFCs are published.

However, I think we probably want to change the process for other  
reasons. I think it would be very useful to have the "source" of an  
RFC available with style tagging and so on in order to more easily  
derive future work. It's probably also a good idea to have "blessed"  
PDFs or some similar format for pretty printing, especially for the  
RFCs that contain formulas and drawings. And we may want to make  
those formulas and drawings available as simple bitmap images so they  
can be easily viewed on systems with limited capabilities. But with  
all of that in place, it's probably a good idea to keep having the  
ASCII version of RFCs be the normative version.

Anyway, that's my $0.02 Canadian on this subject.

---

From: Ned Freed <[email-masked]>
Date: Mon, 19 Jun 2006 16:07:55 -0700 (PDT)

> edits?

The answer is it depends. I've had some documents that were pretty much
unchanged while others were edited quite extensively. In recent work I've
observed that most edits are good ones, but occasionally the RFC Editor doesn't
quite get what's going on and bolixes something up. It is therefore imperative
that every change be carefully reviewed by the document authors.

> And if so, what are the nature of those edits? I can't imagine

Most are editorial in nature. Occasionally there will be a change with
technical implications though. We're not dealing with fools here, you know.

> > considerable, mostly manual, work to retrofit those changes into

I don't know what other authors do, but I edit all the changes back into my
xml2rfc source, iterating until my output matches, modulo numbering and
paragraphing and whatnot, what the RFC Editor produced. This way I am
sure to catch any mistakes introduced by the editing process. I also end
up with a source file that's a useful starting point for the next revision
of the document.

This is quite tedious but not especially difficult as long as you have provided
xml2rfc sources to the RFC Editor as a starting point. If you haven't done that
my guess is the process isn't nearly as nice.

> preserves the style tags if not their attributes.)

The RFC Editor provides an annotated differences listing showing you what
changed between your final draft and what's in the actual RFC. It is a simple
matter to duplicate this tool and use it to tweak your sources to match the
actual RFC. I've tried using change bars and other fancier tools, but I have
concluded they're more trouble than they're worth.

> of style tagging.

There already is such a process, but IMO you're mistaken about what's needed to
improve it. The thing I'd like to have that isn't already there is a way to get
the xml2rfc sources the RFC editor used back for comparison purposes.

> In addition, more advanced word processors such as

Again, I've tried these things a couple of times and found them to be more pain
than gain.

> > return editing results to the authors for review.

As I indicated above, the RFC Editor already accepts xml2rfc source for
documents as a starting point. My understanding is that they then do  as much
of their editing as possible against the xml2rfc source, then generate nroff,
then tweak the nroff and possibly even the final output to get exactly what
they are after.

it would be great if more of the work was done on the xml2rfc and less in the
later stages, but I think the RFC Editor is already moving in that direction.

> information is lost when saving in a non-native file format.

My immediate thought in response to all this is "what a colossal waste of
time". I want to focus on document content, not stylistic frills and irrelevant
minutiae. That's what the RFC Editors gets the big bucks to do... I therefore
want a tool that lets me engage in semantic markup with as little attention
paid to layout issues as possible. It is exceedingly unfortunate that some
amount of device-level markup is still needed in xml2rfc, but hopefully as the
tools improve over time actual use of such facilites will become less
necessary.

THis is not to say there aren't cases where I want precise control of document
output. I run into such cases all the time, and when I do I use TeX. But this
has nothing to do with writing RFCs. Something is very wrong if an RFC requires
this sort of work.

> > the discussion has never gotten off the ground.

THe issues surrounding the production of revised versions are top of my
personal list at least.

> very often require edits.

It depends on what sort of edits you're talking about. Both figures
and equations move things away from pure semantic markup and towards
presentation specifics. It's unavoidable, and once you enter the presentation
realm the list of possible tweaks to make things just a little bit
better often seems endless. But I question whether such changes
are really necessary in a lot of cases. Sure, I've sometimes spent hours
with TeX or in OmniGraffle trying to make those equations or that block
diagram look a bit nicer, but after having done so I've rarely believed
it was time well spent.

				Ned

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 19 Jun 2006 17:33:00 -0700

Hi -

> From: "Ned Freed" <[email-masked]>
> To: "Iljitsch van Beijnum" <[email-masked]>
> Cc: "John C Klensin" <[email-masked]>; "IETF-Discussion Discussion" <[email-masked]>
> Sent: Monday, June 19, 2006 4:07 PM
> Subject: Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'ProposedExperiment: Normative Format in Addition to ASCII
Text'to Experimental RFC (draft-ash-alt-formats))
...
> my guess is the process isn't nearly as nice.

I've used the same process for RFCs formated using nroff/groff.
It was pretty easy, and wasn't even particularly tedious.  (Though
I suppose the fact that we're still reading this thread is evidence
that we have a rather high tolerance for tedium.  :-)

...
> concluded they're more trouble than they're worth.
...

This matches my experience as well.  Change bars are helpful to a reader,
but much less helpful to an editor.  As for tools with "built in" change
tracking, the ones I've tried have been more trouble than help, and seem
to be easily confused by incidental layout tweaks.

Randy

---

From: Tony Hansen <[email-masked]>
Date: Tue, 20 Jun 2006 01:05:45 -0400

Ned Freed wrote:
> 
> The RFC Editor provides an annotated differences listing showing you 
> what changed between your final draft and what's in the actual RFC. 
> It is a simple matter to duplicate this tool and use it to tweak your
> sources to match the actual RFC. I've tried using change bars and
> other fancier tools, but I have concluded they're more trouble than
> they're worth.

I've gotten really good mileage from rfcdiff at
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht. It compares two RFC
text files and nicely shows the diffs side by side. Regenerate the text
in one browser tab pointing at xml.resource.org, do a reload on the diff
tab, repeat until fully baked.

	Tony Hansen
	[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Jun 2006 12:00:08 +0200

On 20-jun-2006, at 1:07, Ned Freed wrote:

>> does the

> that every change be carefully reviewed by the document authors.

I see.

> paragraphing and whatnot, what the RFC Editor produced.

Ouch!

That must be a colossal waste of time for everyone involved.

> concluded they're more trouble than they're worth.

Then you haven't been doing it right... If you use Word, for instance  
(but Open Office has the same functionality) you can set up "track  
changes" and "highlight changes when editing" or words to the same  
effect, and then you'll see text that's added in a different color  
depending on who added it, and you can reject or accept changes made  
by others. You can also easily skip to the next edit. I can't imagine  
two or more people working on the same document without this  
functionality.

>> to .doc format.

> paid to layout issues as possible.

And that's exactly what the style mechanism is for: you can indicate  
headings of different levels (= generate numbering and table of  
contents automatically), have different kinds of lists (bulleted,  
numbered) and so on.

> It is exceedingly unfortunate that some

Speaking of time wasting: it doesn't make much sense to me to work on  
a tool specifically for this purpose while much more powerful general  
purpose tools are readily available. I.e., wouldn't it make sense to  
move towards a situation where it's possible to write a draft or RFC  
with a regular word processor with only a little post processing  
rather than spend time perfecting yet another tool that's hard to learn?

> output.

I don't care about that (well, obviously to some degree, but not  
much). As an author, I mark up my text correctly and then the layout  
people can do their magic and get it right about 98% of the time.

> better often seems endless.

I'm talking about stuff like "the text in this box should be A but  
it's B" and "there shouldn't be a line between those two boxes".

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Jun 2006 11:41:28 -0400

--On Tuesday, 20 June, 2006 12:00 +0200 Iljitsch van Beijnum
<[email-masked]> wrote:

>> I've tried using change bars and other fancier
>> tools,   but I have
> Then you haven't been doing it right... If you use Word, for
> instance  (but Open Office has the same functionality) you can
> set up "track  changes" and "highlight changes when editing"
> or words to the same  effect, and then you'll see text that's
> added in a different color  depending on who added it, and you
> can reject or accept changes made  by others. You can also
> easily skip to the next edit. I can't imagine  two or more
> people working on the same document without this
> functionality.

Hmm.   With Word, for instance, virtually every correction to
the text results in a huge clutter of change-tracking notes
about format changes and similar drivel.  For many documents, it
makes the S/N ratio just miserable.   If there were a "track
substantive textual changes only" option, an "ignore format
changes" one, or some sort of "accept all format, font, and
style changes" command, I'd probably agree with you about
utility.  But, given the reality of those systems today, I tend
to agree with Ned, even though I like a feature of those system
that you didn't mention (the ability to insert comments whose
appearance in the output can easily turned on and off.  <cref>
and some processing options comes close, but isn't quite the
same).

> And that's exactly what the style mechanism is for: you can
> indicate  headings of different levels (= generate numbering
> and table of  contents automatically), have different kinds of
> lists (bulleted,  numbered) and so on.

If it worked, that would be how it would work.  My own
experience is that it is very hard to get it to work well.  To
take a handy example, try to generate a cross reference to a
heading that hasn't been generated with a built-in style in Word
(2000/ XP/ 2003). 

>...
>>> That is not my experience. Figures are very hard to get
>>> right, they very often require edits.
> 
>> It depends on what sort of edits you're talking about. Both
>> figures and equations move things away from pure semantic
>> markup and towards presentation specifics. It's unavoidable,
>> and once you enter the   presentation
>> realm the list of possible tweaks to make things just a
>> little bit better often seems endless.
> 
> I'm talking about stuff like "the text in this box should be A
> but  it's B" and "there shouldn't be a line between those two
> boxes".

But those are precisely the things that, in our environment, one
wants the author to get right and the RFC Editor to not mess
with.

    john

---

From: Ned Freed <[email-masked]>
Date: Tue, 20 Jun 2006 09:37:49 -0700 (PDT)

> makes the S/N ratio just miserable.

This matches my (much more limited) experience with OpenOffice.

> If there were a "track

IMO this is something that needs to be added to xml2rfc. It is very common to
have text of various sorts in drafts that has no business being in the final
RFC, and the current mechanisms for controlling this are a bit primitive.

Consider this a vote for some added functionality in xml2rfc to cover
this case.

> heading that hasn't been generated with a built-in style in Word

It actually sounds like Word is more capable than some other
high end tools in this specific case.

> wants the author to get right and the RFC Editor to not mess

Exactly so.

I will also add that while the temptation is great to use the most powerful
tool available, the most powerful tool is often not the best tool for the job.
When it comes to producing RFCs, xml2rfc plus a competent XML editing tool
(I'm currently using Exchanger XML Editor) is a clear winner in my book.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Jun 2006 20:06:20 +0200

> Consider this a vote for some added functionality in xml2rfc to cover

People interested in change tracking for xml2rfc may want to check out 
my extensions in rfc2629.xslt, see example documents such as 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-14.html> and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-14.xml>.

> ..

Exactly. When I write specs, the last thing I want to care about are 
presentational issues. In fact, my experience is that "WYSIWYG" tools 
tend to distract me from the content, slowing me down drastically. But 
that may be just me :-)

Best regards, Julian

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 21 Jun 2006 09:25:06 +0200

Hmm.   With Word, for instance, virtually every correction to
the text results in a huge clutter of change-tracking notes about format
changes and similar drivel.  
For many documents, it makes the S/N ratio just miserable.   If there
were a "track
substantive textual changes only" option, an "ignore format changes"
one, or some sort of "accept all format, font, and style changes"
command, 
I'd probably agree with you about utility.  But, given the reality of
those systems today, I tend to agree with Ned, 
even though I like a feature of those system that you didn't mention 
(the ability to insert comments whose appearance in the output can
easily turned on and off.  <cref> and some processing options comes
close, 
but isn't quite the same).

[YJS] My experience has been quite different.

I work, on a daily basis, with many extremely complex Word documents
each of which is handled by many different people (often with
conflicting aims).
These documents often go through dozens of revisions.

And although (as mentioned often before) I am no great fan of Word,
I have never seen S/N problems of the type you mention.

I suspect that your co-authors are really fooling around way too much
with presentation aspects rather than content.
Next time agree on a ground rule that first the ideas should be
gotten right, and leave the pretty-printing for the final round.
Not only does this make sense and save everyones time, 
it will probably eliminate your S/N problem. 

Y(J)S

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 21 Jun 2006 09:20:41 +0200

> with presentation aspects rather than content.

++

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 22 Jun 2006 09:21:50 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: "IETF-Discussion Discussion" <[email-masked]>
Sent: Tuesday, June 20, 2006 12:18 AM
Subject: Re: Image attachments to ASCII RFCs (was: Re: Last Call:
'ProposedExperiment: Normative Format in Addition to ASCII Text' toExperimental
RFC (draft-ash-alt-formats))

> > produces a document in form X, where X might include
<snip>
> Unicode characters displayed properly.

I agree in principle that adding a selected subset of Unicode would address the
most pressing issues.  But, for whatever reason, I get gibberish on both the
URLs you give.  By contrast, the figure embedded in an e-mail earlier displayed
perfectly (until it got mangled when included in a reply).  This suggests to me
that the world is not quite ready for Unicode yet (I am using vanilla Windows
software, as most of the world does:-(.

Tom Petch

The Unicode line art looks a

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Jun 2006 11:26:53 +0200

> software, as most of the world does:-(.

Well, that's because for the URLs above the content was served with an 
incorrect content type:

GET /drafts/utf8-art.txt HTTP/1.1
Host: www.muada.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) 
Gecko/20060508 Firefox/1.5.0.4
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Date: Thu, 22 Jun 2006 09:24:22 GMT
Server: Apache/2.0.53 (FreeBSD) PHP/4.4.0 mod_ssl/2.0.53 OpenSSL/0.9.7e
Last-Modified: Mon, 19 Jun 2006 21:10:53 GMT
Etag: "5aa8a0-2a9-3394b140"
Accept-Ranges: bytes
Content-Length: 681
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Content-Type: text/plain; charset=ISO-8859-1

Best regards, Julian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 Jun 2006 14:15:31 +0200

> <inline>

Where else?

> software, as most of the world does:-(.

Well, apparently Windows isn't, although I gather that it does  
actually support Unicode to a more noticable degree than I've seen.  
As someone else observed, my server adds an ISO-8859-1 header (thank  
you Apache for guessing (wrong) what the file contains and then  
overwrite what's specified in the file or what the client may guess  
correctly, wasting a little bandwidth for every request). I've done  
some additional experimenting, most notably at:

http://www.muada.com/drafts/utf8-art.php
http://www.muada.com/drafts/utf8-art-html.php

These both result in something workable on the Mac with Safari,  
something that works to varying degrees in Firefox on Mac/Linux/ 
Windows but no luck on Windows with Internet Explorer. (The right  
header in gets stuffed into the HTTP reply with PHP.) Apart from IE's  
ineptitude the main problem is that most systems have a hard time  
getting all the characters the same width.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Jun 2006 14:40:14 +0200

Iljitsch van Beijnum schrieb:
> something that works to varying degrees in Firefox on Mac/Linux/Windows 
> but no luck on Windows with Internet Explorer. (The right header in gets 
> stuffed into the HTTP reply with PHP.) Apart from IE's ineptitude the 
> main problem is that most systems have a hard time getting all the 
> characters the same width.
> ...

1) This seems to be a bug in IE6 and IE7 (the contents of the HTML looks 
correct to me).

2) In rfc2629.xslt, I generate HTML with encoding ISO8859-1, thus the 
box drawing characters are serialized as character references (such as 
&#9484; for down/right). This seems to work in IE.

Best regards, Julian

---

From: Tony Finch <[email-masked]>
Date: Fri, 23 Jun 2006 13:43:05 +0100

On Thu, 22 Jun 2006, Iljitsch van Beijnum wrote:
>
> As someone else observed, my server adds an ISO-8859-1 header (thank you
> Apache for guessing (wrong) what the file contains and then overwrite
> what's specified in the file or what the client may guess correctly,
> wasting a little bandwidth for every request).

I doubt it is guessing. Check your configuration for an AddDefaultCharset
directive. http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
NITON: RISK OF FOG BANKS ON SATURDAY IN EAST AND SOUTH.