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

Henrik Levkowetz <> Thu, 01 March 2012 11:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2C7721F86C1 for <>; Thu, 1 Mar 2012 03:32:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m+9NnStAS5IN for <>; Thu, 1 Mar 2012 03:32:56 -0800 (PST)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 388FC21F86BE for <>; Thu, 1 Mar 2012 03:32:56 -0800 (PST)
Received: from [2a01:3f0:1:0:21e:c2ff:fe13:7e3e] (port=60165 by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from <>) id 1S34Fi-00051S-KI; Thu, 01 Mar 2012 12:32:54 +0100
Message-ID: <>
Date: Thu, 01 Mar 2012 12:32:54 +0100
From: Henrik Levkowetz <>
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: Robert Sparks <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on
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 11:32:56 -0000

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.
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,