Subject: Re: [iola-conversion-tool] Trimming Whitespace from the beginning of DISCUSS and COMMENT

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 01 Mar 2012 12:32:54 +0100

Hi Russ, Robert,

I've entered this into the issue tracker as #781:
  http://trac.tools.ietf.org/tools/ietfdb/ticket/781

On 2012-02-28 22:03 Robert Sparks said:
> I agree with a first step of getting closer to where we were.
> 
> That said, prior to conversion, the reflow mechanics, particularly when 
> preparing email, have been
> consistently in my way. Can we move to something that performs reflow by 
> default, but allows us
> to turn it off and provide our own formatting when it's the best way to 
> get the information across?

That should be possible, but may move the re-flowing operation from
entry to presentation, where I believe we have it now, in order to not
mess with what's entered into the database.

Can you give me some examples of where reflowing is messing things up?

If re-flowing is only applied for very long lines and on presentation,
then anything you enter with proper formatting should be left alone.
I'll check the code to see if this is the way it's being handled now.

> RjS
> 
> On 2/28/12 2:58 PM, Russ Housley wrote:
>> Prior to the conversion, an AD entering text in the discuss or
>> comment box had greater control over the formatting.  The new form
>> seems to trim whitespace from the front of the provided text.

Ok; we should check whether this is done on entry or at presentation
time -- do you have an example to look at?

Best regards,

	Henrik

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Mar 2012 10:19:50 -0500

> time -- do you have an example to look at?

NEW: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-lr/ballot/

OLD: https://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ballot/

Russ

---

From: Robert Sparks <[email-masked]>
Date: Thu, 01 Mar 2012 09:40:17 -0600

On 3/1/12 5:32 AM, Henrik Levkowetz wrote:
> then anything

> you enter with proper formatting should be left alone.
What do you mean by proper formatting? What formatting is improper?
I really would like to have the option to make the presentation leave 
what I've
sent alone - full stop. I would also like the option to let the 
presentation have
its way with my layout.

We have conflicting requirements. Some folks want to use tools that produce
long-line form paragraphs and want the presentation to do line breaks. Some
folks want to use tools that introduce line breaks for them. Depending 
on what
kind of discuss I'm preparing I different ones, so I get poor results 
with anything
that chooses just one behavior.

In lieu of that, maybe we could get a preview option showing what the 
presentation
code is going to do so we have a chance to work around it if we need to?

Here's an example where the current behavior and what I entered interact 
badly
for the web presentation.

<https://datatracker.ietf.org/doc/draft-ietf-pcp-base/ballot/>

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 01 Mar 2012 18:51:00 +0100

Hi Robert,

> What do you mean by proper formatting? What formatting is improper?

What I meant here with 'proper' was, I guess something incorporating
both the idea that you had taken care with the formatting, and that
it was in a form that could be used both for email and on web pages
without touching it.

> sent alone - full stop. I would also like the option to let the 

Understood.  I'm trying to find out which paths are possible and workable
to achieve that.

> on what kind of discuss I'm preparing I different ones, so I get poor
> results with anything that chooses just one behavior.

Mmm.  Ok.  I see the problem.

To handle this, it seems like we then need either an in-channel or
out-of-channel indication of formatting type, because the two options
really can't be handled cleanly by guessing (which is what we have to
do currently).  That of course would let us support anybody's choice
of formatted plaintext, flowed plaintext, html, various wiki markups,
markdown, restructured-text, and whatnot.

> presentation code is going to do so we have a chance to work around it
> if we need to?

That should be quite easy to accomplish.

> <https://datatracker.ietf.org/doc/draft-ietf-pcp-base/ballot/>

Right.  Here you actually would have been best off with the ability to
have paragraphs handled as flowed, but the ascii-art handled as pre-
formatted text.

Ok, this increased my understanding of the problem.  I think for the
future, in order to be able to support mixed flowed/formatted text,
we need to support some kind of markup language.

Best regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 01 Mar 2012 18:52:41 +0100

> On Mar 1, 2012, at 6:32 AM, Henrik Levkowetz wrote:

...

> OLD: https://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ballot/

Ah.  I get it.  Thanks.

	Henrik

---

From: Ole Laursen <[email-masked]>
Date: Thu, 1 Mar 2012 21:30:14 +0100

> OLD: https://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ballot/

Right. sorry about that!

It's trying to guard against an empty looking but actually
white-spacing containing comment being considered a comment even
though it's empty. But if I change it so it only removes white space
from the end instead of from both ends, I guess we're good.

Ole

---

From: Ole Laursen <[email-masked]>
Date: Fri, 2 Mar 2012 14:58:55 +0100

2012/3/1 Henrik Levkowetz <[email-masked]>:
>> badly for the web presentation.
>>

I can't help wondering if one could handle this particular case with a
smarter paragraph detector. If we could see that the first paragraph
is an ordinary text paragraph, then we could ignore the newlines in it
and get a perfect reflow. I don't know if this is wishful thinking,
though.

Ole