gmane.ietf.rfc.interest

Re: Pagination requirements

Julian Reschke — 2012-05-25T10:51:38

You realize that that's not "the" RFC format, right?


Note that 3.6 has been end-of-lifed a few weeks ago.


Has anybody reported a bug?


Best regards, Julian

Re: Pagination requirements

Martin Rex — 2012-05-25T10:43:47

Reality check:

  http://tools.ietf.org/html/rfc2246

prints pages correctly (on A4 paper) out-of-the-box with
   Chrome on Win7
   MSIE 8 on Win7
   MSIE 8 on WinXP

I had to change "scale" to 95% in Firefox 3.6 in PrintPreview to
make it break pages correctly, whereas FF 12 on Win7 seems to break
pages correctly with the default scale "shrink to fit" (for A4 paper)
and the default margins of 1/2 in. all around.


The reason why MSIE 8 and Chome break pages incorrectly with

  http://tools.ietf.org/rfc/rfc2246.txt

is a bug with respect to processing ASCII FormFeeds (12d/0x0c)
characters when printing text/plain contents.


You're in the CABrowser Forum -- tell the browser maintainers to fix
their text/plain printing, a code change in the ballpark of 1-10 LoC

Re: Proposed new RFC submission requirements

Martin Rex — 2012-05-25T09:19:51

[Thanks.  Reusing your thread for a reply to Joe]

 

I strongly believe that the structure of the content of I-Ds and RFCs
should be (for the large majority of them, at least) remain sufficiently
clear that the current "line printer format" (pre-paginated ASCII) will
remain an acceptable submission format _and_ sufficient for deriving
HTML-enriched versions of it.

For the simple reason that B&W-printouts as well as informationed rendered
through accessibility enhancements will not repro the meta-data either,
and it is extremely desirable that the lack of the meta-data will
NOT impair clarity/understanding of the document and not adversely
affect implementations based e.g. on the printout.

For me, the type face, non-ASCII glyphs for demonstrations purposes
images and meta-data markings are first of all eye-candy.
Embedded links that enable a browser to navigate between different portions
of the same document or different specifications facilitate online navigation.

But it is absolutely essentials that any such cross-references continue
to work in printouts (=offline).  And _when_ they work in printouts,
then converting cross-references in clickable cross-references work
just fine for plain ASCII printouts, as can be seen with rfcmarkup
on tools.ietf.org.

Personally, I believe that meta-data in the authoring format can
significantly impair authoring (it certainly does for me), where as
"implied meta-data" that can be easily recognized (e.g. by rfcmarkup)
that works both online and offline, does not impair the authoring process.


-Martin

Re: Pagination requirements

Martin J. Dürst — 2012-05-25T07:19:07



There's certainly some relationship between font spacing and reflow.

Also, please note that while for ASCII, it's usual to have fixed-width 
fonts, such fonts don't exactly exist for Unicode. There are several 
models that come close to the "fixed width" model of ASCII, such as the 
East Asian full-width/half-width model, but for some scripts (e.g. 
Arabic), any kind of fixed-pitch model is looking highly suboptimal. On 
top of that, there's the issue of character width vs. bytes-per-character.

Of course, we don't expect too much (non-ASCII) Unicode stuff, but being 
able to reflow will help visual quality where we need Unicode, avoiding 
too short or too long lines even after using careful heuristics when 
trying to line-break the text.

Regards,   Martin.

Re: Pagination requirements

Martin J. Dürst — 2012-05-25T07:02:33


Eyesight is another. Some people, in particular younger ones, seem to 
have eagle's eyes, while others (me more and more included) have limits.

Regards,   Martin.

Re: Pagination requirements

Martin J. Dürst — 2012-05-25T06:59:20

I'm personally extremely happy with Amaya (http://www.w3.org/Amaya/). 
It's free, and it has an unique combination of structural and WYSIWYG 
(or actually WYSIWYM - what you see is what you mean) editing (WYSIWYG 
for reflowing HTML doesn't exactly exist). It's not a product, and 
therefore it's sometimes a bit flaky, and I recommend frequent saving 
and reload if the display starts to look strange.

I haven't used it for editing IDs and RFCs, because it doesn't do 
generic XML, but I'm editing all my lecture notes/slides with it, as 
well as quite a bit of other stuff. Of course, YMMV.

Regards,   Martin.

Re: Pagination requirements

Martin J. Dürst — 2012-05-25T06:54:16

It would be a pity if we lost containment. If there's a problem for 
Word, I'm quite sure a post-processing script (similar to the one that's 
used currently) will be able to fix things.

Regards,   Martin.

Re: Pagination requirements

Martin J. Dürst — 2012-05-25T06:52:23

Sorry, just forgot: I'm saying that because I'm comparing it with at CSS 
file that I wrote that displays the xml2rfc XML rather close to a .txt 
document, and allows close to WYSIWYG editing in editors that support 
that. It's far from being complete or perfectly tweaked, but I'm 
attaching it just so that people interested can have a look at it (or 
improve it).

The WYSIWYG I'm speaking about is Oxygen XML Editor. That's not free, 
but has a steep academic discount, which may work for Joe Touch and some 
others, too. Earlier, I was using XMetaL,  but they went the corporate 
route and it's now way too complicated and completely unaffordable for 
me. I'm sure there are other tools that can do similar things.

I have to admit that I'm not using the WYSIWYG mode too often because I 
really care about the markup, and I'm afraid that editing in WYSIWYG 
mode may produce spurious diffs (but that hasn't been too bad so far). 
Also, xml2rfc's peculiarities, in particular the fact that section 
titles are attributes, not elements, makes WYSIWYG editing more 
difficult than it should be (and we really should fix that on the 
xml2rfc side!).

Regards,   Martin.

_______________________________________________
rfc-interest mailing list
rfc-interest< at >rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Re: Pagination requirements

Martin J. Dürst — 2012-05-25T06:40:59

Yes, it does. And that CSS is awfully long. In addition, there's lots of 
style information inline, but it should be possible to clean that up.

Regards,   Martin.

Re: Pagination requirements

Joe Touch — 2012-05-24T22:35:50

PS - I modified the file trivially (we could do this in post-processing) 
to add "preformatted" to all figures.

Figures no longer wrap.

(the file appears to have its own CSS at the beginning; I modified it 
there in case anyone looks at source).

Joe

On 5/24/2012 3:19 PM, Joe Touch wrote:

Re: Pagination requirements

Joe Touch — 2012-05-24T22:19:46


On 5/24/2012 3:16 PM, Joe Hildebrand wrote:

Heading marking is easy - and already supported. As per below, it may be 
easy to change the particular tag.

Section marking isn't AFAICT, though.


I know that - it's not complete, as I noted.

I'm not sure yet how to force Word to spit out the right tags...

Joe

Re: Pagination requirements

Joe Hildebrand — 2012-05-24T22:16:38


It's a reasonable discussion to have whether sections contain sections, or
whether we just use the heading number (h1-h6) to intuit relationships.  I
don't have a strong preference.  The CSS is probably a *little* easier with
containing, but it's doable either way.


Make your browser very narrow, and navigate to section 4.1, please.  Note
that your ascii art gets mangled, since it's not wrapped in a <pre> tag (or
a div with style whitespace: pre).

For more info on your choices for wrapping and whitespace handling, see:

http://www.w3schools.com/cssref/pr_text_white-space.asp

Re: Proposed new RFC submission requirements

John Levine — 2012-05-24T22:10:05

What he said.  The more semantic info we have in the canonical format,
the more likely it is that the tools that manipulate it will do
what we want them to.

I suppose that if there are people who for whatever reason are utterly
unable to deal with tools that produce markup, we could have some
backup path.  But just as we do not, as far as I know, still accept
hand typed I-Ds (see, for example RFC 635), perhaps we can take another
small step into the modern era.

R's,
John

Re: Pagination requirements

Joe Hildebrand — 2012-05-24T22:09:45


I'm imagining that the RFC editor puts their .css file up via HTTP.  The
template that we give out has their CSS referenced by full URL.  When they
do the final publishing step, they replace that link in your html/head with
a style element that contains the contents of the link.


It's canonical when viewed with only the canonical style sheet.  You can
replace individual styles trivially for your viewing pleasure, but then you
can't call what you're viewing canonical.  It's mostly an irrelevant
distinction, but meant to deal with the objection that if I change out my
styles so that my document looks different, it might mean something other
than what was originally intended.  It's just lawyer weasel-language.

Re: Proposed new RFC submission requirements

Joe Touch — 2012-05-24T21:52:46


On 5/24/2012 2:47 PM, Joe Hildebrand wrote:

No; N input formats, hopefully ONE canonical archival format, and N 
output formats

Right now that's already true, FWIW.


There shouldn't be multiples for a given submission - there should be 
one, but it need not be a single format for all submissions.

Joe

Re: Pagination requirements

John R Levine — 2012-05-24T21:48:39

There's a zillion format converters for document formats in various versions of 
Word.  If it turns out that there's more than one person who wants to use Word 
to edit I-D's, I don't think it would be a big deal to find someone with 
experience in writing them to do a converter to and from whatever format we 
pick.

As a prototype, it should be reasonably straightforward to do it outboard, to 
and from the mess that is DOCX format.

Regards,
John Levine, johnl< at >iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Re: Proposed new RFC submission requirements

Joe Hildebrand — 2012-05-24T21:47:04


There doesn't *have* to be one input format for all submissions, but if I
were the RFC editor, I'd sure prefer that, in order to drastically reduce
the amount of tooling required.  N input formats * M output formats = a
mess.

I would say that for a *given* submission, I would like there to be exactly
one input, from which all of the output formats are generated.  If we don't
take this approach, there's no way, short of heroic human effort, to ensure
that the multiple inputs say the same thing.

Re: A proposal: HTML

Julian Reschke — 2012-05-24T21:38:42

Hiding things makes it more likely to break them. There are better ways 
to do this, such as RDFa, microformats or microdata. Unfortunately these 
are multiple, competing ways, so there will be disagreement about which 
to pick. This is why I personally would prefer to stick with what we 
have (RFC2629) and to carefully extend it.


What you consider a feature others (IMHO correctly) see as a defect in 
HTML 4, and HTML 5 happens to have ... <section> 
(<http://dev.w3.org/html5/spec/single-page.html#the-section-element>).


Delegating to CSS makes it impossible to copy paste from the HTML into 
plain text (think email), so I think that should be avoided.


No, you don't need that at all. You can simply copy & paste the contents 
of <http://xml.resource.org/public/rfc/bibxml/reference.RFC.0959.xml> 
into your document.


That's a tool problem. The fact that nobody has written that tool could 
mean that the problem isn't a big as you think. I personally have no 
problem maintaining my references by hand.


Almost. These two use entirely different HTML formats.


Yes.

But then, rfc2629.xslt has allowed overriding the builtin CSS stylesheet 
for many many years, but I haven't seen anybody using them. Maybe that 
just means that a good-enough stylesheet is sufficient.


I'll remain skeptical about that until I see a concrete example plus 
code that recovers all the information we have in RFC2629 right now.


+1

And again, this problem has been solved years ago. Just feed rich HTML 
into PrinceXML and get PDF from it. It's a commercial tool, but I'm sure 
the IETF could afford it.

Best regards, Julian
_______________________________________________
rfc-interest mailing list
rfc-interest< at >rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Re: Pagination requirements

Joe Touch — 2012-05-24T21:04:04


On 5/24/2012 1:52 PM, John R. Levine wrote:

For those interested, I'm thinking of the .DOTX file needed to have Word 
"save as HTML" generate the right stuff - not something that translates 
from the native .DOCX file directly.

As Iljitsch noted, e.g., the current XML uses nested tags that Word has 
trouble generating. If we look more at what kind of stuff Word DOES 
generate, that's a hint at what might be feasible in Word.

(Not that this should drive the discussion, but if we can chose a format 
that isn't Word-hostile and it doesn't otherwise matter, I would hope we 
would)

See http://www.isi.edu/touch/pubs/tcp-ao-html/

Note - it already indents and reflows. Yes, it's still using fixed-width 
fonts, and also still uses ASCII diagrams. Ignore the colors - they're 
there as a helper for authors.

And yes, the HTML source is a mess; there ought to be a way to make it 
simpler, but I haven't looked at that yet.

Joe

Re: Proposed new RFC submission requirements

Joe Touch — 2012-05-24T20:53:00


On 5/24/2012 11:37 AM, Brian E Carpenter wrote:
...

The requirement for text allows multiple author formats. Allowing the 
current XML markup is an option because it allows xml2rfc-tools.

Forcing a particular markup has implications upstream for author tools. 
The markup chosen should be as agnostic to those tools as possible, and 
minimal to only those aspects the RFC Editor actually cares about.

I haven't seen a specific proposal for such a markup. I'll be glad to 
see if there's a way to support it in a modern word processor (e.g., MS 
Word) once there is.

Joe

Re: Proposed new RFC submission requirements

Joe Touch — 2012-05-24T20:49:40


On 5/24/2012 11:35 AM, Paul Hoffman wrote:
...

There has to be one canonical format. There does not have to be one 
input format for submission.

Joe