Description: This past November, I upgraded my home workstation from Fedora 25 to Fedora 26. In an Impress file that I created time ago, just before the November 2017 Fedora upgrade, all textbox text was properly positioned relative to graphic objects (lines, rectangles, etc.). (see attachment "after_save.png") Shortly after the November Fedora upgrade, all textbox text appears obviously shifted upward relative to graphic objects. ( attachments "shiftedtext_f26.jpg" and "shiftedtext_zoomed250_f26) Steps to Reproduce: 1. Open the Impress file created prior to Fedora 26. Actual Results: Text in textboxes will appear shifted vertically relative to graphic objects. Prior to Fedora 26, these would have aligned as desired. Expected Results: Text in textboxes should still appear properly aligned with graphic objects. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 5.3.7.2.0+ Build ID: 5.3.7.2-6.fc26 CPU Threads: 8; OS Version: Linux 4.14; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: en-US (en_US.utf8); Calc: group My workstation has an Intel Core i7-3770K CPU @ 3.5GHz x8 (x86-64) chip, but I don't think it's "itanium". My workstation has a GeForce GTX 660/PCIe/SSE2 graphics card. The problem shows up both in Gnome 3.24.2 and in Plasma (version unknown). User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Created attachment 139440 [details] shows the slide before the upgrade to Fedora 26.
Created attachment 139441 [details] shows the slide after the upgrade to Fedora 26.
Created attachment 139442 [details] shows the slide after the upgrade to Fedora 26, but zoomed in 250%
Created attachment 139835 [details] another example, shows text in textbox shifted vertically relative to horizintal line. When this was last modified and saved (mid-October 2017, under Fedora-25), the horizontal line was vertically centered in the empty line between the lines of text of the two text boxes that straddle the horizontal line. Now (mid-February 2018, Fedora-26), the text appears shifted vertically upward. This argues strongly (not proves) that the problem is not a corrupted Impress file.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 139915 [details] This is the Impress file from which screen captures 139440, 139441, and 139442 were created. This is the Impress file from which screen captures 139440, 139441, and 139442 were created. The file was last modified *before* my upgrade to Fedora-26. It has not been modified since.
Created attachment 139916 [details] This is the Impress file from which screen capture #139915 was created. This is the Impress file from which screen capture #139915 was created. This file was last modified before I upgraded to Fedora-26.
The first Feb. 14, 2018 attachment (drafty.odp) is also the Impress file involved in bug #105424 (textbox and rectangle fill transparency altered when file is loaded.). Feel free to share the Impress file with the developer(s) assigned to that bug. If I should attach the drafty.odp to that bug, please let me know.
For me, the font is something that I do not have installed: Nimbus Roman No9 L Bill: if the font is missing, its name will be in italics in the font selection dropdown. Is this the case on your Fedora? If so, you could install the Nimbus font and see what happens.
Hi Buovjaga, When I select a text box, Libreoffice shows that Nimbus Roman No9 L is used for the text in that text box. That font name shows in italics. But When I bring up the menu of fonts as though I wanted to change the font, Nimbus Roman No9 L is not among the choices of fonts. What I find curious is that Nimbus Roman No9 L is already installed on my system. It's in directory "/usr/share/fonts/default/Type1/": -rw-r--r--. 1 root root 43432 Feb 11 2017 n021003l.afm -rw-r--r--. 1 root root 101374 Feb 11 2017 n021003l.pfb So how do I get LibreOffice to once again make that available to me? Thank-you for your attention to this bug. Bill.
(In reply to Bill from comment #10) > What I find curious is that Nimbus Roman No9 L is already installed on my > system. It's in directory "/usr/share/fonts/default/Type1/": > -rw-r--r--. 1 root root 43432 Feb 11 2017 n021003l.afm > -rw-r--r--. 1 root root 101374 Feb 11 2017 n021003l.pfb > So how do I get LibreOffice to once again make that available to me? Aah, there we have the answer to the mystery: "Type1". Type1 fonts are no longer supported, but I found an OTF version of Nimbus: https://www.fontsquirrel.com/fonts/nimbus-roman-no9-l I hope it will work for you.
The reporter contacted me privately for some reason, asking for support on how to install the font. Well, I found Fedora has packaged the font: https://apps.fedoraproject.org/packages/urw-base35-nimbus-roman-fonts So they should be installable with dnf install urw-base35-nimbus-roman-fonts
(In reply to Buovjaga from comment #12) > The reporter contacted me privately for some reason, asking for support on > how to install the font My apologies: I thought it impossible to comment on a closed (resolved) bug. > Well, I found Fedora has packaged the font: > https://apps.fedoraproject.org/packages/urw-base35-nimbus-roman-fonts > > So they should be installable with > dnf install urw-base35-nimbus-roman-fonts Didn't work. I got this: bash.1[~]: dnf install urw-base35-nimbus-roman-fonts Last metadata expiration check: 1:23:58 ago on Thu 08 Mar 2018 08:09:17 AM MST. No match for argument: urw-base35-nimbus-roman-fonts Error: Unable to find a match bash.2[~]: "Apper" also showed a package "urw-fonts". When I try to install that, I get: bash.5[~]: dnf install urw-fonts Last metadata expiration check: 1:38:38 ago on Thu 08 Mar 2018 08:09:17 AM MST. Package urw-fonts-3:2.4-23.fc26.noarch is already installed, skipping. Dependencies resolved. Nothing to do. Complete! bash.6[~]: Is this the Type1 font that LibreOffice no longer supports? Anything else that I can try? One of my Impress slides has about 50 text boxes that I'd otherwise have to re-do one by one. Bill.
Sorry, I don't know as I do not use Fedora. The way that I install fonts besides from using package manager is that I simply download an archive like https://www.fontsquirrel.com/fonts/download/nimbus-roman-no9-l Then I extract the contents somewhere, double click the font file so it opens the font viewer and click "Install" (you can select for the whole system or only for your user). This is using KDE desktop.
Good evening Buovjaga, Download and de-compress worked fine. Tool to delete old fonts and install new ones kept hanging, requiring multiple kills and re-starts. But I think the replacement worked. I tested... I 1. launched Impress on my slide with many text boxes and graphic objects; 2. selected everything; and 3. changed the font to the new nimbus roman "NimbusRomNo9L". The text remains shifted upward relative to where it originally was and relative to graphic objects. I next 4. selected one text box in a way that made its border visible. The text appears shifted up within the border, almost to the top border. I launched the pre-problem screen capture of this slide, and made sure both that image and the current Impress session were showing the slide at the same size and zoom. Checking several graphic objects, I can confidently say that * the graphic objects have not shifted; * the text boxes themselves (the borders) have not shifted. Then I 1. again selected everything; and 2. changed the font to Liberation Sans (the default). The text still appears shifted vertically up relative to text box borders and graphic objects. Last year, did something change regarding the positioning of text within text boxes? It seems to me that the font is not the problem. It sure was a good guess. But I now accept neither that this bug is "RESOLVED", nor that this is "NOTABUG". Based on my past experience as a programmer and as a software team lead, I assume it is not my place to change this bug's status at this point in its life cycle. So I'm leaving those settings alone. Let me know if I should change the status, and I will do so. I am willing to help with this as I reasonably can, for example by testing and trying things, or send you screen captures or LibreOffice files. But I am limited. I cannot go back to previous releases/patches, or go ahead of what's in the Fedora repositories. By the way, I patched this system this afternoon, before doing any of the testing reported above. Thank-you for your attention, time, and effort. Bill.
Well, I would say the way the formulas have been created is brittle. You have the dividing line as a separate element and dT dz etc. going around them. Why not simply use the native formula functionality of LibreOffice? Then you would have {dT} over {dZ} as the formula syntax and everything would be robust.
So from the menu: Insert - Object - Formula and you can use the left sidebar to pick common arrangements. For the rotated ones, you just right-click the formula object - position and size - set rotation angle to 90,00.
Good evening Buovjaga, > Well, I would say the way the formulas have been created is brittle. It shouldn't be! Actually, I originally did first try the native formula functionality. Years ago, I was criticized for having the objects in my slides too small and too crowded. Those criticisms were correct. I learned the lesson. The results of using the native formula functionality were too crowded for my preferences in this case, too. So I brute-forced things to get them as I wanted. Someday, I should study and play with LibreOffice's functionality for aligning things. Regardless, I had things spaced and aligned as I wanted. Code changes last year should not have broken that. After seeing your latest comments, I re-tried the built-in formula functionality, and the results are still too crowded for my preferences. Some more experimentation showed me that things are mostly, but not fully, corrected if I set the text boxes so text is vertically centered within them. When I originally made the slide, I was not aware of such a choice. So whatever the default was is what I got. It was great when I made the slide. Did code changes last year change (default?) vertical positioning of text in text boxes? The problem that I reported in this bug is not limited to one Impress file. Another with no formulas also shows this bug; that Impress file and a screen-capture of its slide were attached to the bug last month. If I'm the only person experiencing this problem, then I'm ok with the bug being “RESOLVED” as “NOTABUG”, and I will brute-force fix the slides. Otherwise, this bug needs further attention. The slide with the formulas is also the subject of bug 105424 (textbox and rectangle fill transparency altered when file is loaded.). That problem still exists. Is that bug actively being worked? My apologies for the delayed response: I've been swamped for the past 3 days. Bill.
(In reply to Bill from comment #18) > Some more experimentation showed me that things are mostly, but not fully, > corrected if I set the text boxes so text is vertically centered within > them. When I originally made the slide, I was not aware of such a choice. > So whatever the default was is what I got. It was great when I made the > slide. Did code changes last year change (default?) vertical positioning of > text in text boxes? Support for the obsolete Type 1 fonts was removed in version 5.3. Different fonts have different metrics, so naturally the relation to the static dividing line will be different. Regarding the crowdedness of formulas, I'm not entirely sure what you mean. If you want to brute-force the layout in a bit more predictable way, you could: 1. Create the dividing line 2. Press F2 to enter text for the line shape and input your text 3. Right-click the text and click Text 4. Select the bottom center radio button in the Text Anchor thing 5. Adjust the Bottom value of Spacing to borders to 0,30 cm or similar You end up with a line that is tied with its text. Now you can create the bottom text as a separate object and position it "brute-force" below the dividing line.
One more hot tip: after creating a brute-forced formula, select all its elements by left-clicking them while pressing down Shift key. Then right-click the selection and click Group. Now you can move the formula around as a group. Right-clicking the group you can either Enter group (to temporarily edit the individual elements) or Ungroup (break them apart again).
(In reply to Buovjaga from comments 19 and 20) > Regarding the crowdedness of formulas, I'm not entirely sure what you mean. The numerator and denominator were too close to the horizontal fraction line. The left part and the right part were too close to the '=', "<", etc. These are merely personal preferences; nothing is objectively wrong or bad. My preferences are likewise when I code equations in software. I code C = 5.0 * (F - 32.0) / 9.0 rather than C=5.0*(F-32.0)/9.0 and if ((a != 0) && ((b * b) <= (4.0 * a * c))) rather than if((a!=0)&&((b*b)<=(4.0*a*c))) I tend to like space; for me, it improves readability. By the way, how would I get the horizontal spacing I like using the formula functionality? Your comment 19 suggestions are quite helpful, and led to more discoveries for me. The text can be made two-line, making the whole fraction a single object. I can get the extra vertical space I like around the horizontal line by making the vertical spacing of the text 1.5-space (between 1.15 space and double space). I can get very close to the vertical centering I want by clicking the center radio button rather than the bottom center radio button in the Text Anchor thing. A little vertical "tweaking" will still be needed depending on whether exponents or subscripts are used, whether lower or upper case is used, whether characters have bottom parts (as do 'Q', 'g', 'j', 'p', and 'q'), etc.. But I see in the Text Anchor functionality how to do that. I was already familiar with the grouping functionality. I should use it more in my slides. Thank-you for your help, Buovjaga. Bill.