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.
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
Why not, perhaps easy to add in the localized xml files. Seth, what do you think?
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....
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?
(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.
(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.
(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.
(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).
(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.
* 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.
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.
(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? ;)
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."
en_GB has no definition for FollowPageWord, collected all in c10.
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.
R. Green, do you agree, that this is fixed?
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.
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.
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.
Sorry, scrub that last post: none of the entries have a thin space.
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
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.