Bug 48213 - EDITING: Number (ful context) references are rendered as plain "n", omitting the "after" data stablished in "Options" tab from "Bullets and Numbering" dialog.
Summary: EDITING: Number (ful context) references are rendered as plain "n", omitting ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: preBibisect, regression
Depends on:
Blocks: Fields-Cross-Reference
  Show dependency treegraph
 
Reported: 2012-04-02 12:49 UTC by Rainer Hurtado Navarro
Modified: 2023-10-03 06:39 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Exampla. (10.01 KB, application/vnd.oasis.opendocument.text)
2012-04-02 12:49 UTC, Rainer Hurtado Navarro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Hurtado Navarro 2012-04-02 12:49:38 UTC
Created attachment 59399 [details]
Exampla.

Problem description: 
I am very literal and, when I use the numbering function, I take care of literally integrate the numbers, if text demanded that them to be of the ordinal kind.
So, in the "Options" tab from "Bullets and Numbering" dialog, I change the "after" field, which is just a dot, that I replace for ".ª" or ".º", according the gender of the subject (orthography in Spanish demands that the dot be placed between the number and º or ª). Thus, 1.º, 2.º, 3.º,... n.º, and equally for ".ª".
Some times, I need to refer to some of those numbered paragraphs. Then I insert a reference. Often, the reference is to the number it self. There are three options in that case: number, number (without context) and number (full context).
Previously (LibreOffice 3.4.3/3.5.0 Final x86_64), Number (ful context) rendered the reference as "n.º". But after the recent new updates (LibreOffice 3.5.1 Final x86_64), the references are rendered as plain "n", omitting the "after" data.
So, the numbers are not literally integrated in my text as before.

Steps to reproduce:
1. ....See above.
2. ....
3. ....

Current behavior: Number (ful context) references are rendered as plain "n", omitting the "after" data stablished in "Options" tab from "Bullets and Numbering" dialog.

Expected behavior: Number (ful context) references be rendered considering the "after" data stablished in "Options" tab from "Bullets and Numbering" dialog, as previous versions of LibreOffice.

Platform (if different from the browser): x86_64 (OS: openSuSE 12.1 Final x86_64)
              
Browser: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Comment 1 Rainer Hurtado Navarro 2012-04-02 12:54:02 UTC
Regarding this issue, openSuSE 12.1's LibreOffice (3.4.2.6-4.2.2-x86_64, 3.4.5.5-1.1-x86_64, from OBS, and 3.4.5.5-4.5.1-x86_64, from Updates) works fine.
Comment 2 Yifan Jiang 2012-12-28 06:36:57 UTC
hehe, I finally have a good time slot to understand what happened, it is really a regression problem.

-------------------------------><-------------------------------

[Steps]

  1. Create a new document using writer
  2. Type random short paragraphs
  3. Select the paragraphs and make the as bullets items (by clicking bullet on/off button)
  4. Right click the writer body, and select "Numbering/Bullets...", then switch to "Options" tab
  5. Replace the "." in "After" field to ".foo", and click "OK"\
    => the bullets will be shown things as 1.foo 2.foo (so far so good)

  6. From the menu select "Insert->Cross References...", set the fields as:

    Type: Numbered Paragraphs
    Selection: any one bulleted item
    Insert reference to: Number(full context)

  7. Click insert

[Problem]

  In 3.6 build or later, only number of the bullet is inserted as displayed reference: 
    "1", "2", "3"
  However it is expected the number and the appended words can be inserted:
    "1.foo", "2.foo", "3.foo"
Comment 3 Robinson Tryon (qubit) 2013-10-19 00:57:57 UTC Comment hidden (obsolete)
Comment 4 Cédric Bosdonnat 2014-01-20 08:57:54 UTC
Restricted my LibreOffice hacking area
Comment 5 Joel Madero 2014-06-09 16:26:55 UTC
I can confirm the regression (works in 3.3.0) but it's not bibisectable because it was broken by 3.5 pre-release. Setting version to PreBibisect and leaving regression keyword
Comment 6 Robinson Tryon (qubit) 2015-12-14 05:52:42 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2016-09-14 15:48:17 UTC
[This is an automatic message]

Changing version to 3.5.7.2 in order to get rid of 'preBibisect' version as 3.5.7.2 looks to be the last version not covered by bibisect-43all.
Comment 8 peterpan 2016-12-12 11:38:42 UTC
Still applies to version 5.2.2.2
Comment 9 QA Administrators 2017-12-13 09:29:02 UTC Comment hidden (obsolete)
Comment 10 Thomas Lendo 2018-10-01 07:20:02 UTC
Still reproducible.

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 89a60912bba7ffd6f65ea99f4664f343c5025c95
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-01_03:18:33
Locale: de-AT (de_AT); Calc: CL
Comment 11 QA Administrators 2019-10-02 02:56:40 UTC Comment hidden (obsolete)
Comment 12 peterpan 2019-10-02 07:59:12 UTC
Still present in Version: 6.3.1.2 (x64)
ID sestavení: b79626edf0065ac373bd1df5c28bd630b4424273
Comment 13 QA Administrators 2021-10-02 03:40:02 UTC Comment hidden (obsolete)
Comment 14 Regina Henschel 2021-10-02 13:41:23 UTC
The problem still exists in Version: 7.1.5.2 (x64) / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_US); UI: en-US
Calc: threaded
Comment 15 QA Administrators 2023-10-03 03:16:23 UTC Comment hidden (obsolete)
Comment 16 peterpan 2023-10-03 06:39:20 UTC
Still present in:
Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: cs-CZ (cs_CZ); UI: cs-CZ
Calc: threaded