--On Monday, November 28, 2011 18:27 +0100 Julian Reschke
<julian(_dot_)reschke(_at_)gmx(_dot_)de> wrote:
That's more of an attribute of the text reader than any thing
else. I've had readers that reflow text just fine --- far
better than PDF, at any rate.
It requires a format that does allow reflowing and
repagination. HTML does, PDF/A does, text/plain does not
(maybe RFC 2646 would help, maybe not). text/plain is what we
use, and that's a problem that'll need to be solved.
Julian, PDF/A is a page-image format, just like base PDF. I
think there is enough information present to permit reflowing
lines and repaginating, but that certainly is not the intent.
PDF/A wouldn't help at all with RFC 12 and those nice
hand-sketched flowcharts: the ideal display situation would do a
little scaling, a little line-intensifying, and a little
scrolling of the charts while flowing the (non-header) text. If
one knew --via some mechanism such as those Marc has been
considering and experimenting with -- that a document was
actually in paginated ASCII page images (rather than an ASCII
stream) -- what Marc calls "line printer" -- then the heuristics
to remove the pagination headers and footers and flow other text
are actually pretty obvious and not much less reliable than
trying to display PDF/A in a format not intended by the file
creator.
Where I think we disagree is how to characterize the situation
vis-a-vis rendering engines. If I understood one of your
earlier notes, you think that creating new readers/ rendering
engines is a bad idea. I think we've had a problem rendering
plain-text materials since assorted operating systems decided
they were much smarter than users and content-creators about the
meaning of line terminators, etc. I think that creating an
expectation of being able to render plain text (Given that it
isn't 1975 any more, I'd hope for UTF-8 with Bidi and
multiple-script rendering support, not just ASCII) in a
plausible way, including variations for what the text/plain spec
calls "fixed", "flowed", "DelSP", and maybe "lp" would make a
lot of things easier and more sensible.
At the other extreme, if one really does want device-dependent
formatting and rendering for highly structured text, then many
of us (including you, or at least so I assume from earlier
comments in other thread) have understood since the early 80s
that one wants generic markup, the purer the better. Whether
the right answer to that version of the problem is HTML (as
someone else said, "which version?", to which I'd add "which
variation?"), XML with some agreed-upon characteristics for
processors, or even slightly-hybrid combinations of generic
markup with inline formatting markup or directives (e.g., docx
and the way most people seem to write xml2rfc files) is a matter
of taste and how far one wants to go to accommodate arbitrary
present and future devices.
I don't see a lot of future in those scenarios for formatting
markup (e.g., nroff and other runoff descendants) as a
distribution format but, as far as I know, if one doesn't count
U**x "man" files, no one ever did.
And now, in deference to the colleague who suggested that this
whole repeating discussion causes him to have strong urges to
find an appropriate virtual tower from which he could start
picking people off with an equally virtual weapon, I'm going to
try to drop out of this conversation because I don't think any
minds are being changed by it.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf