Bug Hunting Session
Bug 55844 - EDITING: Insert Special Character creates dummy styles applied to cell contents
Summary: EDITING: Insert Special Character creates dummy styles applied to cell contents
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.2 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 56647 (view as bug list)
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2012-10-10 17:30 UTC by b.patrick
Modified: 2017-03-06 14:56 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
snapshot of spreadsheet containing cells containing Arabic text with diacritics and cells pointing to them (244.27 KB, image/png)
2012-10-10 17:30 UTC, b.patrick
Details
small file showing super- and subscripts rendered differently in pointing cell, and instances of missed laam-'alif ligatures (11.65 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-11-19 16:11 UTC, b.patrick
Details
snapshot of spreadsheet containing cells with Arabic text with presentation in pointing cells different from original and with(out) missed laam-'alif ligatures (125.12 KB, image/png)
2012-11-19 16:21 UTC, b.patrick
Details
Windows screenshot (44.58 KB, image/jpeg)
2012-11-20 01:22 UTC, Urmas
Details
screen print showing different displays in two columns of which one points to the other (cellwise) (146.19 KB, image/png)
2012-11-22 01:44 UTC, b.patrick
Details
screenshot showing discrepancies in two columns of which left one points to contents of right one (cellwise) (146.19 KB, image/png)
2012-11-22 01:49 UTC, b.patrick
Details
Source cells content (977 bytes, text/plain)
2012-11-22 14:09 UTC, Urmas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description b.patrick 2012-10-10 17:30:28 UTC
Created attachment 68410 [details]
snapshot of spreadsheet containing cells containing Arabic text with diacritics and cells pointing to them

Processor (CPU):   Intel(R) Core(TM)2 Quad CPU @ 2.40GHz
Speed:  1,596.00 MHz
Cores:  4
OS:  Linux 2.6.34.10-0.6-desktop x86_64
System:  openSUSE 11.3 (x86_64)
KDE:  4.4.4 (KDE 4.4.4) "release 3"

LibreOffice 3.4.2 
OOO340m1 (Build:1206)

(Please refer to snapshot.)

Cell J721 contains arabic دَقَِّ (d^fatHa q^shadda^fatHa) where the shadda and fatHa are stacked in correct order.

Cell I721 points to cell J721 with code: "=IF(CODE(J721)=45,L721,J721)". One would expect it to display the same thing as cell J721. However, it displays دَقِِّ (d^fatHa q^kasra^shadda). Since the more or less diagonal stroke meant as a fatHa (for vowel "a") is now placed below the shadda (more or less a wiggle), it now takes the function of kasra (for vowel "i").

The same thing happens for (e.g.) cells I725 and J725, also visible on the snapshot.
Comment 1 Issa Alkurtass 2012-11-11 05:45:13 UTC
Are you using a specific font? Because all the fonts I have installed show both the same way regardless of order (fatHa^shadda or shadda^fatHa), so I couldn't really test it.
Comment 2 b.patrick 2012-11-19 07:52:49 UTC
(In reply to comment #1)
> Are you using a specific font? Because all the fonts I have installed show
> both the same way regardless of order (fatHa^shadda or shadda^fatHa), so I
> couldn't really test it.

I am using Arial in the columns with Arabic text. The text got there from the Insert -> Special Character menu from the "Basic Arabic" group. Just now I noticed that the "qaaf" in my example does not only have shadda^fatHa, but also kasra with it. The latter does not belong there as far as correct Arabic is concerned. I am not sure if this extra "burden" helped create the (minor) problem.
Comment 3 Issa Alkurtass 2012-11-19 12:18:21 UTC
Could not reproduce on neither LibreOffice 3.5.1.2 nor LibreOffice 4.0.0.0.alpha0+.
Would you mind attaching the file itself?
Comment 4 b.patrick 2012-11-19 16:11:08 UTC
Created attachment 70261 [details]
small file showing super- and subscripts rendered differently in pointing cell, and instances of missed laam-'alif ligatures

Please refer to 56647 and 55844.
Comment 5 b.patrick 2012-11-19 16:11:39 UTC
(In reply to comment #3)
> Could not reproduce on neither LibreOffice 3.5.1.2 nor LibreOffice
> 4.0.0.0.alpha0+.
> Would you mind attaching the file itself?

I will attach a strongly downsized file with the same issues in it. Column A cells point to contents of respective column B cells.

-line 1: d^(a)q^(s+a)_(i) in column B rendered incorrectly as d^(a)q^(s+i);
-line 2: d^(a)q^(s+a) in column B rendered correctly as d^(a)q^(s+a);
-line 3: d^(a)l^(s+a)_(i) in column B rendered incorrectly as d^(a)l^(s+i);
-line 4: q^(a)Ay^(h+aa)_(i)lA in column B rendered correctly (i.e. exact copy) as q^(a)Ay^(h+aa)_(i)lA; BUT column B contents were entered by first entering q^(a)Ay^(h)_(i)l^(aa)A, then putting cursor at end of text, then entering backspace twice (from which I expected that the cursor would be just behind l), and then entering double fatHa (i.e. fatHa plus nunation), so instead of on laam the double fatHa are shown on y^(h);
-line 5: everything in order;
-line 6: created by first entering q^(a)Ay^(h+aa)_(i)l, then hitting <return> (cursor leaves cell), then putting cursor back at end of q^(a)Ay^(h+aa)_(i)l, then entering ^(aa)A;
-line 7: creation quite similar as that in line 6 (although precise order of actions forgotten).

The laam-'alif presentations in lines 4, 6, and 7 are incorrectly shown without the laam-'alif ligature.
Comment 6 b.patrick 2012-11-19 16:13:16 UTC
[I will attach] (see comment 5) => [I have attached] (see comment 4)
Comment 7 b.patrick 2012-11-19 16:21:50 UTC
Created attachment 70266 [details]
snapshot of spreadsheet containing cells with Arabic text with presentation in pointing cells different from original and with(out) missed laam-'alif ligatures

snapshot of screen with spreadsheet page with lines 1-7 opened
Comment 8 Urmas 2012-11-20 01:22:14 UTC
Created attachment 70292 [details]
Windows screenshot

That's how your table does look on my machine.
Comment 9 b.patrick 2012-11-22 01:44:09 UTC
Created attachment 70398 [details]
screen print showing different displays in two columns of which one points to the other (cellwise)

(In reply to comment #8)
> Created attachment 70292 [details]
> Windows screenshot
> 
> That's how your table does look on my machine.

That is very funny: your attachment shows things my machine does not show, not even with enlargement to 300%. That means that from the look of my screen I cannot (always) judge what is actually stored in those cells. Your attachment also shows at least some of the discrepancies between the right column and the left column (that points to the right column's contents) that I also encountered. I wonder how you made all these double(d) letters visible on your screen. If they are traces of my input, I would like to have something that really and clearly displays me what the contents of the cells are, instead of the views I get on my screen.
Comment 10 b.patrick 2012-11-22 01:49:37 UTC
Created attachment 70399 [details]
screenshot showing discrepancies in two columns of which left one points to contents of right one (cellwise)

Excuse me: I seem to have to indicate the file type. I hope I did it in a helpful way this time. For remaining part of comment, please refer to my previous comment.
Comment 11 Urmas 2012-11-22 14:09:26 UTC
Created attachment 70432 [details]
Source cells content

That's what your source cells contain.
Comment 12 b.patrick 2012-11-22 23:29:55 UTC
(In reply to comment #11)
> Created attachment 70432 [details]
> Source cells content
> 
> That's what your source cells contain.

Thanks for displaying the contents in a different way. I am still puzzled. In your opinion:

1) did I report things that relate to (a) bug(s)?
2) (how) can I have the cell contents displayed properly, i.e. a) in the "correct" way (for Arabic), and b) in a way that tells me what I entered?
3) is there a simple, "natural" way of entering Arabic text that prevents the - to me at least - strange appearance of certain pieces of Arabic text, and, if so, which is it?
4) (how) can I get the same (correct) appearance in both original and pointing cell?

Up to now I have been entering Arabic text from the menu Insert -> Special Character -> Basic Arabic (in Arial).

Thanks!
Comment 13 b.patrick 2012-11-22 23:39:00 UTC
(In reply to comment #11)
> Created attachment 70432 [details]
> Source cells content
> 
> That's what your source cells contain.

As far as I can see and understand the code in your attachment, I can discover nor understand:

A) why and how different sequences of entering text should result in different contents and displays of the laam-'alif sequence;
B) why and how using backspace EXACTLY twice starting with a cursor at what I think is the end of a word brings me back into the word MORE than two positions;
C) why and how the pointing cell displays the contents of the original cell in a different way than the latter.

Is this puzzling anyone else, or just me?

Thanks!
Comment 14 Urmas 2012-11-23 04:47:52 UTC
The ligatures look differently because they are composed from various fonts and cannot "ligate" with each other.
The BACKSPACE key is deleting the entire graphemes for complex scripts, so it can delete several characters at the time.
The functions which refer the cell contents are taking the text without applied formatting, so they display it as they should.

To fix your table, try to cut the offending cells, paste them into Kate or GEdit, then cut them once again and paste in their original place.
Comment 15 b.patrick 2012-11-23 14:06:30 UTC
(In reply to comment #14)
> The ligatures look differently because they are composed from various fonts
> and cannot "ligate" with each other.
> The BACKSPACE key is deleting the entire graphemes for complex scripts, so
> it can delete several characters at the time.
> The functions which refer the cell contents are taking the text without
> applied formatting, so they display it as they should.
> 
> To fix your table, try to cut the offending cells, paste them into Kate or
> GEdit, then cut them once again and paste in their original place.

* I am not aware of having entered characters from various fonts, as I entered all from Insert -> Special Charactres -> Basic Arabic (within Arial). I understand you mean the software did this for/to me.

* Deletion of several characters at a time makes sense to me in the case of a laam-'alif ligature.

* I am not aware of applying any specific formatting by myself; all I was aware of is that I picked the Arabic letters one by one from the said menu. I understand you are hinting at some formatting done by the software automatically.

* Thanks for the suggestion for how to improve my table!

* It is still not clear to me if I reported (symptoms of) a bug, or if I have just missed some understanding of how to use LibreOffice Calc in a sensible and appropriate way.
Comment 16 Urmas 2012-11-23 17:16:39 UTC
Yes, that's the bug with "Ïnsert Special character" feature or somewhere along this line.
Comment 17 b.patrick 2012-11-24 20:53:56 UTC
(In reply to comment #16)
> Yes, that's the bug with "Ïnsert Special character" feature or somewhere
> along this line.

Thanks a lot for your explanations!
Comment 18 Urmas 2013-04-30 12:41:44 UTC
*** Bug 56647 has been marked as a duplicate of this bug. ***
Comment 19 QA Administrators 2016-02-21 08:34:36 UTC Comment hidden (obsolete)
Comment 20 QA Administrators 2017-03-06 14:56:55 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice 
(5.2.5 or 5.3.0  https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and 
your operating system, and any changes you see in the bug behavior
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave 
a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug-20170306