Created attachment 121694 [details] PDF files showing problem 15.12.27 file is OpenOffice created, 16.01.03 file is rewritten by Libreoffice When using LibreOffice/4.2.8.2$Linux_x86 LibreOffice_project/420m0$Build-2 installed with the Ubuntu 14.04 distribution on a 32 bit machine that were originally written by OpenOffice 4.1.1 on a 64 bit machine are reformatted. In particular the base font is changed. In particular the serif font is changed to a sans-serif font. Since Libreoffice and Openoffice share the same odt file extension for Writer files they should interoperate. Users cannot easily determine which software created the odt file and so can destroy other's work without prior knowledge they are doing so. FILEOPEN FILESAVE FORMATTING
LO v4.2.8 is quite old now and not longer supported. Could you test it again with a new version ?
Created attachment 121709 [details] Files reproducing the problem Tested against LibreOffice 5 and OpenOffice 4.1.1 and 4.1.2 on 64 bit and 32 bit Ubuntu installations. The 32 bit Ubuntu installation did not originally have the Gentium font installed. When LibreOffice 4.2.8 or 5 opened the file written in AOO4.1.1 it could not find the required font so substituted a sans-serif font of some sort. Two screen shots are provided to show that LibreOffice reported the Gentium font was being use even though some default sans-serif font was being displayed.
A font used to produce the document on the 64bit Ubuntu machine in OpenOffice4.1.1 was not present on the 32bit Ubuntu machine running LO 4.2.8. When LO 4.2.8 opened the document it substituted some default font but continued to indicate the correct (Gentium) font was being used. A user's expectation is that when there is a missing font on open: 1) The user should be alerted to a font substitution 2) The fact that another font has been substituted should be reflected in the toolbar. There was no way I could find to get the toolbar to show which font was being used in place of the original Gentium font. Additionally saving the document from LO will cause AOO to crash on open.This will be reported in a separate bug report also.
(In reply to kellnerp@earthlink.net from comment #3) > A user's expectation is that when there is a missing font on open: > 1) The user should be alerted to a font substitution > 2) The fact that another font has been substituted should be reflected in > the toolbar. There was no way I could find to get the toolbar to show which > font was being used in place of the original Gentium font. A substituted font will be shown in italics in the font dropdown. There is bug 61134 which requests for a tooltip to show the font that has been used as replacement. How else should the user be alerted?
When the problem originally arose there was nothing obvious to me that the font had been changed other than the text no longer fit the columns properly. On further investigation clicking on various portions of the text SHOULD have shown what font was being used in that area of the text, yet the text drop down did not change and continued to show the Gentium font instead of the sans-serif font that was being used. I am accustomed to the font drop down list to either show the actual font displayed or nothing to indicate the program can't figure out what is going on. I am not sure I would associate a font listed in italics with a substitution. And in any case the substituted font was not indicated at all. The original font was always indicated. This is shown in the screen shots.
Ok, I will hand this over to the design team to figure out.
Agreed, italic font is not salient enough. How about an icon next to the font name perhaps a red exclamation mark? I wouldn't color the background of this combobox since it draws too much attention to the control.
--"Make it more obvious that a font has been substituted"--as in the summary was done for LibreOffice for the 4.1 release (fixed for bug 50189). The only remaining work was to adjust the onmouseover tooltip to indicate the actual substitution font that is being applied. That is bug 61134. (In reply to kellnerp@earthlink.net from comment #5) > > I am accustomed to the font drop down list to either show the actual font > displayed or nothing to indicate the program can't figure out what is going > on. > > I am not sure I would associate a font listed in italics with a > substitution. And in any case the substituted font was not indicated at all. > The original font was always indicated. This is shown in the screen shots. Sorry for the confusion, but that is correct behavior, the Fontlist dropdown reflects the style applied to the document--but with an indication (itallic and tooltip) that font substitution was made for fonts not present on the system. Fonts that are named in a style, that have been substituted, are still as named in the style. You would not want to change a style unilaterally when only reviewing a file. Especially as we now provide support to embed fonts with documents. Rather if you are editing a document, you would need to implicitly select and apply a different style (now previewed in the dropdown list or the Sidebar deck). Or select and modify the style from the Sidebar and apply it globally--changing the font that way. If you think about it it makes sense, dealing with named styles--an ODF or OOXML document imported with a style including named fonts--displaying with alternate font substitution is benign. It may mangle the display, but the document structure (its style) remains intact until implicitly changed. Really wanted to say it is a RTFM issue--but just spent a moment hunting for it in the release notes and can't find that this neat feature actually got covered when introduced at 4.1 But, Heiko's correct, if possible, suspect that adding a suitable icon to the drop down list in addition to italicized font name would be reasonable.
(In reply to V Stuart Foote from comment #8) > reflects the style applied to the document s/document/paragraph/
Hmmmm, The workflow that brought this to light was that the file was created in AOO on one machine and opened from the cloud on another machine which had just had a fresh install of Trusty Tahr. So the font needed was not there and LO4.2.8 is the default install. The file was opened in a rush just to print it. So embedding fonts was not a possibility nor can it be expected when opening legacy documents or those written by other software. This was file interchange so the expectation that a nifty feature in one program is present and used in another is not really valid. I still have no idea what font was actually used as a substitute. The machine with a fresh OS install had the latest version of LO installed the next day and now displays the file more or less correctly. The obvious solution to me is that when opening a file where a font cannot be provided locally where needed, a popup should appear with a message like: Danger Will Robinson, the necessary fonts are not present on this machine to display it as last saved and a substitution will take place. Please install font(s) xxx to guarantee the documents formatting remains as intended. In addition, the nifty feature that isn't there is something like DOM inspector in Firefox. Like I said, I still have no idea what font was actually substituted. If you really want the user to be aware of a problem of this type, a red background in the fontlist and maybe a star next to styles in the style manager where there is an unfulfilled requirement (like different fonts used in different styles.) I use a number of Asian fonts and especially with Chinese, expecting the right font to be on another machine is a bad assumption. I may be making the migration to LO soon for that reason if the problem with Impress is solved.
Could someone write a brief summary what needs to be done in this bug (and not in bug 50189 and bug 61134)?
To resolve this a more *obvious* visual indication of the errant fontname in the combobox list is needed. Something more than simply applying italicized effect in system/desktop UI default font to the unresolved fontname. Possible options: 1. set a background color (yellow?) for the errant fontname as listed in combobox 2. add an alert icon (red exclamation, yellow triangle?) prepended to the fontname as listed in combobox 3. if applying background color, or inserting an alert graphic to tag a single combobox list item is not possible--then something more than fontname in italics would be needed. So, simply modify the string for the errant fontname and enclose it in visual brackets. Perhaps double-square or braces. =-Discussion-= To resolve bug 50189, at 4.0.1 the Toolbox controls were modified *[1][2] to test fontnames as either known or unknown--present on system or embedded in document, or not--and list in combobox. System fonts are obviously know, so these would be as provided from a paragraph or character style in ODF or other import stream. Fonts not installed, or misnamed in the imported document required some indication that the style was not valid. When known they are rendered in the combobox with system/desktop UI default font, or when "Show preview of fonts" (EnableFontWYSIWYG) is enabled, the fontname is rendered using the specific font. But, when unknown fonts are named in the paragraph and character styles of the opened/imported document the fontname is listed in the combobox with system/desktop UI default font and is given an italicized effect. Likewise when EnableFontWYSIWYG is set, the fontname remains system/desktop UI default italicized. Also when the font is unknown the Tooltip (basic, or extended) is altered and reads "Font Name, The current font is not available and will be substituted" This is functional but has two flaws: 1. that of bug 61134 enhancement--it is very helpful to know what font is being substituted for the unresolved fontname. So, provide that additional detail in tooltip, but possibly also in the character dialog (additionally need ability to search/select for the substituted text--that needs its own write up). 2. the issue here, is that indication in the UI of an unresolved fontname imported from the document styles is too subtle. It needs to be more *obvious*, both visual and as the tooltip (to support our Assistive Technology aspect). =-refs-= *[1] https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0-1&id=0376a4c13ccffa64c938c6361a337264ad8f2b67 *[2] https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0-1&id=17d86df23e7be3ab0a161f69ff0f703728e0e135
(In reply to kellnerp@earthlink.net from comment #10) > The obvious solution to me is that when opening a file where a font cannot > be provided locally where needed, a popup should appear with a message like: > > Danger Will Robinson, the necessary fonts are not present on this machine to > display it as last saved and a substitution will take place. Please install > font(s) xxx to guarantee the documents formatting remains as intended. I've suggested this be shown as an infobar in bug 78186.
(In reply to Heiko Tietze from comment #7) > Agreed, italic font is not salient enough. As the default look of the text in the combobox is normal and black, maybe a suitable change would be for it to be italic and red. Possibly even adding bold or bold without italics. > How about an icon next to the font name perhaps a red exclamation mark? Dont think this would be suitable and also think it would be difficult to add an icon to the standard combobox control. @Samuel, Maxim: Any input on this? > I wouldn't color the background of this combobox since it draws too much attention to the control. Totally agree.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
One thing that the developer needs to bear in mind is that when a font substitution is made is that the person opening the document may not be the person who created the document and may not be using a system at all similar to the system that created the document.The ultimate goal when re-opening the document is to have it appear as it did when created.
*** Bug 88438 has been marked as a duplicate of this bug. ***
*** Bug 114650 has been marked as a duplicate of this bug. ***
Proposal has been mad in this blog post https://design.blog.documentfoundation.org/2018/02/18/improvements-font-listing/. Removing UX to attract devs.
(In reply to Heiko Tietze from comment #19) > Proposal has been mad in this blog post > https://design.blog.documentfoundation.org/2018/02/18/improvements-font- > listing/. > > Removing UX to attract devs. Actually that was the font listing portion, improving the font fallback/substitution was this blog (and bug 104667) https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/ But that is ready to move forward with dev effort as well...
The blog post doesn't really deal with the issue reported here. Since odt is a document standard that at least one other software can originate there are many scenarios that can happen not under the user's control either as the originator of the document or as a recipient. The creator can have created a document on software X either currently or long in the past. That document can have fonts r,s,t in in it. The document can be currently or in the future opened on another machine with software Y and fonts r,s but not t. Software Y can substitute a font for t, let's say font m. This may or may not allow the document to visually appear the same or the layout to be effectively the same. Visually appearing essentially the same is a critical issue (the reason why pdf was invented). If the document is in an edit cycle between users, fonts can be conceivably be changed repeatedly and not under anybody's control. If the document was distributed to a number of viewers each viewer could potentially see the document differently because they open it with different software on systems with different fonts. But we are here talking just about LibreOffice which may or may not have created the document which may be current or legacy. The user needs to be alerted when the file is opened that font(s) have been substituted and where. A list of substitutions in the options is not going to give the user the necessary visibility into what is happening to the document and what and where in the document appearance is affected. What in LibreOffice would give the user a superior view into what is happening in the opened document(s)? Is this a document control issue as well as a font control issue?
(In reply to kellnerp@earthlink.net from comment #21) > The user needs to be > alerted when the file is opened that font(s) have been substituted and > where. The first image notifies the user. Somewhere below we make a proposal on the substitution. > A list of substitutions in the options is not going to give the user > the necessary visibility into what is happening to the document and what and > where in the document appearance is affected. Please elaborate how you would deal with the detailed information.
*** Bug 128025 has been marked as a duplicate of this bug. ***
*** Bug 146123 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #22) > (In reply to kellnerp@earthlink.net from comment #21) > > The user needs to be > > alerted when the file is opened that font(s) have been substituted and > > where. > > The first image notifies the user. Somewhere below we make a proposal on the > substitution. > > > A list of substitutions in the options is not going to give the user > > the necessary visibility into what is happening to the document and what and > > where in the document appearance is affected. > > Please elaborate how you would deal with the detailed information. The two pieces of information a user would need in the event that a font has been substituted are what the old font was and where in the document said substitution occurred. Knowing where the substitution occurred I think would be doable in a similar way to revealing other hidden information to users, e.g., turn on some kind of changed font highlighting similar to what is done for fields and paragraph marks, etc. Once the user knows where the substituted fonts are then placing the cursor on them would reveal what font was substituted.
*** Bug 149779 has been marked as a duplicate of this bug. ***