Subject: [xml2rfc] &nbsp;

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Oct 2013 17:17:42 -0600

The Tcl tool had support for &nbsp; to force the inclusion of spaces in
inline text. The Python tool does not. Is this a known issue? I see that
http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/40 was closed, but
it seems that only support for &wj; was added.

I can probably provide a patch if needed.

Peter

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 15 Oct 2013 09:52:42 +0200

Hi Peter,

On 2013-10-15 01:17 Peter Saint-Andre said:
> inline text. The Python tool does not. Is this a known issue?

Noo...; I actually thought it had that.  I don't think you'll find &nbsp;
in the xml2rfc python code (except for a couple of comments), but I thought
it would be caught and handled when the xml source was read by lxml.

Worth investigating.

> I see that

That would be appreciated.  I intend to start working on xml2rfc as soon
as I'm done handling the current agenda rendering emergency in the datatracker.

Best regards,

	Henrik

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Oct 2013 09:56:58 -0500

I tend to define the &nbsp; entity in my XML I-D sources.  Well,
actually, Julian's rfc2629-xhtml.ent does anyways, and I use that.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2013 17:01:46 +0200

> actually, Julian's rfc2629-xhtml.ent does anyways, and I use that.

That's not "mine".

Anyway: I'd really doesn't matter whether it's "&#160;", "&foobar;" 
(with foobar previously declared in the DTD), or a literal U+0160 code 
point; it all should have the same effect.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Oct 2013 10:08:10 -0500

>> actually, Julian's rfc2629-xhtml.ent does anyways, and I use that.

Ah, sorry.  Thanks for the correction.

> Anyway: I'd really doesn't matter whether it's "&#160;", "&foobar;" (with
> foobar previously declared in the DTD), or a literal U+0160 code point; it
> all should have the same effect.

Indeed.  But I like being able to use named entities in my I-D sources
(including those produced by lyx2rfc).

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2013 17:15:52 +0200

> (including those produced by lyx2rfc).

Yes. You can do that by either including the rfc2629.dtd, or by locally 
declaring it (see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#examples.internalsubset>).

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Oct 2013 10:28:44 -0500

> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#examples.internalsubset>).

Can the Python xml2rfc not just do that?  If it can, is there any reason not to?

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2013 17:31:33 +0200

> Can the Python xml2rfc not just do that?  If it can, is there any reason not to?

I have no idea how xml2rfc v2 works; I've never tried it.

Getting the character into the document is one thing (governed by XML). 
Making use of it when generating plain text is a completely different 
question.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Oct 2013 10:40:07 -0500

> Making use of it when generating plain text is a completely different

Ah, good point.  I was thinking of various entities, many of which
have no special semantics (e.g., &mdash;), but non-breaking spaces
have special semantics, so indeed, they have to be implemented by
xml2rfc proper.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Oct 2013 17:42:39 +0200

> have special semantics, so indeed, they have to be implemented by

Well, when producing plain text, xml2rfc needs to replace it by a ASCII 
character (or a sequence of ASCII characters).

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Oct 2013 09:50:55 -0600

> character (or a sequence of ASCII characters).

This seems to work for me on one computer but not another. I'll do some
more testing. Sorry about the noise.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/