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

Robert Sparks <> Thu, 01 March 2012 15:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0DEB21E80B8 for <>; Thu, 1 Mar 2012 07:40:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.531
X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1kdczJm74WDA for <>; Thu, 1 Mar 2012 07:40:18 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 361F921E808C for <>; Thu, 1 Mar 2012 07:40:18 -0800 (PST)
Received: from unexplicable.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q21FeGuB082239 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 09:40:17 -0600 (CST) (envelope-from
Message-ID: <>
Date: Thu, 01 Mar 2012 09:40:17 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Henrik Levkowetz <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Subject: Re: [iola-conversion-tool] Trimming Whitespace from the beginning of DISCUSS and COMMENT
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Mar 2012 15:40:18 -0000

On 3/1/12 5:32 AM, Henrik Levkowetz wrote:
> Hi Russ, Robert,
> I've entered this into the issue tracker as #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.
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 
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 
for the web presentation.


> 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