Created attachment 79346 [details] The "h" that I had before "Libreoffice 4" Hello everyone. I have just installed LibreOffice 4.0.3 on ' Windows 7 ' and 4.0.2 on Linuxmint 12. I use the fonts "Linux Libertine G" and "Linux Biolinum G" (http: // numbertext.org / linux/) in their last version (16/01/2012). I also use the toolbar of typography (http: // extensions.libreoffice.org / extension-center / typography-toolbar). Problem is that certain options make no more effect, while they are always available. I discerned that 'h' cannot resemble like the attached picture. Sometimes, under windows, whole lines of characters disappear; leaving white lines. Have you already seen it? Is it a bug? Thank you beforehand for your answers LeChi
Created attachment 79347 [details] The "h" I had before Libreoffice 4
hm so to see this bug all I have to do is: 1. Install font 2. Open writer 3. type the letter 'h'? When reporting please give explicit steps on how to reproduce the problem, also be as descriptive as possible instead of general like "certain options make no more effect" as we have no clue what options you're talking about. Options in the extension you mentioned? Marking as NEEDINFO - please give us some steps to work with and say exactly what options don't work then mark as UNCONFIRMED. Thanks!
! To see the first bug (the "h" one). 1. install fonts "Linux libertine G" 2. install LibreOffice 4.0.x 3. write h 4. choose the font "Linux Libertine G:salt=1" see on page 2 of http://numbertext.org/linux/fontfeatures.pdf : salt Stylistic Alternatives ... h ... -> ... ... If you intall the plugin "typography toolbar", you'll have a toolbar with buttons for the differents options and you will not have to write the font "Linux Libertine G:salt=1". The buttons write :salt=1 for example. ? To see the second bug Choose "Linux Libertine G" as default (style...) write some lines and you will see disappearing some lines. Letters become white or transparent.
Please report the 2nd issue as a different bug, our FDO policy is 1 bug report = 1 bug, else it gets very tricky to triage and assign the bugs. Will look into first one to see if I can reproduce. Thanks!
1. install fonts "Linux libertine G" 2. install LibreOffice 4.0.x If you intall the plugin "typography toolbar", you'll have a toolbar with buttons for the differents options and you will not have to write the font "Linux Libertine G:salt=1". The buttons write :salt=1 for example. 3. write h 4. choose the font "Linux Libertine G:salt=1" or use typography toolbar. Bug : the "h" doesn't change ! For the result you might have, see on page 2 of http://numbertext.org/linux/fontfeatures.pdf : salt Stylistic Alternatives ... h ... -> ... h like attachement ... regards, LeChi
LeChi: is comment 5 the second bug? I mean report it completely as a new bug, not just in a comment? Or is that one still bug #1?
Thank you for reporting this issue! I have been able to confirm the issue on: Version 4.0.0.3 release Platform: Bodhi Linux 2.2 x64 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm this problem on an earlier release I am changing the version number as version is the earliest version that we can confirm the bug, we use comments to say that the bug exists in newer versions as well. Marking as: New (confirmed) Minor - doesn't prevent nor slow down high quality work, limits ability to use a single font in a specific way but a regression so marking as minor Low - won't affect many users at all, default for minor bugs Keywords - regression Whiteboard Status - bibisected + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
48ad81cc86b8858bfaa923854139e56fce18d28a is the first bad commit commit 48ad81cc86b8858bfaa923854139e56fce18d28a Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon Dec 10 22:13:54 2012 +0000 source-hash-98a77cef93663a0ae41dcc2c2858b418aeaaa40e commit 98a77cef93663a0ae41dcc2c2858b418aeaaa40e Author: Kohei Yoshida <kohei.yoshida@gmail.com> AuthorDate: Fri Oct 12 00:29:31 2012 -0400 Commit: Kohei Yoshida <kohei.yoshida@gmail.com> CommitDate: Fri Oct 12 01:33:01 2012 -0400 Hide (part of) the implementation. Change-Id: Ia750cb1a6234ff3566728b9e22def65febed4f5c :100644 100644 6f0beb12bf61f217308a44abe9617234ee46ef7e 72b1048aba8af254d8626f6b4ba70d2d6b1cb77c M ccache.log :100644 100644 992d343b80e3ff88fab56666f9c486a47311b4f8 ffcc8f08a763b42d08b69369a7e993ff8f071925 M commitmsg :100644 100644 2a36afcdd4cd10298e813e2a93e008f870286470 ac16f8708d0c429c902849041bc771709f84da42 M dev-install.log :100644 100644 9d044610b6f21324644dfcd369f82a9a6e4128e4 ae653365b8e2227d69ddb25af33d9c7d9274ca6e M make.log :040000 040000 57b4af94997fee7cc49f140adf3c7f55c507961e 6e275018c98bca5211cc400fe9f98f2e718d4976 M opt ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # bad: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect bad 114fd3b76bcba890e6d702d00cef910f1493c262 # good: [6af64581913aa7ce3fcf0890fe671830d416a6ea] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f git bisect good 6af64581913aa7ce3fcf0890fe671830d416a6ea # good: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f git bisect good 7e20e241c1d8819d8d5edb7894baeddde33f9d3a # good: [62b2ae5ee4cc77ad0b399c5a716ef526023d13ab] source-hash-e9960f36675a025c0536dec30ae56c50f4adecb1 git bisect good 62b2ae5ee4cc77ad0b399c5a716ef526023d13ab # good: [e7627bbadeb1ab2ff16757dd240d55c0023f8257] source-hash-5b195fbcf7a441aeb193f6abd08b877e580938e0 git bisect good e7627bbadeb1ab2ff16757dd240d55c0023f8257 # bad: [48ad81cc86b8858bfaa923854139e56fce18d28a] source-hash-98a77cef93663a0ae41dcc2c2858b418aeaaa40e git bisect bad 48ad81cc86b8858bfaa923854139e56fce18d28a
regression was introduced by graphite upgrade: commit f0d1a2e9927243bf650e280af9d9dcdaca8b603e Author: Martin Hosken <martin_hosken@sil.org> AuthorDate: Sat Oct 6 22:08:10 2012 +0700 Update graphite to 1.2.0 could one of our font experts take a look at this?
Looks like a Graphite since I get the same output with other Graphite-using applications. With OpenType the alternate h works, but not with Graphite.
I don't know how to do with opentype. can you explain ? Thanks
You can’t activate optional OpenType features in LibreOffice currently, unfortunately. But I’m not sure if this a Graphite or LibreOffice bug.
Adding Keywords: bisected to indicate that a commit has already been identified
This is not a general graphite issue but a bug in the LinLibertine_R_G.gdl. Here are the key parts of the code: class__salt__Stylistic_Alternatives_lookup_21_subtable_1 = p ("ampersand", "h", "beta", "theta", "kappa", "phi", "h.alt", "a.sc", "y.alt") ; class__salt__Stylistic_Alternatives_lookup_21_subtable_2 = p ("ampersand.alt", "h.alt", "uni03D0", "theta1", "uni03F0", "phi1", "h", "a.scalt", "y") ; Notice that h -> h.alt and also h.alt -> h if (salt && !(lng==SRB )) if (caps == 0) class__salt__Stylistic_Alternatives_lookup_21_subtable_1 > class__salt__Stylistic_Alternatives_lookup_21_subtable_2 / ^_; endif; class__salt__Stylistic_Alternatives_lookup_21_subtable_1 > class__salt__Stylistic_Alternatives_lookup_21_subtable_2; endif; The first rule here maps h -> h.alt and then leaves the cursor before the output h.alt. The rule then runs again, mapping h.alt -> h. I don't understand why the ^ is here and why the h.alt -> h mapping. The font is buggy for this reason.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Closing per comment 14.