Issue 10569 - Search for formatted text sometimes doesn't work
Summary: Search for formatted text sometimes doesn't work
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1 RC2
Hardware: PC All
: P3 Trivial with 8 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
Depends on:
Reported: 2003-01-09 21:19 UTC by akrioukov
Modified: 2013-08-07 14:38 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

a sample macro, using search functionality (6.65 KB, application/octet-stream)
2003-01-09 21:20 UTC, akrioukov
no flags Details
Yet another testcase document for those who don't like macros. (5.37 KB, application/octet-stream)
2003-06-14 17:27 UTC, akrioukov
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description akrioukov 2003-01-09 21:19:07 UTC
I'm writing a text converter in Visual Basic, which uses search and replace
functionality, and can't make it work. I'll upload a sample file to make the
problem more clear.
Comment 1 akrioukov 2003-01-09 21:20:24 UTC
Created attachment 4259 [details]
a sample macro, using search functionality
Comment 2 akrioukov 2003-01-09 21:31:27 UTC
Now a comment for the uploaded file (search.sxw).

It contains some English text, formatted with Times New Roman, and a
simple macro, called "TestSearchReplace", which searches for all ASCII
symbols, formatted with Times New Roman, and changes them to the same
symbols, but formatted with Arial. Now do the following:

1) Run "TestSearchReplace" on this file (or any other text document).
You will see, that some symbols were converted, but some remained in
Times New Roman.

2) Try do the job of this macro manually, i.e. search for a text,
formatted with Times New Roman. OO reports that nothing was found,
while Times New Roman is visible in the document!

3) Save the file, for example, as MS Word document, then reopen it,
and save again as .sxw. Search again for a text, formatted with Times
New Roman. It works!

4) Now you can uncompress both .sxw documents and take a look at the
content.xml files. There are some remarcable differences in the xml

The problem was encountered both under Linux and Windows with 1.0.1
and 643C.
Comment 3 h.ilter 2003-01-15 16:43:27 UTC
Reassigned to SBA
Comment 4 akrioukov 2003-03-11 20:32:32 UTC
Sorry, I simply fixed a grammatical error in the issue description.
Comment 5 prgmgr 2003-06-14 16:05:42 UTC
Thank you for using OOo.

I can run a manual search and replace to change the font from Times
New Roman to Arial.

Perhaps you can use the API to grab all the text in the document and
use that for your search and replace key?
Comment 6 akrioukov 2003-06-14 17:25:57 UTC
Generally speaking, it is *very* easy to reproduce the problem even without 
using macros. For me the problem looks as follows: OOo can find a piece of 
formatted text only if it is immediately enclosed in its formatting tags. So 
inserting secondary formatting tags makes some formatted text invisible for 
search/replace engine. I'm going to upload another testcase document (created 
without macros, just with manual formatting); please, try to search for Times 
New Roman and Arial in it. 
And, of course, I have some alternate ways to implement search/replace 
functionality in my macros, but the resulting code will work much more slower. 
Using ReplaceDescriptor is the most natural (and the most correct) way for all 
replace operations, and it *must* work. 
I've changed the "version" field for this issue, since it is still not fixed in 1.1Beta. 
Comment 7 akrioukov 2003-06-14 17:27:30 UTC
Created attachment 6883 [details]
Yet another testcase document for those who don't like macros.
Comment 8 jack.warchold 2003-08-07 17:52:20 UTC
jw: changed owner to jw
changed status to confirmed -> new
changed version to OOo 1.1 RC2

reproducable on OOo 1.1 Rc2

select the last bugdoc
1. Open the bugdoc set the cursor at the beginning of the document
2. edit -> Find & Replace
3. click on "Attributes" check "Font" -> OK
4. select "Format" selct "Font" -> Times New Roman Select "Size" -> 12
5. In the Find&Replace dialog check "Including Styles"
6. Find
=> The text formated in times new roman will be seleced
7. repeat stepp 4 woith Font Courier New an go on wir 5 - 6
=> The Courier New will be found.
8. Click on "Find All" => all words formated in Courier new will be 
9. repeat all the steps between 4 and 6 with Arial => nothing happens

Comment 9 jack.warchold 2003-08-08 10:11:05 UTC
jw:changed owner to fme
Comment 10 frank.meies 2003-08-08 11:34:47 UTC
Comment 11 frank.meies 2003-09-10 11:18:24 UTC
Comment 12 stefan.baltzer 2003-10-13 11:08:08 UTC
SBA: According to the roadmap 
(see this issue was retargeted to 
"OOo Later".
Comment 13 Unknown 2003-10-13 17:07:07 UTC
I confirm this behavior in OOo 1.1 (RC5). "By hand" formatting is not 
a choice in a case of a big complex text. Macro seems to be a right 
way, but it doesn't work. "OOo Later" is too late for such issue.
Comment 14 akrioukov 2003-10-13 18:01:43 UTC
=> SBA: 
OOo Roadmap is too brief to understand why this issue was retargeted. It is not 
an enhancement or feature request, but real bug in OOo search/replace engine. 
And this bug is really serious, because any contemporary word processor allows 
searching for formatted text, while in OOo this functionality is simply not 
useable right now. 
Comment 15 frank.meies 2004-01-13 11:56:00 UTC
Comment 16 stefan.baltzer 2004-02-06 16:35:10 UTC
SBA: I understand that you have a problem with this behavior. A look in the
online help about Find and Replace tells that the current behavior was designed
to find only hard-set attributes:
Attribute: Choose the general text attributes that you want to search for. For
example, if you search for the Font attribute, only the instances of text that
do not use the default font style are found. 

I talked to developers and UserExperience team about this and we think that this
"designed behavior" is contrary to the user's expectations. So I won't flag this
one an "Enhancement".

Please note that this behavior is the same since at least StarOffice 5.2 (on
this code base OOo took off). Things that are in the product for "quite a while"
and NOT being detected/nagged about  by a lot of people get a lower priority.

Please believe that the developers at SUN are "far from bored" on our way
towards OOo 2.0/StarOffice 8.

On the other hand, if you find someone from the OOo community who is willing and
able to make the needed code changes, we will welcome all support from OOo
That's purpose of OOo and this is the only way to speed up "fulfilling
EVERYBODYs needs, dreams and wishes" without BUYING more developer ressources.
Comment 17 akrioukov 2004-02-07 10:18:46 UTC
=> SBA

Thank you for your explanation.

You are right, there is a problem with searching for text having the default
font formatting. I agree that this problem is not critical, although irritating,
and fixing it may be marked as an enhancement. I've even mentioned this problem
in some of my comments above and in my second testcase document.

However, the problem *this* issue deals with is really quite different. Please,
have a look at the first testcase document. Here we have some text with manually
applied font (Arial) and we are searching for this formatting. Also have a look
at my second testcase document: it illustrates both the problems, and the second
one is the most interesting. Here the default font is Times New Roman while we
are searching for fragments in Arial. They cannot be found simply because there
are some smaller text fragments in Courier New which break the paragraph
formatted in Arial. 

This means even searching for hard-set formatting attributes is broken, and
simply cannot be used right now, especially in any applications using the OOo
API. I think, nobody will assert that it is corect or OOo is designed to do so.

Of course I understand that there are not so many people supporting this issue
(although there are already 6 votes for it), but this is simply because one
should have basic knowledge of the API in order to be able to reproduce this
problem. However, I am sure there are enough people who miss important fragments
in their documents while searching for some specific formatting attributes even
without knowing it.
Comment 18 jack.warchold 2004-09-01 16:27:36 UTC
reassigend to fme. because he ist the developer for this
don't know why  akrioukov reassigned this back to sba