The Hebrew language employs punctuations - points and lines added over, under or within a letter to indicate aspects of its pronunciation. One of the punctuation symbols is the Dagesh - it converts a V into B, F into P and otherwise places an emphasis on a consonant. Now, punctuation symbols, including the Dagesh, have Unicode character codes (and are considered "modifier" characters if I'm not mistaken). Dagesh is at U+0x5BC (which is the same character for Mapiq, which is about the same thing as a Dagesh). Now, if I choose to insert a special character in LibreOffice Writer, and choose the Hebrew font I'm using for my text (say, David CLM from the culmus project), I see what is supposedly the entire set of Hebrew characters provided by this font. Yet, while some punctuation symbols can be chosen - such as Patah, Qamats and others - I don't see the Dagesh character. David CLM _does_ have a Dagesh, as I observe using an external character map utility. It seems like the Special Character dialog is somehow filtering more of the Hebrew fonts than it should be.
Please upload a test document, so others could verify the report.
> Please upload a test document, so others could verify the report. This is not specific to a certain document. Just: 1. Create a new document 2. In the menus, choose Insert | Special Character 3. Choose some Hebrew font, e.g. David CLM 3. Look for the Dagesh character... you won't find it
Special character dialog was reworked for LO 6.0. So perhaps the problem is solved in this version. Can you test it with the master from http://dev-builds.libreoffice.org/daily/master/ ?
Created attachment 136982 [details] GNOME charmap utility displaying the Dagesh character of David CLM The screenshot is of an _external_ character map utility, not o LO 5.4's. Note that unlike LO, the GNOME utility does not mark the original character with a dotted circle which the punctuation mark combines with - here it "combines" with just white background.
Using the master build which Dieter linked to, I noticed the following: * The character U+0x5BC _is_ one of the characters presented in the dialog, but * The Dagesh/Mapiq (U+0x5BC) character is _not_ shown as placed inside the base character, but rather outside and to the left of it (i.e. after it). * If I choose to insert a Dagesh/Mapiq, the character at which it is inserted is not affected, and indeed we see the Dagesh/Mapiq on the outside and to the left. That lead me to check myself again with 5.4. Well, I _can_ find U+0x5BC - I didn't notice it before because it didn't look like a Dagesh, but rather like a Shuruq. Checking that, it seems 0x5BC is indeed used for Shuruq when composed with a vav (ו) character (too bad!). But thhat's not how it behaves with other letters. But it gets more complicated, since it's still the case - with both LO 5.4 and LO 6.0 - that if I paste an U+0x5BC from an outside charmap I get a Dagesh/Mapiq composed as I expect, but if I insert it using the Special Characters dialog, it always behaves like a Shuruq. Attachment to illustrate this forthcoming.
Created attachment 136983 [details] Mapiq/Dagesh inserted from different sources
Created attachment 136984 [details] Mapiq from different sources - screenshot
I've added U+0x5BC and it's indeed a bit after the letter than inside it. But it also get created with a different font setting. Marking it and setting it to David CLM, makes it fall into the right place. Eyal - the two test document you've added has two chars after the ה. Removing the 2nd and changing the font as mentioned above makes it look OK.
(In reply to Lior Kaplan from comment #8) > I've added U+0x5BC and it's indeed a bit after the letter than inside it. > But it also get created with a different font setting. Marking it and > setting it to David CLM, makes it fall into the right place. Both in 5.4.1 and in master build: Version: 6.0.0.0.alpha0+ Build ID: 9685532bc859167c1aa856c6f6792559904b8fb9 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group Eyal, please update the bug description.
Created attachment 136991 [details] dagesh character found in master (In reply to Eyal Rozenberg from comment #2) > This is not specific to a certain document. Just: > > 1. Create a new document > 2. In the menus, choose Insert | Special Character > 3. Choose some Hebrew font, e.g. David CLM > 3. Look for the Dagesh character... you won't find it I found it in 5.4 and master, so this bug likely needs to be closed. Version: 6.0.0.0.alpha0+ Build ID: 8eacd3be08bf6e1a97900624611822de9b00a379 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group
(In reply to Yousuf Philips (jay) from comment #10) > I found it in 5.4 and master, so this bug likely needs to be closed. But the character rendered in your attachment (which corresponds to mine) is _not_ a Dagesh/Mapiq - which goes in the middle of the underlying character (or about the middle) - not to the side of it. I am changing the bug name accordingly. It's not that it it's missing - it's mis-rendered.
Created attachment 136993 [details] double-mapiq after inserting a Dagesh/Mapiq and setting its font right If I do the following: 1. Open the "mapiq from different sources" document 2. Select the Heh with the Mapiq (הּּ) 3. Set the font to David CLM The Mapiq gets doubled. Same thing happens if Do: 1. Create new document 2. Set the font to David CLM 3. Write the letter He (ה) 4. On the menus, choose, Insert | Special Character 5. Select U+0x5BC (at this point you have the Mapiq rendered to the side of the He) 6. Select the Heh with the Mapiq (הּּ) 7. Set the font to David CLM you again get the double-Mapiq - in the middle and to the side.
And I see the double-Mapiq with both 5.4.2.2 release and 6.0 master (from Yousuf's link).
(In reply to Eyal Rozenberg from comment #12) > Created attachment 136993 [details] > double-mapiq after inserting a Dagesh/Mapiq and setting its font right > > If I do the following: > > 1. Open the "mapiq from different sources" document > 2. Select the Heh with the Mapiq (הּּ) > 3. Set the font to David CLM > > The Mapiq gets doubled. It worked fine with me with these steps 1. open attachment 136983 [details] 2. select after the Heh with the Mapiq 3. press delete 4. select the Heh with the Mapiq 5. set the font to David CLM I opened the odt in word and it showed a square character next to the Mapiq, so i'm assuming two Mapiqs were pressed next to the Heh, which is why one appeared in the middle and one at the end in your steps. > Same thing happens if Do: > > 1. Create new document > 2. Set the font to David CLM > 3. Write the letter He (ה) > 4. On the menus, choose, Insert | Special Character > 5. Select U+0x5BC (at this point you have the Mapiq rendered to the side of > the He) > 6. Select the Heh with the Mapiq (הּּ) > 7. Set the font to David CLM > > you again get the double-Mapiq - in the middle and to the side. I dont get double-Mapiq. Screencast coming.
Created attachment 137001 [details] screencast of font change with mouse or keyboard selection So inserting the Mapiq from the special character dialog does insert it in the wrong location and selecting the Heh and the Mapiq results in the font name toolbar field to go blank, which normally means that multiple fonts are in the selection, so this is quite strange. But what i noticed when testing this bug and which can be seen in the screencast is that when you select the Heh by keyboard, it will also select the Mapiq, which will result in the character appearing correctly when changing the font, but if you select the Heh by mouse, it will not select the Mapiq, resulting in no change of the Mapiq when changing the font. This should be filed as a separate bug.
(In reply to Yousuf Philips (jay) from comment #15) > This should be filed as a separate bug. Go for it :-) Additionally, I'm starting to think maybe this bung and bug 113135 are more related than one would initially assume... perhaps even being dupes of each other.
Khaled, Maxim, Caolan: Any thoughts why inserting this hebrew diacritic isnt getting combined correctly with the hebrew character before it, until both character as selected and the font name reapplied to both of them?
(In reply to Yousuf Philips (jay) from comment #17) > Khaled, Maxim, Caolan: Any thoughts why inserting this hebrew diacritic isnt > getting combined correctly with the hebrew character before it, until both > character as selected and the font name reapplied to both of them? Looks like the special characters dialog is inserting the character with a different font. Checking the actual ODT XML should show if this is the case. That being said, I know nothing about how this dialog works.
Akshay may know.
Looking into the XML source, the mark character is inserted as <span> with a text style that points to the same font (though I don’t understand ODT’s XML that much), and I think we don’t join spans when shaping (long outstanding bug, might be the root for bug 61444).
This is likely to be breaking other things as well like kerning a and ligatures.
Eyal -- On Linux, you don't need to use the special character dialog for Hebrew diacritics (Niqqud); the default Hebrew key mapping has U+0x5BC on <right-alt>+S (that's ד for דגש) and the rest of them on similarly reasonable places. That is, of course, a workaround, there still appears to be a problem with the special-char dialog.
(In reply to Khaled Hosny from comment #20) > Looking into the XML source, the mark character is inserted as <span> with a > text style that points to the same font (though I don’t understand ODT’s XML > that much), and I think we don’t join spans when shaping (long outstanding > bug, might be the root for bug 61444). Yes i checked the XML as well which looks like this <style:style style:name="P1" style:family="paragraph" ... > <style:paragraph-properties ... /> <style:text-properties style:font-name="David CLM" /> </style:style> <style:style style:name="T2" style:family="text"> <style:text-properties ... style:font-name-complex="David CLM1" /> </style:style> ... <text:p text:style-name="P1"> ה <text:span text:style-name="T2">ּ</text:span> </text:p> So the problem seems to be that the special character dialog is not taking into account that 'David CLM' is already set in P1's <style:text-properties> as style:font-name and as P1 and T2 dont have 'David CLM' in style:font-name-complex, they arent able to mix. Here is what the XML looks like when they are correctly joined. <style:style style:name="P1" style:family="paragraph" ...> <style:paragraph-properties ... /> <style:text-properties style:font-name="David CLM" style:font-name-complex="David CLM" /> </style:style> <style:style style:name="T3" style:family="text"> <style:text-properties officeooo:rsid="0004f39f" /> </style:style> ... <text:p text:style-name="P1"> ה <text:span text:style-name="T3">ּ</text:span> </text:p>
(In reply to Yousuf Philips (jay) from comment #23) > <style:text-properties ... style:font-name-complex="David CLM1" /> Is there really a "David CLM1" attribute there or is it just a typo?
(In reply to Eyal Rozenberg from comment #24) > Is there really a "David CLM1" attribute there or is it just a typo? Not a typo, as its the style:name value and not the font name. Bellow is pulled from attachment 136983 [details]. <style:font-face style:name="David CLM1" svg:font-family="'David CLM'" /> <style:font-face style:name="David CLM" svg:font-family="'David CLM'" style:font-pitch="variable" />
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still seeing this with build: ּVersion: 6.2.0.0.alpha0+ Build ID: ad6adb1bfadf49af3187a0bb3ceffbf355e9eed1 CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-29_02:45:20 Locale: en-US (en_IL); Calc: threaded
Dear Eyal Rozenberg, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still manifests with: Version: 6.3.2.2 Build ID: 1:6.3.2-1 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; Locale: he-IL (en_IL); UI-Language: en-US And please don't let us wait another year on this bug with no action :-(
(In reply to Eyal Rozenberg from comment #29) > Please don't let us wait another year on this bug with no action :-( Bug still manifests with: Version: 7.1.0.3 Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Linux 5.9; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US
Updated the Culmus font package to 0.133 in bug 141553. The new font may solve this issue.
(In reply to Heiko Tietze from comment #31) Here's how it stands with the latest nightly: * In the Insert Special Character dialog, with font David CLM, the Dagesh/Mapiq (U+0x5BC) character _is_ shown as placed inside the base character (dotted circle and a point inside of it). OK (buggy behavior gone) * If I choose to insert a Dagesh/Mapiq, the character at which it is still inserted is not affected, and indeed we see the Dagesh/Mapiq on the outside and to the left. BUG * If I insert a Dagesh/Mapiq from the clipboard, by pasting, it is inserted on the inside of the character. OK (but there is still a discrepancy from insertion using the Special Character dialog) * If I insert a Dagesh/Mapiq using the keyboard, pressing RightAlt+ד in Hebrew layout, it inserted on the inside of the character. OK (but there is still a discrepancy from insertion using the Special Character dialog) * If I select the text including the Dagesh/Mapiq I inserted, and set the the font to David CLM or anything else, the Dagesh/Mapiq is _not_ doubled, and in fact takes its appropriate position inside the character. OK (buggy behavior gone) So, part of the issue is now gone, but something still tells LO that the inserted Dagesh/Mapiq is somehow not an integral part of the run of text with its preceding letter.
(In reply to Eyal Rozenberg from comment #32) > So, part of the issue is now gone, but something still tells LO that the > inserted Dagesh/Mapiq is somehow not an integral part of the run of text > with its preceding letter. You are too fast, I submitted the patch this morning so the nightly build wont be ready until tomorrow (depends on OS and mood of build machines).
(In reply to Heiko Tietze from comment #33) > You are too fast, I submitted the patch this morning so the nightly build > wont be ready until tomorrow (depends on OS and mood of build machines). I will also add that the behavior with David CLM is the exactly same for me with Liberation Sans. With font family such as Noto Sans Hebrew and Frank Ruehl CLM, the behavior is very similar, except that in the Insert Special Character dialog we see the Dagesh/Mapiq dot slight outside and to the left of the dotted circle. If you'd like, I can attach a screenshot of the Insert Special Character with the two different families.
(In reply to Eyal Rozenberg from comment #34) > I will also add that the behavior with David CLM is the exactly same for me > with Liberation Sans. What I understand is that Dagesh/Mappiq/Shuruk are diacritical symbols that cannot stand alone. It's a dot inside the symbol changing the Hebrew Vet into Bet. Similar in French for ^ or ´ in â or á. Khaled is the expert in this topic and he said in comment 20: "...inserted as <span> with a text style... we don’t join spans when shaping (long outstanding bug, might be the root for bug 61444)." So updating the font will not improve anything. Perhaps a topic to dive in for Hossein.