On 2011-11-28 22:09, Martin Rex wrote:
Julian Reschke wrote:
On 2011-11-28 20:44, Martin Rex wrote:
...
The real problem is buggy software for displaying on small displays.
Reflowing ASCII is *no* problem whenever ASCII text is reflowable
at all. It can be done in 1-2 KByte of code. Displaying HTML or XML
But our format currently is not reflowable. Can we make it? And if we do
so, do we have clients to display it?
ASCII itself is fully reflowable. Web Browsers that are displaying
HTML are actually reflowing ASCII pretty much on every page.
Web browsers that display text/html are reflowing text pretty much on
every page.
Yes, that's my point.
Again: please distinguish between character encodings and file formats.
Web browsers are *not* reflowing text/plain, and that's the format we
currently use.
But there are two things that cause problems:
* reflowing ascii arts makes the information incomprehensible
That's why you need markup so the browser knows what is what.
* displaying ascii arts with variable width fonts distorts the
information up to incomprehensibility
That's why you need markup so the browser knows what is what.
Since "plain ascii" does not contain hints about "reflowability",
the visualization software would need to account for two things:
* a heuristic to ensure that lines that should not be reflowed
are not reflowed. Looking at the amount of whitespace (empty lines)
and left to the text (indent) is often sufficient.
Maybe. Maybe not.
Proposal: take Henrik's rfcmarkup tool and tune it so that it *reliably*
distinguishes between reflowable stuff and what's not (examples,
diagrams, tables, whatnot).
Once you get this working in more than a few sample documents I'll
likely tell you: great, but why didn't you produce HTML in the first place?
* display non-flowed text with a fixed-width font
(which normally means that the flowed text should also be displayed
with a fixed-width font by default)
I disagree, but that's another thing HTML allows you to control.
Really, displaying ascii text was a *solved* problem 30 years ago,
where the common environment was 8-bit CPU, 2 Mhz clock cycle
and 1-2 kByte of code for display text. It would almost a no-brainer
to make this work on smartphones and pads--so unless one is stuck in
a no-brain situation...
So go ahead, do it. I don't mean to be rude but telling people that it's
simple doesn't help. Do it.
When modern display devices, which claim to be *made* for reading text,
can not adequately display ASCII text that is pre-formatted for 80chars
line-length, then it is first of all a clear shortcoming of the software
on these devices and the engineers responsible for this software.
No, it's just a sign that the world today is different from the world 30
years ago.
During this summer holiday, I tried to use my childs Nintendo DSI
(256x192 3.25 inch display, WLAN-support, Opera Browser) for reading
a few news headlines in a language I am more accustomed to than french.
I only used it with HTML pages, but it was a royal PITA as far as
usability goes, inspite of HTMLs flowability.
Yes. What does this prove?
There are Phones with displays of 128 pixels across. Where is the limit?
I think it would be worthy goal to get proper display of RFCs on 7 inch
tables in portrait mode, or dedicated ebook readers of that size.
...
usally requires more than a megabyte of code.
...
So?
Fix the obviously broken readers of new devices rather than
requiring 30 full years of computing history being re-edited and
re-published just so that the dense creators of those devices
do not have to add 1-2 KByte of code for sensibly visualizing ASCII text
(which seems too much to ask compared to the megabytes of code-updates
that vendors have to regularly provide due to other shortcomings
and negligences in the security area.)
And btw. most of the Web pages that I try print out on paper
have truncated borders, waste lots of paper because only a small
portion of the surface is used for information and sometime only
the first page gets printed (the rest only accessible inside
the browser with a scroll bar).
Use a proper browser (-> Firefox), and make sure to do print preview.
I do and it regularly doesn't work. Many sites render well only
in specific browser and print badly, if at all.
Yes. You need to consider printing when generating the HTML. You also
need to consider printing when generating text/plain. But with the
latter it's much harder because you need to known the paper dimensions
beforehand.
How to print ASCII text is the type of problems for which easy solutions
existed already 20 years ago. That some modern devices fail to
display ascii text in a reasonable fashion is a demonstration that
the software in these devices is defective, not that it is not
possible to sensibly display ascii on such devices.
No, it just shows that our format has been optimized for a use case
which almost nobody cares about anymore.
I'm sorry, but I'm a developer and not in the professional publishing
service, and I care much more about non-flowing 80-char text than
I care about flowing text.
I have my EMail at 80chars, and I try to make all of my C-Source code
fit 80-chars, and accompanying readme.txts at 80 chars.
And most other C-Code I look at is the same.
Last time I checked, the IETF was about "Engineering".
Yes, but that's not an excuse for being the only org unable to publish
in a usable format.
I often put snippets of RFCs into code comment blocks
of my C-Code. Not having to reformat the text manually
saves me a lot of time (compared to copying ASN.1 structures
into comments from ISO X.something).
I do that sometimes as well. Eclipse will reformat these, thankfully.
That being said, I don't believe that's use case we should optimize for.
Nor is printing, btw. What's important is *reading*, because that's what
these documents are for.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf