Bug 137160 - ALPHABETICAL INDEX: need to add thin space between page reference and f./ff.
Summary: ALPHABETICAL INDEX: need to add thin space between page reference and f./ff.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Heiko Tietze
URL:
Whiteboard: target:7.3.0 target:7.2.0.0.beta2
Keywords:
Depends on:
Blocks: TableofContents-Indexes Bibliography Writer-Styles Authors
  Show dependency treegraph
 
Reported: 2020-09-30 12:45 UTC by R. Green
Modified: 2021-08-29 18:09 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Writer file showing update issue for f./ff. index entries (49.35 KB, application/vnd.oasis.opendocument.text)
2021-08-15 10:26 UTC, R. Green
Details

Note You need to log in before you can comment on or make changes to this bug.
Description R. Green 2020-09-30 12:45:34 UTC
Version: 7.0.0.3 (x64)
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

See Bug 94411. This was an important fix changed the incorrect p./pp. abbreviations to the correct f./ff.

So far, so good. However the "Oxford Book of Style" (which is the Bible for Br. En. document formating) also specifies that there should be a THIN SPACE between the page number and the f./ff (Oxford University Press, 2005, p. 591). This is an essential component, enhancing the readability and professional appearance of the index.

ENHANCEMENT REQUEST: Please add a THIN SPACE between the page number and the ff./ff. characters.
Comment 1 Dieter 2021-01-13 07:07:51 UTC
Thia is the question, if LO follows a certain style (could also be CMOS and some others). Unfortunately there is no internal guideline for that. I still think, at least Design-Team needs an internal consensus about it.

cc: Design-Team for further input and decision
Comment 2 Heiko Tietze 2021-01-18 11:50:02 UTC
Why not, perhaps easy to add in the localized xml files. Seth, what do you think?
Comment 3 sdc.blanco 2021-01-18 14:10:39 UTC
If the request was to add ff.  instead of ff. then the localized xml could be used.

But OP is asking for:

indexed_word ...................n(thinspace)ff.

where n = page number
      (thinspace) = where (thinspace) should be placed.


in my amateur opinion, could be tricky.

Two options.

a. make this "thinspace" universal, by modifying the place in the source code where index entries are composed, or 

b. drop the space between n and ff in source code, and make the localization include space/thinspace as preferred 

Additional information.

About 150 localizations have a value for "ff" and several of them already have a "space" included in the localization before the "ff" (which suggests that a dropped space would have to be added back into those localizations) 


Summa summarum

You might have to ask the 70+ translators if they have any opinions about such a change 

  -- if they accept a, then it should be easy to implement.

  -- if a. is rejected and b. is accepted, then someone (with good awk/bison skills) will have modify about 150 .xml files, according to local preferences.


Feel free to seek a second opinion....
Comment 4 sdc.blanco 2021-01-19 09:40:49 UTC
One more idea:  

1. Add following checkbox option in Entries tab (in the "Format" section) in the Edit Index dialog.  
   
    [ ] Use thinspace before f. or ff.

2.  Modify source code to:
     (a) check status of checkbox
     (b) use thinspace if checked, regular space if not.

Should not require any changes in the .xml files (or agreement by translators), but would give users the option to control the appearance.

Perhaps an interesting EasyHack?
Comment 5 Heiko Tietze 2021-01-20 18:39:12 UTC
(In reply to sdc.blanco from comment #4)
>     [ ] Use thinspace before f. or ff.
What is the opposite, a normal space? This needs to be a radio button- but feels like an overkill of options to me. Would rather expose the f/ff xml stuff somewhere and allow the thin space per workplace.
Comment 6 sdc.blanco 2021-01-20 22:51:31 UTC
(In reply to Heiko Tietze from comment #5)
> Would rather expose the f/ff xml
> stuff somewhere and allow the thin space per workplace.
Is this note to self?  Not sure what you are thinking about here.
Comment 7 Heiko Tietze 2021-01-21 08:53:07 UTC
(In reply to sdc.blanco from comment #6)
> Is this note to self?  Not sure what you are thinking about here.

We should provide user customization by exposing the option on the index dialog.
Comment 8 sdc.blanco 2021-01-21 09:49:13 UTC
(In reply to Heiko Tietze from comment #7)
> We should provide user customization by exposing the option on the index
> dialog.
Right.  Considered this possibility. Here are some complications.

1. Entries tab has "Structure" control to "edit" the appearance of index.

2. But note that "ff" is currently "hidden" as part of "Page No."

3. Could separate that part out, but then remember that "ff" is an option set on the "Type" tab (i.e., not always used), so some "design" work would be needed to these handle variations.

Or -- as yet another alternative, sketched roughly -- without trying to think through the different variations and specific design -- 

Put/allow all the design decisions to be made/taken in the "Structure" control (on the Entries tab)

In particular: 
   - Move the "combine identical entries" control (on Type tab) to Entries tab, so that it becomes integrated into the "Structure" control.

   - For example, when the Page No. control is selected in the Structure, then the dialog box shows the various options in relation to "Page No.", where the user can customize how the index entry would appear, in terms of combined with ff, thinspace, or with - , case-sensitive, etc. 

   - and of course with a sensible (localized) "default" that does not need intervention (i.e., for most users)?

(this approach could also be relevant / a possible direction in relation to bug 130003 )

(Not advocating for any particular solution -- just generating alternatives and trying to highlight practical consequences).
Comment 9 sdc.blanco 2021-02-03 11:43:11 UTC
(In reply to Heiko Tietze from comment #7)
> We should provide user customization by exposing the option on the index
> dialog.
Appears that the current/existing UI in Entries tab was created (and has not visibly changed) since early OOo -- perhaps contemporary GUI tools will allow better UI designs, beyond the immediate issue of this ticket.
Comment 10 Heiko Tietze 2021-07-05 12:26:13 UTC
* da_DK, de_DE, fo_FO, nds_DE, sv_SE use f./ff.
* en_GH has an entry for FollowPageWord but p/pp
* br_BR, br_FR, es_ES, et_EE, eu_ES, fr_FR, ia, it_IT, la_VA, lij_IT, rw_RW, vro_EE have a space before the following pages indicator such as sq.

I'm going to add the thin space to en_US only.
Comment 11 Commit Notification 2021-07-05 15:07:00 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/06e48b4beb0f898483211c77adbb2e83d8908cee

Resolves tdf#137160 - Thin space before f./ff. in en_US

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Mike Kaganski 2021-07-05 19:37:12 UTC
(In reply to R. Green from comment #0)
> Locale: en-GB (en_GB); UI: en-GB
> ...
> However the "Oxford Book of Style" (which is the Bible for
> ***Br. En.*** document formating) also specifies that...

(In reply to Heiko Tietze from comment #10)
> I'm going to add the thin space to en_US only.

(In reply to Commit Notification from comment #11)
> Resolves tdf#137160 - Thin space before f./ff. in en_US

I'd say it's a confusion - it's "resolved" for en-US, while it was requested for en-GB? ;)
Comment 13 R. Green 2021-07-05 21:32:08 UTC
The "Chicago Manual of Style" cautions, "Never in any circumstances use f., or ff., … in an index: use only the actual sequence of pages." So, strictly speaking, those following CMS guidelines should avoid this form altogether.

The "Oxford Guide to Style" (1989) states, "A thin space separates the page reference and the abbreviation where f. and ff. are unavoidable."

"New Harts Rules" (2005) states that "The spacing, if any, before the abbreviation [i.e. f. or ff.] is a matter of house style; Oxford traditionally uses a thin space between a number and a following f. or ff."
Comment 14 Heiko Tietze 2021-07-06 05:28:37 UTC
en_GB has no definition for FollowPageWord, collected all in c10.
Comment 15 Commit Notification 2021-07-07 20:00:22 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/b2d93a34ce83e9442ba12c4f11586c9a02e63119

Resolves tdf#137160 - Thin space before f./ff. in en_US

It will be available in 7.2.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Dieter 2021-08-15 05:41:07 UTC
R. Green, do you agree, that this is fixed?
Comment 17 R. Green 2021-08-15 10:26:23 UTC
Created attachment 174300 [details]
Writer file showing update issue for f./ff. index entries

(In reply to Dieter from comment #16)
> R. Green, do you agree, that this is fixed?
Not quite. It appears to work fine if you create the index entries in versions 7.2.0.0 and above.

However, it is not updating indexes in Writer files created prior to version 7.2.0.0, and consequently these have no thin space before a f./ff.

To confirm this, open the attached file (created in vs. 7.1.3.2) and inspect the index at the end of the doc.
Comment 18 R. Green 2021-08-15 10:30:56 UTC
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: c703b2d22c3f45825d9c9d790c3b5a4b6f97e776
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-17_00:44:32
Calc: threaded

NOTE: These are the test version details for the previous post.
Comment 19 R. Green 2021-08-15 10:38:01 UTC
Just had a second look at the test document. The first instance of "f." in the index appears to be preceded by a thin space, but subsequent "f."s are not.
Comment 20 R. Green 2021-08-15 10:41:43 UTC
Sorry, scrub that last post: none of the entries have a thin space.
Comment 21 V Stuart Foote 2021-08-15 14:00:07 UTC
Frankly should revert the change. There is no expectation that prior < 7.2 documents would be restyled with the extra space, just newly created en-US documents.

Specific layout of each "house rule" for indexing (including the big 4) is described in CSL [1]. Rather than attempting this piecemeal as in Heiko's en-US patch for f. or ff.--we really need a framework for using CSL.  Similar to bug 64960 for Bibliography, or bug 121945 for citation style (bug 121945), Index layout to canvas/ODF archive needs to be CSL controlled.

Better LO structural support for CSL then allows better extension support with writing/research tools that support it--e.g. Zotero, or Mendeley

We can't do this one formatting attribute at a time.

Revert the change and => WF

=-ref-=
[1] https://github.com/citation-style-language/styles
Comment 22 Heiko Tietze 2021-08-19 10:39:31 UTC
Request has been fixed. We will never change the layout of existing documents, only newly created are affected therefore. Whether to revert the patch is another question; would discuss this in another ticket.