OpenJade PATCH(bugfix): extra spaces emitted by RTF backend (now with attachment)

["Andrey Taranov" <andrey@xxxxxxxxx>]

Hello, DSSSList

The following patch fixes a bug in RTF backend. It is obtained with:
    cvs diff -r jade_1_3 RtfFOTBuilder.cxx > extra-spaces.diff
while working on the jade_1_3_branch.

==============================================================
Problem description:

The RTF backend emits extra spaces into RTF output under some circumstances.
This sometimes visibly impairs the quality of MS Word printout. Actually,
there are two cases, when this happens, and these may be fixed independently
of each other.

*Case #1:
---------

Sometimes, a newline character and leading spaces of the next line (on SGML
input) do not collapse into one space on output. That is, considering places
where they really should. Instead, they collapse into exact 2 spaces.

**Cause/solution:

Leading spaces on a line (actually, leading spaces on call to
FOTBuilder::characters()) are ignored, when followWhitespaceChar_ is true
upon entry to RtfFOTBuilder::characters(). But it only remains true, if we
do not call RtfFOTBuilder::inlinePrepare() at this point -- so everything
goes Ok if inlineState_ is set to inlineMiddle. The bug occurs, when we come
to inlineState_==inlineFieldEnd. When such a line field ends,
RtfFOTBuilder::endLineField does not set inlineState_ back to inlineMiddle,
although it does so in case of a simple inlineField.

The patch fixes RtfFOTBuilder::endLineField().

*Case #2:
---------

This bug ALWAYS produces extra spaces. If a displayed block is embedded in
another displayed block, and the next source line after the inner block
begins with a space (i.e. is indented), then the RTF continuation para also
begins with a space character. Example: <orderedlist> embedded in a <para>
in DocBook produces one extra space at the beginning of the part of <para>
following the list.

I understand, that incorrectness of this behavior is arguable -- <para> in
DocBook has a mixed content model. But the RTF backend already ignores any
newline characters encountered at the place I described. Why shouldn't it
also ignore any spaces immediately following the newlines?

**Solution:

The patch fixes RtfFOTBuilder::characters(). It's meaning: if we handle a
continuation para, and if there were any newlines at the start of the data
(which are ignored by the current code), then also ignore any spaces
immediately after these newlines.

==================================================================

Index: RtfFOTBuilder.cxx
===================================================================
RCS file: /cvsroot/openjade/jade/jade/RtfFOTBuilder.cxx,v
retrieving revision 1.2
diff -r1.2 RtfFOTBuilder.cxx
1165a1166,1168
>       if (specFormat_.inputWhitespaceTreatment != symbolPreserve)
>               for (; n > 0 && *s == ' '; s++, n--)
>                       ;
2034c2037
<     inlineState_ = inlineMiddle;
---
>     
2035a2039
>   inlineState_ = inlineMiddle;

==================================================================

Regards,
Andrey Taranov,
Customized Information Systems,
Moscow, Russian Federation



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist