Apache OpenOffice (AOO) Bugzilla – Issue 32712
Table of Authorities
Last modified: 2019-07-12 06:36:53 UTC
A table of authorities is somewhat like a bibliography and a table of contents. TOAs are used for legal documents. They are way to cite cases that are referenced in a document Here is an explanation of a TOA http://www.legalassistanttoday.com/issue_archive/legal_research_nd03.htm (a pratical example) http://www.legalassistanttoday.com/legalresearch&writing/ Here is a real world example of a TOA http://www.gop.com/Counsel/BCRA_pdfs/Opening_Brief_TOA.pdf "A Table of Authorities is a list of references (cases, statutes, rules, etc.) in a legal document, along with the numbers of the pages on which the references appear. To create a table of authorities, you mark the citations and then create the Table of Authorities. You can search your document for the next long or short citations to mark, or automatically mark each subsequent occurrence of the citation." -- http://www.law.georgetown.edu/ist/word/toa_whatisatoa.htm "A table of authorities lists the citations of cases, statutes, rules, and so on in a legal document-along with the pages they appear on. For example, we can list citations that appear in their long form (such as "Forrester v. Craddock, 51 Wn. 2d 315 (1957)") or in their short form (such as "Forrester v. Craddock")." -- found this one from a google cache -- http://home.ximb.ac.in/~u102096/mc/master doc.html I hope this helps provide some good information. I used the following two searches on Google to find this information: "table of authorities" "table of authorities" format
MRU->ES: pls comment before reassigning this RFE...
As described. A usefull enhancement
=== In the US, a citation may look like: Plaintiff v. Defendant, 555 State App. 555, 123-456, 888 A.2d 9999, cert. granted on other grounds, 333 State 444, 212 A.2d 111 (2007) ...where "Plaintiff v. Defendant" should be underlined. === The indexing feature works pretty well for this, with a few quirks: As of 2.0.2, index entries can't be formatted. Case names are supposed to be underlined, this requires manual massaging over (potentially a lot of) entries afterwards. In the above example, the "Plaintiff v. Defendant" title deserves underlining and the rest of the text doesn't, something paragraph styles can't handle. Indexing an Ibid, Id., or second cite requires cut and paste of the cite and produces a visually small anchor (the width of one space character, maybe less) rather than highlighting the word. Pasting can be error-prone, leading to index entries for "laintiff v. Defendant" or possibly " Plaintiff v. Defendant" with a leading space. It's nice that you can select and copy text while the Entry dialog is hovering, but unexpected that highlighting text changes the anchor point selected when you entered the dialog. Highlight Ibid, select the text for the index entry you need, paste in, and you've accidentally made the anchor on the text you copied. Highlight Ibid, select the text for the index entry you need, paste in before reselecting where you want the anchor to be and the reselected 'Ibid' blows out the text you wanted in the field. (Eventually, you learn to select, copy, select, paste, commit.) Nobody really paid attention to how the index feature handles very long, multiline items. This can get ugly (cite ending in a number filling a line, followed by a single '.', '-', or space, then the page number), and cleaning it up with formatting options -- to, say, preserve three '.'s space at a minimum -- is non-obvious. If the case name is long, often you want a line break after it to keep things legible, but too much manual editing will flow the table across another page and break all the automatic numbering, while 'Updating' the table will blow out all changes. (These tables generally appear in the first pages of the document, following a TOC.) To fix this perfectly you'd need to make manual edits visibly different from automatic content, preserve them, and treat the page numbers in the generated table as fields to be updated. If the user wants to start clean, he/she'll delete the whole table and insert a fresh one. The Bibliography feature may also work, but the procedure for using a local database per-document is poorly defined and requires editing a huge number of separate fields for each entry, instead of using the standard citation format that someone will have already typed into the document you're trying to generate the Table of Authorities from. My "user story" from five minutes of experimentation is that I found it appears to force a [ ] citation style into the text of the document, that can't be selectively underlined, rendering it painful and unsuited for this task.
A few more experience notes: A legal document can require multiple sections in the ToA -- for reference, this can be emulated by using "Cases", "Statutes", and "Treatises" as index "keys," if you can accept the alphabetical sort those categories get. It does require painfully editing every index entry anchor in the document once you realize this, of course. You can make as many "user-defined" indexes as you want, but as of 2.0.2 user-defined indexes cannot be sorted alphabetically and do not inherit the options to 'combine' keys and do page number ranges. This is a huge drawback to the index feature and recent documentation suggests it hasn't changed in later versions. The alphabetic sort naturally doesn't have the intelligence to numerically sort statutory references like the below properly (predictable, but an annoyance): C.G.S. §55-555(a)(1) C.G.S. §55-555(a)(11) C.G.S. §55-555(a)(6) The document I'm preparing requires an Appendix which requires its own multiple Tables of Authority; given the above, I have no choice but to put it in a different file, and will still run into problems requiring manual editing, since it should really be separate Tables / Indexes for different types of content with page breaks between. As above, if you can only get alphabetical sort and intelligent combining of keys and page ranges: C.G.S. §55-555(a)(6)........3, 5-8, 43, 49, 52 ...for the predefined types, you can only really have one index. (Ideally, I'd be able to create a bunch of named user-defined indexes: Testimony, Statutes, Cases, ... , which would all *be* of the alphabetically sorted type. Or smarter legally-aware types.)
Hello everyone, I am wondering what needs to be done to make a table of authorities generator in openoffice? I have not done much programing in C++ or looked into openoffice extensions yet. If I wanted to try and make a feature in openoffice for generating a table of authorities would the "best" way to go about it be to make a extension or to code it right into openoffice using the code for a table of contents as a base? Thanks, Gokee2
*** Issue 87162 has been marked as a duplicate of this issue. ***
Created attachment 54953 [details] Here is a sample legal document written with Microsoft Word, to illustrate what this functionality looks like
This is a larger issue than it appears. Why? Many attorneys want to use OpenOffice, especially to represent indigent clients on serious legal appeals and legal cases--i.e., the lawyer likely does NOT get paid, but the lack of the core legal feature limits the use of OpenOffice. Working on this project can literally mean the difference between an innocent person going to "the chair" or a person seeking asylum being granted asylum. I am willing to help in advising, testing, or general technical issues. Prior to entering lawschool I worked in the IT industry (CIO and web dev.).
Formal styling of case names requires selective italicization. For example: Plaintiff v. Defendant, 250 U.S. 306 (1942) _Plaintiff v. Defendant_, 250 U.S. 306 (1942) (fairly formal) _Plaintiff_ v. _Defendant_, 250 U.S. 306 (1942) (most formal) One approach is to identify strings within strings as exempt from italiciziation. Examples: v. (including leading and trailing spaces) Ex parte (including trailing space) (as in Ex parte _Thompson_) ex rel. (including leading and trailing spaces) (as in _U.S._ ex rel. _Quixote_ v. _Stammerbob_) -- Nick
To support internationalization of this feature, I suggest: 1. Let a user select a text string and tag it as ToA material. Compiling the ToA would then copy all these strings together into a table together with their (possibly dynamic) page numbers or page ranges. The user would then manually categorize, sort, edit, and format the strings as the user wishes, thus being able to conform to the user's nation's practice. Even though editing the ToA would be manual, that would be faster than having to copy manually and then edit manually. 2. Define particulars for each nation for which OOo has a language version. Local programmers can do this as demand warrants. Permit a user to select a national set of particulars from all national sets, regardless of the language being used by their installation of OOo; for example, an American lawyer might write a brief for an Israeli court. 3. Define particulars for each subnation. A subnation can be defined any way local users wish. For example, in the U.S., military law cited to military tribunals uses different conventions than those that apply to civilian law; thus, "UCMJ, Article 3" is clearer to military officers but a Title 10 U.S.C. reference to the same UCMJ provision is clearer to civilian lawyers and judges. Programmers familiar with demands of any subnational community can program this. 4. Create an empty list of authority types. OOo should populate the list from each set of national and subnational particulars programmed by whomever programs them; that requires a standard by which programmers would declare authority types (at least one) so that OOo can extract them from each national/subnational set of particulars. To keep the list short enough for one user's needs, all national and subnational sets of particulars should populate a checklist in an options dialog; a user may then opt for only certain set(s) to be relevant to their work, in which case only those sets would populate the authority types list. Then, when a user tags a string as ToA-eligible, the user can assign an authority type to it before compiling the ToA. The compiled ToA would then be presorted. Thanks. -- Nick
While it might be interesting for OpenOffice to have the ability to "automagically" recognize legal citations by their format alone, I should point out that it really isn't necessary to go that far in the first phase. The other major word processors (Microsoft and WordPerfect) require users to manually tag citations throughout the document, so consumer expectations currently aren't any higher than that.
Let me add to this a number of things: 1. There are many legal citation formats. 2. Citation formats require italics/underling and sometimes smallcaps. 3. The appearance of the TOA entry, is often not the same as the citation in the text. For example, the text may include a page number in the cite: Felder v. Casey, 487 U.S. 131, 151 (1988) (With the case name in italics) that should appear as Felder v. Casey, 487 U.S. 131 (1988) (With the case name still in italics). After a case has been referenced, there are several short forms that can be used in the text, including: Id. Felder, 487 U.S. at 152 4. This is a feature that Word does VERY poorly. In fact, most attorneys do it by manually. -=-=-=-= A. There needs to be an ability for the user to create TOA groups (e.g "Statutory Materials", "Regulations", "Cases") and an ordering for those grous. A. There needs to be an ability to specify a citation that will appear in the TOA, a group assignment, and how it will appear (an index entry). B. There needs to be a mechanism mark points in the text where the TOA entry appears. B. There needs to be an ability to generate a TOA in various forms. This should include sorting the entries in alphabetical or numeric order. -=-=-=-=-= Useful features would be to allow editing and correcting from within the TOA itself. For example, if a case appears under the statute section, it would be desirable to be able to select the entry in the TOA and change it to a case. If an entry appears multiple times (ie variations in spelling), it would be desirable to be able to select the spelling variation and reassign it to the desired spelling.
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".
A work-around exists by (1) Insert an Index/Table by selecting table Type of "Alphabetical", then renaming the table to "Table of Authorities". (2) select the full text of the entry you want to index. Select from Insert menu Table/Index / Entry. On dialog that opens select "Alphabetical" as table type. Make sure "main entry" is NOT checked, and enter category of authority in Key1, e.g. "Cases", "Statutes", "Rules", etc. Then click 'OK' at bottom of dialog. Tips - Multiple instances of cases should be all the same text throughout body of document. Right-click first word of table and select "Update" to effect changes in the table. Just before you print final version to PDF, right-click first word of table and select "Edit", and un-check "Protect contents from manual ..." and "OK" to close dialog. This allows you to manually change font of case citations to underline or italics as required. If you update the table, expect to have your formatting of citations to be undone. The problem is that although the word 'type' is used in the index of tables to ascribe "Alphabetical", which implies multiple alphabetical tables may be possible, as of OO 4.1.1 only one instance is possible, which you rename in step (1) above. Fortunately you can use "key1" to group categories of authorities. A test-case would be to select Type "Alphabetical" on the Insert / table index dialog, rename the table to create a new instance of an alphabetical table, and add an entry through the Entry dialog showing the newly added table. The Index of Tables should show the new table as well. This comment was written before exploring "User-defined" tables as a matter of expediency.
Created attachment 85586 [details] opinion of the court
*** Issue 126405 has been marked as a duplicate of this issue. ***