Created attachment 190895 [details] One word sample document In a manuscript I'm writing, I found sections of text with somehow mixed fonts, after copying text from one document into another. Normally, if one selects an area of text, the font field in the UI will tell you the font name, and beside it, the font size. If there has been a change to the font, or the size, the field helpfully blanks out to indicate there's more than one. But it turns out one can't reliably use this to find when the font has changed. I have attached a one word example file, containing the text: squalor. 1) Select any of the letters in the word: UI indicates the font is Georgia. 2) Select the period: UI indicates the font is Georgia. 3) Select any span that includes any of the word and the period: font name blanks (usually means multiple fonts). Expected result: font field only blanks when there are mixed fonts. It's not possible to clear direct formatting (if that's the source of the problem) as then I'd lose all italics. I wanted to discover what the unwanted font was, but it seems there is no font change in this case, and I can't rely on the UI to indicate when there really is a mix of fonts in a span of text. This will make it very hard to clean up the MS. My guess is that Writer has constructed text styles with equal definitions but different names (perhaps as a result of copying between documents), and this is crippling this aspect of the UI. Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Created attachment 190897 [details] A simplified FODT The attachment emphasizes the markup that creates the phenomenon. I don't know what specifically creates that, but the issue is because there are two font definitions referring to Geogia font family, one with 'style:font-family-generic="roman"', and one without. They are both used in the document; and selection including both shows a blank font field.
UX team: any idea how strange issues like this could be made more obvious?
Only by showing the font family. But I see the difference also in the styles inspector, although have to go through the characters step-by-step. The layout also changes if you remove all DF (ctrl+M). In the end it is a matter of using styles properly - and to paste without formatting. => NAB
Installing Georgia font fixed it for me. Downloaded the zip from https://www.downloadfonts.io/download/georgia-estate/, unzipped it, placed the font ttf file in `/usr/share/fonts`, then run `fc-cache` Version: 7.6.3.2 (X86_64) / LibreOffice Community Build ID: 60(Build:2) CPU threads: 8; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US 7.6.3-3 Calc: threaded
Nope it didn't. Having or not having Georgia font doesn't change anything. Also for some reason, Georgia is not showing in the fonts dropdown, even after fc-cache, and a reboot.
We discussed the topic in the design meeting. In fact the font family remains constant if the font is not substituted (on Windows). So we recommend to treat the issue as bug and to not touch this attribute (or keep the font family for all text). Showing the information beyond what we do with the Styles Inspector is pointless and not actionable.
(In reply to Sahil Gautam from comment #5) > Nope it didn't. Having or not having Georgia font doesn't change anything. I also see the bug manifest with the simplified ODT, Georgia installed, and: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US (In reply to Heiko Tietze from comment #6) > So we recommend to treat the issue as bug and to not touch this > attribute (or keep the font family for all text). I don't quite understand the recommendation. In particular, is the "or" an explanation of the text outside the parentheses, or is it an alternative? Please clarify.
(In reply to Eyal Rozenberg from comment #7) > Please clarify. I don't know what exactly causes the trouble, so I guess. There is no "or" in fixing the bug.
(In reply to Heiko Tietze from comment #3) > Only by showing the font family. But I see the difference also in the styles > inspector, although have to go through the characters step-by-step. The > layout also changes if you remove all DF (ctrl+M). > > In the end it is a matter of using styles properly - and to paste without > formatting. => NAB Pasting without formatting means you lose all formatting and style information, as far as I know. That seems to imply that copy and paste, including formatting, is not a recommended action with Writer. That seems a strange recommendation for a word processing program. Perhaps I misunderstood your point?
(In reply to Luke Kendall from comment #9) > Pasting without formatting means you lose all formatting and style > information... That seems to imply that copy and paste, including > formatting, is not a recommended action with Writer. (In reply to Luke Kendall from comment #0) > In a manuscript I'm writing, I found sections of text with somehow mixed > fonts, after copying text from one document into another. Obviously copy/paste with formatting is a typical source of layout issues. If the source of rich text is your browser, how should the text processor merge the formats, for example? Could imagine something like Calc's paste special with attribute classes like font (name, weight, size), font effects (upper/lower case, color, spacing), paragraph layout (margin, spacing, indentation), alignment, lists, etc. (details up for discussion). But that wouldn't solve the problem with font family. Point is that we don't allow setting this attribute manually but rather decide per chosen font name what to use. I see no elegant way to solve your problem (except to paste unformatted).