In a now-closed related bug, Mike Kaganski said (comment #9 of bug 161373): > Note that the ODF documentation of font-family attribute [1] references SVG, > so the respective SVG documentation [2] applies. The SVG (and by extension, > ODF) syntax uses comma. But the UI uses semicolon. > > [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#attribute-svg_font-family > [2] https://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-family So, let us please settle this. This way or the other. Also, it wouldn't hurt for the ODF wording to either be more specific/explicit, or to add an example.
What should settle here? The UI uses semicolon. It is OK. The ODF has comma. This is also OK. I don't see a problem at all.
(In reply to Mike Kaganski from comment #1) > What should settle here? The UI uses semicolon. It is OK. The ODF has comma. > This is also OK. I don't see a problem at all. It's not that "the UI uses a semicolon". It's that the textual value you can provide, for a field defined in the ODF spec, can be a semicolon-separated list of values - but can't be a comma-separated list of values. LibreOffice is an ODF editor. And if it takes a string for some ODF field value, then it should accept the legitimate strings for that ODF field value, and interpret them properly. So if for some reason we insist on supporting semicolons - then at the very least, commas should be supported as well. Additionally, you have to do some sleuthing to properly realize ODF supports comma-separated typeface lists - which is confusing for people who see the semicolon used as a separator in the app itself.
The API too says for property CharFontName, "It may contain more than one name separated by comma." ODF uses SVG, that in turn uses CSS. And for CSS the separator is a comma. https://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-descriptions In my tests, the import field accepts both comma and semicolon. After reload a semicolon is shown. The file format is in both cases a comma. I do not see a problem with UI vs file format. Such different separators exist in other places too, e.g. the separators for inline array and the separator for function parameters. But I see as problem that API description and UI are different.
We don't put < and <text:p> in UI to put < and start a new paragraph. The UI vs. difference is legit and OK. This is not a bug.
As for "legit" - even if an _additional_ separator may be legit, refusing the ODF separator is not legit. People expect to be able to use it, for two reasons: 1. The spec says so 2. More importantly, as few people read the spec - it's what's customary in CSS and SVG, so it's what people know. As for "ok", it is very not-ok. I have not heard a single argument regarding why it is in any way better to accept semicolons rather than commas - and the other way around is simply easy and consistent. (Well, as much as font fallback is simple and easy anyway.)
(In reply to Regina Henschel from comment #3) > In my tests, the import field accepts both comma and semicolon. After reload > a semicolon is shown. The file format is in both cases a comma. Which is what I would suggest. NAB? No need for further input from UX.
(In reply to Eyal Rozenberg from comment #5) > refusing the ODF separator is not legit. People expect to be able to use it, > for two reasons: > > 1. The spec says so No. The spec only says that the file format uses it. Please stop implying that a detail of file format specification has *anything* to do with the UI. > 2. More importantly, as few people read the spec - it's what's customary in > CSS and SVG, so it's what people know. Doesn't matter at all. Just because of the above.