Issue 104107 - Add option to combine identical entries and keys to one entry
Summary: Add option to combine identical entries and keys to one entry
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: formatting (show other issues)
Version: OOO310m11
Hardware: PC Windows XP
: P3 Trivial with 12 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-08 19:58 UTC by ramonsdk
Modified: 2013-02-07 22:33 UTC (History)
3 users (show)

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


Attachments
Entry not combined (105.02 KB, application/vnd.oasis.opendocument.text)
2009-08-10 23:54 UTC, ramonsdk
no flags Details
A small sample (10.16 KB, application/vnd.oasis.opendocument.text)
2009-08-11 23:23 UTC, eric.savary
no flags Details
example1 (234.70 KB, image/png)
2010-06-28 09:30 UTC, giovannibattista
no flags Details
example2 (673.81 KB, image/png)
2010-06-28 09:31 UTC, giovannibattista
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ramonsdk 2009-08-08 19:58:15 UTC
A) Steps to take
1. Enable index option "Combine identical entries" without any sub-options selected
1. Add an entry for an index
2. Add another entry using the previous entry as first key
3. Add more entries of the same kind as well as simple entries without sub-entries
4. Update the index

B) What happens
The index entries for an entry with sub-entries appears as such (spacing is
displayed wrongly here, but is correct in index):
Graphical User Interface	175
Graphical User Interface	
    Context free help	15
    Context-sensitive help	13
    Label	11

C) What should happen
Should combine entry / 1st key of sub-entries properly so that it looks like this:
Graphical User Interface	175
    Context free help	15
    Context-sensitive help	13
    Label	11

D) Additional Notes
Sometimes the problem can be eliminated by removing the first sub-entry, adding
it back in, and then updating the index. After adding a few more index entries
and updating the index again the problem is back. This makes using the index
close to unusable.
Comment 1 eric.savary 2009-08-10 21:58:11 UTC
Please attach a sample document.
Comment 2 ramonsdk 2009-08-10 23:10:22 UTC
I will see if I can recreate this is a new document. The document I encountered
this in is a book soon to be published. I don't want to post that here and would
only give it out after a person signs an NDA - sorry, to both sides I guess.
I'll report back.
Comment 3 ramonsdk 2009-08-10 23:54:20 UTC
Created attachment 64050 [details]
Entry not combined
Comment 4 ramonsdk 2009-08-10 23:59:48 UTC
OK, see the attachment. I was able to recreate this bug (and also another one)
in this sample document. The contents are just rubbish. Some text copied in over
and over and a copy and paste from the forums web site pasted in a few times to
get a lot of diverse content.
In the index in the back look under "A". You will see that "Awesome" is listed
twice, one with page number as single entry and one without page number as 1st
key for some sub-entries. It should appear like entry "Some".

PS: That "Awesome" is where it broke is just coincidence, I didn't try to be funny.
Comment 5 eric.savary 2009-08-11 23:23:53 UTC
Created attachment 64078 [details]
A small sample
Comment 6 eric.savary 2009-08-11 23:58:19 UTC
It's not so easy to understand but I'll try to explain why it's not a bug...

Sum up: this happens when a key has the same string as an entry.

Have a look at my attached document:
Apple..................3
Fruit................2,3
Fruit..................
     Apple.............2
     Peach.............2
     Pear..............2
Peach..................3
Pear...................3

Why?

Because the first entry for fruit "Fruit................2,3" represents an entry
without key located on page 2 an 3.

The second "Fruit.................." is only a key which only applies for
entries on page 2. So it is handled separately.

Just set a key "fruit" to the entry "fruit" on page 3 and the lonly entry gets
merged with the key. The index looks at is should.

Conclusion: don't forget keys to words which already have one.
Comment 7 eric.savary 2009-08-11 23:58:34 UTC
closed
Comment 8 ramonsdk 2009-08-12 00:42:44 UTC
So if I want to combine fruit....2,3 with the other fruit entry I have to enter
"fruit" as keyword and "fruit" as 1st key?
In that case I still think it is a bug. Who on earth would consider current
behaviour as correct? It doesn't make any sense.

I'll keep the bug as closed/invalid for now to try out the workaround. If it
works this issue will have a lower priority. I still think it is broken.
Comment 9 ramonsdk 2009-08-12 02:53:48 UTC
OK, I spend way more time than I should on trying to figure out how to get it
the way it should be.
It basically boils down to making entry and 1st key to be the same word (as in
the second sample document)
or
entering only a 1st key without entry filled in.

So rather than
Apple..................3
Fruit................2,3
Fruit..................
     Apple.............2
     Peach.............2
     Pear..............2
Peach..................3
Pear...................3

I now get this:
Apple..................3
Fruit..................
     Fruit...........2,3
     Apple.............2
     Peach.............2
     Pear..............2
Peach..................3
Pear...................3

In no way is either result anywhere near anything the vast majority of users
would understand as "Combine identical entries". The entries are in fact
identical and do not get combined. 
Looking at the sample document from es it is so that both entries for "fruit"
have "fruit" as 1st key, the approach that is proposed to take, but it doesn't work.
I'd agree to lowering the priority if there is a reliable workaround. I know
this isn't the place for tutorials, but the forums didn't give anything. I'll
try posting in the advanced forum. Sorry for being a pain about this, but this
is broken.
Comment 10 eric.savary 2009-08-13 01:09:31 UTC
@OS: please give a statement about what follows...

- Provided I have *several times* words in my text like "Fruit" and "Apple"
- I set every "apple" as an index entry without key. I might have:

Apple........1,4,5 (or "Apple........1,4pp" depending on the index settings)

- If I apply to every "apple" a key which I call "fruit", I will have:

Fruit...........
   Apple........1,4,5

(Please note that "fruit" has no page reference because it is, at this step, a
key, a category which has been freely invented without existing in the text *as
entry*)

- Now I a am marking 1 occurrence of the word "fruit" in the text as an index
entry, I will get:

Fruit...........1
Fruit...........
   Apple........1,4,5

Because the first "fruit" is an *entry*, existing int the text but the second
"fruit" is a key, freely invented. Those are 2 different things = different
entries which are not grouped.

- Now I select one of the "apple" entries and I delete its "fruit" key, I will get

Apple...........5
Fruit...........1
Fruit...........
   Apple........1,4

Because 1 "apple" has now no key, no category but 2 other ones have a category
(page 1 and 4)

Sum up: this trouble is caused by a user error, a user who is not consistent
with himself. He gives keys to a word but sometimes forgets to set that key for
other occurrences of THIS word.

The meaning of "identical" in "Combine identical entries" is that a KEY is not
an ENTRY (main word) so entries and keys are handled separately.
This creates sometimes 1 "Fruit" (as an *entry*) AND 1 "Fruit" as a key.

Comparison: I f you call your dog "Dog", don't complain about that the word
"dog" appears 2 times on the veterinarian patient card (one at "Name" and 1 time
as "species"). 
Comment 11 eric.savary 2009-08-13 01:10:02 UTC
closed
Comment 12 ramonsdk 2009-08-13 02:06:26 UTC
So, it works the way it does because one "Fruit" is a key and the other one is
an entry? But there is no way right now to achieve what I want to do. If I key
the keyless entries they right fully so appear as sub-entries. If I only specify
a key without an entry (which is kinda stupid) it is handled as if it is a
keyless entry.
I reject the notion that this is purely user error. The desired effect cannot be
achieved with current functionality. "es" explained in great detail every case
except the one I am looking for, which makes me believe that there is currently
no way to make Writer do what I expect it to do. I am still open to be shown
otherwise.
I did change the Summary entry to use the correct terminology.

I open this one again, but begrudgingly classify it as a feature enhancement
just so that it gets addressed eventually. In the current form the indexing is
of limited use.
I propose to have an additional option added that combines identical keys and
entries to one entry. Any entries keyed with a key identical to the entry will
be listed as sub-entries under that key.

Example:
Entry "Fruit" is on pages 2 and 3.
Entry "Apple" with key "Fruit" is on page 4.
Entry "Orange" with key "Fruit" is on page 5.

Index that results with option checked is as follows:
Fruit...............2,3
     Apple............4
     Orange...........5
Comment 13 michael.ruess 2009-08-13 06:33:31 UTC
Reassigning RFE to requirements.
Comment 14 iaincc 2009-12-18 20:25:06 UTC
The Openoffice.org 3 Writer Guide  Page 394 states this facility is already LIVE
Issue 107746 was closed saying the help doc only allows consecutive pages to be
consolidated  (THAT IS NOT THE REQUIRED PERFORMANCE + does not meet that spec !)
M$Word provides indexers with ranges so OO must be able to do the same !!!!
Comment 15 giovannibattista 2010-06-28 09:30:19 UTC
Created attachment 70252 [details]
example1
Comment 16 giovannibattista 2010-06-28 09:31:44 UTC
Created attachment 70253 [details]
example2
Comment 17 giovannibattista 2010-06-28 09:38:02 UTC
I carefully read all comments.
"ramonsdk" want to use the keys as a "small title" for a group of index entries.
This is wrong (IMHO) and It is the fault of bad teachers!
http://www.openoffice.org/nonav/issues/showattachment.cgi/70252/BAD.PNG

However, I believe this error arises from a misunderstanding: 
- The desire to highlight a group of similar index entries.

Indeed in some indices the entries are grouped according to this scheme:
http://www.openoffice.org/nonav/issues/showattachment.cgi/70253/INDEX.PNG

Apple Fruit ............ 4
      Peach ............ 2
      Pear ............. 2
      Orange ........... 5

1) First proposal:
The text box of "insert index entries" should be able to accept a special 
character (e.g. "|") to indicate which part of the index entry should be 
"obscured"(only when the first part is identical and only from the second).

[Fruit|Apple] [Fruit|Peach] [Fruit|Pear] [Fruit|Orange]
get an index above

contrariwise

[Fruit Apple] [Fruit Peach] [Fruit Pear] [Fruit Orange]
get an index like this (as it is now).

Apple Fruit ............ 4
Apple Peach ............ 2
Apple Pear ............. 2
Apple Orange ........... 5

One might consider a formatting option like this:

Apple Fruit ......... 4
 - Peach ............ 2
 - Pear ............. 2
 - Orange ........... 5

2) In alternative (second proposal)
When there an key without page could create an option to force index creation as 
described above.

My two cents.
Regards
Comment 18 ramonsdk 2010-06-28 12:19:15 UTC
After 15 years of being a technical writer I take exception to being taught
wrong, doing the wrong thing, wanting the wrong thing, or proposing the wrong
thing. What I expect is what bazillion other word processors do as well and it
is common practice across printed material. Aside from that, it is very useful
for the reader.
That said, I do like the proposal to use the pipe character to separate main
from sub entries and indicate the desired processing rule. But, I disagree with
the proposed process. Giovannibattista proposes this:
"Apple Fruit ............ 4
      Peach ............ 2
      Pear ............. 2
      Orange ........... 5

1) First proposal:
The text box of "insert index entries" should be able to accept a special 
character (e.g. "|") to indicate which part of the index entry should be 
"obscured"(only when the first part is identical and only from the second).

[Fruit|Apple] [Fruit|Peach] [Fruit|Pear] [Fruit|Orange]
get an index above"


Such index entries should produce this:
Fruit Apple ............ 4
      Orange ........... 5
      Peach ............ 2
      Pear ............. 2

The common index key word is "Fruit" and it is also named first, which I would
expect to be the indicator for main entry. The key word after the separator is
then used for sub-entries that are to be sorted in alphanumerical ascending
order, or in the same order as the main entries of an index.

As I pointed out before, this is absolutely common practice. The examples from
giovannibattista show clearly that this is found in print regularly.
There may be writing guides that explicitly prohibit the writer from using such
useful things. In that case the writer can decide not to use this functionality.
The word processor application is the wrong tool to enforce any writing styles.
It should rather enable writers to make use of any style deemed suitable.

I second the proposal of using a separator such as the pipe character to enter
index key words for main and sub-entries to produce the expected index formatting.
Comment 19 oooalpha 2010-06-29 20:46:00 UTC
Writer has major limitations in the indexing tool.
e.g. Issue 6401 and  Issue 104691, that's incredible!
"Ramonsdk" has quite right!!!
Take a ride on Google Book or request has a professional indexer.
Comment 20 nebbiolo 2010-07-01 01:07:36 UTC
Hi,

I think "giovannibattista" meant to  combine lone keys with their entries and
stacked subsequent.

Apple 
      Fruit ............ 4
      Peach ............ 2         
      Pear ............. 2
to:
Apple Fruit ............ 4
      Peach ............ 2
      Pear ............. 2

But the issue speaks to combine keys with entries.
All indexes are like that.
You can ask any mailing list of indexers.

e.g.
http://groups.yahoo.com/group/scholarlyindexing
http://indexpup.com/index-list/faq.html

I do not want to argue, but "Es" did wrong, this is a bug and also big.
Greetings.
Comment 21 helmut_lothar 2010-07-02 16:20:46 UTC
"Combine identical Entries" option is useless (IMHO).
In fact, all alphabetical indexes combine identical entries, otherwise is TOC.

Proposal:
- "Combine identical Entries" option must be default, not an option.
- Replace "combine identical Entries" option with  "combine identical keys"
Comment 22 seber 2010-08-01 02:58:57 UTC
Please, consider this Issue as a "Defect" rather than as a "Enhancement".
Two examples Authoritative:
http://authornet.cambridge.org/information/productionguide/hss/

See page 3 
http://authornet.cambridge.org/information/productionguide/hss/XML_indexing_v2.pdf
See page 3
http://authornet.cambridge.org/information/productionguide/hss/Guide%20on%20Making%20an%20Index.pdf

Cambridge University Press is the publishing business of the University of
Cambridge, one of the world’s leading research institutions. It is the oldest
publisher and printer in the world, having been operating continuously since 1584.

Best regards and thanks in advance.
Sebastian
Comment 23 helmut_lothar 2010-08-08 02:09:54 UTC
My apologies for typo, I meant to write:
- Replace "combine identical Entries" option with "combine identical entries and
keys"
Sorry
Comment 24 scriptamanent 2010-08-25 21:29:56 UTC
Hi,
1. IMHO,It's a bug :-)
2. To-> "giovannibattista" You have confused this bug
with a problem of "sort specific entry" used to "obscure".
So,You want to get this?

Fruit Apple
 - Peach
 - Pear
 - Orange

On MsWord you can use the flag ";"
http://taxonomist.tripod.com/indexing/wordproblems.html#override

XE "Fruit Apple;Fruit Apple"
XE "- Peach;Fruit Peach"
XE "- Pear;Fruit Pear"
XE "- Orange;Fruit Orange"

OOo Writer does not have this very useful option.
I opened Issue 114115

3. The Issue 52088 is a duplicate (sub-entry=key)?

Kind regards
D.L.
-------- Off topic --------
* Here are many issues we need to be solved if we are to compete with
Ms Word in the educational/academic context! 
It is Oracle target? OOo Writer is great for automation office,
but the writers need different features (OOoBib,improved Index/ToC,outline
view,etc...).
* To-> "Marketing Project" 
The problem are limited human resources? 
http://blogs.sun.com/GullFOSS/entry/why_all_issues_are_equal
You could try to involve in the project (as Sponsor / Developer)
Universities[1], Indexing societies[2] and Publishers[3].
Perhaps they are interested in investing in OOo for free itself
from the cost of Microsoft licenses.
* A good idea might be a project to improve the alphabetical indexes.
Currently, the standard is MsWord[4].

References.
1
http://wiki.services.openoffice.org/wiki/Major_OpenOffice.org_Deployments#Schools_and_Universities
2 http://www.indexers.org.uk/index.php?id=104
and http://www.aboutindexing.info
3 An example of how widespread MsWord:
http://www.editorium.com/index.htm#Our_Customers
4 http://cambridge.org/us/notesforauthors/word_indexing.pdf