When I am offered a font in the font selection dialog, I want to know which parts of the Unicode space (say, the basic multilingual plane) they cover. More precisely, I want to know which written scripts I can use them for. At the moment, this seems like anyone's guess, and when you use a font which is missing the glyphs you need, typically, some default is used; and since we don't know when/what fallback fonts are used (see bug 151121), we're left kind of in the dark.
Horrible idea. And we already provide for this with the Special Characters... dialog. Selecting the Font from the listbox there will refresh the adjacent listbox for the font's covered Unicode blocks. And which further can then be selected to move the character chart focus to the start of the block. You can pick from there.
(In reply to V Stuart Foote from comment #1) > Horrible idea. But I haven't even given a concrete idea, how can you know it's horrible beforehand? And - how am I supposed to know if the fonts LO offers me even have the (combination of) languages I'm trying to write in? The only thing LO is willing to tell me is whether it's a "Western", "Complex", or "Asian" font family. > And we already provide for this with the Special Characters... dialog. Hmm, yes, that's true, that dialog doesn't show the silly fallback text. But it's very inconvenient for someone to have to go back and forth between the two dialogs, to check. Possible ways to get this indication: * Filter the language-family font-family-list by chosen language and features. * Sub-option: Same, but allow requiring multiple languages. * Stylistic indication of which fonts in the language-family font-family list support the chosen language. * Have some button or hover-over-able widget open up a list, perhaps bulleted by symbolic icons, of the BMP regions covered by the font family. i.e. essentially the same list from the Insert Special Character dialog. Orthogonally to the above: * Add ability to toggle the fallback font use in the preview area of the font selection dialog, on or off.
(In reply to Eyal Rozenberg from comment #2) > (In reply to V Stuart Foote from comment #1) > > Horrible idea. > > But I haven't even given a concrete idea, how can you know it's horrible > beforehand? > Because the suggestion in the 'Font list' context is that the drop list itself should included those details--they do not belong there in the UI! > And - how am I supposed to know if the fonts LO offers me even have the > (combination of) languages I'm trying to write in? The only thing LO is > willing to tell me is whether it's a "Western", "Complex", or "Asian" font > family. > > > And we already provide for this with the Special Characters... dialog. The Special Character Dialog (SCD) is where LibreOffice's delivery of these Unicode font coverage issues belong. I'd also argue that detailing font fall back and even font replacement (the Tools -> Options -> Fonts panels) likewise need linkage from the SCD. Attempting to provide such details via the font selection listboxes (e.g. with tolltip and pop-up dialogs) is recipe for UI garbage. And is a "Horrible idea". When you are assigning the font is not the time (or place in the UI) to be identifying the font to use.
> When you are assigning the font is not the time (or place in the UI) to be > identifying the font to use. ... identifying the font feature/language coverage to use.
Don't see a clear use case. And in general I would keep the font selection mechanism as simple as possible and let the OS provide font management functions. If necessary a special dialog perhaps realized via extension could give insights to font attributes.
(In reply to Heiko Tietze from comment #5) > Don't see a clear use case. I gave the use case in Comment #2: I need to know whether the font family on the list covers the language I want to write in. The preview area does not provide that information, nor even a good hint of whether that's the case.
(In reply to V Stuart Foote from comment #3) > Because the suggestion in the 'Font list' context is that the drop list > itself should included those details--they do not belong there in the UI! > > The Special Character Dialog (SCD) is where LibreOffice's delivery of these > Unicode font coverage issues belong. > > When you are assigning the font is not the time (or place in the UI) to be > identifying the font to use. (In reply to Heiko Tietze from comment #5) > in general I would keep the font selection > mechanism as simple as possible A single reply to all of these comments... A font selection dialog (FSD; versus, say, a font choice text box elsewhere in the UI) is not intended merely for the user to communicate their apriori choice of font - but rather to allow the user to make the choice while in the dialog. While its true that this dialog is not a full-fledged "font explorer" - it does presume to allow making that choice - via the preview area. The idea is that you see what the font looks like for some piece of text, and make your decision. But this has two underlying assumptions: 1. That the font you see in the preview area is the actual font you're selecting (rather than some kind of fallback). 2. (When assumption 1 holds) That if the font covers the glyphs used for the preview area, then it covers all glyphs for all of the languages in that language group you intended to use. (*) These assumptions almost always hold if you're writing English, and usually hold if you're writing German or other Latin-based alphabets. But that is absolutely not the case for other languages, especially in CTL language-group. Let's ignore CTL for a second though. Suppose I want write in Russian. Some fonts have glyphs for the Cyrillic alphabet, some don't. I cannot choose from amongst a set of fonts unless I know that they are fonts which cover all glyphs related to the Russian language; and the font dialog does not let me know that this is the case. You both seem to suggest that I should first open the SCD and check. That is a weird suggestion even if it were valid - to use a not-directly-linked dialog, from another menu, which officially has an entirely different purpose, as part of the font selection process. But even ignoring its weirdness - I can't use the SCD to choose between fonts, since I don't see how a stretch of text looks in a given font; and I can't use the FSD to choose between fonts since a great many of the fonts I'm offered I can't actually use. And I also cant use the FSD since the stretch of text presented in the preview is not in my language of interest. (Yes, I can first type some text in Russian, then select it, then launch the FSD, and I'll get the preview I want, but that's cumbersome and newbie users won't even think of doing that. And there's the fact that the preview might not actually use the font itself but some fallback.) So even by LO's current effective standard of what's necessary for selecting a font, this information needs to be related somehow. In fact, _some_ of it is already related - by placing some fonts in the Western language-family list and other fonts in the CTL language-family list: That's a partial indication of which parts of the Unicode plane are covered by the font family. What is necessary is additional refinement - somehow - to let the user choose only from amongst the fonts relevant to the languages they intend to write in. Stuart worries about avoiding UI garbage. I agree that this is a danger and that careful thought is necessary. But something needs to be done, and users cannot be expected to do trial-and-error font selection. So how about we focus on my first possible idea: * Filtering the list of fonts by the choice of language already present underneath the list: Only those fonts offering all glyphs associated with the chosen language will be displayed. * (Possibly) allowing the choice of multiple languages in the widget(s) below the font list, for stricter filtering. > If necessary a special dialog perhaps realized via extension > could give insights to font attributes. If something is necessary, then it needs to be in LO itself. If it's nice-to-have it may belong in an extension. I hope I've managed to convince that LO's own "standard" for what's necessary for font selection also necessitates some UI change to avoid mistaken selection of language-incompatible fonts.
@Eyal You're clearly wanting to achieve something and struggling with fonts/ font replacement. I haven't taken much interest in fonts (or font family's etc). I'm only aware of font substitution because I encountered documents on the bug tracker with exotic fonts. (And couple of layout bugs caused by font substitution). So I really lack the understanding of the whole topic.. Would you mind to share what you're working on (some integral for all recent reports). And what the issues are you're encountering. It sounds highly specific what you want to do from a distance. And those requests are highly technical .. I lack knowledge of limitations of fonts (how many symbols each font supports). And I have surely no clue about font issues with Hebrew/Arabic/Chinese/Japanese fonts (and font family's).
Created attachment 182649 [details] 3 Screenshots of CTL-family fonts in the font selection dialog @telesto To illustrate what CTL language users are facing here, please have a look at the three screenshots in the attached zip files. Each screenshot corresponds to the selection of a different CTL font (family). Now, tell me what you can discern about the differences between these three fonts for Arabic script. When you answer me I hope my reply will make things clearer for you.
(In reply to Eyal Rozenberg from comment #9) > Created attachment 182649 [details] > 3 Screenshots of CTL-family fonts in the font selection dialog Ah, OK "font selection dialog" = Format -> Character dialog -> Font tab with Complex Text Layout Turned on in Tools -> Options -> Language settings -> Languages (not active by default with Western locale) You ask yourself, does the Hebrew font cover the same characters as the Western font.. Now I get it :-). Seems to be a PITA to figure out.. I guess that there are cases that the lack of a certain character to be trivial. You probably want same kind of side-by-side special character dialog if there are mismatches; and for which symbols.. How is this problem handled with other application? Like MSO?
(In reply to Telesto from comment #10) > > How is this problem handled with other application? Like MSO? It is not, nor should it be. And that is the issue. There are already some fabulous programs for doing font selection based on its Unicode coverage. Point being these font management features do not belong in an office product bcz they are handled better either by os/DE provided apps--eg fontconfig and the fc- utilities or the ancient xfd or xfontsel, or by any number of GUI based character map utilities including the GNOME Character Map. If on Windows give Andrew West's BableMap a drive [1]. It has *ALL* the features that Eyal is asking for, but it is specialized software. In fact the dev spun off the font manager from his text editor BablePad bcz font management and analysis does not belong with the editor. And of course there are commercial products that provide similar function--on Windows High-Logic's MainType for example. =-ref-= [1] https://www.babelstone.co.uk/Software/BabelMap.html
(In reply to Telesto from comment #10) > You ask yourself, does the Hebrew font cover the same characters as the > Western font.. Now I get it :-). Oh, you made the wrong mistake :-P First of all - that's meaningless. There's no need for the font used for Arabic (not Hebrew, the screenshots has Arabic sample text despite Hebrew being selected as the language which is another bug I should file I think) to cover the same characters as the one of Western scripts. In fact, they might as well be disjoint. I was expecting you to say "the three fonts look almost similar in Arabic" In fact, _none_ of the three fonts in the screenshots supports Arabic, or Hebrew, at all. It only looks like they do, and it even looks like the three fonts are slightly different - as apparently somehow the glyph spacing is taken from the font's general meta-data, so the result doesn't look the same. If you choose one of these fonts for CTL, you'll just get some fallback font glyphs used, and you would not be told which font (family) those fallback glyphs are taken from. This is a problem for people, because: * The user believes a certain font supports Arabic, while it doesn't. * If the user sends this file to another person, that other person is likely to see it rendered differently - depending on which OS, VCL and font choices they have, which in turn determines the fallback font used. * The chosen font may cover one CTL language's range of glyphs but not another one's. Even if the preview corresponded to the chosen language - how would the user choose a font which has glyphs for both, say, Hebrew and Arabic? Or Arabic and Shahmukhi (Punjabi)? The third problem affects fewer people - but still, quite a few. The first two problems are faced by RTL/CTL users all the time. In fact, all three problems affect even people who only use LTR/Western languages, as in the example I gave with Cyrillic, above.
What bothers is the wish to get some very broad information at a control that is simply a picker. But if we turn it around and show incongruencies it makes sense. We draw the font name in italic if not available on the system and could so something similar if the listed font item unicode coverage does not match the paragraph language.
(In reply to V Stuart Foote from comment #11) > There are already some fabulous programs for doing font > selection based on its Unicode coverage. Point being > these font management features do not belong in an office > product bcz they are handled better either by os/DE > provided apps--eg fontconfig and the fc- utilities or the > ancient xfd or xfontsel, or by any number of GUI based > character map utilities including the GNOME Character Map. You seem to be suggesting LO remove its font selection dialog, or the font selection pane of the font dialog, entirely... Font selection belongs in (almost) any application in which the user needs to select fonts. And while complex font exploration may perhaps be better suited for a different app, it is not a complex or esoteric task to want to choose a font which can be used for the language you want to write in; and my office productivity app must help me avoid choosing fonts (or font families) which don't cover the language I'm making the choice for. > It has *ALL* the features that Eyal is asking for, I asked for just one thing. And I'm not even the one who asks for it; I would argue every user asks for it: Not misdirected into choosing an invalid font for the language I'm writing in.
(In reply to Heiko Tietze from comment #13) > What bothers is the wish to get some very broad information at > a control that is simply a picker. But if we turn it around I just need to know the font I'm selecting covers my language(s). The title may overstate what's necessary, I've rephrased it. > unicode coverage does not match the paragraph language. There's a language choice underneath the picker - I believe it's better to go with that one. That can also allow the user to require coverage of multiple languages or no language. I haven't made up my mind regarding whether I like italicizing, graying-out or filtering-out better.
I don't like "avoid selecting" and would prefer better feedback (that we have). Fiddling around with the list of available fonts makes it unclear for the user what is possible. Imagine a font is available for one paragraph style but not for another.
(In reply to Heiko Tietze from comment #16) > I don't like "avoid selecting" and would prefer better feedback (that we > have). You mean "than we have", right? > Fiddling around with the list of available fonts makes it unclear for > the user what is possible. Imagine a font is available for one paragraph > style but not for another. How would this happen, unless you choose a different language? And if you do that, you would probably not be surprised to see a different list of fonts. If we go for feedback-only, LO would still be frustrating you, making you have to guess which fonts covers a language until you get it right.
(In reply to Eyal Rozenberg from comment #17) > > How would this happen, unless you choose a different language? And if you do > that, you would probably not be surprised to see a different list of fonts. > > If we go for feedback-only, LO would still be frustrating you, making you > have to guess which fonts covers a language until you get it right. You currently don't have to guess anything, just open the Special Characters dialog and review the character chart directly, even select the specific Unicode character block range to explore for a particular script. You'll see what the font "covers".
Hello, I add my thoughts, maybe it can help to find a solution. I have the same problem to find the correct font for my targeted languages. I have created a list of alphabets I need. I put it in a cell, and I apply the font I want to test, and I analyze the result and compare with other cells/fonts. But it's borring to not have a "direct" function that do the job: for example we could have a parameter in the options saying what are our preferred languages, and then the font list indicate which font is (un)compatible. After reading the discussion, it seems complicated to obtain this result. In my opinion, there is still a little thing that could help a lot. In the attached document CaptureFontPreview, we can see the current font preview in Calc: - in a combobox, we have the name of the font, and sometimes a list of characters (who has made the choice for these letters?) - in a dialogbox, we have a textbox with "lorem ipsum" (who has made the choice for this text?). My proposition: - the user can parameter his "lorem ipsum". For example, I write "abcáàâä αβγάέή абве́а́я́ çœæñãõ åøþđð őű iIğ" in this new parameter, this is a list of letters for latin, grec, cyrillic, and specific european countries. - then the dialogbox displays the personnalized "lorem ipsum", and I can see immediately if the font support my targeted languages, before validating the change. I can even see if the glyph has the right shape for my need. - and it would be great if this personnalized "lorem ipsum" could be displayed in the font combolist, as a third column. Tanks for your help and comments!
Created attachment 196392 [details] Capture Font Preview in Calc
(In reply to Manu from comment #19) > ... > My proposition: > - the user can parameter his "lorem ipsum". For example, I write "abcáàâä > αβγάέή абве́а́я́ çœæñãõ åøþđð őű iIğ" in this new parameter, this is a list > of letters for latin, grec, cyrillic, and specific european countries. > - then the dialogbox displays the personnalized "lorem ipsum", and I can see > immediately if the font support my targeted languages, before validating the > change. I can even see if the glyph has the right shape for my need. > - and it would be great if this personnalized "lorem ipsum" could be > displayed in the font combolist, as a third column. > Using the Calc dynamic font preview feature is one efficient way--though as mentioned the font combobox is not filtered, so while "browsing" for a font to use there is a lot of "chaff" fonts to pass over. And, you do know that you can simply highlight any representative text then open the Character... dialog and directly review how that text is rendered, right? Applicable in any of the modules. Placing user configurable strings into the fontlist box widget would force the widget even wider than its two column format (of font name and generated sample where applicable). UX of blocking UI and document canvas. Possibly an *optional* alternative of displaying user string(s) in a mouseover/kb focus tooltip popup for the font combobox might be functional, but it seems awfully contrived.
(In reply to V Stuart Foote from comment #21) > Using the Calc dynamic font preview feature is one efficient way--though as > mentioned the font combobox is not filtered, so while "browsing" for a font > to use there is a lot of "chaff" fonts to pass over. Only Calc has this live preview feature with the combobox. Doesn't work with Writer. And there is two bugs with calc live preview with the combobox, so maybe oneday it would be disactivated, or enabled/disabled by the user (if someone want to fix these problems)... > And, you do know that you can simply highlight any representative text then > open the Character... dialog and directly review how that text is rendered, > right? Applicable in any of the modules. That's true, I didn't know it was possible to personnalize the lorem ipsum that way. Therefore the feature already exist, in calc and writer. Please don't break it! Just a comment: this is only single line. Maybe it could go on 2 lines so we can see the interference between the two lines (with ascenders and descenders)... > Placing user configurable strings into the fontlist box widget would force > the widget even wider than its two column format (of font name and generated > sample where applicable). UX of blocking UI and document canvas. That's true, but the combobox list in Writer recover already the document, so can't see a lot already... > > Possibly an *optional* alternative of displaying user string(s) in a > mouseover/kb focus tooltip popup for the font combobox might be functional, > but it seems awfully contrived. Good idea!
(In reply to V Stuart Foote from comment #18) > You currently don't have to guess anything, just open the Special Characters > dialog and Stop right there... I can't. When the user is selecting a typeface, they not looking at the Special Character Dialog. And the procedure for selecting a typeface should not involve opening a dialog to figure out which typefaces are relevant, saving that in your brain, then filtering the list of typefaces in the combo-box accordingly. (PS - Have started using the term typeface in various places on Bugzilla to clarify that I don't mean the font size; I would say "font family" like in the CSS property but some people get confused by that term.)
(In reply to Manu from comment #19) > But it's borring to not have a "direct" function that do the job: for > example we could have a parameter in the options saying what are our > preferred languages, We already have it: The font selection dialog includes language indications. > and then the font list indicate which font is (un)compatible. Either that, or a proper filter. > After reading the discussion, it seems complicated to obtain this result. Not that complicated. At worst, it could be a toggle for those who would rather avoid the heuristic. > In my opinion, there is still a little thing that could help a lot. We must not give up on an appropriately decorated or filtered list of fonts. You can make alternative suggestions, like the ability to customize the sample text in a different issue. I support that, but not instead of resolving this one.
And - marking this as a bug. Users expect to see a list of valid typefaces they can use, but many, if not most, of those they are offered - are unusable. That's a bug, albeit in the form of a historical design mis-consideration.
(In reply to Eyal Rozenberg from comment #23) > (In reply to V Stuart Foote from comment #18) > > You currently don't have to guess anything, just open the Special Characters > > dialog and > > Stop right there... I can't. When the user is selecting a typeface, they not > looking at the Special Character Dialog. And the procedure for selecting a > typeface should not involve opening a dialog to figure out which typefaces > are relevant, saving that in your brain, then filtering the list of > typefaces in the combo-box accordingly. I maintain my objection to doing more than the SCD. Nor should we incur the performance overhead of dynamic font browsing, like available to a cell selection in Calc, across an entire ODF document (text, drawing, presentation). Dynamic rerendering of anything more than current selection, or current Paragraph would be a problem. Oh and by definition this *is* an Enhancement request, asking for new development.
(In reply to V Stuart Foote from comment #26) > Nor should we incur the performance overhead of dynamic font browsing, like > available to a cell selection in Calc, across an entire ODF document (text, > drawing, presentation). Dynamic rerendering of anything more than current > selection, or current Paragraph would be a problem. Agreed. The ask in this bug is static, not dynamic. Of course, there's a one-time cost of determining which language is covered by which fonts, and that's something we would like delay until the first time the user needs to choose a font in that language (although we could do it earlier); and there's the need to update the categorization/filtering when new fonts or versions of fonts are introduced. But other than that, static. > Oh and by definition this *is* an Enhancement request, asking for new > development. No, that's not the definition of an enhancement. Bugs often require new development - sometimes even large amounts of it, when functionality which is already supposedly offered to the user isn't actually, or properly, available; or when functionality must necessarily be offered to the user is missing. In this case - users need to be able to select a typeface which they can use with their chosen language - chosen on the same dialog. And at the moment, users don't have that possibility. > I maintain my objection to doing more than the SCD. That's an easy position to take when 99% of Western language typefaces cover the English alphabet. You Westerners already have typeface selection working properly - we don't.
(In reply to Eyal Rozenberg from comment #27) > (In reply to V Stuart Foote from comment #26) > > Nor should we incur the performance overhead of dynamic font browsing, like > > available to a cell selection in Calc, across an entire ODF document (text, > > drawing, presentation). Dynamic rerendering of anything more than current > > selection, or current Paragraph would be a problem. > > Agreed. The ask in this bug is static, not dynamic. Of course, there's a > one-time cost of determining which language is covered by which fonts, and > that's something we would like delay until the first time the user needs to > choose a font in that language (although we could do it earlier); and > there's the need to update the categorization/filtering when new fonts or > versions of fonts are introduced. But other than that, static. > Again that information is already presented in the SCD! It is trivial to statically identify if a font has script/language coverage by its listed coverage of Unicode locale block. Those same Unicode block coverage details could allow query filtering of the fontlist. But filtering of the fonts exposed on SCDs fontlist combobox in response to a script or locale entry is not implemented. Presumably that same static filter/query could be implemented for the font list combobox in other elements of the UI. > > Oh and by definition this *is* an Enhancement request, asking for new > > development. > > No, that's not the definition of an enhancement... Of course it is. > Bugs often require new > development - sometimes even large amounts of it, when functionality which > is already supposedly offered to the user isn't actually, or properly, > available; or when functionality must necessarily be offered to the user is > missing. > > In this case - users need to be able to select a typeface which they can use > with their chosen language - chosen on the same dialog. And at the moment, > users don't have that possibility. > And that *is* a feature request! But whatever... > > I maintain my objection to doing more than the SCD. > > That's an easy position to take when 99% of Western language typefaces cover > the English alphabet. You Westerners already have typeface selection working > properly - we don't. Uh, sure.
(In reply to V Stuart Foote from comment #28) > Again that information is already presented in the SCD! It is trivial to > statically identify if a font has script/language coverage by its listed > coverage of Unicode locale block. If you think it's trivial trivial, then great, the computation isn't expensive and it's not an issue to filter out or mark the typeface which doesn't support a language. Of course, forcing the user to go through the SCD every time - and actually, go through it as many times whenever they need to make a choice of typeface, is out of the question. > Those same Unicode block coverage details could allow query filtering of the > fontlist. But filtering of the fonts exposed on SCDs fontlist combobox in > response to a script or locale entry is not implemented. > > Presumably that same static filter/query could be implemented for the font > list combobox in other elements of the UI. 1. I'm not sure I would filter the font combobox in the SCD itself, we're talking about the Font selection tab of the CS dialog, and the other typeface combo-boxes (formatting toolbar, properties sidebar). But that's bikeshedding and others might feel differently. 2. The filtering, or higlighting/marking, not being implemented - is the bug. It needs to have been. > Of course it is. > > And that *is* a feature request! But whatever... I'll take the "whatever" :-)
(In reply to Eyal Rozenberg from comment #24) > (In reply to Manu from comment #19) > > we could have a parameter in the options saying what are our > > preferred languages, > > We already have it: The font selection dialog includes language indications. > > > and then the font list indicate which font is (un)compatible. > > Either that, or a proper filter. > > We must not give up on an appropriately decorated or filtered list of fonts. > You can make alternative suggestions, like the ability to customize the > sample text in a different issue. I support that, but not instead of > resolving this one. I think there is a misunderstanding, and I think I understand why you believe there is a bug. I will try to explain even if I'm not a specialist, therefore if I'm wrong I apologize. When we observe the Character dialogbox, we see in the tab "Font" (or Typeface): - 3 tabs for the writing system : Western, Asian, Complex - the Font list (with the textbox for research) - the properties for the font: style, size, language, functionalities This is the misunderstanding in my opinion. The combobox Language is not a filter, it is a property we assign (like the size) to the selected font. I explain: in the font file, the definition of each shape can be unique or dependant of the language. This is a problem created by Unicode. Everyone know that both latin and cyrillic letter A have the same shape, but not the same code because there is a latin block (set of characters) and a cyrillic block. But for some reason, one letter could have a different shape in two different languages and this is the only difference between these two languages, that's why Unicode doesn't have a specific block (or character code) for the second language, and that's why we can assign a property in order to let the font display the right shape, because this is the only way to see this shape. Therefore, this language property, is only useful when the font has different shapes for this language. For example, I believe it's useless for English or French (all our characters have a unique code and shape). That's why I said "we could have a parameter saying what are our preferred languages". And that's why saying "The font selection dialog includes language indications." is partially wrong, because it is not the purpose of this property. When we observe the Special Character dialogbox, we see: - the textbox for character research - the combobox for the font list - the combobox for the block of characters For example, if I select the block cyrillic, then I go into the combobox for the font list, I can go up and down, and try to see which font can display this block correctly. But this system works only one block at a time, and it's long to process manually, and we must memorize all the results... I'm not Rain Man guys... What we can conclude for the Character dialogbox: it miss a filter with the block of characters (or languages) we want to use. Eyal already said it with her words, maybe it is more clear now. Maybe this filter could be in the options like I suggested (we select the languages, or the blocks we want to use), maybe it could be directly before the list of fonts (but I can't see something simple, because only one language is a problem in my opinion). For comparaison, we can already see this filtering system in https://fonts.google.com we choose the writing system, then the language, then the filter displays only the fonts compatibles. The problem here is that we can only select one language. I prefer my suggestion because I propose to select all the languages (or block) we want to use. Then the filter displays the fonts compatible or not. We can have different options: - exclusive filter (a font must have compatibility with all selected languages) - non exclusive filter (a font must have at least one selected languages) and the most important: it is written next to the name of the font (full compatibility, or only this language). And as the character set is not the same for different language, that's why a multilanguage lorem ipsum is important (but I know, I can define it myself in the document before I open the dialogbox) if we want to see the result in advance. I hope it helps.
I confirm this enhancement is useful because this other enhancement has not been inmplemented yet: Bug 88416 - UI: Allow hiding fonts from font drop down list in options dialog For example, with the manual work we can already do in order to select which fonts are suitable, we can unsintall the fonts not suitables. Unfortunately, not all fonts can be unsinstalled, that's why windows allows to mask them (in the windows explorer). But Office doesn't care and displays all the masked fonts! With the filter system implemented in LibreOffice, we can make a great improvement! Thanks in advance.
Here's a thought, don't know if it is feasible. For UX-advise and any devs that have comment. Extend the SCD framework to implement font filtering by Unicode block coverage? First clear the active font and load a full list of Unicode character blocks BMP & SMP. Then let users make active selection(s) from the Unicode block listing. Filter for fonts with selected coverage and display just those in the font combobox listing? Use only that filtered list of fonts across the other instances of the font combobox listing--until changed/cleared via the SCD, and some reset elsewhere like on the Character... dialog? Of course, the Unicode block would not be a translatable (Unicode is not), but it would provide a functional UI for the requested font filtering by locale/script.
(In reply to V Stuart Foote from comment #32) > Then let users make active selection(s) While that may be an additional, secondary, possibility for advanced users to play with - we need a decent default mechanism, without the user having made any changes. Remember most users aren't proficient enough to play with Unicode ranges for definitions of what to filter. To be honest, there is a fine point here I/we have not considered so far, which is that range coverage is not a binary thing. For example, suppose a font contains all the Hebrew letters, but no diacritics; it can still be used for documents which don't use diacritics (and most, indeed, don't). Or - letters and diacritics but no cantillation marks - that covers 99.9% of documents, but still isn't full coverage. Or - coverage/non-coverage of digits - where the fallback might be to the Western language group digits, or to some other fallback font. And I understand (thanks Jonathan) that CJK fonts never cover _everything_ possible - and there's even an OpenType limitation of 65Ki glyphs per font, while there are more glyphs than that to cover if you include all traditional forms and variants. So, we may need some higher-level configuration of what to consider as "covering" (e.g. "Require digits Y/N", "Require diacritics Y/N") - which might even differ among some of the languages. Alternatively, we could have leeway for partial-coverage, with some kind of small info widget opening a pop-up with some coverage explanation. ... but at the very least, there's the "easy" part, which is filtering (or marking) fonts which clearly don't cover, e.g. are missing letters or common ideograms. > Extend the SCD framework to implement font filtering by Unicode block > coverage? Would this really impact typeface selection combo-boxes? Or - are you suggesting to "rewire" the combo-boxes that way? Hmm... are you sure that doesn't introduce too much of a danger of messing things up?
(In reply to Eyal Rozenberg from comment #33) > > Extend the SCD framework to implement font filtering by Unicode block > > coverage? > > Would this really impact typeface selection combo-boxes? Or - are you > suggesting to "rewire" the combo-boxes that way? Hmm... are you sure that > doesn't introduce too much of a danger of messing things up? Yes, expect the SCD choices/settings would propagate to the combo-boxes for typeface selection. No more risk than trying to overload ICU libs with more granular typeface selection based on a font's provided Unicode glyph coverage. KISS suggests starting with the SCD's framework of positioning character chart by Unicode block, and making that query enabled for typeface listing. Once that listbox is populated in SCD propagate to the other typeface selection combobox(s) across the UI.
I'm rephrasing the title to focus on the typical user's perspective rather than the power user who is interested in Unicode range coverage. (And of course I should have opened this bug with a comment from that perspective...)
Filtering is IMO not entirely correct approach; but when the language is given (which must then always accompany places where the font list is given - e.g., language selection would appear in Special Characters dialog) - the list could be split into e.g. top part with "fonts covering the (relevant part of) Unicode range", and bottom part (possibly after a separator) with fonts that don't, preferably with a icon which would contain the language name (e.g., BUL) striken out, and a tooltip telling that it doesn't support the chosen language; or an infobar (including the dialogs, like the warnings we provide elsewhere) about the fact that the chosen font doesn't include the characters needed.
We discussed the topic in the design meeting. The use case is to understand what fonts cover the glyphs of a language. Eyal wrote a nice summary at https://listarchives.libreoffice.org/global/design/2024/msg00117.html. It needs clarification whether the font a) needs to be chosen before typing, in this case we have no information what about the user's intention and need different methods while b) applying a font to a selection could analyze the used glyphs in the background. We pondered over the idea with the "live preview", which is working in Writer too. A checkbox "[ ] Fonts covering the selection" in the character dialog could support the selection of an appropriate font but wont cover use case b). This filtering could also be done after typing and tag fonts that can be used, eg showing a checkmark next to the name. Some cornercases like multi-selection needs to be addressed.
(In reply to Heiko Tietze from comment #37) > We pondered over the idea with the "live preview", which is working in > Writer too. Just let me repeat my previous comment (22) and add some details. I hope it will help. "Only Calc has this live preview feature with the combobox. Doesn't work with Writer." This feature works directly with the combobox in the toolbar in Calc, but not in Writer. In another history of comments, it was clearly said that Writer will not have this function (for technical reasons). This is still the case in Version: 24.8.1.2 (X86_64) As there is also two bugs with calc's "live preview" with the combobox, I don't recommend to implement it in writer before it is fixed in calc. See the bug 144151 for understanding the problems generated by this function: - delay with specific files (not only huge file, but also specific file like the small one described in the bug 161898). - systematic recalculation when we move from cell to cell if we don't know how to disable the bug. So imagine in the Writer, after each move of the cursor, we would have to wait for the recalculation of all the document! Maybe you was refering to the "render" function or "lorem ipsum" textbox in the character dialogbox? It works as a preview of the selected text with some "unconvenient choices": - in Writer and Calc, the different selected lines are concatenated on one single line. - the rendering textbox displays the text centered. Fine if the selected text is short, but when it's too long, the text is cut on the left and on the right. There is no automatic EOF/CR, nor scrollbars. Maybe it seems a luxuous wish, but let me explain: if I want to control the available characters, I have to write my special character list for all languages I use (one line per alphabet). Therefore, if the lorem ipsum cut half of my list, and the left or right parts of the list, I cannot see if the font is compatible with all my character needs before validating the change. I can try to see all characters by decreasing the size of the font, but the details of small characters are very difficult to see. Why the textbox and dialog box cannot be extended and manage EOF? Note 1, about case a and b: I don't really understand the problematic. Normally, the language is associated (technically set) with the text even if we don't type anything. Indeed, when we want to set the language before typing (menu tools>language), it opens the Character dialogbox, and we can select another language (or let the default one), and after we can try the different fonts available. Even if no text is selected or typed before, the "lorem ipsum" is the default rendered text. Maybe as an option we could imagine to display in a second tab (behind lorem ipsum) the full alphabet and specific characters for the selected language? therefore libreoffice needs to have a list of these characters for each language. Therefore it would be possible to have either "[ ] Fonts covering the selected text" or "[ ] Fonts covering the selected language". I have previously proposed to have a parameter where we can set our personalized "lorem ipsum" or "character list", and all the languages we use, in order to identify the compatible fonts in the list of fonts (without depending of the selected text or the not already typed text). In my opinion, it is an option that allows to calculate everything in advance instead of repeating the process each time the dialogbox is opened. Note 2, about filtering: it's really boring to see all the useless fonts we cannot uninstall (protected by microsoft windows) and hide (even if windows allows it in the file explorer, because libreoffice doesn't care). A checkbox to hide them in libreoffice will make the font list lighter for the user and for the calculations behind the dialogbox.
(In reply to Manu from comment #38) > Maybe you was refering to the "render" function or "lorem ipsum" textbox in > the character dialogbox? Yes, and I see no live preview in the toolbar/sidebar dropdown (on Linux). > Note 1, about case a and b: I don't really understand the problematic. Different workflow require different UIs. Imagine to type a character via alt+numpad. If you need to understand the font coverage before text is written, the live preview approach is pointless. > I have previously proposed to have a parameter where we can set our > personalized "lorem ipsum"... Sounds okay to me. > Note 2, about filtering: it's really boring to see all the useless fonts we > cannot uninstall (protected by microsoft windows) and hide (even if windows > allows it in the file explorer, because libreoffice doesn't care). A > checkbox to hide them in libreoffice will make the font list lighter for the > user and for the calculations behind the dialogbox. KDE allows to disable fonts (I use to do it with 99% of Noto), Windows probably too. I'm against introducing square wheels.
(In reply to Heiko Tietze from comment #39) > > Note 2, about filtering: it's really boring to see all the useless fonts we > > cannot uninstall (protected by microsoft windows) and hide (even if windows > > allows it in the file explorer, because libreoffice doesn't care). A > > checkbox to hide them in libreoffice will make the font list lighter for the > > user and for the calculations behind the dialogbox. > KDE allows to disable fonts (I use to do it with 99% of Noto), Windows > probably too. I'm against introducing square wheels. I confirm: Yes, Windows allows to (un)mask fonts when you browse the font directory. No, LibreOffice under Windows displays all fonts, unmasked or masked. That's why there is this still running Bug 88416 - UI: Allow hiding fonts from font drop down list in options dialog So, you are lucky if LibreOffice doesn't display the disabled fonts in KDE! :)
(In reply to Manu from comment #40) > Yes, Windows allows to (un)mask fonts when you browse the font directory. > No, LibreOffice under Windows displays all fonts, unmasked or masked. > That's why there is this still running Bug 88416 - UI: Allow hiding fonts > from font drop down list in options dialog But bug 88416 is unrelated to the other bug, that LibreOffice ignores the system setting on Windows. Do you have a reference for that latter one?
(In reply to Mike Kaganski from comment #41) > (In reply to Manu from comment #40) > > Yes, Windows allows to (un)mask fonts when you browse the font directory. > > No, LibreOffice under Windows displays all fonts, unmasked or masked. > > That's why there is this still running Bug 88416 - UI: Allow hiding fonts > > from font drop down list in options dialog > > But bug 88416 is unrelated to the other bug, that LibreOffice ignores the > system setting on Windows. Do you have a reference for that latter one? I'm sorry, when I wanted to create the bug report, I found this one, and added my comments in order to avoid a duplicate. In my opinion, it describes the same need: Comment #1: "I would like to have the ability to hide fonts/font families from the font list in LibreOffice, without removing the fonts from my system. This option could be integrated into the LibreOffice options GUI." The creator of this report proposed "For the implementation, I was thinking about a ListBox." But Heiko said "KDE allows to disable fonts (I use to do it with 99% of Noto), Windows probably too. I'm against introducing square wheels." Me too, I prefer a same solution for the same problem. So the best solution is to do the same as in Linux version, and the needs explained in the bug 88416 will be fullfilled. We still can add a parameter in the option: [ ] Hide system masked fonts from all font lists (or detail by font list type).
(In reply to Mike Kaganski from comment #36) > Filtering is IMO not entirely correct approach etc. List splitting is a good solution. +---------------------+ | Covering Font 1 |V| +---------------------+ | Covering Font 2 | | Covering Font 3 | | ----------------- | | Non-covering font 1 | | Non-covering font 2 | | Non-covering font 3 | | Non-covering font 4 | | (etc. etc.) | +---------------------+ Its benefits: * Can "override" LibreOffice' heuristic if you disagree with it, without the hassle of leaving the drop-down list and figuring out where to change the settings. * With this in place, we can forego a toggle control in the font selection dialog for Filtered/Unfiltered. (Although I would still keep one in Tools | Options somewhere.) Its detriments: * You can forget / lose track of whether you're in the "covering" part of the list of fonts or the "non-covering" part. * A user may fail to understand/notice/realize that there is a partition, or what it means. * Doesn't whittle down the number of items on the list * Cannot express the degree-of-coverage (like a partial gray-out could) So, the detriments are mostly minor and the benefits are significant. I therefore change my mind and currently believe this is the better solution.
(In reply to Eyal Rozenberg from comment #43) > List splitting is a good solution. > Its detriments: > * Cannot express the degree-of-coverage (like a partial gray-out could) > Maybe it's possible to express the degree of coverage. I don't think the "list splitting" solution cannot do it. Moreover, it could be done independently of the selected solution. For example in font Liberation Serif we have this covering per block: Latin de base U+0000-U+007F 95/128 Latin-1, supplément U+0080-U+00FF 96/128 Latin étendu A U+0100-U+017F 128/128 Latin étendu B U+0180-U+024F 208/208 Alphabet phonétique international (API) U+0250-U+02AF 96/96 modificateurs phonétiques chassants U+02B0-U+02FF 80/80 Diacritiques U+0300-U+036F 112/112 Grec et Copte U+0370-U+03FF 127/135 Cyrillique U+0400-U+04FF 256/256 supplément cyrillique U+0500-U+052F 24/48 Hébreu U+0590-U+05FF 87/88 etc. In the fonts parameters, maybe we could add a table where the user can set an identification letter per block: Table « Display covering of these code pages by identification letter » : [L] Latin de base U+0000-U+007F /128 [L] Latin-1, supplément U+0080-U+00FF /128 [L] Latin étendu A U+0100-U+017F /128 [L] Latin étendu B U+0180-U+024F /208 [ ] Alphabet phonétique international (API) U+0250-U+02AF /96 [L] modificateurs phonétiques chassants U+02B0-U+02FF /80 [L] Diacritiques U+0300-U+036F /112 [G] Grec et Copte U+0370-U+03FF /135 [C] Cyrillique U+0400-U+04FF /256 [C] supplément cyrillique U+0500-U+052F /48 [H] Hébreu U+0590-U+05FF /88 etc. Therefore for the font Liberation Serif, we can calculate : [L] = 95/128 + 96/128 + 128/128 + 208/208 + 80/80 + 112/112 = 632 / 784 = 0,81 [G] = 127/135 = 0,94 [C] = 256/256 + 24/48 = 280 / 304 = 0,92 [H] = 87/88 = 0,98 (blocks without letter are ignored in the calculation) And with Superscript numbers (º¹²³⁴⁵⁶⁷⁸⁹) or Subscript (₀₁₂₃₄₅₆₇₈₉) we can add the covering before the name of the font (only the first decimal digit is enough) in order to compare easily the different lines: L⁸G⁹C⁹H⁹ Liberation Serif Possible other symbols if you don’t like numbers: ◌ not covered ◔ partially (25 %) ◑ (partially 50%) ◕ (partially 75%) ● fully covered It takes a minimal size, and the user can choose the code pages he want to see and regroup them in a unique identifier. And if the user can order the identifiers in the table, we could also imagine the list to be ordered descending, showing the most covering font first. And if a normal user want to ignore this, no problem and the font list stays like as before. Another side of the story, is the problem of shapes. For example with bulgarian, it must have a different italic shape than russian (see the table with 3 colors in https://en.wikipedia.org/wiki/Bulgarian_alphabet ) Therefore Liberation Serif is not fully compliant, even when we set the language to Bulgarian. Maybe it would be to heavy to add this kind of information in the program code. Maybe it would be simpler to only indicate next to the selected langage combobox, that there is 0 or « n » specific shapes for this language in this font ?
(In reply to Manu from comment #44) I'll start by saying that, if we are tending to accept the list partition solution, then - we should probably differ the discussion of partial-coverage-indication to a later time and a separate bug, because we can start with something simpler (and a "relaxed" heuristic), then refine it later. Anyway, > For example in font Liberation Serif we have this covering per block: > ... > In the fonts parameters, maybe we could add a table where the user can set > an identification letter per block: The thing is, block coverage rate is not a good enough indicator of language glyph coverage, for some written languages. Just as an example: A font could cover all Hebrew cantillation marks, but fail to cover final letter forms (םןףךץ) or digits (1234567890). It covers more, but is much less usable. > Possible other symbols if you don’t like numbers: > ◌ not covered ◔ partially (25 %) ◑ (partially 50%) > ◕ (partially 75%) ● fully covered That's an interesting suggestion graphically - regardless of how we actually evaluate coverage. But it would be at least challenging, if not controvertial, to "stick" something like this onto the list of fonts. I still think a good starting point would be just the partition Mike suggested - a rather minimal change UI-wise, with a lot of "bang for the buck".
I see the choice to sort the font list in 2 groups. Do you confirm each time the user select a new language, then the font list must be reanalyzed and repopulated? therefore, in a multilanguage document, each time I open the dialogbox characters, it means the font list is repopulated according to the language of the selected text? how much time and delay for the user if the computer is slow? is there a possibility to disable this "work" if it is too slow or unconfortable? At this time of the discussion, I don't understand what is a "relax heuristic" and the "easy part" when the rule is "filtering (or marking) fonts which clearly don't cover, e.g. are missing letters". Which rule or source of information define the missing letters or the mandatory letters? does the user have the choice to include the diacritics? ancient letters, special numbers, phonetics, and so on? or AT LEAST, can the user just write in a textbox a list of characters he would like to have in all the fonts whatever the language and the "easy relax method"? For example in French, diacritics are needed in minuscules AND majuscules, while in German, there is a system for writing in capitals without diacritics. In French a full capital text could be accepted without diacritics (for "low quality" titles or flyers), but it is not the norm, therefore it is not expected to see a font without diacritics in the first group.
(In reply to Manu from comment #46) > Do you I'm guessing you mean me, since I reported the bug, but it's good to always mention the name since other people comment as wlll. > Do you confirm each time the user select a new language, then the font list > must be reanalyzed and repopulated? No, it doesn't. The analysis and partition of the list only happens once (once per LO session or even less than that if we persist the partition). Also, to the extent that we rely on the font itself to tell us which language it supports, there's no analysis to begin with. As for the re-population of the GUI control on the toolbar or sidebar - that happens now whenever one switches language group; I presume our code clears the control, then loads a list from somewhere in memory. > At this time of the discussion, I don't understand what is a "relax > heuristic"... This will be different for different languages. But the general point is: It is not very difficult (though not entirely trivial either) to devise a criterion for a font _completely_ covering a language's glyphs. Just mark all the glyphs that can be used in that language, and if the font has them, then it's good. But - many fonts are pretty usable, but don't meet this criteria. You gave the example for French, of fonts without accented majuscules. So, either the developers, or preferably, the French language community, needs to make the call whether to include such fonts in the list of fonts-for-French. And similar decisions need to be made for other languages. Beyond that, there's the question of individual missing glyphs. Suppose a font for German has everything except for, say, the glyph for double-s. And let's even say it exists for regular weight, but missing for bold. Do we say this typeface doesn't support German? Maybe. We need to set some policy. While we don't have a policy for a language, we should fall back on font self-reporting or per-language Unicode ranges with strict coverage requirement.
(In reply to Eyal Rozenberg from comment #47) > (In reply to Manu from comment #46) > > Do you > I'm guessing you mean me, since I reported the bug, but it's good to always > mention the name since other people comment as wlll. Sorry, I will be more explicit: "Do you all" At this time of the long discussion, I would like to understand the solution understood by everyone. There was many changes, and even if your (Eyal) viewpoint is valuable, I think other's viewpoints are important, especially the one who will develop the program code. I can understand that individually we like to use a trial-and-error (heuristic) method. But in a program code, generally, it does not give good results... In my opinion, libreoffice is an openproject, therefore human resources are only voluntary resources and must be used wisely. If we ask for something, and the results is not efficient, and must be changed again, that is not pleasant for everyone. And how to change the rules efficiently if they are not clear? > > Do you confirm each time the user select a new language, then the font list > > must be reanalyzed and repopulated? > > No, it doesn't. The analysis and partition of the list only happens once > (once per LO session or even less than that if we persist the partition). I still don't understand. For example I set english, then the list would be: group1: fontEN1 fontEN2 group2: fontCYR1 fontCYR2 Later, I set bulgarian, then the list would be: group1: fontCYR1 fontCYR2 group2: fontEN1 fontEN2 Therefore, even if the program code analyzed the font files one time and created a table of font-language compatibilities, the program code needs to send a query to this table and to repopulate the combobox after we change the language, isn't it? therefore the "font list" for the combobox is reanalyzed (what should be listed) and the combobox is repopulated with the new list. > Also, to the extent that we rely on the font itself to tell us which > language it supports, there's no analysis to begin with. In my knowledge, it is not the case, because the information is not in the format file, but maybe there is new enhancements I don't know? > As for the re-population of the GUI control on the toolbar or sidebar - that > happens now whenever one switches language group; I presume our code clears > the control, then loads a list from somewhere in memory. I thought only the dialogbox Characters was modified. Now I understand also the toolbar and sidebar will be modified. For example, in a multilanguage document with english, bulgarian, and greek, it means each time I move the cursor in a different paragraph with a different language, then the list in the toolbar and in the sidebar is refreshed? I asked for the time of process and if it can be disabled for the dialogbox. Now I ask the same for the toolbar and the sidebar. > > At this time of the discussion, I don't understand what is a "relax > > heuristic"... > This will be different for different languages. But the general point is: It > is not very difficult (though not entirely trivial either) to devise a > criterion for a font _completely_ covering a language's glyphs. Just mark > all the glyphs that can be used in that language, and if the font has them, > then it's good. But - many fonts are pretty usable, but don't meet this > criteria. You gave the example for French, of fonts without accented > majuscules. So, either the developers, or preferably, the French language > community, needs to make the call whether to include such fonts in the list > of fonts-for-French. And similar decisions need to be made for other > languages. Beyond that, there's the question of individual missing glyphs. > Suppose a font for German has everything except for, say, the glyph for > double-s. And let's even say it exists for regular weight, but missing for > bold. Do we say this typeface doesn't support German? Maybe. We need to set > some policy. > While we don't have a policy for a language, we should fall back on font > self-reporting or per-language Unicode ranges with strict coverage > requirement. I dont feel this is so easy if "the developers, or preferably, the French language community, needs to make the call whether to include such fonts in the list of fonts-for-French." It means there will be a full project in order to identify the rules for all languages... therefore if we want to implement this solution, there will be a lot of updates in a short and long term. My suggestion of a personalized table with unicode ranges is also interesting, because it's clear and it's easy to adapt the ranges for user's needs without new delopment, and it doesn't request to update the font list in dialogbox/toolbar/sidebar each time the text language is modified. But if we want more simple, there is the character list the user set in a textbox. For example, if I set ÇÑÃÕÅßIJŐĞŊŮĆŞΞѢЁЪЂ then the fonts that have these letters could be potentially used for French, Spanish, Portugish, Nordic, German, Netherland, Hungarian, Turkish, Baltic, Slavic, Polish, Romanian, Grec, Russian, Bulgarian, Serbian languages. As a user, this is very simple, I know I want to use this alphabet, I take one letter and put it in this textbox. I want to use two alphabets, I add another letter. I want the special ancient letter, I add it. Nothing complicated. I also suggested some improvements in the lorem ipsum textbox, and even the creation of an alphabet textbox and a personalized lorem ipsum because of different shape problems. So if the team doesn't like these suggestions, and if the time of processing is not a problem, maybe it will be more efficient to use the work of this other project shaperglot? I don't know how many languages they have defined, but at least, they clearly understand the problematic with a clear solution. https://github.com/googlefonts/shaperglot Thanks all for your next comments.
(In reply to Manu from comment #48) > There was many changes, and even if your (Eyal) viewpoint is valuable, I > think other's viewpoints are important, especially the one who will develop > the program code. Yes, certainly, I thought you were talking to me... of course it's in no way my call just because I reported. > https://github.com/googlefonts/shaperglot Oh, that looks really useful! Thanks, Manu! Whether we use that library itself or not, the ideas are certainly relevant, and the heuristic they choose (the examination of aspects of "behavior"). > I can understand that individually we like to use a trial-and-error > (heuristic) method. But in a program code, generally, it does not give good > results... Remember that the other fonts are still all there on the list below the partition. So if our heuristic is not good enough, you can still use whichever font you like. Also, many features or behaviors in LO are not perfect when first released, and feedback from users makes them improve in later releases. Of course we need something "decent" enough to actually be committed in the first place. > For example I set english, then the list would be: > group1: fontEN1 fontEN2 > group2: fontCYR1 fontCYR2 > Later, I set bulgarian, then the list would be: > group1: fontCYR1 fontCYR2 > group2: fontEN1 fontEN2 Yes. But even today, if you switch from English to, say, Hindi - the font list changes, and the combo-box is repopulated. > Therefore, even if the program code analyzed the font files one time and > created a table of font-language compatibilities, the program code needs to > send a query to this table and to repopulate the combobox after we change > the language, isn't it? Well, the query results for different languages are - one would assume - already stored in memory, in some form of another. That is, there will not be a need to run the nested loop "for all fonts for all language glyphs do make sure the glyph is present". > For example, in a multilanguage document with english, bulgarian, and greek, > it means each time I move the cursor in a different paragraph with a > different language, then the list in the toolbar and in the sidebar is > refreshed? Possibly, but not necessarily. It is enough to set the selected item only; and delay the repartitioning until you actually pull-down the list using the arrow button. Another possibility is to have multiple sets of controls, with all being hidden except the ones for the current language. But let the developers tell us what happens in practice. > I dont feel this is so easy if "the developers, or preferably, the French > language community, needs to make the call whether to include such fonts in > the list of fonts-for-French." > It means there will be a full project in order to identify the rules for all > languages... therefore if we want to implement this solution, there will be > a lot of updates in a short and long term. It will be a project, yes. But - not a long-term one. It should involve approaching the different LO language teams: https://wiki.documentfoundation.org/Language_Teams and asking for the input of each one on this matter. Such input will allow switching the criterion for the relevant language from the fall-back (font self-reported, Known Unicode range covering status). Over time, there will probably be some bug reports about the list choices - the handling of which will allow us to refine the partition heuristic further. > But if we want more simple, there is the character list the user set in a > textbox. Assume the user has not typed in any characters; they are just about to do so. Or they are editing a style. What would you use then? > Nothing complicated. That suggestion _will_ actually require some dynamic recomputation (especially if I selected a lot of text on multiple pages); and while it might be simpler to implement and does not require familiarity with languages - it is _quite_ complicated for the user, who will have absolutely no idea what's going on with the partitioned list, which will keep changing for them.
(In reply to Eyal Rozenberg from comment #49) > Also, many features or behaviors in LO are not > perfect when first released, and feedback from users makes them improve in > later releases. Of course we need something "decent" enough to actually be > committed in the first place. I would like this to be true, but there are other examples of bugs that have been created by an improvement (real-time preview in calc for example), and when a performance problem appears, we cannot disable the improvement, and no correction is made because it is considered specific to certain documents. At least don't forget a new parameter to disable the new system, because we never know what the user will encounter in reality. > > But if we want more simple, there is the character list the user set in a > > textbox. > Assume the user has not typed in any characters; they are just about to do > so. Or they are editing a style. What would you use then? Your understanding is not what I suggest. In the new system, we need a full specifications saying which character codes are associated with each language. That's a long work to do, and it will be certainly constantly criticized by a user who want more or differently. With my suggestion, the user write himself the list of characters that represent his needs. These characters are easy to find: on the keyboard, in the special character dialogbox, in wikipedia (alphabet of the targeted language), on unicode website. If you want, in the parameters, fonts paragraph, we could see: [X] activate the new font list presentation (disabled = standard A-Z list) (Y) first group with fonts that support all these characters: __________ (Z) first group with fonts that support the select language So when X is enabled, we can select the method: either Y or Z. In the two cases Y or Z, the result will be a font list with 2 groups. For example if the textbox is ÇÑÃÕÅßIJŐĞŊŮĆŞΞѢЁЪЂ we could see: --- fonts supporting user's choice fontEUROPE fontCYR --- other fonts fontEN(only) fontGRE(only) fontEURnotCYR fontCYRnotEUROPE With choice Y, we can set many different alphabets, and with choice Z the method is user-friendly. For example: --- fonts supporting "language" fontHEB --- other fonts fontEN(only) fontGRE(only) fontCYR(only) fontOTHER(not HEB) > That suggestion _will_ actually require some dynamic recomputation > (especially if I selected a lot of text on multiple pages); and while it > might be simpler to implement and does not require familiarity with > languages - it is _quite_ complicated for the user, who will have absolutely > no idea what's going on with the partitioned list, which will keep changing > for them. What you explain, the selection of text, is what is already in function. The selected text is used for the lorem ipsum in the textbox for rendering a preview before validating the Characters dialogbox. At the present moment, only one line is displayed. As the new enhancement (list partition) will change the dialogbox, I suggested to add a few more lines (maybe 3 or 5) in order to see more in the preview, and extensibility of the dialogbox in order to see really well the shapes without the need of a microscope (see my other comment above). I hope it helps.
Determining what languages a font supports is tricky, since defining what characters are required to support a language does not always have a single answer. Some system APIs can provide a list of languages a font supports (e.g. FontConfig on Linux), which would allow us to offload this question, but such APIs might not be available for all platforms and if they are they might not give consistent answers (FontConfig might say a font supports Arabic, CoreText might say it does not, so we get different list filtering in different platforms). Unicode’s CLDR has language data that includes exemplar characters (e.g. https://github.com/unicode-org/cldr/blob/main/common/main/ar.xml#L1231C4-L1231C22), so that is might be something we can use. Fonts can have a “meta” table that declares what language they support and what languages they are designed for https://learn.microsoft.com/en-us/typography/opentype/spec/meta, though not many fonts include it.
(In reply to خالد حسني from comment #51) > Unicode’s CLDR has language data that includes exemplar characters etc. Agree that this is a decent candidate for a default heuristic for all languages (which I mentioned in comment 47), to start with; and by discussion with language communities we can refine/modify it for some languages if necessary.