I have a use-case where this defect has caused considerable trouble. My task was
very simple. A non-technical manager developed a variable length form using MS
Word. Some of the content of the form will be modified three times a year by the
manager. There are 10 blank areas at the end of the form where the person
receiving the form will type in several paragraphs of text. In addition to the
three times a year customization, the manager customizes each instance of the
form by filling in six fields at the top of the form with information that
defines the status of a specific item that is to be reviewed by the person
filling out the remainder of the form. There are over 100 unique forms emailed
to reviewers for each meeting. The fields for the form will be defined in a
spreadsheet.
I wrote a short Python script to do the text substitution using the UNO API. I
put substitution strings, e.g. $SchoolName and $Reviewer, where I wanted the
content to be replaced. It took about 30 minutes to write and it worked great.
It took the script about three minutes to generate all 100+ forms. Each form was
in a file with a unique name as defined by the manager.
The top of the form looks like a typical old fashioned data gathering form that
could have been typed on a typewriter. Each field is preceded by a text
description and the area where the field is to be filled in is a blank line on
which the text was to be written. The form will be filled out using MS Word so
the blank line that is suppose to have the custom content is just a string of
spaces written with the underline attribute turned on. In MS Word the line will
be drawn to the end of the text area on the page even if there are more spaces
than will fit in that space.
The underlined spaces for the fields at the end of the line do not work the same
in OpenOffice Writer. If the underlined spaces would fit in the space available
then the line is drawn. If there are too many underlined spaces the underline
disappears. (Actually, there will be one space underlined following the text.)
The trouble I encountered with this bug made it look like the form substitution
script was not working consistently. The underlined spaces following text at the
end of a line disappeared on some of the forms. The appearance depended on the
length of the substituted text. A short string would fit, but if the substituted
string was too long the trailing underlined spaces disappeared. My 30 minutes
script writing exercise turned into hours as I tried to track down the cause of
the disappearing line.
Oddly, the trailing blank line did appear when the forms were opened by MS Word.
I could use my script, in spite of the defect in Writer, but I wasted quite a
bit of time because of a defect in how Writer handles underlined spaces that
extend past the end of the text area.
I have a use-case where this defect has caused considerable trouble. My task was
very simple. A non-technical manager developed a variable length form using MS
Word. Some of the content of the form will be modified three times a year by the
manager. There are 10 blank areas at the end of the form where the person
receiving the form will type in several paragraphs of text. In addition to the
three times a year customization, the manager customizes each instance of the
form by filling in six fields at the top of the form with information that
defines the status of a specific item that is to be reviewed by the person
filling out the remainder of the form. There are over 100 unique forms emailed
to reviewers for each meeting. The fields for the form will be defined in a
spreadsheet.
I wrote a short Python script to do the text substitution using the UNO API. I
put substitution strings, e.g. $SchoolName and $Reviewer, where I wanted the
content to be replaced. It took about 30 minutes to write and it worked great.
It took the script about three minutes to generate all 100+ forms. Each form was
in a file with a unique name as defined by the manager.
The top of the form looks like a typical old fashioned data gathering form that
could have been typed on a typewriter. Each field is preceded by a text
description and the area where the field is to be filled in is a blank line on
which the text was to be written. The form will be filled out using MS Word so
the blank line that is suppose to have the custom content is just a string of
spaces written with the underline attribute turned on. In MS Word the line will
be drawn to the end of the text area on the page even if there are more spaces
than will fit in that space.
The underlined spaces for the fields at the end of the line do not work the same
in OpenOffice Writer. If the underlined spaces would fit in the space available
then the line is drawn. If there are too many underlined spaces the underline
disappears. (Actually, there will be one space underlined following the text.)
The trouble I encountered with this bug made it look like the form substitution
script was not working consistently. The underlined spaces following text at the
end of a line disappeared on some of the forms. The appearance depended on the
length of the substituted text. A short string would fit, but if the substituted
string was too long the trailing underlined spaces disappeared. My 30 minutes
script writing exercise turned into hours as I tried to track down the cause of
the disappearing line.
Oddly, the trailing blank line did appear when the forms were opened by MS Word.
I could use my script, in spite of the defect in Writer, but I wasted quite a
bit of time because of a defect in how Writer handles underlined spaces that
extend past the end of the text area.