Re: I-D file formats and internationalization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Nov 30, 2005, at 2:54 PM, Frank Ellermann wrote:
> 
> > As Bob said raw UTF-8
> > characters won't fly with `cat rfc4567 > /dev/lpt1` and other
> > simple uses of RFCs.
> 
> 1. I wonder what proportion of the population prints things this way?
> 2. If the file is correctly encoded in UTF-8 and the above doesn't  
> work, then your operating system is buggy.  

I guess that depends on your definition of "buggy".  The most popular OS
in the world no longer natively supports printing of _any_ kind of flat
files - you have to have a special application to do that.  While most
people would agree that that OS is buggy, its inability to print flat
files was a deliberate design choice and is therefore more properly
termed a "crippling feature".

Also, the vast majority of printers in use don't natively support
printing of utf-8, thus forcing users to layer each of their computer
systems with more and more buggy cruft just to do simple tasks like
printing plain text.  Perhaps those are buggy also?

These days, your best bet for getting utf-8 files to print is to use a 
web browser's print command, which is doable but can be fairly
cumbersome as compared to typing a simple "lpr" command.  Unfortunately,
most web browsers fail to preserve page breaks (FF characters) when
printing flat text files, which makes the resulting documents hard to
read.

HTML with utf-8 actually displays and prints more portably than plain
text with utf-8, though it's not clear how many browsers support the
style sheet extensions enough to print page breaks in the right
places.  Also, HTML is still somewhat of a moving target and it is
somewhat unclear whether any particular subset of HTML that is used
today will still be effectively presented 10-20 years from now.  The
biggest problems with HTML are (a) no way to include images in the
document without external links (yes I know about MHTML but it's not as
widely supported); (b) difficulty in finding authoring tools that will
produce output in a subset of HTML that we define; (c) avoiding
the temptation to make the documents pretty rather than readable.

It's hard to escape the conclusion that we're trying very hard to make
our document processing much more complex for a very marginal gain.

Keith


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]