From julian.reschke@gmx.de Fri Oct 1 05:12:14 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56AA3A6F43 for ; Fri, 1 Oct 2010 05:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.85 X-Spam-Level: X-Spam-Status: No, score=-104.85 tagged_above=-999 required=5 tests=[AWL=-2.251, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSbKMKbF3lUn for ; Fri, 1 Oct 2010 05:12:12 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id B83EA3A748D for ; Fri, 1 Oct 2010 05:10:29 -0700 (PDT) Received: (qmail invoked by alias); 01 Oct 2010 12:11:16 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.146]) [217.91.35.233] by mail.gmx.net (mp070) with SMTP; 01 Oct 2010 14:11:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18/15RkE5Q/HyWthUQDNsMIEqr+ZuHhjo6kZYshJt vxV3xtgSti0SuO Message-ID: <4CA5CFDC.2010200@gmx.de> Date: Fri, 01 Oct 2010 14:11:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Russ Housley References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> <4CA37E51.1060005@vigilsec.com> <4CA3964A.1030504@gmx.de> In-Reply-To: <4CA3964A.1030504@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 12:12:14 -0000 On 29.09.2010 21:40, Julian Reschke wrote: > On 29.09.2010 19:58, Russ Housley wrote: >> ... >> I see this a something that needs broader community discussion. We have >> several ways of generating HTML versions of RFCs, and the features that >> we get from rfcmarkup seem to be very useful for folks that read online. >> Obviously, offline reading is important too. >> >> Many eBook readers need paginated output. >> ... > > Sorry? ePub is just (X)HTML + metadata in a ZIP container. > ... In the meantime I realized that I may have misunderstood Russ. eBook readers indeed show paginated output, but AFAIK normally what get's delivered to them is ePub, which is a non-paginated format. Pagination happens on the device, and that's of course the right place to do that (unless everybody can agree on the page format and a font size). Best regards, Julian From ahagens@amsl.com Fri Oct 1 10:50:53 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481A23A6C80 for ; Fri, 1 Oct 2010 10:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=1.620, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1o2Ha5ZK+Bx for ; Fri, 1 Oct 2010 10:50:51 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 030AF3A6BB0 for ; Fri, 1 Oct 2010 10:50:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 0676CE08B1; Fri, 1 Oct 2010 10:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kysnj08aZP7F; Fri, 1 Oct 2010 10:51:39 -0700 (PDT) Received: from pirlt-01.pir.com (mail.pir.org [72.44.190.134]) by c1a.amsl.com (Postfix) with ESMTPSA id 2F160E0709; Fri, 1 Oct 2010 10:51:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Alice Hagens In-Reply-To: <4CA3ACBB.30900@att.com> Date: Fri, 1 Oct 2010 13:51:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <567C1E90-5445-4895-9EA2-36862770D01F@amsl.com> References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> <4CA39521.3080606@gmx.de> <4CA39E0E.5010202@att.com> <5C69EC65-216D-4989-AC3C-6D0E6CE1C8CE@amsl.com> <4CA3ACBB.30900@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1081) Cc: RFC Editor , RSE , xml2rfc-dev@ietf.org, Sandy Ginoza , Glenn Kowack Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 17:50:53 -0000 Tony, > Also, do you do any post processing on the nroff output? Yes. Details below. *Notes below indicate where changes in the XML file = can be used (instead of post-processing) to alter the text output as = needed (or partially as needed). This always involves: - replace the header with the 5741 header. - replace the Status of This Memo text with the RFC 5741 SoTM text = (http://www.rfc-editor.org/rfc-style-guide/status-memos.txt). - remove the hard page breaks and place them again (so figures and = reference entries are not broken across lines. *Note: needLines in the = XML does not handle all cases and does not have expected behavior.) - update the Table of Contents, if necessary. This sometimes involves: - remove extra blank lines before and/or after figures. (*Note: deleting blank lines inside figure elements in the XML handles = some cases.) - fix indentation of a list. (e.g., when hanging lists are used and hangIndent attribute is set above = a certain value, xml2rfc's nroff output sometimes is not consistent with = xml2rfc's text output. This seems to be a bug.) - tweak the format of references. (various oddities occur, e.g., when the title or seriesInfo elements do = not create the desired text output. specifically: an author has put data = in the seriesInfo name attribute (without using the value attribute), = then text is followed by [space][comma], so the space is removed. An = author does not want a title to appear inside quotation marks, but the = contents of the title element automatically enclosed in quotation marks, = so the quotation marks are removed.) *Note: authors and RFC Editor can = use the elements within the reference element to attempt to get the text = output correct. - move the line break(s) in a URL in a reference. (e.g., when xml2rfc breaks a long URL is across multiple lines or after = a "-", we place the line breaks 'nicely', so there are less line breaks = or it's after a "/") - move the line break in other text.=20 (e.g., if "BGP/MPLS" is broken across a line (where it shouldn't be, = e.g., title of a document). *Note: &wj; can be inserted in the XML to = prevent a line from breaking. - add a space after a period.=20 (when sentence ends with a capital letter (e.g., "node X.", "node A." = etc.) or the string "Bob." (and sometimes other odd strings), xml2rfc = inserts only one space after the period. If it is the end of the = sentence, we can insert   into the XML file to force an extra = space. However, if it's not caught until the later stage, we would add = the extra space during post-processing.) - fix indentation or the width of a figure. (when a figure is over 69 characters, xml2rfc decreases the 3-space = left-hand margin (i.e., shifts everything left), rather than letting the = figure run over the 72-character limit. If we spot this visually (our = automated check won't catch it because it's not over 72 chars), we can = see about shortening the figure.) For example, if there were 3 figures = in a row that should all line up (i.e., be indented the same amount), = when one figure has one line that is one character too long, the figure = is moved to the left, and no longer lines up with the other 2. > Do you need to use post processing filters that eliminate backspaces = or do other odd things? Nope. Please let us know if you have further questions. Thanks, Alice=20 On Sep 29, 2010, at 5:16 PM, Tony Hansen wrote: > Thanks for the confirmation Sandy. >=20 > This is going on a slight tangent to the other questions, but is = directly relevant to the question of the evolution of the xml2rfc = processor. >=20 > I'd really like to understand better the differences you encounter = using xml2rfc -> text vs xml2rfc -> nroff -> text. >=20 > Also, do you do any post processing on the nroff output? Do you need = to use post processing filters that eliminate backspaces or do other odd = things? >=20 > Tony >=20 > On 9/29/2010 4:51 PM, Sandy Ginoza wrote: >> Moving away from having an .nroff source file in the near future = seems like a bad idea, as the output looks very different depending on = whether you are using an .xml or .nroff source file. > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 From ahagens@amsl.com Fri Oct 1 10:56:32 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B00D3A6CD1 for ; Fri, 1 Oct 2010 10:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iySWTYKQzB4c for ; Fri, 1 Oct 2010 10:56:31 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 6BD763A6C80 for ; Fri, 1 Oct 2010 10:56:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 7500CE08B5; Fri, 1 Oct 2010 10:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh0x5eIT2iqV; Fri, 1 Oct 2010 10:57:20 -0700 (PDT) Received: from pirlt-01.pir.com (mail.pir.org [72.44.190.134]) by c1a.amsl.com (Postfix) with ESMTPSA id B018CE0709; Fri, 1 Oct 2010 10:57:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Alice Hagens In-Reply-To: <567C1E90-5445-4895-9EA2-36862770D01F@amsl.com> Date: Fri, 1 Oct 2010 13:57:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> <4CA39521.3080606@gmx.de> <4CA39E0E.5010202@att.com> <5C69EC65-216D-4989-AC3C-6D0E6CE1C8CE@amsl.com> <4CA3ACBB.30900@att.com> <567C1E90-5445-4895-9EA2-36862770D01F@amsl.com> To: Tony Hansen X-Mailer: Apple Mail (2.1081) Cc: RFC Editor , RSE , XML Developer List , Sandy Ginoza , Glenn Kowack Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 17:56:32 -0000 correction: I meant broken across pages. On Oct 1, 2010, at 1:51 PM, Alice Hagens wrote: > - remove the hard page breaks and place them again (so figures and = reference entries are not broken across lines. *Note: needLines in the = XML does not handle all cases and does not have expected behavior.) From tony@att.com Sat Oct 2 18:05:49 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7603A6E0D for ; Sat, 2 Oct 2010 18:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.385 X-Spam-Level: X-Spam-Status: No, score=-107.385 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuPETcjYRq3w for ; Sat, 2 Oct 2010 18:05:48 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id F0CD33A6E0A for ; Sat, 2 Oct 2010 18:05:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-11.tower-121.messagelabs.com!1286067998!44101976!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 31107 invoked from network); 3 Oct 2010 01:06:38 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2010 01:06:38 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9316t4n026921 for ; Sat, 2 Oct 2010 21:06:55 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9316qcV026899 for ; Sat, 2 Oct 2010 21:06:52 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9316Z0d016643 for ; Sat, 2 Oct 2010 21:06:35 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9316X8a016605 for ; Sat, 2 Oct 2010 21:06:33 -0400 Received: from [135.70.60.29] (vpn-135-70-60-29.vpn.west.att.com[135.70.60.29]) by maillennium.att.com (mailgw1) with ESMTP id <20101003010630gw100ei1b6e> (Authid: tony); Sun, 3 Oct 2010 01:06:32 +0000 X-Originating-IP: [135.70.60.29] Message-ID: <4CA7D715.40109@att.com> Date: Sat, 02 Oct 2010 21:06:29 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Alice Hagens References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> <4CA39521.3080606@gmx.de> <4CA39E0E.5010202@att.com> <5C69EC65-216D-4989-AC3C-6D0E6CE1C8CE@amsl.com> <4CA3ACBB.30900@att.com> <567C1E90-5445-4895-9EA2-36862770D01F@amsl.com> In-Reply-To: <567C1E90-5445-4895-9EA2-36862770D01F@amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: RFC Editor , RSE , xml2rfc-dev@ietf.org, Sandy Ginoza , Glenn Kowack Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 01:05:49 -0000 wow, I'm amazed. I hadn't realized there was so much post processing done even *after* nroff. Tony On 10/1/2010 1:51 PM, Alice Hagens wrote: > Tony, > > >> Also, do you do any post processing on the nroff output? >> > Yes. Details below. *Notes below indicate where changes in the XML file can be used (instead of post-processing) to alter the text output as needed (or partially as needed). > > This always involves: > > - replace the header with the 5741 header. > > - replace the Status of This Memo text with the RFC 5741 SoTM text (http://www.rfc-editor.org/rfc-style-guide/status-memos.txt). > > - remove the hard page breaks and place them again (so figures and reference entries are not broken across lines. *Note: needLines in the XML does not handle all cases and does not have expected behavior.) > > - update the Table of Contents, if necessary. > > This sometimes involves: > > - remove extra blank lines before and/or after figures. > (*Note: deleting blank lines inside figure elements in the XML handles some cases.) > > - fix indentation of a list. > (e.g., when hanging lists are used and hangIndent attribute is set above a certain value, xml2rfc's nroff output sometimes is not consistent with xml2rfc's text output. This seems to be a bug.) > > - tweak the format of references. > (various oddities occur, e.g., when the title or seriesInfo elements do not create the desired text output. specifically: an author has put data in the seriesInfo name attribute (without using the value attribute), then text is followed by [space][comma], so the space is removed. An author does not want a title to appear inside quotation marks, but the contents of the title element automatically enclosed in quotation marks, so the quotation marks are removed.) *Note: authors and RFC Editor can use the elements within the reference element to attempt to get the text output correct. > > - move the line break(s) in a URL in a reference. > (e.g., when xml2rfc breaks a long URL is across multiple lines or after a "-", we place the line breaks 'nicely', so there are less line breaks or it's after a "/") > > - move the line break in other text. > (e.g., if "BGP/MPLS" is broken across a line (where it shouldn't be, e.g., title of a document). *Note:&wj; can be inserted in the XML to prevent a line from breaking. > > - add a space after a period. > (when sentence ends with a capital letter (e.g., "node X.", "node A." etc.) or the string "Bob." (and sometimes other odd strings), xml2rfc inserts only one space after the period. If it is the end of the sentence, we can insert  into the XML file to force an extra space. However, if it's not caught until the later stage, we would add the extra space during post-processing.) > > - fix indentation or the width of a figure. > (when a figure is over 69 characters, xml2rfc decreases the 3-space left-hand margin (i.e., shifts everything left), rather than letting the figure run over the 72-character limit. If we spot this visually (our automated check won't catch it because it's not over 72 chars), we can see about shortening the figure.) For example, if there were 3 figures in a row that should all line up (i.e., be indented the same amount), when one figure has one line that is one character too long, the figure is moved to the left, and no longer lines up with the other 2. > > >> Do you need to use post processing filters that eliminate backspaces or do other odd things? >> > Nope. > > Please let us know if you have further questions. > > Thanks, > > Alice > > On Sep 29, 2010, at 5:16 PM, Tony Hansen wrote: > > >> Thanks for the confirmation Sandy. >> >> This is going on a slight tangent to the other questions, but is directly relevant to the question of the evolution of the xml2rfc processor. >> >> I'd really like to understand better the differences you encounter using xml2rfc -> text vs xml2rfc -> nroff -> text. >> >> Also, do you do any post processing on the nroff output? Do you need to use post processing filters that eliminate backspaces or do other odd things? >> >> Tony >> >> On 9/29/2010 4:51 PM, Sandy Ginoza wrote: >> >>> Moving away from having an .nroff source file in the near future seems like a bad idea, as the output looks very different depending on whether you are using an .xml or .nroff source file. >>> >> _______________________________________________ >> xml2rfc-dev mailing list >> xml2rfc-dev@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc-dev >> >> > From ahagens@amsl.com Sun Oct 3 14:19:35 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8383A6DC1 for ; Sun, 3 Oct 2010 14:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=1.099, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1syqp1g7WQQI for ; Sun, 3 Oct 2010 14:19:34 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id C3B0C3A6D97 for ; Sun, 3 Oct 2010 14:19:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id CF90FE08A3; Sun, 3 Oct 2010 14:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfDF37SfMMQ0; Sun, 3 Oct 2010 14:20:28 -0700 (PDT) Received: from rfc2.home (pool-173-73-54-24.washdc.fios.verizon.net [173.73.54.24]) by c1a.amsl.com (Postfix) with ESMTPSA id C93BDE0886; Sun, 3 Oct 2010 14:20:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Alice Hagens In-Reply-To: <4CA7D715.40109@att.com> Date: Sun, 3 Oct 2010 17:20:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> <4CA39521.3080606@gmx.de> <4CA39E0E.5010202@att.com> <5C69EC65-216D-4989-AC3C-6D0E6CE1C8CE@amsl.com> <4CA3ACBB.30900@att.com> <567C1E90-5445-4895-9EA2-36862770D01F@amsl.com> <4CA7D715.40109@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1081) Cc: RFC Editor , RSE , xml2rfc-dev@ietf.org, Sandy Ginoza , Glenn Kowack Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 21:19:36 -0000 Tony, > I hadn't realized there was so much post processing done even *after* = nroff. Perhaps to clarify (apologies if I misinterpreted the question): All the = changes described below are done *in* the nroff (output from xml2rfc). = We do not make any changes in the text file (generated from the nroff). Thanks, Alice On Oct 2, 2010, at 9:06 PM, Tony Hansen wrote: > wow, I'm amazed. I hadn't realized there was so much post processing = done even *after* nroff. >=20 > Tony >=20 > On 10/1/2010 1:51 PM, Alice Hagens wrote: >> Tony, >>=20 >> =20 >>> Also, do you do any post processing on the nroff output? >>> =20 >> Yes. Details below. *Notes below indicate where changes in the XML = file can be used (instead of post-processing) to alter the text output = as needed (or partially as needed). >>=20 >> This always involves: >>=20 >> - replace the header with the 5741 header. >>=20 >> - replace the Status of This Memo text with the RFC 5741 SoTM text = (http://www.rfc-editor.org/rfc-style-guide/status-memos.txt). >>=20 >> - remove the hard page breaks and place them again (so figures and = reference entries are not broken across lines. *Note: needLines in the = XML does not handle all cases and does not have expected behavior.) >>=20 >> - update the Table of Contents, if necessary. >>=20 >> This sometimes involves: >>=20 >> - remove extra blank lines before and/or after figures. >> (*Note: deleting blank lines inside figure elements in the XML = handles some cases.) >>=20 >> - fix indentation of a list. >> (e.g., when hanging lists are used and hangIndent attribute is set = above a certain value, xml2rfc's nroff output sometimes is not = consistent with xml2rfc's text output. This seems to be a bug.) >>=20 >> - tweak the format of references. >> (various oddities occur, e.g., when the title or seriesInfo elements = do not create the desired text output. specifically: an author has put = data in the seriesInfo name attribute (without using the value = attribute), then text is followed by [space][comma], so the space is = removed. An author does not want a title to appear inside quotation = marks, but the contents of the title element automatically enclosed in = quotation marks, so the quotation marks are removed.) *Note: authors = and RFC Editor can use the elements within the reference element to = attempt to get the text output correct. >>=20 >> - move the line break(s) in a URL in a reference. >> (e.g., when xml2rfc breaks a long URL is across multiple lines or = after a "-", we place the line breaks 'nicely', so there are less line = breaks or it's after a "/") >>=20 >> - move the line break in other text. >> (e.g., if "BGP/MPLS" is broken across a line (where it shouldn't be, = e.g., title of a document). *Note:&wj; can be inserted in the XML to = prevent a line from breaking. >>=20 >> - add a space after a period. >> (when sentence ends with a capital letter (e.g., "node X.", "node A." = etc.) or the string "Bob." (and sometimes other odd strings), xml2rfc = inserts only one space after the period. If it is the end of the = sentence, we can insert  into the XML file to force an extra space. = However, if it's not caught until the later stage, we would add the = extra space during post-processing.) >>=20 >> - fix indentation or the width of a figure. >> (when a figure is over 69 characters, xml2rfc decreases the 3-space = left-hand margin (i.e., shifts everything left), rather than letting the = figure run over the 72-character limit. If we spot this visually (our = automated check won't catch it because it's not over 72 chars), we can = see about shortening the figure.) For example, if there were 3 figures = in a row that should all line up (i.e., be indented the same amount), = when one figure has one line that is one character too long, the figure = is moved to the left, and no longer lines up with the other 2. >>=20 >> =20 >>> Do you need to use post processing filters that eliminate backspaces = or do other odd things? >>> =20 >> Nope. >>=20 >> Please let us know if you have further questions. >>=20 >> Thanks, >>=20 >> Alice >>=20 >> On Sep 29, 2010, at 5:16 PM, Tony Hansen wrote: >>=20 >> =20 >>> Thanks for the confirmation Sandy. >>>=20 >>> This is going on a slight tangent to the other questions, but is = directly relevant to the question of the evolution of the xml2rfc = processor. >>>=20 >>> I'd really like to understand better the differences you encounter = using xml2rfc -> text vs xml2rfc -> nroff -> text. >>>=20 >>> Also, do you do any post processing on the nroff output? Do you need = to use post processing filters that eliminate backspaces or do other odd = things? >>>=20 >>> Tony >>>=20 >>> On 9/29/2010 4:51 PM, Sandy Ginoza wrote: >>> =20 >>>> Moving away from having an .nroff source file in the near future = seems like a bad idea, as the output looks very different depending on = whether you are using an .xml or .nroff source file. >>>> =20 >>> _______________________________________________ >>> xml2rfc-dev mailing list >>> xml2rfc-dev@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc-dev >>>=20 >>> =20 >> =20 >=20