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

[Henrik Levkowetz <[e-mail]>]

Hi Robert,

On 2012-03-01 16:40 Robert Sparks said:
> 
> 
> On 3/1/12 5:32 AM, Henrik Levkowetz wrote:
>> 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.
> 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.

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

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

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

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.

> 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?

That should be quite easy to accomplish.

> 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/>

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

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