Subject: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New Section 2.20.4, "indent" Attribute

From: [email-masked]
Date: Mon, 01 Oct 2018 04:36:25 -0700

This captures an issue noted during implementation, also described in
https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation#section-3.1.4

---
New Section 2.20.4, "indent" Attribute

   The deprecation of the "hangIndent" attribute on <list> leaves no
   opportunity to control the size of the hanging indent.  In some
   definition lists, it is desirable to have a wide indentation, in order
   to clearly show the terms, in other cases it is more important to allow
   for a larger text volume than the width of the terms would allow.

   Recommendation:  Add an "indent" attribute on <dl> to control the size
                    of the hanging indent.

   Implementation:  The current version of xml2rfc does not support the
                    attribute, but has all the underlying functions needed
                    to apply such an attribute.  Internally, an indentation
                    is calculated based on length of the <dt> text and the
                    settings of some of the other attributes.
---

Regards,
	Henrik

---
This issue is tracked at:
   https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/39

Discussion should take place on this list.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Oct 2018 14:09:18 +0200

On 10/1/2018 1:36 PM, [email-masked] wrote:
> ...

I agree that this would be useful - however we'll need to define it in a 
way that works well with non-monospaced fonts.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 1 Oct 2018 14:39:47 +0200

Hi Julian,

> way that works well with non-monospaced fonts.

Agreed.

What about specifying indentation as a number that would indicate characters
in monospaced output, and en-space otherwise?

Best,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Oct 2018 15:05:34 +0200

> in monospaced output, and en-space otherwise?

Works for me.

Best regards, Julian

---

From: Jim Schaad <[email-masked]>
Date: Tue, 2 Oct 2018 20:14:19 -0700

> -----Original Message-----
> From: xml2rfc-dev <[email-masked]> On Behalf Of Julian
> Reschke
> Sent: Monday, October 1, 2018 6:06 AM
> To: Henrik Levkowetz <[email-masked]>; [email-masked]
> Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC 7991, New
> Section 2.20.4, "indent" Attribute
> 
> >> I agree that this would be useful - however we'll need to define it
> >> in a way that works well with non-monospaced fonts.
> >
> > Agreed.
> >
> > What about specifying indentation as a number that would indicate
> > characters in monospaced output, and en-space otherwise?
> 
> Works for me.

+1
Jim

> 
> Best regards, Julian
> 
> _______________________________________________
> xml2rfc-dev mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 7 Oct 2018 16:14:07 +0200

I propose closing this ticket with the following resolution:

Add an attribute "indent" to <dl>, signifying the character indentation
in monospace rendering, and the indentation measured in en-space [1] units
in other renderings.

If there are no objections to the resolution by EOB Monday, I'll close the
ticket.  

With respect to document text, I propose the following new text under
Section 2.20. <dl>:

---
2.20.4.  "indent" Attribute

   Indicates the indentation to be used for the second and following
   lines of item rendering (the first line starts with the term, and
   is not indented).  The indentation is to be interpreted as characters
   for monospace renderings, and en-space units when using proportional
   fonts.  One en-space is assumed to be the length of 0.5 em-space in
   CSS units.

---

[1] https://en.wikipedia.org/wiki/En_(typography)

Best regards,

	Henrik

---

From: Jim Schaad <[email-masked]>
Date: Sun, 7 Oct 2018 08:10:40 -0700

> From: xml2rfc-dev <[email-masked]> On Behalf Of Henrik
> Levkowetz
> Sent: Sunday, October 7, 2018 7:14 AM
> To: [email-masked]
> Add an attribute "indent" to <dl>, signifying the character indentation in
> monospace rendering, and the indentation measured in en-space [1] units in
> other renderings.
> 
> If there are no objections to the resolution by EOB Monday, I'll close the ticket.
> 
> With respect to document text, I propose the following new text under Section
> 2.20. <dl>:
> 
> ---

I think it would be fine just to use em rather than en.  Also I don't think that the text needs to be written as different between monospace and proportional fonts.  The width of an em is going to be font specific and is equal to a character width for monospace.  If you don't do the 0.5 but just use em to start with then everything is consistant.

Jim

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 7 Oct 2018 17:18:06 +0200

Hi Jim,

On 2018-10-07 17:10, Jim Schaad wrote:
> I think it would be fine just to use em rather than en. Also I don't
> think that the text needs to be written as different between
> monospace and proportional fonts. The width of an em is going to be
> font specific and is equal to a character width for monospace. If you
> don't do the 0.5 but just use em to start with then everything is
> consistant.

The reason I expressed this in en-space is that as a rule of thumb, the
average character width in a proportional font is 1 en.  If we apply the
indent figure as number of em-spaces, the visual impression will be a
much larger indentation when using proportional fonts than for monospaced
fonts.

Best regards,

	Henrik

---

From: Jim Schaad <[email-masked]>
Date: Sun, 7 Oct 2018 13:15:55 -0700

> From: Henrik Levkowetz <[email-masked]>
> Sent: Sunday, October 7, 2018 8:18 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> >> Subject: Re: [xml2rfc-dev] RFC 7991 issue #39: Schema Issue, RFC
> >> 7991, New Section 2.20.4, "indent" Attribute
> >>
> >> Add an attribute "indent" to <dl>, signifying the character
> >> indentation in monospace rendering, and the indentation measured in
> >> en-space [1] units in other renderings.
> >>
> > think that the text needs to be written as different between monospace
> > and proportional fonts. The width of an em is going to be font
> > specific and is equal to a character width for monospace. If you don't
> > do the 0.5 but just use em to start with then everything is
> > consistant.
> 
> The reason I expressed this in en-space is that as a rule of thumb, the average
> character width in a proportional font is 1 en.  If we apply the indent figure as
> number of em-spaces, the visual impression will be a much larger indentation
> when using proportional fonts than for monospaced fonts.

My worry is that this means that trying to get the value right in css is going to based on if the current paragraph is using a mono-space font (n * em) or a proportional font ( n / 2 * em).   For some places a mono-space font is going to be more readable and you are now getting different displays.

I understand what you are saying, I am just not too sure if it is going to be the correct answer in all cases.

Jim

> >> >>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementa
> >> >>> tio
> >> >>> n#section-3.1.4
> >> >>>
> >> >>> ---
> >> >> I agree that this would be useful - however we'll need to define
> >> >> it in a way that works well with non-monospaced fonts.
> >> >
> >> > Agreed.
> >> >

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Oct 2018 20:20:26 +0000

> much larger indentation when using proportional fonts than for monospaced

This makes sense, but the reason I proposed using the em unit earlier is that em is defined in CSS, but (I'm pretty sure) en is not. This would make the HTML much easier to render directly, I think.

--Paul Hoffman

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 7 Oct 2018 22:26:23 +0200

n 2018-10-07 22:15, Jim Schaad wrote:
> My worry is that this means that trying to get the value right in css
> is going to based on if the current paragraph is using a mono-space
> font (n * em) or a proportional font ( n / 2 * em). For some places a
> mono-space font is going to be more readable and you are now getting
> different displays.

Ah.  Ok, got you.  What about this, then:

---

   Indicates the indentation to be used for the second and following
   lines of item rendering (the first line starts with the term, and
   is not indented).  The indentation is to be interpreted as characters
   in text/plain rendering, and en-space units when using renderings
   with richer typographic support, such as html or pdf.  One en-space is
   assumed to be the length of 0.5 em-space in CSS units.
---

> 
> I understand what you are saying, I am just not too sure if it is
> going to be the correct answer in all cases.

Ack.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 7 Oct 2018 22:33:48 +0200

On 2018-10-07 22:20, Paul Hoffman wrote:
> This makes sense, but the reason I proposed using the em unit earlier
> is that em is defined in CSS, but (I'm pretty sure) en is not. This
> would make the HTML much easier to render directly, I think.

I understand, but I think I covered this in both my first (and second,
just now) proposal.  

---

The reason to use en-space is to get a comparable rendering.  Equating
one character step with an em-space results in very different renderings.
Using steps of 0.5em in CSS is trivial.

If it makes you happier, we could change the text above to say

   ... the length 0.5em in CSS units.

	Henrik

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Oct 2018 21:18:46 +0000

>   ... the length 0.5em in CSS units.

Yes, giving the unit as ems would make it more definitive.

--Paul Hoffman

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 7 Oct 2018 23:54:32 +0200

> Yes, giving the unit as ems would make it more definitive.

Ok.

	Henrik

---

From: Jim Schaad <[email-masked]>
Date: Sun, 7 Oct 2018 16:18:56 -0700

> Sent: Sunday, October 7, 2018 1:26 PM
> >> >> From: xml2rfc-dev <[email-masked]> On Behalf Of
> >> >> Henrik Levkowetz
> >> >> indentation in monospace rendering, and the indentation measured
> >> >> in en-space [1] units in other renderings.
> >> >>
> >> >> With respect to document text, I propose the following new text
> >> >> under Section 2.20. <dl>:
> >> >>
> >> >> ---
> >> > I think it would be fine just to use em rather than en. Also I
> >> > don't think that the text needs to be written as different between
> >> > font specific and is equal to a character width for monospace. If
> >> > you don't do the 0.5 but just use em to start with then everything
> >> > is consistant.
> >>
> >> The reason I expressed this in en-space is that as a rule of thumb,
> >> the average character width in a proportional font is 1 en.  If we
> >> apply the indent figure as number of em-spaces, the visual impression
> >> will be a much larger indentation when using proportional fonts than for
> monospaced fonts.
> >

It took me twice to figure out what was different, but yes I think that this works just fine.  

Jim

> >> >> >>>     Recommendation:  Add an "indent" attribute on <dl> to
> >> >> >>> control the
> >> size
> >> >> >>>                      of the hanging indent.
> >> >> >>>
> >> >> >> I agree that this would be useful - however we'll need to
> >> >> >> define it in a way that works well with non-monospaced fonts.
> >> >> >
> >> >> > Agreed.
> >> >> >
> >> >> > What about specifying indentation as a number that would
> >> >> > indicate characters in monospaced output, and en-space otherwise?
> >> >>
> >> >
> >> >
> >> >
> >
> >
> >

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Oct 2018 07:22:10 +0200

On Oct 7, 2018, at 17:10, Jim Schaad <[email-masked]> wrote:
> 
> an em is going to be font specific

One em is the nominal point size, which is approximately the character height plus minimal (“1.0 space”) leading.

> and is equal to a character width for monospace

I don’t think so (except for square fonts such as for fullwidth Hanzi).

Grüße, Carsten

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 8 Oct 2018 11:08:52 +0200

On 2018-10-08 07:22, Carsten Bormann wrote:
> One em is the nominal point size, which is approximately the
> character height plus minimal (“1.0 space”) leading.
> 

I agree with this, but Jim nevertheless found an issue with the proposed
text, which I believe the subsequent reformulation avoids.

Best regards,

	Henrik